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