jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gustavo Henrique Orair <gustavo.or...@gmail.com>
Subject Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Wed, 21 Dec 2011 16:06:16 GMT
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

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
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<?> repositoryFactoryClass =

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

Best Regards,
                               Gustavo Henrique Orair

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message