You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Gustavo Henrique Orair <gu...@econoinfo.com.br> on 2012/01/01 00:09:14 UTC
Re: Conflict between expected classloading behaviour on
jackrabbit-api and default classloading Glassfish Policy
Hi Pontus,
Did you try using my small test example?
Could you provide your small test?
Br,
Orair.
2011/12/29 Pontus Amberg <po...@comhem.se>:
> 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<po...@milso.se>:
>>>
>>> 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<po...@comhem.se>:
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
---------------------------------------------------------------------------------------------------------------------
Gustavo Henrique Orair
Sócio-Diretor
EconoInfo Tecnologia da Informação
Celular: 55-31-85157887
------------------------------------------------------------------------------------------------------------------
Re: Conflict between expected classloading behaviour on jackrabbit-api
and default classloading Glassfish Policy
Posted by Pontus Amberg <po...@comhem.se>.
Here's a small test for Jackrabbit JCA lookup in Glassfish. To try it out
follow these steps
1. Deploy Jackrabbit JCA in Glassfish as I described in my first response.
Make sure that the connection resource is named "jcr/Repository" as
that is the name used by the EJB in the attached example.
2. Unzip the attached example and build it with Maven "mvn install"
3. Deploy the JcaJackrabbitEar-1.0.0-SNAPSHOT.ear file found in
/JcaJackrabbitEar/target/ to Glassfish
4. You should now be able to access a webapp at
http://localhost:8080/JcaJackrabbitWeb that contains a link
that will create a new Node in the repository using the value
of the parameter "name" as the name of the new node.
/Pontus
On 2012-01-01T00:09:14 CET, Gustavo Henrique Orair wrote:
>
> Hi Pontus,
>
> Did you try using my small test example?
> Could you provide your small test?
>
> Br,
> Orair.
>
> 2011/12/29 Pontus Amberg<po...@comhem.se>:
>>
>> 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<po...@milso.se>:
>>>>
>>>>
>>>> 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<po...@comhem.se>:
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>