Paul Hammant wrote: > > Carsten, > > > 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. > > Implementation is one thing. Lacing (lookup & assembly) and > configuration are another. > > Imagine these abstract ideas : > > 1) Servlet container (one design along A-F lines rather > than Sun's established javax.servlet standard) > 2) Bean container (as above) > 3) Mailet container (apols to JAMES lurkers for rehashing old topics) > 4) Newslet container > 5) Gopherlet container > 6) Portlet container > > These comps all honor the usual interfaces - Startable, > Initializable .. i.e. our principal art. > > Imagine that these comps come in their own packaging - WAR, EAR, > JAR with their own assembly > manifests (web.xml, ejb-jar.xml etc). > > Imagine that these comps all have subtle differences in context - > BeanContext (as EOB does), > ServletContext, MailetContext, GopherletContext. > Contextualizable passes in Context. The comp > casts it to the suitable sub-interface and uses its special features. > > That's all for container-in-contrainer scenarios though. > Hmmm, ok I understand this - and I (now) totally agree with you here. But (sorry it's in my nature to write each second sentence a 'but') these are containers for different purposes. You can't use the newslet container implementation for portlets, e.g. At this point I agree with you, but I would not agree if you would have two portlet container implementations which are configured (or their components) in different ways.
> <snip> > > A-F interfaces make them compatible. I have some workside > projects that use multiple containers > (like those above) in one CVS tree for different run scenarios. > I assure you that A-F is the > magic, not comp-lacing. And it is magic. > It is, definitly! And I agree from a components implementor view that's a very good solution (or better, the best solution). Now, perhaps we are talking about the same things. Let's have a look at an example: I want to develop the coolest web publishing framework in the work and of course I want to use A-F. So far, no problems - now I choose to use Implementation A for this which is configured via a configuration XML with format A.dtd. After some time, I figure out that A does not scale under some circumstances. Now I want to replace A with Implementation B. Unfortunately B uses B.dtd for configuration and I have to rewrite my whole configuration - so implementations are not easily exchangeable. Carsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
