EAR deployment in specific classloader and SAR librairies

[lyc1]

Hello

I'm trying to use a specific classloader for each of my EARs i can deploy thanks to the "loader-repository" instruction in jboss-app.xml.

Each of my EAR loads its own database pool connection service (one jboss-service.xml per SAR file), with inside the SAR file, the jdbc driver. Everything works fine for db pool connections if i don't try to use a specific classloader for each EARs.

If i try this (just add loader-repository tag in jboss-app.xml), db pool connections don't work anymore :-( They are not able to find the jdbc driver (I remember that this driver is inside a SAR file, which is inside my EAR).

Now, in this configuration, if I add the driver in lib/ folder, db pool connections work again.

I think the jdbc driver is loaded inside the specific EAR classloader, but my db pool connection seems to be outside of it.

So, how to configure the service in order to load the driver which is inside the specific classloader of my EAR ?

Thanks for your help

Damien

[adrian.brock]

Post the stacktrace.

There is probably a Class.forName()
in there somewhere.

Regards,
Adrian

[davidjencks]

The jca-jdbc wrappers are normally loaded in the "top level" loader repository. Therefore they won't be able to see jdbc drivers loaded in individual .ears. What you need to do is remove the jboss-common-jdbc-wrapper.jar from [config]/lib and the jboss-local-jdbc.rar and jboss-xa-jdbc.rar from [config]/deploy and put them in each one of your .ear files. (with appropriate deployment instructions for the .rar you choose in application.xml).

Presumably you will need only one of the two .rars.

[lyc1]

Thanks

I precise i'm working with jboss 3.0.6.

Well, I tried something closed to what you explained, and it works.

Firstly, jboss-common-jdbc-wrapper.jar file doesn't exist. But it doesn't matter.

Secondly, if I move jboss-local-jdbc.rar from deploy dir to my EAR, it works, but that doesn't solve my problem, because I have to deploy at least 2 EARs on my JBoss. So I add in each one of my EAR a RAR file wich is exactly the same as jboss-local-jdbc.rar but where I changed the display name (one for each EAR). I also changed the mapping in my connection pool. Now, that works only if I delete the original file jboss-local-jdbc.rar from [config]/deploy/ dir.

Thirdly, as I explain above, I have to remove jboss-local-jdbc.rar in order to use my own jboss-local-jdbc.rar modified in my EAR, otherwise jboss is not able to find the jdbc driver.
So i would like to know if is it possible to let the original jboss-local-jdbc.rar in [config]/deploy/ and use my own one modified ?

Thanks for your help

Damien

[lyc1]

Thanks

I precise i'm working with jboss 3.0.6.

Well, I tried something closed to what you explained, and it works.

Firstly, jboss-common-jdbc-wrapper.jar file doesn't exist. But it doesn't matter.

Secondly, if I move jboss-local-jdbc.rar from deploy dir to my EAR, it works, but that doesn't solve my problem, because I have to deploy at least 2 EARs on my JBoss. So I add in each one of my EAR a RAR file wich is exactly the same as jboss-local-jdbc.rar but where I changed the display name (one for each EAR). I also changed the mapping in my connection pool. Now, that works only if I delete the original file jboss-local-jdbc.rar from [config]/deploy/ dir.

Thirdly, as I explain above, I have to remove jboss-local-jdbc.rar in order to use my own jboss-local-jdbc.rar modified in my EAR, otherwise jboss is not able to find the jdbc driver.
So i would like to know if is it possible to let the original jboss-local-jdbc.rar in [config]/deploy/ and use my own one modified ?

Thanks for your help

Damien

[lyc1]

Thanks

I precise i'm working with jboss 3.0.6.

Well, I tried something closed to what you explained, and it works.

Firstly, jboss-common-jdbc-wrapper.jar file doesn't exist. But it doesn't matter.

Secondly, if I move jboss-local-jdbc.rar from deploy dir to my EAR, it works, but that doesn't solve my problem, because I have to deploy at least 2 EARs on my JBoss. So I add in each one of my EAR a RAR file wich is exactly the same as jboss-local-jdbc.rar but where I changed the display name (one for each EAR). I also changed the mapping in my connection pool. Now, that works only if I delete the original file jboss-local-jdbc.rar from [config]/deploy/ dir.

Thirdly, as I explain above, I have to remove jboss-local-jdbc.rar in order to use my own jboss-local-jdbc.rar modified in my EAR, otherwise jboss is not able to find the jdbc driver.
So i would like to know if is it possible to let the original jboss-local-jdbc.rar in [config]/deploy/ and use my own one modified ?

Thanks for your help

Damien

[lyc1]

Thanks

I precise i'm working with jboss 3.0.6.

Well, I tried something closed to what you explained, and it works.

Firstly, jboss-common-jdbc-wrapper.jar file doesn't exist. But it doesn't matter.

Secondly, if I move jboss-local-jdbc.rar from deploy dir to my EAR, it works, but that doesn't solve my problem, because I have to deploy at least 2 EARs on my JBoss. So I add in each one of my EAR a RAR file wich is exactly the same as jboss-local-jdbc.rar but where I changed the display name (one for each EAR). I also changed the mapping in my connection pool. Now, that works only if I delete the original file jboss-local-jdbc.rar from [config]/deploy/ dir.

Thirdly, as I explain above, I have to remove jboss-local-jdbc.rar in order to use my own jboss-local-jdbc.rar modified in my EAR, otherwise jboss is not able to find the jdbc driver.
So i would like to know if is it possible to let the original jboss-local-jdbc.rar in [config]/deploy/ and use my own one modified ?

Thanks for your help

Damien

[davidjencks]

You'd have to configure the scoped class loader to look at its own classes first, then the parent classloader's classes. I think this is possible with the 3.2 classloaders, but I doubt it is in 3.0.x.

Sorry I forgot about changing the display names. Using the display name for identification is not ideal, but I'm not sure what would work better. There's a general problem of how deployed packages can refer to one another in a location-independent way.