On Wednesday 29 October 2003 22:38, Vjeran Marcinko wrote: > Ugh ... I'm not some top notch developer to understand everything you've > written above,
That's ok... > but what I had in > mind is - I would like to have pooled component, or for sake of simplicity, > let's say singleton component which uses .xconf configuration, depends on > other components, implements standard lifecycle avalon methods, or in other > words, uses all commodities of avalon container, I don't think you mean .xconf configurations. .xconf is a dependency declaration file. You probably mean the Configuration system, which varies a bit from container to container. > BUT before being given to > client code by ServiceManager.lookup(), it would need one additional > argument configured during runtime. I never worked with nested containers > or lifecycle extensions, but I guess that would be the way to go ... The question is then WHAT does this do? You can't pool a component that is not identical between instances. Could you elaborate what this "additional argument" would do? Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
