avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Optional Dependencies
Date Wed, 10 Jul 2002 10:30:21 GMT
Peter Donald wrote:
> > I think the XSLTProcessor is a good example for a use-case of b).
> >
> > A store is available in (nearly) every system, so this component is
> > always present. If we only have use-case a), then the XSLTProcessor
> > always uses the store for caching stylesheets.
> true but thats only true in the container where there is no such 
> thing as an 
> assembler. ECM has a global namespace for components where as other 
> containers may or may not have this but even so...
> Just because you aquire a service does not mean you have to use 
> it. ie You can 
> aquire service but only use it in certain locations. One of which 
> may be you 
> only use it if a flag is true or similar (Similar to how I 
> implemented it in 
> XSLTProcessor).
Ok, I understand this.

> It is unfortunate that ECMs lookup is costly. Does Fortresss have 
> this problem 
> aswell? Most containers I work with are little more than a hashlookup.
Even if the lookup is not costly, what about non ThreadSafe components?
For example the XSLTProcessor is configured to not use the Store,
the Store would be Poolable (as the XSLTProcessor is) and the XSLTProcessor
looksup a Store in compose().
So each XSLTProcessor component would block a Store component, although
this would not be necessary.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message