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.
---
How about the coarse-grained server of server apps. Merlin and Phoenix today, others
tomorrow.
OK, Lets talk over 'the others' ...
Imagine...
1) 'Diamond' - It uses some run-time optimizing lookup mechanism for services and
LDAP for
configuration/meta.
2) 'Nano' - A single-class component-bootstrap server that uses can bring up
components in teh
right order from a properties file or command line args.
3) 'Wolfstream' - A container that only ever operates in a federation of servers and
that some
primary/secondary master servers indicate comp lacing (and whether those impls are
local or remote
- it uses AltRMI don't ye know). I.e. the local comps have no meta.
4) 'Adapterver' Some container that prifiles the codebase and laces components
dynamically without
any instruction
5) 'Redunderver' As (4) but invokes all impls of the same server with the same method
requests for
some sort of Spaceshuttle/failsafe behaviour.
Phew! Comps are just implementors of A-F interfaces. Their original writers may be
amazed where
they are used or how they are laced together. So what if 'Redunderver' coders have to
write some
more manifests.
- Paul
> Hmm, is there a rough explanation of the differences available?
> > 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.
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.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
