JBoss 6 & Persitence Archive in WEB-INF/lib

[vincent_aumont]

Hello,

I have a persitence jar that I want other jars in my web-app n(packaged as a war)  to use:

{code}
my-war
 +--WEB-INF
       +-- lib
             A.jar
             persistence.jar
             Z.jar
{code}

The persistence unit defined in persistence.jar is injected in Stateless beans in A.jar in Z.jar like so:

{code}
@Stateless
public class ABean {
 @PersistenceContext(unitName =  "my-pu")
  EntityManager em;
}
@Stateless
public class ZBean {
 @PersistenceContext(unitName =  "my-pu")
  EntityManager em;
}
{code}

Now, Jboss 6 (I'm using 6.0.0.Final) scans the jars in web-inf/lib in alphabetical order, and tries to locate the persistence unit at load time.

So,  it fails to scan A.jar because it cannot find the persistence unit (as  persitence.jar hasn't been scanned yet).

If I remove A.jar, everything works fine because  the persistence unit has been started by the time jboss scans Z.jar.

1) Can a persistence unit defined in a jar under web-inf/lib  be accessed by other jars in web-inf/lib?

2) If yes, how can I tell jboss to load the PU jar first?

3) If not, is the solution to perform a jndi look-up to retrieve the entity manager, instead of injecting it?

Thanks,

Vincent

[alesj]

I doubt the order has anything to do with this.

As we scan things in a different stage then where we do the wiring.

The real cause may be hidden somewhere else,

unfortuantely I don't have any idea where that might be. :-)

[asiandub]

Dan Allen just blogged about about a similiar issue with Glassfish / JEE 6. I doubt that this is related, but as I happen to read both articles within 30 minutes or so, I provide the link...

http://in.relation.to/Bloggers/IsSeam3GoingToBePortableOrWhat#H-AlphabravoVisibility

Cheers,

Jan

[alesj]

How is this related?

Afaik VincentA is not using Seam nor CDI, but plain per-spec web-profile behavior.

[vincent_aumont]

Jan, Ales,

Not related, but similar.

The issue Dan describes is:

• in certain cases, types (classes) in one bean archive (jar) aren't visible to beans and extensions in another jar in a web module
• visibility is dependent on the alphabetic order of the archive names

which is what I'm observing with AS 6.

I would expect jboss to start all Persistence Units it finds in web-inf/lib/*.jar before doing the wiring (@PersistenceContext(unitName =  "my-pu")). It is clearly not the case.

It start smelling like a bug.

I guess the workaround is to 1) rename my persistence jars so that the are scanned first or (2) stopusing  @PersistenceContext and do a lookup instead

Vincent

[alesj]

Are you using Seam3/CDI?

I think .war visibility issues are mostly related to GlassFish,

as BeanManager wiring is done differently as how we do it in JBossAS6.

* WELD-846

[vincent_aumont]

I'm not using seam, but I use CDI.Should I try to upgrade Weld?

[vincent_aumont]

Making progress: when I have two entities jars (i.e. 2 persistence.xml files) in WEB-INF/lib, only the persistence unit from the first jar is started.

My war file has the following structure:

{code}
my-war
  +-- WEB-INF
     +-- lib
        +-- pu1.jar
           +-- META-INF
              + persistence.xml
        +-- pu2.jar
           +-- META-INF
              + persistence.xml
 {code}

pu1.jar's persistence.xml:

{code}
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="pu1" >
     <jta-data-source>java:/DefaultDS</jta-data-source>
  </persistence-unit>
</persistence>
{code}

pu2.jar's persistence.xml:

{code}
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="pu2" >
     <jta-data-source>java:/DefaultDS</jta-data-source>
  </persistence-unit>
</persistence>
{code}

When I deploy this file, only the first PU is started:

{code}
12:23:38,192 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=webapp-1.0-SNAPSHOT.war#pu1
{code}

If I rename pu2.jar 'apu2.jar' (so that it is scanned first), only the pu2 PU is started:

{code}
12:37:15,631 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.unit:unitName=webapp-1.0-SNAPSHOT.war#pu2
{code}

I tried using two different data sources but it didn't help.

Having JPA entities in the jars does not help either.

Any idea who jboss 6 doesn't process the second entities jar?

[vincent_aumont]

Attaching the war file.

[alesj]

Any idea who jboss 6 doesn't process the second entities jar?

I think this is by design -- see PersistenceUnitParsingDeployer.

It only parses the first persistence.xml it finds in (sub)deployment.

If you would re-organize / re-structure your app,

so that it's 1 persistence.xml per sub-deployment,

it will pick up all of them.

e.g.

An .ear with N jars with persistence.xml and X .wars.

[vincent_aumont]

And if I have a pu in WEB-INF/classes/META-INF, it's the one that gets started:

{code}
my-war
  +-- WEB-INF
     +-- classes
        +-- META-INF
           + persistence.xml
     +-- lib
        +-- pu1.jar
           +-- META-INF
              + persistence.xml
        +-- pu2.jar
           +-- META-INF
              + persistence.xml
{code}

Is this behaviour documented somewhere? I don't understand why it was implemented that way.

I also noticed that when jboss does not start my PU's, it starts the timerdb PU from $JBOSS_HOME/common/deploy/jboss-ejb3-timerservice-mk2.jar/ . Should not jars in common/lib be considered as different sub-deployment?

Another workaround -if I want to keep packaging my app as a war- would be add a persistence.xml in WEB-INF/classes/META-INF and load all entities contained in pu1.jar and pu2.jar  with <jar-file>.

Of course it'll wotk only if all my PU's use the same data source.

[vincent_aumont]

Hi Ales,

I read  the JPA spec again, and I think starting only the first PU in a sub-deployment is non-compliant.

Clearly, we can have several persistence jars whithin a war:

{code}
(from section 6.2)
A persistence unit may be packaged within one or more jar files 
contained within a WAR or EAR, as a set of classes within an 
EJB-JAR file or in the WAR classes directory, or as a combination 
of these as defined below.
{code}

The only reason why you'd need an ear file is if your PU contains classes outside of the jar:

{code}
(from section 6.2)
It is not required that an EJB-JAR or WAR containing a persistence
 unit be packaged in an EAR unless the persistence unit contains 
persistence classes in addition to those contained in the EJB-JAR 
or WAR. See Section 6.2.1.6.
{code}

And it's clear that the container must process all persistence.xml files, not just the first one:

{code}
7.1.1    Responsibilities of the Container
At deployment time the container is responsible for scanning the 
locations specified in Section 6.2 and discovering the persistence.xml 
files and processing them.

When the container finds a persistence.xml file, it processes the 
persistence unit definitions that it contains.
{code}

[alesj]

Let me check how hard would it be to replace current deployer's behavior.

[jaikiran]

Ales Justin wrote:

Any idea who jboss 6 doesn't process the second entities jar?

I think this is by design -- see PersistenceUnitParsingDeployer.

It only parses the first persistence.xml it finds in (sub)deployment.

my-war
  +-- WEB-INF
     +-- classes
        +-- META-INF
           + persistence.xml

     +-- lib
        +-- pu1.jar
           +-- META-INF
              + persistence.xml
        +-- pu2.jar
           +-- META-INF
              + persistence.xml

Isn't pu1.jar and pu2.jar considered as 2 different sub deployments in this case?

[alesj]

Isn't pu1.jar and pu2.jar considered as 2 different sub deployments in this case?

Nope, they are just 2 entries in .war's classpath.

(or 2 more roots in its classloader)