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