cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 00:24:16 GMT
> From: Andy Lewis []
> <snip/>
> >
> > If you to change Transformer interface to return only
> > XMLSource/ContentHandler, all the logic and state Transformer has
> > into this XMLSource.
> >
> > Thus, XMLSource becomes heavy and Transformer light. Obviously,
> > Transformer becomes ThreadSafe (which is good) and XMLSource must be
> > made Poolable (its heavy, it is stateful).
> >
> > Instead of having one component we ended up with two. Please tell me
> > see things wrongly.
> >
> actually - you end up with one compoent, but it may consist of more
> one object.

Yes, if they share same ... how you call it? ... scope: both are
ThreadSafe or Poolable (by nature). Here, one (Transformer) will be
ThreadSafe (or even not a component (it's too lightweight for it)), and
other (XMLSource) - Poolable.

Thus, you can not keep an instance of XMLSource in the Transformer, and
forced to ask it from manager and keep it on stack.

> Bascially object != component.

No objections. But heavy reusable object is a perfect candidate for a
component (what are other distinguishable features of a
object-to-be-component? Configuration?). That's why XMLSource can become

> Only the transformer is a
> componenet. But components are conceptually large, and may as a result
> have any number of  other classes incolved in thier work.

Of course.

> I have
> implemented service frameworks in java before (though nothing the
level of
> comprehensiveness of Avalon) and this model works REALLY well.
> It is true that some componeents may have objects that they pool
> depending on the implementation. WE create several abstracts to extend
> handling that when creating a component.
> <snip/>
> >
> > Two issues on this one:
> >
> <snip/>
> The key here is being aware of the lifespan of the componenet you are
> using. We used a default lifespan of a single request, but actually
> you to "anchor" the compoenent to another object for its lifespan -
> that object went away, your component got cleanp-up/returned to the

I hope so. It was not clear from Berin's proposal.

> <snip/>
> >
> >> Anything that is more granular than that needs a
> >> different treatment.
> >
> > What could it be?
> >
> in some cases similar mechnisms will be used, but there is a
> line her eon component vs. object. I'm on this thread because this is
> area where I feel like I have personally made A LOT of the possible
> mistakes on this path.
> <snip/>
> >
> > Some transformers use instance of serializers to do its work. It
> > be looked up on startup and returned on shutdown (to speedup
> > - right now manager.release() is quite expensive operation), and
> > not depend on request/response cycles.
> >
> different componenets can have different basis for
> be done with caution and justification, but it doesn't break anything.
> is a container issue hwo and when it reclaims it. Pooling per request
> one lifetime appraoch a container could take.

How container will know what should be the lifespan?


> --
> "The heights of genius are only measurable by the depths of

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

View raw message