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?
>
>
>