Hi Pontus, Did you try using my small test example? Could you provide your small test?
Br, Orair. 2011/12/29 Pontus Amberg <[email protected]>: > 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 >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------------------------------------------ >>>>>> >>>>> >>>> >>>> >>> >> >> > -- --------------------------------------------------------------------------------------------------------------------- Gustavo Henrique Orair Sócio-Diretor EconoInfo Tecnologia da Informação Celular: 55-31-85157887 ------------------------------------------------------------------------------------------------------------------
