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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
