jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gustavo Henrique Orair <gustavo.or...@econoinfo.com.br>
Subject Re: Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Tue, 27 Dec 2011 12:14:56 GMT
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.


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

                                   Gustavo Henrique Orair
                           EconoInfo Tecnologia da Informação
                           Celular:  55-31-85157887

View raw message