Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Message-ID: <3AB66008.5A767D1D@apache.org>
Date: Mon, 19 Mar 2001 14:37:44 -0500
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org,
 	"avalon-dev@jakarta.apache.org" <avalon-dev@jakarta.apache.org>
Subject: Re: [C2] ComponentManager/Selector Rearchitecture
References: <3AB61418.537413FB@apache.org>
 <01031914373601.02132@ricardo.plenix.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ricardo Rocha wrote:
> 
> 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?

That sounds like a good plan.  I will try to see where it would fit in the
Avalon Framework.  It would be perfect for replacing the DefaultComponentManager
implementation in Avalon--but the Handler and Factory implementations may need
a subpackage.  I am copying this message to the Avalon List.

> Ricardo
> 
> 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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org