I wanted to open a general discussion thread on the shortfalls of Cocoon in business environments. I have some very clear opinions on the matter, but then my opinions are just that -- opinions. Others may differ with me.
First of all, I should say that I have a very direct, a-political, style that sometimes treads on toes unintentionally. Trust me when I say that if I thought Cocoon was a piece of junk, I would say so. As a matter of fact I think it is an excellent product with some shortcommings like all products have. However, Im not particularly into "ra-ra" chearleading so I tend to only point out things I see as deficiencies. In addition, Im not opposed to putting my time where my mouth is so long as what I would contribute is feasible without 2 months of study to understand the source base. 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. 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. 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. 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. 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. 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. 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. Issues Im not privy to directly but concerned about: 6) Project Lint. Over time any project accumulates an amount of lint in the form of dead code, unused classes and unused methods. How much of this is in cocoon and how can we get it out? Comments? Additions? Suggestions? (Please route flames to /dev/null). -- Robert
