Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1063949 - Some EAP static module resources are not loaded by EAP and must be extracted from jar resource
Summary: Some EAP static module resources are not loaded by EAP and must be extracted ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Build and Assembly
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
: ---
Assignee: Roger Martínez
QA Contact: Marek Baluch
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-11 16:52 UTC by Roger Martínez
Modified: 2014-08-06 20:01 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-06 20:01:53 UTC
Type: Bug


Attachments (Terms of Use)

Description Roger Martínez 2014-02-11 16:52:53 UTC
Description of problem:

Problem reported by David Ward from SY.

The following resources for module org.jbpm are not loaded by EAP 6.1.1 when they are present in the ar, they must be extracted as module resource.

Resources:

jbpm-executor-6.0.2-SNAPSHOT.jar
META-INF/Executor-orm.xml

jbpm-human-task-audit-6.0.2-SNAPSHOT.jar
META-INF/TaskAuditorm.xml

jbpm-human-task-core-6.0.2-SNAPSHOT.jar
META-INF/Taskorm.xml

jbpm-kie-services-6.0.2-SNAPSHOT.jar
META-INF/Servicesorm.xml

jbpm-persistence-jpa-6.0.2-SNAPSHOT.jar
META-INF/JBPMorm.xml

Version-Release number of selected component (if applicable):

6.0.2-SNAPSHOT, 6.0.1.ER1

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Kris Verlaenen 2014-02-12 13:40:49 UTC
Roger, our execution server definitely depends on those, so it seems that for BPMS they are being loaded correctly?  Are we talking about automatically picking them up (even if they aren't referenced in the persistence.xml) or isn't it able to pick them up if they are explicit added to the persistence.xml even?

Comment 3 Roger Martínez 2014-02-12 18:33:24 UTC
Hi Kris,

What David comments is that these files (contained in some jars) are not loaded when the jar is inside an static EAP module, it's a known EAP issue.

He tried to copy these object relational mapping (*-orm.xml) files inside the META-INF directory in the org.jbpm module, then the container can load them as are present as a resource in the module.

So theoretically, even if these files are referenced in persistence.xml, the module classloader will contain in its classpath this META-INF directory of the module, with the files, so they will be visible, there should be no problem.

What I don't understand is why we have not detected this issue. We have started process cases and tasks, played with tasks.. etc etc and no issue found related to this.

I'm waiting for David to ask him how did he reproduce it and why we didn't find this issue when testing... that's the key point, because the fix is really easy.

Thanks

(In reply to Kris Verlaenen from comment #2)
> Roger, our execution server definitely depends on those, so it seems that
> for BPMS they are being loaded correctly?  Are we talking about
> automatically picking them up (even if they aren't referenced in the
> persistence.xml) or isn't it able to pick them up if they are explicit added
> to the persistence.xml even?

Comment 4 Lukáš Petrovický 2014-02-13 15:03:10 UTC
From the comments, it appears that we aren't sure if the required changes won't break other components. I am not ACKing this until we have more information - we cannot afford de-stabilizing the product.

Comment 5 David Ward 2014-02-13 18:15:58 UTC
Hi,

Let me try to explain:

I am talking about the lack of visibility of META-INF/*orm.xml files that exist in the various jBPM jars, to applications (like webapps), *when those jars come from AS7 classloading modules*.

Note that this is NOT an issue when all the jBPM jar files are included in the WEB-INF/lib/ of a web application.  This occurs when, instead, the web application needs access to those mapping files but the jBPM jars are loaded using a WEB-INF/jboss-deployment-structure.xml file.

These are the jar files and orm files I'm speaking of:

jbpm-executor-6.0.2-SNAPSHOT.jar
META-INF/Executor-orm.xml

jbpm-human-task-audit-6.0.2-SNAPSHOT.jar
META-INF/TaskAuditorm.xml

jbpm-human-task-core-6.0.2-SNAPSHOT.jar
META-INF/Taskorm.xml

jbpm-kie-services-6.0.2-SNAPSHOT.jar
META-INF/Servicesorm.xml

jbpm-persistence-jpa-6.0.2-SNAPSHOT.jar
META-INF/JBPMorm.xml

If a web app has a jboss-deployment-structure.xml file similar to this (and yes, I've tried various imports/exports):

<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <module name="org.jbpm"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

And a persistence.xml like this:

<persistence ...>
    <persistence-unit name="org.jbpm.persistence.jpa" ...>
        ...
        <mapping-file>META-INF/Executor-orm.xml</mapping-file>
        <mapping-file>META-INF/JBPMorm.xml</mapping-file>
        <mapping-file>META-INF/Servicesorm.xml</mapping-file>
        <mapping-file>META-INF/TaskAuditorm.xml</mapping-file>
        <mapping-file>META-INF/Taskorm.xml</mapping-file>
        ...
    </persistence-unit>
</persistence>

Then you will get this error:

Caused by: javax.persistence.PersistenceException: [PersistenceUnit: org.jbpm.persistence.jpa] Unable to find XML mapping file in classpath: META-INF/JBPMorm.xml
	at org.hibernate.ejb.Ejb3Configuration.addClassesToSessionFactory(Ejb3Configuration.java:1236)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1063)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:293)
	at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:374)
	at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:71)
	at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:63)
	at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:47)

The reason is because the AS7 modules classloading purposely HIDES everything under META-INF, and there really is no way to export them.  The only thing that CAN be exported is META-INF/services/ , because that is handled as a special case.

Sooo...  What can be done?  It appears that so long as AS7 imposes this restriction, the only thing that can be done is to copy those resources (the orm.xml files) outside of META-INF/, "up a path".

What I have successfully tested is:
1) Extract all those orm.xml files
2) Copy them into the modules/system/layers/bpms/org/jbpm/main/META-INF/ directory,
3) Ensure modules/system/layers/soa/org/jbpm/main/module.xml has this element:

<module ...>
    ....
    <resource-root path="META-INF"/>
    ....
</module>

4) Change my application's persistence.xml file to NOT include the META-INF/ path prefix:

<persistence ...>
    <persistence-unit name="org.jbpm.persistence.jpa" ...>
        ...
        <mapping-file>Executor-orm.xml</mapping-file>
        <mapping-file>JBPMorm.xml</mapping-file>
        <mapping-file>Servicesorm.xml</mapping-file>
        <mapping-file>TaskAuditorm.xml</mapping-file>
        <mapping-file>Taskorm.xml</mapping-file>
        ...
    </persistence-unit>
</persistence>

5) Then it works!

Again, you wouldn't see this in the existing brms or bpms consoles or jbpm dashboard, as those application directly include the jbpm jar files inside their WEB-INF/lib/.  This ONLY happens if you try to use "skinny" wars, and point to the jbpm AS7 module using a jboss-deployment-structure.xml.

This is already a known AS7 issue.  But I have to believe it is also a known drools/jbpm issue, considering I already see resources being copied outside of META-INF in other places.  For example:

via <module><resource-root path="META-INF"/></module>:
modules/system/layers/bpms/org/jbpm/main/META-INF/bpsim.xsd
modules/system/layers/bpms/org/jbpm/main/META-INF/drools.xsd

and also:

$ jar tvf jbpm-bpmn2-6.0.2-SNAPSHOT.jar | grep \.xsd
  1906 Sun Feb 09 02:00:02 EST 2014 BPMN20.xsd
  3910 Sun Feb 09 02:00:02 EST 2014 BPMNDI.xsd
  1295 Sun Feb 09 02:00:02 EST 2014 DC.xsd
  3370 Sun Feb 09 02:00:02 EST 2014 DI.xsd
  3991 Sun Feb 09 02:00:02 EST 2014 DiagramDefinition.xsd
  2983 Sun Feb 09 02:00:02 EST 2014 DiagramInterchange.xsd
  1906 Sun Feb 09 02:00:02 EST 2014 META-INF/BPMN20.xsd
  3910 Sun Feb 09 02:00:02 EST 2014 META-INF/BPMNDI.xsd
  1295 Sun Feb 09 02:00:02 EST 2014 META-INF/DC.xsd
  3370 Sun Feb 09 02:00:02 EST 2014 META-INF/DI.xsd
  3991 Sun Feb 09 02:00:02 EST 2014 META-INF/DiagramDefinition.xsd
  2983 Sun Feb 09 02:00:02 EST 2014 META-INF/DiagramInterchange.xsd
 60948 Sun Feb 09 02:00:02 EST 2014 META-INF/Semantic.xsd
 18597 Sun Feb 09 02:00:02 EST 2014 META-INF/bpsim.xsd
  2857 Sun Feb 09 02:00:02 EST 2014 META-INF/drools.xsd
 60948 Sun Feb 09 02:00:02 EST 2014 Semantic.xsd
 18597 Sun Feb 09 02:00:02 EST 2014 bpsim.xsd
  2857 Sun Feb 09 02:00:02 EST 2014 drools.xsd

Those are all examples of resources that are *duplicated*, and I can only imagine it's because of the lack of visibility into META-INF/.

In conclusion, what I'm requesting is for the various jBPM *orm.xml files to also be duplicated.  Either inside the jar itself, or inside the META-INF resource path of the AS7 module.  It doesn't matter to me which way.  But if they aren't duplicated, they simply won't be visible, and SwitchYard will (continue) to have to extract these out and duplicate them ourselves as part of our build process.  But I think since this is a bigger problem then SwitchYard, then it should be done as part of the drools/jbpm build.

Thank you!
David

Comment 6 David Ward 2014-02-13 18:31:58 UTC
Of course, AS7 getting fixed, so that exporting things other than services/ from META-INF/ would actually work - would be the NICEST solution.  Alas...

Comment 7 David Ward 2014-02-14 17:45:29 UTC
The more I think about it, the more I think the best thing to do would be to extract those orm.xml files into the <resource-root path="META-INF"/> directory for the purpose of AS7 module usage, as this fixes a problem directly related to THAT, and not direct usage of the jars. In other words, don't duplicate them in the jars themselves.

Comment 8 David Ward 2014-02-17 19:44:40 UTC
(In reply to David Ward from comment #5)
> ...
> 3) Ensure modules/system/layers/soa/org/jbpm/main/module.xml has this
> element:
> ...

Typo.  I meant: modules/system/layers/bpms/org/jbpm/main/module.xml

Comment 9 David Ward 2014-03-25 17:43:26 UTC
Update: This will no longer be an issue in SwitchYard from 2.0 moving forward.  On Feb 10, 2014, I submitted a build change so that these orm xml files are extracted from the bpms eap module jars and included in the switchyard-component-bpm one, so all an application has to do now is have a META-INF/jboss-deployment-structure.xml file with this dependency :<module name="org.switchyard.component.bpm" meta-inf="import"/> . The change was done in associate with jira: SWITCHYARD-1955.

Comment 10 David Ward 2014-03-25 17:44:48 UTC
Sorry the date was wrong above. It was merged into master on March 13, 2015.

Comment 11 David Ward 2014-03-25 17:45:18 UTC
2014! (reaches for coffee...)

Comment 12 Roger Martínez 2014-03-25 18:25:24 UTC
As David commented, this issue is no longer present and can be closed.

Moving it to modified.

Thx


Note You need to log in before you can comment on or make changes to this bug.