Back to the subject at hand. If we analyze the shortcommings in a business environment, we can potentially plan out strategies to make Cocoon leap from a sometimes used app to something as ubiquitous as ant or Apache web server. This is a leap from pure open source to business ready open source and is not an easy one.
I will start by stating my issues with cocoon as is:
1) Production builds are lacking. What I mean by this are builds that a developer would use if he is USING cocoon and not developing on it at all.
I think this comes from simplifying Cocoon to its core, and making blocks truly work.
1a) One might object that blocks have to be described dureing the build process. This could be true but needs to change. The ideal solution is that someone cha drop in a block into the blocks directory post build and then indicate the block in the sitemap. This would allow a binary build that would give users the chance to merely delete blocks that they are not interested in and add their own blocks to a binary build.
I think we are in agreement on this.
1b) Examples for blocks need to be out of the blocks themselves. In my opinion, the only thing in the blocks directory should be the blocks jars themselves and perhaps something akin to a deployment descriptor for the blocks in the directory. Examples should be in a completely different locations.
We need to build the blocks. Where would you suggest putting the source code?
2) Monitoring is not intuitive. If you are deploying a business application with 20 cocurrent Cocoon instances, you need a way to cohesively monitor the health of the entire cluster. Separate log files just arent sufficient. Something like JMX instrumentation would be ideal.
Understood. Keep in mind that Cocoon does have some instrumentation available to it through Avalon's instrumentation package. It has a nice client that can connect to remote servers. That way you can monitor your Cocoon instances from your desk, and see their relative happiness.
3) Cocoon needs cluster management and load balancing functionality. You should be able to set up a cluster of cocoon instances that know about each other and have them perform load balancing and failover. This needs to be established at the cocoon level because the servlet engine wont have information about how busy cocoon is. For example, a cocoon instance getting a single reuest per second might be more busy than one getting 20 requests per second because that single request takes lots more processing time and resources.
Clustering is really an issue for the container. For all intents and purposes, it is a Servlet. It load balances as well as the Servlet Container does. I would focus on the blocks first, and then address this issue.
4) Cocoon documentation is minimal and non-cohesive. (But you knew this already) Although wiki is good for knowledge sharing, the information in Wiki is oftewn out of date and its reliability is sometimes questionable.
Hmm. Is there any way to make it more self-documenting?
5) Performance. Cocoon needs to have some routines gone over with a fine tooth comb for performance reasons. Think of deploying cocoon in a 100 concurrent user environment and having it take the load. Things Id like to see include URL per-caching at startup, pipeline timing for performance tuning and component execution timing. If these items were instrumented with JMX it would be even better.
In the mean time it would be easier to instrument it with the Avalon instrumentation package. JMX integration is planned for incorporation into Avalon containers--but it just isn't here yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin