Hi!

Aaron Mulder wrote:
>         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.

Ah, but you're forgetting something here. When you deploy an EAR the
J2EEDeployer creates a classloader that points to all parts in the EAR,
i.e. the EJB JAR's and WAR's. So, in fact the servlet and EJB
classloaders will not be loading any classes (becuase of the classloader
delegation model): they will all be loaded by the parent CL created by
the J2EEDeployer. Tada :-) That's the only clean way for servlet and EJB
containers to share classes so that they live in the same namespace.

> > 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)?  

Sorry, my mistake. It takes care of EAR,JAR, and WAR deployment,
including shared classloading. Shared JNDI (i.e. servlets using the
"java:comp/env") should be done soon. Shared logging would be
interesting. The new JDK logging API spec is out, and we should probably
take a look at it. Shared security is done if I read Olegs and Dans
emails correctly.

> 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.

So Tomcat 4 has its own JNDI provider? 

> > 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.

"The goal is..", "provide a unified interface for.."... right.. but
"what do I get on the screen?" (infamous quote from a local programming
course)

>         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).  

Kind of like our Service interface then?

>Then, to quote a more knowledgeable party,
> "Out of the box, Avalon includes an integrated Logger, resource pooling,
> Thread management, Store management, and Timers."  

Seems like cool JMX MBeans, but not a framework in itself. Implement
them as MBeans and I'm cool with it.

> 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.

Alright... well... let me know if something actually happens with that.
In the meantime I think we got quite a few of those areas covered pretty
well.

>         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.

Use JMX is my mantra :-) If the above functionality is available as JMX
MBeans or interfaces I'm ok with it.

/Rickard

-- 
Rickard �berg

Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com


Reply via email to