Check it out!

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:

1. Have a clean and simple Java Pipeline API that isn’t bound to any particular content (SAX, StAX etc).
2. 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.
• There are many high quality libraries that make Javascript development for web browsers so much simpler.
• 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:

• It focuses on providing RESTful webservices. For rich client technologies (including plain Javascript clients) they are the ideal contract for the client-server communication. Following this path also gives you a clean API for your web applications for free, that can be used by machines as well.
• 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.

The website of Cocoon 3 is online and the first alpha release of Cocoon 3 is at the ready. Stay tuned! (For those of you who don’t want to wait, read the build instructions.)

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.