I found the answer in
http://logback.qos.ch/manual/loggingSeparation.html#tamingStaticRefs
2012/1/25 Gustavo Henrique Orair <gustavo.orair_at_gmail.com>:
> 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.
>
> ---------------------------------------------------------------------------------------------------------------------
> Gustavo Henrique Orair
> Mestre em Ciência da Computação - MSc in Computer Science
> Universidade Federal de Minas Gerais
> Celular/Cell phone: 55-31-85157887
> ------------------------------------------------------------------------------------------------------------------
>
>
>
> 2012/1/25 Gustavo Henrique Orair <gustavo.orair_at_gmail.com>:
>> 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
>>>>
>>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>>