You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2004/10/03 15:03:35 UTC
Multiple Inheritance
Currently I have an EJB JAR that depends on a single J2EE
Connector. So the connector's parentId is o/a/g/Server, and the EJB JAR's
parentId is the connector's ID. What happens if my EJB depends on 2
connectors? Or is there some better way to express classpath dependencies
than with the parentId?
Thanks,
Aaron
Re: Multiple Inheritance
Posted by Dain Sundstrom <ds...@gluecode.com>.
I would simply put the 5 resource adapters in an EAR and then make each
of the 3 applications a child of the resources EAR. Does this solution
work for you?
As for "during app deployment we could silently construct the RA CL for
you and insert that "above" the rest of your application," I really
dislike this idea. The last application server I worked on, had this
type if implicit class loader manipulation which has made it usable for
complex production deployments.
-dain
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
> EJB
> 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.
Re: Multiple Inheritance
Posted by David Jencks <dj...@gluecode.com>.
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.
or
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.
or
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.
thanks
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
> EJB
> 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.
>
Re: Multiple Inheritance
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 EJB
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.
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I just came across a similar problem that would be solved by this.
I currently have a database configuration and an application
configuration. The database isn't directly in the dependency hierarchy
for the application, but I passed it first on the command line and it
worked OK: "java -jar bin/server.jar DB app"
The problem is that if I then run the server with no arguments,
the app fails to start on account of the database not being ready. Both
entries were present in the var/config/config.list, so I assume it just
started them out of order when I didn't maually provide the ordering on
the command line.
If it's going to be a long-term fix to implement the dependency
strategy outlined in this thread, it may be worth putting in a quicker fix
to preserve component ordering when writing to and reading from the
var/config/config.list file.
Aaron
On Sun, 3 Oct 2004, David Jencks wrote:
> I agree, this is a good idea. Lets have the default value for the flag
> be "mandatory", i.e you only include the flag when it is optional. We
> can presumably do the same with ejb-refs from web apps to ejbs? I
> don't think we can have dependencies between ejbs since there can be
> circular references.
>
> david jencks
> On Oct 3, 2004, at 12:26 PM, Jeremy Boynes wrote:
>
> > toby cabot wrote:
> >> On a (hopefully) related topic, what's the mechanism to declare the
> >> dependencies within an ear? I ask because I've got a webapp that uses
> >> a connector and despite a <resource-ref> in web.xml and a
> >> <resource-ref> in geronimo-jetty.xml I get
> >> javax.naming.NamingException: could not look up : env/ra/CF [Root
> >> exception is java.lang.IllegalStateException: Proxy not returned.
> >> Target
> >> geronimo.server:
> >> J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF
> >> not started] when I start the server. I assumed that the
> >> <resource-ref> provided
> >> the dependency data to the server, but if there's some other technique
> >> I need to use I'll try that.
> >
> > I think this is a reasonable assumption - it certainly makes sense
> > from the application's viewpoint.
> >
> > I should not be that hard to do - after all at deployment time we know
> > all the references a component is making and what they will ultimately
> > resolve to. Seeing as any attempt to use the resource will fail, then
> > we might as well not start the component.
> >
> > The big downside I see is that it means a component won't start unless
> > all its local references can be resolved. This could be an issue if
> > there is logic in the code that chooses between references based on
> > application-level criteria. Perhaps we should add a flag to the
> > resource-ref that tags it as mandatory (we create a dependency) or
> > optional (we don't).
> >
> > --
> > Jeremy
> >
>
>
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by David Jencks <dj...@gluecode.com>.
OK, I like that.
david jencks
On Oct 3, 2004, at 1:41 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> yes, but is there anything preventing circular ejb references between
>> ejbs in 2 or more ejb-jars in a single ear?
>
> You would just need to make the dependency optional. I don't think
> this is a big burden as this is likely to be unusual.
>
> --
> Jeremy
>
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by Jeremy Boynes <jb...@gluecode.com>.
David Jencks wrote:
> yes, but is there anything preventing circular ejb references between
> ejbs in 2 or more ejb-jars in a single ear?
>
You would just need to make the dependency optional. I don't think this
is a big burden as this is likely to be unusual.
--
Jeremy
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by David Jencks <dj...@gluecode.com>.
yes, but is there anything preventing circular ejb references between
ejbs in 2 or more ejb-jars in a single ear?
david jencks
On Oct 3, 2004, at 12:52 PM, Jeremy Boynes wrote:
> David Jencks wrote:
>> I agree, this is a good idea. Lets have the default value for the
>> flag be "mandatory", i.e you only include the flag when it is
>> optional. We can presumably do the same with ejb-refs from web apps
>> to ejbs? I don't think we can have dependencies between ejbs since
>> there can be circular references.
>
> CMP EJBs will also have dependencies for the CMRs between them (as
> well as the dependency on the CMP data store which will not be an
> ejb-ref). I agree that resolving those will be problematic.
>
> Perhaps the compromise is to bundle the dependencies at the EJBModule
> level rather than at the individual EJB level - this would mirror the
> model at the web layer where they are define for the WebApplication
> not individual servlets.
>
> In other words, an ejb-ref from a WebApplication would depend on the
> EJBModule that contained the target EJB not the individual EJB.
> Similarly, individual EJB's ejb-refs would be rolled up into
> dependencies from their EJBModule to the EJBModules of the targets.
>
> --
> Jeremy
>
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by Jeremy Boynes <jb...@gluecode.com>.
David Jencks wrote:
> I agree, this is a good idea. Lets have the default value for the flag
> be "mandatory", i.e you only include the flag when it is optional. We
> can presumably do the same with ejb-refs from web apps to ejbs? I
> don't think we can have dependencies between ejbs since there can be
> circular references.
>
CMP EJBs will also have dependencies for the CMRs between them (as well
as the dependency on the CMP data store which will not be an ejb-ref). I
agree that resolving those will be problematic.
Perhaps the compromise is to bundle the dependencies at the EJBModule
level rather than at the individual EJB level - this would mirror the
model at the web layer where they are define for the WebApplication not
individual servlets.
In other words, an ejb-ref from a WebApplication would depend on the
EJBModule that contained the target EJB not the individual EJB.
Similarly, individual EJB's ejb-refs would be rolled up into
dependencies from their EJBModule to the EJBModules of the targets.
--
Jeremy
Re: Resource ref as dependency; WAS: Multiple Inheritance
Posted by David Jencks <dj...@gluecode.com>.
I agree, this is a good idea. Lets have the default value for the flag
be "mandatory", i.e you only include the flag when it is optional. We
can presumably do the same with ejb-refs from web apps to ejbs? I
don't think we can have dependencies between ejbs since there can be
circular references.
david jencks
On Oct 3, 2004, at 12:26 PM, Jeremy Boynes wrote:
> toby cabot wrote:
>> On a (hopefully) related topic, what's the mechanism to declare the
>> dependencies within an ear? I ask because I've got a webapp that uses
>> a connector and despite a <resource-ref> in web.xml and a
>> <resource-ref> in geronimo-jetty.xml I get
>> javax.naming.NamingException: could not look up : env/ra/CF [Root
>> exception is java.lang.IllegalStateException: Proxy not returned.
>> Target
>> geronimo.server:
>> J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF
>> not started] when I start the server. I assumed that the
>> <resource-ref> provided
>> the dependency data to the server, but if there's some other technique
>> I need to use I'll try that.
>
> I think this is a reasonable assumption - it certainly makes sense
> from the application's viewpoint.
>
> I should not be that hard to do - after all at deployment time we know
> all the references a component is making and what they will ultimately
> resolve to. Seeing as any attempt to use the resource will fail, then
> we might as well not start the component.
>
> The big downside I see is that it means a component won't start unless
> all its local references can be resolved. This could be an issue if
> there is logic in the code that chooses between references based on
> application-level criteria. Perhaps we should add a flag to the
> resource-ref that tags it as mandatory (we create a dependency) or
> optional (we don't).
>
> --
> Jeremy
>
Resource ref as dependency; WAS: Multiple Inheritance
Posted by Jeremy Boynes <jb...@gluecode.com>.
toby cabot wrote:
>
> On a (hopefully) related topic, what's the mechanism to declare the
> dependencies within an ear? I ask because I've got a webapp that uses
> a connector and despite a <resource-ref> in web.xml and a
> <resource-ref> in geronimo-jetty.xml I get
>
> javax.naming.NamingException: could not look up : env/ra/CF [Root exception is java.lang.IllegalStateException: Proxy not returned. Target geronimo.server:J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF not started]
>
> when I start the server. I assumed that the <resource-ref> provided
> the dependency data to the server, but if there's some other technique
> I need to use I'll try that.
>
I think this is a reasonable assumption - it certainly makes sense from
the application's viewpoint.
I should not be that hard to do - after all at deployment time we know
all the references a component is making and what they will ultimately
resolve to. Seeing as any attempt to use the resource will fail, then we
might as well not start the component.
The big downside I see is that it means a component won't start unless
all its local references can be resolved. This could be an issue if
there is logic in the code that chooses between references based on
application-level criteria. Perhaps we should add a flag to the
resource-ref that tags it as mandatory (we create a dependency) or
optional (we don't).
--
Jeremy
Re: Multiple Inheritance
Posted by toby cabot <to...@caboteria.org>.
On Sun, Oct 03, 2004 at 08:05:01AM -0700, David Jencks wrote:
> I agree this is inconvenient. The solutions I know of are:
..snip...
> 2. put everything (both connectors and MyApp) in an ear.
On a (hopefully) related topic, what's the mechanism to declare the
dependencies within an ear? I ask because I've got a webapp that uses
a connector and despite a <resource-ref> in web.xml and a
<resource-ref> in geronimo-jetty.xml I get
javax.naming.NamingException: could not look up : env/ra/CF [Root exception is java.lang.IllegalStateException: Proxy not returned. Target geronimo.server:J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=testCF not started]
when I start the server. I assumed that the <resource-ref> provided
the dependency data to the server, but if there's some other technique
I need to use I'll try that.
Thanks,
Toby
PS. more details in http://nagoya.apache.org/jira/browse/GERONIMO-307
Re: Multiple Inheritance
Posted by David Jencks <dj...@gluecode.com>.
I agree this is inconvenient. The solutions I know of are:
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.
thanks
david jencks
On Oct 3, 2004, at 6:03 AM, Aaron Mulder wrote:
> Currently I have an EJB JAR that depends on a single J2EE
> Connector. So the connector's parentId is o/a/g/Server, and the EJB
> JAR's
> parentId is the connector's ID. What happens if my EJB depends on 2
> connectors? Or is there some better way to express classpath
> dependencies
> than with the parentId?
>
> Thanks,
> Aaron
>