geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Multiple Inheritance
Date Sun, 03 Oct 2004 16:04:31 GMT
Maybe I don't understand what you are suggesting, but it looks to me as 
if either

1. you are in fact constructing a classloader with multiple parents, 
namely the classloaders that were used to originally deploy the 
connectors individually.


2. you are constructing a classloader with no relationship to the 
classloaders that were originally used to deploy the connectors 
individually, in which case the classloader will be useless for 
accessing connector classes.


3. you are suggesting deploying all (5) connectors at once in one 
classloader and providing them all to all applications.  You can do 
this today by constructing an ear with all the connectors in it and 
using the ear configId as your "real" application's parentId.  I don't 
think it's practical to have one connector deployment plan deploy more 
than one connector module, so I think this solution is as good as 
possible within the j2ee specs.

david jencks

On Oct 3, 2004, at 8:29 AM, Aaron Mulder wrote:

> On Sun, 3 Oct 2004, David Jencks wrote:
>> I agree this is inconvenient.  The solutions I know of are:
>> ...
> 	I'm more worried about the general-purpose case where you have 5
> connectors in the server and each of 3 apps requires a different 
> subset of
> them.  I don't think there's a way to make that work with either of the
> methods you suggested.  You'd have to deploy each app with the 
> connectors
> it uses and just sacrifice the potential to pool connections across
> applications.
> 	If we were going to try to make this work, I wouldn't try to
> construct an app classloader with multiple parent classloaders, I'd
> instead create an "RA ClassLoader" for the app that included all the RA
> JARs for all the RAs that the application depends on.  So in essence,
> you'd get:
> normal parent CL (o/a/g/System?)
>       |
> App's RA CL (references JAR URLs from RAs)
>       |
> App's normal CL
> That way the parent of the app could be whatever, and we could tell 
> from
> the resource mappings what RA's the app requires (and perhaps let you 
> list
> additional ones explicitly), and during app deployment we could 
> silently
> construct the RA CL for you and insert that "above" the rest of your
> application.  We could do a similar thing for web apps that depend on 
> JARs (normal parent - RA CL - EJB CL - web app) too.  That would be 
> nice
> because it would pretty much eliminate the need to manually specify 
> this
> ClassLoader hierarchy in your Geronimo deployment plan -- everything 
> could
> default to the parent o/a/g/System and we'd auto-wire the obvious
> dependencies and everything ought to "just work".
> 	Of course, I'm not sure this would really work in practice -- but
> it seems like it has some potential.  I'd really like to avoid needing 
> to
> manually configure all the parentIds properly in order for your app to
> work.
> Aaron
>> 1. make a chain Server --- Connector1 --- Connector2 --- MyApp
>> 2. put everything (both connectors and MyApp) in an ear.
>> I think there are 2 cases here.
>> If you need the connector classes on the MyApp classpath, then I think
>> the solutions (1,2) are sufficient.  Otherwise we will have to write
>> some bizarre classloader with several parent classloaders, that most
>> likely won't work reliably.
>> If you simply need the connectors started and available before MyApp
>> starts, this could be taken care of by some kind of explicit 
>> dependency
>> mechanism.  So far I haven't thought of a reasonable way to do this,
>> but I think it would be possible and convenient.

View raw message