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