cocoon-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: Minimal JDK Version for 2.1
Date Fri, 14 Mar 2003 07:23:12 GMT
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

Mime
View raw message