jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pontus Amberg <pontus.amb...@comhem.se>
Subject Re: Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Tue, 27 Dec 2011 01:51:19 GMT
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