Sahoo,
thanks for your precise and clear answer!
2012/1/23 Sahoo <sanjeeb.sahoo_at_oracle.com>:
> 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 Henrique Orair
>>
>> ------------------------------------------------------------------------------------------------------------------
>
>