On Thu, 2 Nov 2000, Rickard [iso-8859-1] �berg wrote:
> Nope. Look at the J2EEDeployer which deploys EAR's in an efficient in-VM
> manner. The solution to the above is to have one parent classloader
> which the servlet and EJB classloaders are children to. That way they
> will have the same namespace, but the servlet and EJB implementations
> don't know about each other *at all*. The way we implement the "sending"
> of the parent CL into the servlet and EJB implementations is to set it
> as context classloader on deploy. Very clean, and it's the right way to
> go I think.
Help me out here. It looks like the servlet and EJB ClassLoaders
are not children of one ClassLoader, but rather the servlet ClassLoader is
a child of the EJB ClassLoader. Or am I misreading it? In ClassLoader
terms, I thought you could only load classes from your parent and its
ancestors, not from your parent's other children.
> Again, look at the J2EEDeployer. It does most of the above already. The
> rest is doable :-)
Uh, out of shared security, shared JNDI, and shared logging, which
does it do (I see none)? You could make a claim for JNDI, I suppose, but
AFAICT Tomcat 4 will be storing some stuff in JNDI and it would be it's
own JNDI not jBoss' JNDI, so I don't buy it.
> Can someone point to any docs on just what Avalon provides? All I've
> seen are some "this would be cool" docs, but nothing like an API or
> similar. What does it do?
I've just been asking this on the Avalon list. As I understand
it, the goal is to provide a unified interface for a number of services
(such as a unified management interface, etc.), and provide them each with
a number of, uhhh, services.
Let me try again. If you make Tomcat and jBoss into Avalon
"blocks", then you can start/stop/manage them through the Avalon interface
(one interface for both/all). Then, to quote a more knowledgeable party,
"Out of the box, Avalon includes an integrated Logger, resource pooling,
Thread management, Store management, and Timers." So you could have all
the logs go to the same place, etc.
In the future, they will potentially be providing JNDI support,
security, resource management, etc. across all the "blocks" deploying in
the server, with an integrated concept of a "server application" which
would map nicely to an EAR.
Overall, it seems like this could be a great way to hook up Tomcat
and jBoss and Apache (or whatever) to enable them all to "act
unified" beyond just sharing classes or VMs.
(I'm sure the Avalon folks will jump in if I'm misrepresenting it
- but this is my understanding after a couple of e-mails on the Avalon
list.)
Aaron
