Paul Hammant wrote: > > (Vote) -1 > This is not a vote, it's an RT ;) (just kidding)
> I do not believe it is necessary to make the containers we have > compatible at anything other than > Avalon-Framework-Interface level. Ok. > If we strive for compatibility > on component-lacing (XML, > properties, whatever) we will find some other team does not honor > the chosen lacing team an > delivers a container with a twist. This could be BEA, Pramati, > JBoss, Catalina, OpenEJB, Lutris. > It could be some University in Bangalore or Manila. We cannot > contain the container landscape; > we'd be foolish to try. There are thing people are imagining now > that will impress the socks off > us when released. > Perhaps I had a wrong understanding of the different implementations we currently have - I thought, it's not only the way how to configure the components but also that there are some difference in the features provided to implement components. Hmm, is there a rough explanation of the differences available? I think, there was a discussion about this some months ago in the mailing list, right. So I can look up there. Anyway, different implementations mean different code bases for the same tasks. An alternative might be (and it's nothing more than a loud thought) to have a common core and several "plugins" for the different purposes. > Better to concentrate on our core product -> Avalon Framework's > interfaces. > It's correct, that this is the first part to do. > Embrace the multi-container world!! > And what can I do, if I want to combine to open source projects, the first one using container implementation A and the second one container implementation B? Hmmm. Carsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
