> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > > 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?
If it does not have Lists (and it does not... for what I could understand), then it should be faster then ECM. > > 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 Neither XSLTProcessor, nor XSLTProcessorImpl is Poolable. XSLTProcessorImpl is SingleThreaded ATM. Vadim > looksup a Store in compose(). > So each XSLTProcessor component would block a Store component, although > this would not be necessary. > > Carsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
