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