The only injection I had in the small test I made was an injection of
the EJB reference in the servlet that accessed the EJB. Otherwise
there were no other injection and the jndi lookup worked fine.
/Pontus
On 2011-12-27 16:00, Gustavo Henrique Orair wrote:
Hi Pontus,
I use JcrUtils because my Crawler class where I "inject" the JCR
repository were developed to be used both in J2SE and J2EE
environment.
So, I have a .properties file that inform the uri to be used to get
the JCR repository. In tests and J2SE environment, I specify a "file:"
scheme and in production and J2EE environment I just change the uri to
a "jndi:" scheme.
Did you check if there is no injection (annotation or deployment
descriptor) in your project when you tested the explicit Jndi lookup?
Please, double check this.
As I discussed with Glassfish developers, if glassfish finds at least
one injection inside the EAR client, it will put the resource adapter
available to the application.
If you confirm that explicit Jndi lookups works without any resource
injection inside the same application project, could you give a try in
the ears I've filed in Glassfish issue?
http://java.net/jira/browse/GLASSFISH-18082 or
http://java.net/jira/secure/attachment/48733/useJackrabbitJCA-ROOT.tar.gz
to access the file directly.
Thanks for your attention,
Orair.
2011/12/27 Pontus Amberg<[email protected]>:
I tested with a direct lookup
InitialContext ctx = new InitialContext();
Repository repository = (Repository) ctx.lookup("jcr/local");
and that worked. Why do you want to use JcrUtils?
/Pontus
On Tue Dec 27 13:14:56 2011, Gustavo Henrique Orair wrote:
Pontus,
thank you for your attention.
As I said, I am using JCRUtils.getRepository with an jndi: scheme uri.
It results in an explicit JNDI lookup for the resources that is
different from your approach (using injection).
The derived classloading policy states that the libraries inside
resource adapter would be available to the application "clients" if
there is a reference on the application to the resource adapter.
Since I am using explicit JNDI lookups, Glassfish doesn't find this
"reference" and the resource adapter doesn't work.
Just as a reference if someone find this page facing similar problems,
I've created an issue on Glassfish
http://java.net/jira/browse/GLASSFISH-18082 .
Btw, I will comment on this issue stating that some JackRabbit users
successfully used Jackrabbit-JCA using injection.
Br,
Orair.
2011/12/26 Pontus Amberg<[email protected]>:
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
------------------------------------------------------------------------------------------------------------------
