Marcus Crafter wrote: > > > > > Personally, I don't see a real problem with this. If we use a > new container, > > we change the inheritance from ECM to whatever container we use. > > Well, I know we don't change container implementations all that > often :) so perhaps this is a bit academic - but this was > what I was > hoping to avoid. It could also be that the inheritance method > currently used now is not possible with a future container. > Yes, that's possible.
> > > We could also implement a delegation to the real container, but I don't > > see a real need for this as changing the container implementation > > is due to different feature sets not possible. > > Delegation would be good - then we'd be operating through the > ComponentManager (or ServiceManager or similar) interface right ? > Hmm, yes ServiceManager I guess. > Not sure if I fully understand your last sentence though mate - do > mean it's not possible to change containers in Cocoon at all due > to some other reasons ? > Yes, that's my perception of the different container implementations. I'm not sure if I'm mistaken, but I think, after long discussions in Avalon, there was the agreement that it doesn't make sense to have different container implementations with the same feature set. So if you have different containers, you have different features. (One container implementation is a superset of another one). So, Cocoon will rely on a distinct set of features. Then you can't use an implementation with less features of course. And as we here in Cocoon tend to use everything available, we will choose the container will the most features anyway :) This is only my understanding of the different container implementations, perhaps I'm wrong. Cheers Carsten
