> From: Andy Lewis [mailto:[EMAIL PROTECTED]] > > <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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
