cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
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 [mailto:ajl@ascii27.net]
> 
> <snip/>
> 
> >
> > If you to change Transformer interface to return only
> > XMLSource/ContentHandler, all the logic and state Transformer has
moves
> > 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
I
> > see things wrongly.
> >
> 
> actually - you end up with one compoent, but it may consist of more
than
> 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
component.


> 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
though,
> depending on the implementation. WE create several abstracts to extend
for
> 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
allow
> you to "anchor" the compoenent to another object for its lifespan -
when
> that object went away, your component got cleanp-up/returned to the
pool.

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
conceptual
> line her eon component vs. object. I'm on this thread because this is
an
> 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
could
> > be looked up on startup and returned on shutdown (to speedup
processing
> > - right now manager.release() is quite expensive operation), and
will
> > not depend on request/response cycles.
> >
> 
> different componenets can have different basis for lifespans...it
should
> be done with caution and justification, but it doesn't break anything.
It
> is a container issue hwo and when it reclaims it. Pooling per request
is
> one lifetime appraoch a container could take.

How container will know what should be the lifespan?

Vadim

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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message