Now it’s official: Corona, the reimplementation of Cocoon which is currently available in the Cocoon whiteboard has been accepted by the Cocoon PMC and will become Apache Cocoon 3, the next major version of Cocoon!
When Steven and I started with the reimplementation, we had two main goals:
- Have a clean and simple Java Pipeline API that isn’t bound to any particular content (SAX, StAX etc).
- Make Cocoon 3 a great fundament for RESTful webservices.
These goals are more focused than the goals of Cocoon 2 because, as Stefano pointed out in [RT] Is Cocoon Obsolete, things have changed a lot and web applications are developed very differently than 10 or even 3 years ago:
- RubyOnRails has taught us that simple things should become simple again and many things in the Java world feel like Cargo Cult programming.
- Apart from Flash, using the Mozilla platform directly, the heavy Java applets or the propriatory ActiveX components, other alternatives like Silverlight and JavaFX become available.
- Apache Wicket successfully applies object-oriented sotware development principles on web applications.
- Many web applications are mash-ups of many internally and externally available web services (Google Maps, Flickr, YouTube etc.)
Cocoon 3 has been optimized to live in such a changed world:
- Cocoon 3 doesn’t provide a stateful forms framework. Nowadays, you either develop a rich browser client or you use a really advanced server-side frameworks like Apache Wicket or GWT which hide a lot of the complexity that comes with web applications.
This polarization will make many established web frameworks like JSF, Struts, Spring WebFlow becoming obsolete if they don’t decide for one of the two paths.
- XML, XHTML and HTML5 are (still) important technologies in the development of web applications. Cocoon 3 that provides some default implementations of SAX-based components, still has a strong point when it comes to the generation, transformation and serialization of XML.
- Cocoon 3 has a layered architecture: The fundament is a pipeline module that doesn’t have any dependencies except Java 5 and Apache Commons Logging. On top of it there is a sitemap language interpreter. The current implementation uses Spring 2.5 but this dependency is hidden behind an interface and the implementation is only one! class. This means that you can easily integrate the pipeline and/or the sitemap module into your own Java application.
As you might have noticed, there is no dependency on the Java Servlet API so far. If you want to run Cocoon 3 as web application, there is a third module that provides a servlet for that purpose.
Inspired by Vadim’s last year’s Cocoon GetTogether presentation, I created a simple Maven module that demonstrates how Cocoon 2.2 can be used in classic mode. Classic mode means that Cocoon 2.2 is used without the Servlet-Service Framework or custom blocks. Both are great features but they are not needed in every case, e.g. if you want a simple migration for Cocoon 2.1 to 2.2 you might not want to introduce blocks and servlet services from the beginning.
The sample code is available in the Cocoon whiteboard. Check it out and then you can use it e.g. by mvn install jetty:run or by mvn eclipse:eclipse and loading it into your Eclipse workspace and use the Run-Jetty-Run plugin. This option also gives you automatic reloading of all resources but not of Java classes though.
See the Spring Configurator docs if you want to know where you can put your custom Spring beans, Avalon components, properties or how logging works.
The sample only uses the Template block which works for me as expected. but I haven’t tested with other blocks so far.
Finally, if you are new to Cocoon, I strongly recommend getting familiar with blocks and serlvet-services. Both will help you to moduliarize a (Cocoon) web application. The Cocoon 2.2 tutorials and the available screencast will be a good start.
After too many years of development, Apache Cocoon 2.2.0 finally arrived. As I wrote in Cocoon 2.2: A new architecture a lot of things have improved. There is also a Getting Started guide that helps you with you first steps. Have fun!
The most famous concept of Cocoon is pipelines. The first component of a pipeline generates a stream that is passed to components that can modify this stream and finally you get the result, e.g. a java.io.OutputStream. I guess that developers have wished to have a library that makes this easy:
Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new URLGenerator(new URL("/home/reinhard/file.xml"))); pipeline.addComponent(new XSLTTransformer(new URL("/home/reinhard/stylesheet.xslt"))); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(System.out);
The brave of us have tried to make this code run with Cocoon 2.x. But as far as I know all attempts have failed because Cocoon was designed to a web application and publishing framework. And even if you make this code run, you get a huge stack of dependencies that you have to add to your application.
I think that this has to change. We should develop Cocoon in a bottom-up style: For this a pipeline API is the natural first step. After that we can put all the other stuff like sitemap language interpreters on top of it.
Steven Dolg, one of my colleagues at Indoqa started to reimplement Cocoon based on a layered design that has a pipeline API as its basic layer. You can already checkout working code. Further goals are content-based routing in pipelines and supporting pipeline fragements. By the way, the pipeline API that we want to design shouldn’t impose any limitations on the content that flows between its components. One of the things that I’ve missed desperatly is pipelines that support pull parsing.
Recently there was an article on TheServerSide: JavaRebel Brings Class Reloading to Java. Unfortunatly we (Apache Cocoon) haven’t talked much about it but this feature has already been available for Cocoon for quite some time. Thanks to Jakarta Commons JCI the hard work of class reloading is already done. JCI provides a reloading classloader which detects all changes in classes that it monitors and automatically reloads them. Unlike HotSwap this also works on adding new classes, changing interfaces, removing methods etc.
For all Cocoon 2.2 users this feature comes for free with zero configuration (if you use the archetype which already configures the plugin for you). Use the Cocoon Maven Plugin to run your Cocoon block (a Cocoon block is the modularization unit of Cocoon applications and mostly specifying a standard directory structure) and all changes to your Java classes will take effect immediatly. The Maven plugin also takes care that the Spring application context gets reloaded if necessary (don’t know if the JavaRebel library can do this …) because for singletons it isn’t enough to change the class definition provided by the classloader. Spring wouldn’t change the object that it is using.
If you want to find out more about this really cool stuff, follow the “Your first Cocoon application” tutorial, then start Eclipse and load the created project and change the Spring bean.
After two interesting Hackathon days, Friday was reserved for the ‘official’ program. After doing my keynote “Cocoon 2.2 – A long Journey“, Francesco Chicchiriccò did a presentation “Hands on Cocoon“. He was talking about a lot of projects that he implemented based on Cocoon. Quite impressive and showed me again how powerful Cocoon is.
Jasha Joachimsthal continued with “Create your website in 5 minutes with the Cocoon Project Wizard“. Since he was talking about Cocoon 2.1, it was interessting to listen to his analysis of what needs to be improved and compare it with that what Cocoon 2.2 offers. I’m happy to say that he will find a lot of cool stuff and that we have established contracts on things that have been unspecified yet.
The next one was Bertrand Delacretaz with “XSLT and XPath – without the pain!“. Since XSLT is heavily used in Cocoon applications I don’t think that people heard a lot of new things. Though the interesting thing was how Bertrand structured his presentation. I’m sure that this will help many of us who do trainings on XSLT to get ideas how to make it easier for newbies to understand this different programming language.
Vadim Gritsenko showed how you can use Cocoon 2.2 the classic way. Of course that’s not recommended for new projects, but if you have an already existing Cocoon 2.1 application and want to migrate to the latest and greatest stuff, then his guide is more than helpful. I hope that he finds some time to start off writing a migration guide.
After having a great meal next to the hippos and elephants (the GT took place in a Zoo!), Carsten Ziegeler and Bertrand Delacretaz gave a presentation titled “Bye bye Avalon: an introduction to OSGi“. They explained the motivation behind component based applications and how they devloped over time. Finally the closed the session with a simple OSGi example.
For some of us a deja vu, Daniel Fagerstrom was talking (again) about Cocoon OSGi. After a first attempt two years ago he is working again on this stuff. Thanks to Apache Felix and the Spring-OSGi subproject he has already come rather far. The way things are going his work can be merged into trunk by the end of the year. But don’t be worried about having to learn all this new stuff when you want to work with Cocoon 2.2. We will still fully support the conventional way of using only Spring as sole container too.
The next speaker was Lars Trieloff talking about “Mindquarry Collaboration Software“. Mindquarry uses a huge stack of technologies (SVN, Jackrabitt, Dojo, Jackrabitt, SubethaSMTP, etc.) and Cocoon is playing the role of clueing all the things together. The most interesting parts of his presentations were his lessons learned. As it shows the devil is very often in the details. When working on an architecture it really pays off if you are well acquainted with the technologies that you pull together.
Jeremy Quinn did the last presentation of the day talking titled “Break my site: Practical Stress Testing and Tuning of Cocoon Applications“. The information he gave wasn’t in particular Cocoon specific though useful for everybody who builds web applications.
Find most of the presentations available as downloads at the Cocoon Wiki.
This year I had the honour of doing my second keynote presentation for a Cocoon GetTogether. On popular demand I was talking about Cocoon 2.2 and the developer’s motivations behind all the new stuff:
- Spring 2.0 as component container
- the Servlet-Service framework that establishes contracts in modular web applications
(no dependency on Cocoon core – easily resuseable outside the Cocoon world)
- Easier configuration using the Spring Configurator. There is no need for patching XML configuration files.
(no dependency on Cocoon core – easily resuseable outside the Cocoon world)
- Easier development
Here is my presentation as a PDF.
The relaunch of cocoon.apache.org went online. Check it out!
Last week the vote for Cocoon 2.2-RC2 passed and I’m happy to announce the release of it. Actually Cocoon 2.2 isn’t the big monolith that you might know from the 2.1.x or 2.0.x series. We have been working hard to make Cocoon more modular:
From a first glance the most significant change has been that since version 2.2 Cocoon is based on the Spring 2 framework. We also introduced two new subprojects:
- the Cocoon Spring Configurator which provides consistent configurations and distributed bean definitions for web applications and
- the Cocoon Servlet-Service framework which introduces contracts between sub web applications.
Both can be easily used without Cocoon Core.
Cocoon Core has been put on top of those two frameworks and “only” provides pipelines, sitemaps, out-of-the-box caching support and the most important sitemap components. Everything that goes beyond that has been moved into its own block. Also custom Cocoon applications are build as blocks.
So what’s a block in Cocoon 2.2? You might be familiar with the term block from Cocoon 2.1. In 2.1 a block was a unit to modularize the build system. Starting with 2.2 a block has become more: A block has become the unit of modularization (Eclipse uses the term plugins, OSGi bundles) in Cocoon and can provide the following services:
- general servlet services (any servlet can be managed by the Cocoon servlet-service framework),
- special services that provide pipelines as services,
- component services (Spring beans, Avalon services/components),
- a container for classes and resources (e.g. sitemaps, templates, images, etc.).
A block is packaged as a Java archive (jar) following certain conventions concerning the directory structure. So adding a block to your Cocoon application only means adding it as a dependency and all the services (see above), Java classes and recourses become available automatically.
Are you curious? There are a bunch of tutorials that help you to get started!