jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pontus Amberg <pontus.amb...@comhem.se>
Subject Re: Conflict between expected classloading behaviour on jackrabbit-api and default classloading Glassfish Policy
Date Thu, 29 Dec 2011 22:29:59 GMT
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
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>
>>>
>>>
>>
>
>


Mime
View raw message