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.

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.

Lars Trieloff was talking about “DAX – Where flowscript and XSLT meet“. DAX stands for Declarative API for XML. The idea is to make it easy for others to write transformations in more familiar languages like Java or Javascript. Since I’m fluent in XSLT this wouldn’t be that appealing for me. The interesting point for me is that you can get access to the outside world (e.g. a Spring bean) very easily which I was missing once and then before. Obviously there is a Cocoon integration in the form of a transformer. After thinking about it for a while I’m not sure if I recommend the usage of DAX because it is too easy to implement side effects. Hmmmm.

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
  • three Maven 2 archetypes available to give  your Cocoon 2.2 project a jump start
  • run any Cocoon 2.2  block using the Cocoon Maven plugin which allows reload of any resources, also Java classes and Spring bean defintions

Here is my presentation as a PDF.

The relaunch of cocoon.apache.org went online. Check it out!