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
>>>
>>> ------------------------------------------------------------------------------------------------------------------
>>
>>