Skip to main content

Classloader Hierarchy in Glassfish using deployed Resource adapters

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
5 replies [Last post]
Gustavo Henriqu...
Offline
Joined: 2011-10-27

I'm having problems with classloading when using Glassfish ResourceAdapters.
By deploying rar, their libraries seem to take precedence to both
Glassfish libraries and application libraries itself.

When deploying jackrabbit JCA with global classloading , this resulted
in a conflict in the ejb-timer-service that used the derby library
because there was a different derby version inside the jackrabbit.rar.

In addition, my application uses the Logback and has the file
logback.xml with the settings of the Logging system. But it seems that
the classloader system first the logback.xml inside a library jar
(jackrabbit-jca.jar) within the resource adapter jackrabbit-jca.rar.
So, it used the logback.xml shipped within jackrabbit-jca.rar instead
of my own configuration.

I would like to understand better the priority rules of loading when
using Resource Adapters.

This problem results in several other classloading problems such as
commons-io inside the jackrabbit-jca.rar is at version 1.4 and my
application uses version 2.0.1.

Is there any way to "isolate" the Rar libraries for use only in
classes inside this rar? What's the best approach to avoid all these
conflicts?

If anyone has faced these problems in a similar environment, what is
the recommended way to configure this environment?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ss141213
Offline
Joined: 2005-03-30

On Monday 23 January 2012 06:24 PM, Gustavo Henrique Orair wrote:
> I'm having problems with classloading when using Glassfish ResourceAdapters.
> By deploying rar, their libraries seem to take precedence to both
> Glassfish libraries and application libraries itself.
This is not expected.
> When deploying jackrabbit JCA with global classloading , this resulted
> in a conflict in the ejb-timer-service that used the derby library
> because there was a different derby version inside the jackrabbit.rar.
Should not have happened. Do you have Derby jars in glassfish3/javadb/lib/?

Can you give us a test case to this effect?
> In addition, my application uses the Logback and has the file
> logback.xml with the settings of the Logging system. But it seems that
> the classloader system first the logback.xml inside a library jar
> (jackrabbit-jca.jar) within the resource adapter jackrabbit-jca.rar.
> So, it used the logback.xml shipped within jackrabbit-jca.rar instead
> of my own configuration.
>
Application classloader searches in rar class loader first, so this can
happen.
> I would like to understand better the priority rules of loading when
> using Resource Adapters.
>
Just look for classloader hierarchy in GlassFish documents.
> This problem results in several other classloading problems such as
> commons-io inside the jackrabbit-jca.rar is at version 1.4 and my
> application uses version 2.0.1.
>
> Is there any way to "isolate" the Rar libraries for use only in
> classes inside this rar? What's the best approach to avoid all these
> conflicts?
>
No, not unless you take complete control of your application class
loading by turning it into an OSGi bundle. If you are interested, take a
look at http://glassfish.java.net/public/GF-OSGi-Features.pdf

Sahoo
> If anyone has faced these problems in a similar environment, what is
> the recommended way to configure this environment?
>

Gustavo Henriqu...
Offline
Joined: 2011-10-27

Sahoo,
thanks for your precise and clear answer!

2012/1/23 Sahoo :
> On Monday 23 January 2012 06:24 PM, Gustavo Henrique Orair wrote:
>>
>> I'm having problems with classloading when using Glassfish
>> ResourceAdapters.
>> By deploying rar, their libraries seem to take precedence to both
>> Glassfish libraries and application libraries itself.
>
> This is not expected.
>
>> When deploying jackrabbit JCA with global classloading , this resulted
>> in a conflict in the ejb-timer-service that used the derby library
>> because there was a different derby version inside the jackrabbit.rar.
>
> Should not have happened. Do you have Derby jars in glassfish3/javadb/lib/?
>
Yes, I have derby on this directory. I didn't change anything on this
directory, so it's identical as bundled in Glassfish 3.1.1.

> Can you give us a test case to this effect?
>
Unfortunately, it's been over a month I'm trying to make Jackrabbit
JCA work with Glassfish and my deadlines are already blown.
I am under pressure to moving away from change to Glassfish and JBoss.
I can just state that I have a Timer Service (schedules on ejb-jar.xml
deploynment descriptors) for an ejb inside my EAR. I deployed this EAR
without a reference to the resource adapter and using derived
classloading policy. After changing to derived global policy, there
were erros in ejb-timer-services while trying to access tables from
derby database.

>> In addition, my application uses the Logback and has the file
>> logback.xml with the settings of the Logging system. But it seems that
>> the classloader system first the logback.xml inside a library jar
>> (jackrabbit-jca.jar) within the resource adapter jackrabbit-jca.rar.
>> So, it used the logback.xml shipped within jackrabbit-jca.rar instead
>> of my own configuration.
>>
> Application classloader searches in rar class loader first, so this can
> happen.
>

I've done the following steps to try to solve the logback classloader issue:
1 - Removed the logback.xml from jackrabbit-jca.jar (inside jackrabbit-jca.rar)
2 - Removed all the conflicting libraries (slf4j-api, jcl-over-slf4j,
logback-core e logback-classic, commons-io).
3 - Inserted in domain/lib the most recent versions for slf4j-api,
jcl-over-slf4j, logback-core, logback-classic and commons-io

But this did not work because it seems that the settings logback.xml
not been read (all log messages are going to IO and appearing in
server.log).
Did this happen because I put the logback libraries in domain/lib?
Logback libraries should be kept only within the EAR?
Note: I have two different EARs in the same domain and would like to
have different log settings for each EAR.
How do I solve the problem of having EAR's own Logging settings and
also provide the necessary log libraries to Jackrabbit JCA work
properly?

>> I would like to understand better the priority rules of loading when
>> using Resource Adapters.
>>
> Just look for classloader hierarchy in GlassFish documents.
>
>> This problem results in several other classloading problems such as
>> commons-io inside the jackrabbit-jca.rar is at version 1.4 and my
>> application uses version 2.0.1.
>>
>> Is there any way to "isolate" the Rar libraries for use only in
>> classes inside this rar? What's the best approach to avoid all these
>> conflicts?
>>
> No, not unless you take complete control of your application class loading
> by turning it into an OSGi bundle. If you are interested, take a look at
> http://glassfish.java.net/public/GF-OSGi-Features.pdf
>
> Sahoo
>
>> If anyone has faced these problems in a similar environment, what is
>> the recommended way to configure this environment?
>>
>>

Gustavo Henriqu...
Offline
Joined: 2011-10-27

http://java.net/jira/browse/GLASSFISH-11683 but I couldn't figure out
how to solve this for the resource adapter case.

Gustavo Henriqu...
Offline
Joined: 2011-10-27

I found the answer in
http://logback.qos.ch/manual/loggingSeparation.html#tamingStaticRefs

2012/1/25 Gustavo Henrique Orair :
> Ps: My problem is really similar to
> http://java.net/jira/browse/GLASSFISH-11683 but I couldn't figure out
> how to solve this for the resource adapter case.
>

Jagadish Prasat...
Offline
Joined: 2011-03-11

Hi :

On Mon, 2012-01-23 at 10:54 -0200, Gustavo Henrique Orair wrote:
> I'm having problems with classloading when using Glassfish ResourceAdapters.
> By deploying rar, their libraries seem to take precedence to both
> Glassfish libraries and application libraries itself.
The class-loader hierarchy in GlassFish is as follows :
application-CL -> app-lib-CL -> connector-CL (RAR) ->common-CL ->
extension-CL -> Bootstrap-CL

http://docs.oracle.com/cd/E18930_01/html/821-2418/beadf.html

So, if you have copied any library to GF_HOME/lib or
GF_HOME/domains//lib directory, they will take precedence over
RAR's classes/libraries.

Similarly, the RAR classes/libraries will take precendence over
application classes/libraries.
>
> When deploying jackrabbit JCA with global classloading , this resulted
> in a conflict in the ejb-timer-service that used the derby library
> because there was a different derby version inside the jackrabbit.rar.
I assume, this is a different issue than :
http://java.net/jira/browse/GLASSFISH-18082

> In addition, my application uses the Logback and has the file
> logback.xml with the settings of the Logging system. But it seems that
> the classloader system first the logback.xml inside a library jar
> (jackrabbit-jca.jar) within the resource adapter jackrabbit-jca.rar.
> So, it used the logback.xml shipped within jackrabbit-jca.rar instead
> of my own configuration.
That depends on how the logback.xml resource is being loaded by the
application.
Please provide a test-case to see what's going on.
>
> I would like to understand better the priority rules of loading when
> using Resource Adapters.
Above class-loader hierarchy should help to understand the order in
which the delegation will happen.
>
> This problem results in several other classloading problems such as
> commons-io inside the jackrabbit-jca.rar is at version 1.4 and my
> application uses version 2.0.1.
>
> Is there any way to "isolate" the Rar libraries for use only in
> classes inside this rar? What's the best approach to avoid all these
> conflicts?
If the application does not use the RAR, then by default
(connector-class-loading policy is "derived"), the RARs classes will not
be seen. If the application uses the RAR, then RAR classes will take
precedence. AFAIK, right approach would be to make sure that both the
RAR and the application use common (same version) libraries. Other
option is to copy the library that you want to be used to GF_HOME/lib
directory so that both application and RAR will use the libraries in
GF_HOME/lib.

Thanks,
-Jagadish
>
> If anyone has faced these problems in a similar environment, what is
> the recommended way to configure this environment?
>