cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: [C2] ComponentManager/Selector Rearchitecture
Date Mon, 19 Mar 2001 13:37:36 GMT
Great work, Berin!

I've been using these component manager in a different Avalon-based project
and your improvements came at the right time, thanks!

These components are so well thought out and generic that I think they should
be moved to Avalon: Almost nothing in them is C2-specific.

The _only_ C2 dependencies are the use of the RoleUtils and ClassUtil classes.

ClassUtils.loadClass just does a Class.forName, so this dependency can be
easily counted out if we want to generalize the components.

RoleUtils, on the other hand, is used to pass the manager/selector info about
the Cocoon-specific roles.

This is cool if Cocoon was the only environment where these highly generic
components are used, but what if we want to use them for another framework
(as we're doing at Bibop Research)?

I propose we define a new interface (Avalon?) that generalizes RoleUtils:

    public interface RoleInfo {
      public String lookup(String shorthandName);
      public Iterator shorthandNames();
      public String defaultClass(String role);

of which today's RoleUtils would be but a specific implementation.

Thus, any new framework wishing to reuse these terrific meta-components would
simply need supply its own RoleInfo to leverage this infrastructure.

This is what we're doing for Bibop's components and a new test XSP framework.

What do you think?


On Monday 19 March 2001 15:13, Berin Loritsch wrote:
> I believe I fixed the issues with Cocoon reusing Parser objects in a high
> transaction environment.  The result was a serious rearchitecture of the
> ComponentManager and Selector objects so that they use ComponentFactories
> to create and prepare objects. Also, with some inventive approaches, I made
> sure that the Component is always returned to the correct pool.  That way
> we can have multiple instances of say, the SVG serializers with different
> configurations, and the Components will be returned to the propper pools.
> This also greatly reduced the complexity of the Component Management
> Infrastructure, and reduced the amount of duplicate code.  As a result of
> the reduction in complexity, there is a real increase in speed when
> accessing Components.  This translates to an additional 1-5 milliseconds
> per call.
> Also, thanks to the hard work of Dims, Scott, and Santiago, Cocoon2 has a
> truly stable pipeline with real thread safety.  For simple transformations
> like the "forms/add-department" URL in the Cocoon samples you are looking
> at response times as low as 90 to 250 ms under heavy load.  For more
> complex transformations with 5 TraxTransformer stages, you are looking at
> 350 to 575 ms under heavy load.  NOTE: All times specified are on an Athlon
> 750 w/256MB RAM running W2K and Sun JDK 1.3.0_01 and JVM memmory set to
> 256MB.
> All in all, I think we have an incredible piece of work here--with speeds
> that rival commercial offerings.  Doing the same type of componentized
> pages in a markup based scripting language (like ColdFusion), results in
> 900 to 1250 ms--and is much more difficult to maintain the code.
> With Content Aggregation and Caching (which on my machine may not be
> necessary...) we will have truly Insanely Great (TM) software (appologies
> to Steve Jobs for ripping off his slogan).  We still have Garbage
> Collection cycles (there are alot of Strings created and destroyed), but
> there impact is lessened do to the objects being smaller and us being wiser
> with pooled and thread-safe resources.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message