jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pontus Amberg <pontus.amb...@milso.se>
Subject Re: Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Tue, 27 Dec 2011 13:57:06 GMT
I tested with a direct lookup

InitialContext ctx = new InitialContext();
Repository repository = (Repository) ctx.lookup("jcr/local"); 

and that worked. Why do you want to use JcrUtils?

/Pontus

On Tue Dec 27 13:14:56 2011, Gustavo Henrique Orair wrote:
> Pontus,
> thank you for your attention.
>
> As I said, I am using JCRUtils.getRepository with an jndi: scheme uri.
> It results in an explicit JNDI lookup for the resources that is
> different from your approach (using injection).
> The derived classloading policy states that the libraries inside
> resource adapter would be available to the application "clients" if
> there is a reference on the application to the resource adapter.
> Since I am using explicit JNDI lookups, Glassfish doesn't find this
> "reference" and the resource adapter doesn't work.
>
> Just as a reference if someone find this page facing similar problems,
> I've created an issue on Glassfish
> http://java.net/jira/browse/GLASSFISH-18082 .
> Btw, I will comment on this issue stating that some JackRabbit users
> successfully used Jackrabbit-JCA using injection.
>
> Br,
> Orair.
>
> 2011/12/26 Pontus Amberg<pontus.amberg@comhem.se>:
>> I'm testing Jackrabbit JCA right now on Glassfish 3.1.1 and I have not
>> encountered any class loading problems. The way I deployed it was to
>>
>> 1. Copy jcr-2.0.jar to /glassfish-3.1.1/glassfish/domains/domain1/lib/
>> 2. Start glassfish
>> 3. Open Glassfish web admin console at
>> http://localhost:4848
>> 4. Deploy jackrabbit.rar using
>>     Applications->Deploy...
>> 5. Create a new connection pool for jackrabbit.rar using
>>     Resources->Connectors->Connector connection pool->New...
>>     In step 2 when creating the pool enter values for the Additional
>>     Properties named "ConfigFile"&  "HomeDir"
>>     In my setup they are
>>     ConfigFile: /home/pontus/glassfish-3.1.1/jackrabbit/repository.xml
>>     HomeDir: /home/pontus/glassfish-3.1.1/jackrabbit
>>     I just copied the default repository.xml file created when starting a
>>     standalone Jackrabbit and placed it in
>> /home/pontus/glassfish-3.1.1/jackrabbit/
>> 6. Create a new connection resource named "jcr/local" for the
>>     new pool using
>>     Resources->Connectors->Connector Resources->New...
>>
>> If I haven't forgotten anything in the steps above you should now be able
>> to inject a reference directly using
>>
>> @Resource(name="jcr/local")
>> private Repository repository;
>>
>> or look it up like this
>>
>> InitialContext ctx = new InitialContext();
>> Repository repository = (Repository) ctx.lookup("jcr/local");
>>
>> Using it this way you don't need to include any Jackrabbit jars in you
>> ear archive and you don't need to use JcrUtils.
>>
>> /Pontus
>>
>>
>> On 2011-12-21 17:06, Gustavo Henrique Orair wrote:
>>>
>>> I am trying to make JackRabbit JCA work on Glassfish 3.1.1. In production,
>>> my client used JCRUtils.getRepository with an jndi: scheme uri. So I
>>> really
>>> get the JCR Repository from JackRabbit JCA using explicit JNDI lookups
>>> (performed by JndiRepositoryFactory class).
>>>
>>> I successfully make it work if I include the jackrabbit libraries in my
>>> EAR. But it shouldn't be needed and I started to investigate why it
>>> doesn't
>>> work.
>>>
>>> I've checked the code and tried to understand how JackRabbit JCA (Resource
>>> Adapter) created the JCR Repository.
>>>
>>> I asked in Glassfish Users and dev list about these problems (see the
>>> detailed discussion on
>>>
>>> http://www.java.net/forum/topic/glassfish/glassfish/jackrabbit-jca-classloading-issues
>>> ).
>>> And looks like the expected classloading policy used on
>>> org.apache.jackrabbit.client.RepositoryFactoryImpl class is different from
>>> delivered "derived" classloading policy (Since Glassfish 3.1 version, the
>>> Connector Service default policy is "derived" classloading policy) at
>>> least
>>> for this use case.
>>>
>>> They proposed to me try to change the
>>> org.apache.jackrabbit.client.RepositoryFactoryImpl class code from:
>>> Class<?>    repositoryFactoryClass =
>>> Class.forName("org.apache.jackrabbit.core.RepositoryFactoryImpl",
>>> true,Thread.currentThread().getContextClassLoader());
>>> to:
>>> Class<?>    repositoryFactoryClass =
>>> Class.forName("org.apache.jackrabbit.core.RepositoryFactoryImpl");
>>>
>>> Does someone has already these problems? JackRabbit developers may tell me
>>> which are the implications on change the classloader used on
>>> org.apache.jackrabbit.client.RepositoryFactoryImpl from jackrabbit-api
>>> module?
>>>
>>> Best Regards,
>>>
>>> ---------------------------------------------------------------------------------------------------------------------
>>>                                 Gustavo Henrique Orair
>>>
>>> ------------------------------------------------------------------------------------------------------------------
>>>
>>
>>
>
>
>



Mime
View raw message