At 07:14 2/11/00 -0500, Aaron Mulder wrote:
>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.
really depends on how you want to do it. It is up to developer to decide on
policy but you have outlined the inbuilt java2 policy.
> 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.
right - but all these services would arguably be irrelevent. Avalon does
not aim to provide these services - it is just a side effect ;)
The main advantage of Avalon is on the patterns built in to it. If you look
at how various server orientated projects developer (turbine, james, cocoon
and jetspeed are the ones I am familiar with) then they all evolve roughly
the same way. The same mistakes are made in every product and the same
"fixes" get put in place. Eventually these products end up being extremely
complex webs of interacting components that is hard to maintain/develope etc.
Avalon tries to simplify everything by applying well known design patterns.
This way if you develope an Avalon-Aware app it is less likely (thou still
possible) to fall into development traps. It does this by drawing on the
experience of people involved in many of the different server orientated
projects (ie people that have worked on httpd, jserv, tomcat I believe,
cocoon etc) and also to leverage existing research presented at conferences
like OOPSLA and also under projects like ACE. This is the main strength of
Avalon.
While it will eventually also become a toolbox of lego-like blocks that you
can join together to build a server this is not it's main aim I believe.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
