Hi Gustavo,
If you have a <resource-ref> to a connector-resource of JackRabbit-RAR
in the application (either via @Resource or via the descriptor as Sahoo
stated), the application will be able to see the RAR classes. (Thread
context classloader should be application's classloader in this case and
it will have RAR's classloader in the parent's chain).
Yes, "derived" is the default class-loading policy. You can try setting
it to "global" to see whether it works fine. Later, once you have the
<resource-ref> defined the application's descriptor (or @Resource), the
RAR will be available to the application.
Reference:
http://docs.oracle.com/cd/E18930_01/html/821-2418/bealr.html#gjjyy
Thanks,
-Jagadish
On Wed, 2011-12-21 at 11:23 -0200, Gustavo Henrique Orair wrote:
> Hi Sahoo, thanks for your prompt response!
>
> Regarding your comment about my ejb seems to be accessing jackrabbit
> jca rar classes directly, my ejb uses just the JcrUtils.getRepository
> code. This class is provided by the jackrabbit-jcr-commons module.
> Inside this jackrabbit-jcr-commons module there is also a
> JndiRepositoryFactory class, this class should be found by the
> ServiceRegistry.lookupProviders(RepositoryFactory.class) and make an
> explicit JNDI lookup (as I used an URI with jndi: scheme). My ejb just
> need the jackrabbit-jcr-commons dependency and in fact, using this
> approach, I am not tied to JackRabbit implementation and could use any
> other JCR implementation (jackrabbit-jcr-commons module just use JCR
> API code). This is exactly the EAR3 use case I have provided in my
> first e-mail. Based on your concerns, this use case seems to fail
> because the explicit JNDI lookup couldn't get the JCR Repository.
>
> The problem seems to be really concerned (as you said in your first
> e-mail) as how org.apache.jackrabbit.client.RepositoryFactoryImpl
> class (inside jackrabbit-api module shipped with JackRabbit-JCA) try
> to load the org.apache.jackrabbit.core.RepositoryFactoryImpl class
> (inside jackrabbit-core module shipped with JackRabbit-JCA) since it
> uses Thread.currentThread().getContextClassLoader() instead of the
> default classLoader. Notice that the
> org.apache.jackrabbit.client.RepositoryFactoryImpl class is used in
> multiple different environments, not just J2EE or Glassfish, etc.
>
> My conclusion is that Glassfish's default class loading policy
> (derived) is incompatible with classloading policy expected by the
> jackrabbit-api module.
>
> Anyway, I will give your suggestion a try and change the code from
> org.apache.jackrabbit.client.RepositoryFactoryImpl class inside
> jackrabbit-api module to use the default classloader instead of
> Thread.currentThread().getContextClassLoader() while loading the
> org.apache.jackrabbit.core.RepositoryFactoryImpl class. But Apache
> Jackrabbit developers will probably argue this would break all other
> uses of this class in other environments.
>
> ---------------------------------------------------------------------------------------------------------------------
> Gustavo Henrique Orair
> Mestre em Ciência da Computação - MSc in Computer Science
> Universidade Federal de Minas
> Gerais
> Celular/Cell phone: 55-31-85157887
> ------------------------------------------------------------------------------------------------------------------
>
>
> 2011/12/20 Sahoo <sanjeeb.sahoo_at_oracle.com>
> No, it is not a bug. Your ejb modules does not have any
> resource references that are satisfied by jackrabbit rar. Your
> ejb seems to be accessing jackrabbit jca rar classes directly
> using jackrabbit API called JCRUtils and GlassFish has no idea
> that this dependency comes from jackrabbit rar. Add @Resource
> to your ejb to a jackrabbit rar supplied connection factory
> for the class loader to detect the dependency.
>
> Sahoo
>
> On Tuesday 20 December 2011 11:39 PM, Gustavo Henrique Orair
> wrote:
> > I checked the j2EE6 specification for classloading
> > behaviour.
> > In section 8.3.2 - EJB Container Class Loading Requirements
> > it states:
> >
> > "Components in the EJB container must have access to the
> > following classes and resources.
> > (...)
> > * The contents of all jar files included in each resource
> > adapter archive (rar file) deployed separately to the
> > application server, if that resource adapter is used to
> > satisfy any resource references in the module.
> > (...)"
> >
> > So, the behaviour I found in Glassfish seems like not J2EE6
> > compliant.
> >
> > Should I file a bug?
>
>
>