At 09:04 AM 7/1/2002 +0200, you wrote: >>Even if you want to work around this you can use multiple strategies - a >>container wide mapping (ie all components who want the ****INTERFACE*** >>org.apache.cocoon.CocoonContext get an instance of >>org.apache.merlin.CocoonContextImpl). > >Meaning I add container specific workarounds for every container I know >about - BAD BAD BAD.
you are going to have to anyway as no container specific context implementation will be instantiatable via a no args constructor. The whole point of container specific context is that the container offers container orientated services (like proxing) or data (like ClassLoaders or MBeanServers) that can not be gained via peer components/Composable or via Configuration. You are never going to be able to support these sorts of features without inbuilt support by the container. >>Given how unlikely that people will adopt Merlins model of Context I >>can't see it being base class no matter how "vital" you believe it is. > >This is not Merlin's model of context - it the Avalon Framework structural >defintion of a component. This isn't about Merlin - its about a common >container framework and getting the framework right. Yes - just like ThreadSafe, SingleThreaded is vital to our component model and without them we wont be able to build a scalable system. Or maybe it is vital like ComponentSelector. I think I have heard this tune before. >>and happens to go against the intention of the Context interface - dont >>forget that one ;) > >And is this intention documented anywhere - or is this "your interntion" >that never got clarified completely. I have told you in the past ... You choose to see context as a place to get global variables not as the way via which coponents can aquire environmental services from container. Oh - and ContextUtil breakes model in every container I work with - so enough pointing at it as the panacea. > This is exactly the sort of thing that will break interoperabiliy of > components across containers. Right. >So, to conclude - can you explain why you are opposed to component >portability - or should I say, why are you opposed to the portability of a >phoenix bound components to generic containers ? Nice slur. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
