cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <robert.simm...@norcom.de>
Subject Cocoon in Business Environements and its shortfalls
Date Thu, 28 Aug 2003 11:04:43 GMT
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




Mime
View raw message