<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. Bascially object != 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. 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. <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. -- "The heights of genius are only measurable by the depths of stupidity." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
