cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <...@ascii27.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 03:23:12 GMT

<snip/>

>
> 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.
>

what is the best logical component here? The term "service" has come up in
this thread, and is a good term for its implications. Shoudl the
componenet be the Transformer or the XMLSource? It isn't "weight"
necessarily the specific main class that makes a good candidate for a
componenet, but the weight of the service it provides. I've had
services/componeents that themselves were almost no code - but provided a
solid, logical interface to a significant number of other classes. The
fact that XMLSource as an object is heavier than Transformer doesn't mean
it should be the component. If the two work together, and only one
componenet should exists, the real test is which logical compoenent
abstraction encompassing the two is more applicable  to the solution at
hand? (I'm not going to try to answer that by the way)
Keep in mind that I'm WAY behind on my understanding of Avalon - so feel
free to tell me where I'm wrong on any of this.
<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.
>

Berin - did I understand correctly on this one? Or did I miss it too?

<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?
>

I done this many ways - componenet configration file, marker interfaces
and/or runtime capabilities discover of the class, and requestor specifed.
The first one has generally been the best since sometimes you have a
compoenent that is capable of being used globally, but you choose to
configure it at a smaller scope in a particualr case. The best system I've
worked with for this one had the ability to scope the life of a component
as request, session, user, application, or global at configuration time.
Within that scope it could then be pooled, created as needed, managed as a
singleton, etc. All transparent to the requesting object.

-- 
"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