jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gustavo Henrique Orair <gustavo.or...@econoinfo.com.br>
Subject Re: Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Sat, 31 Dec 2011 23:09:14 GMT
Hi Pontus,

Did you try using my small test example?
Could you provide your small test?

Br,
Orair.

2011/12/29 Pontus Amberg <pontus.amberg@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<pontus.amberg@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<pontus.amberg@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
------------------------------------------------------------------------------------------------------------------

Mime
View raw message