Bug 842452 - JBoss Modules for BRMS Components
JBoss Modules for BRMS Components
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Build and Assembly (Show other bugs)
Unspecified Unspecified
urgent Severity unspecified
: ER5
: 6.0.0
Assigned To: Ryan Zhang
Lukáš Petrovický
Depends On:
  Show dependency treegraph
Reported: 2012-07-23 17:50 EDT by Jeffrey Bride
Modified: 2014-08-06 16:16 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:16:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeffrey Bride 2012-07-23 17:50:05 EDT
  the purpose of this BZ is to discuss the possibility of packaging BRMS web artifacts targeted for EAP 6 / AS 7 such that they leverage the JBoss modules architecture.
  leveraging the JBoss modules architecture would be a departure from the existing approach where each BRMS web artifact for AS7 is self-contained with all jbpm5/drools/mvel libraries that the web artifact needs

the reason for this request is primarily to prevent potential Drools class inconsistency problems that still exist even in an EAP6/AS7 environment.

for example, in assisting Jeff Delong support one of our partners .... we came across the following exception :

java.io.InvalidClassException: org.drools.rule.constraint.MvelConstraint; local class incompatible: stream classdesc serialVersionUID = 2788259769774369539, local class serialVersionUID = -5171063419941396016

this problem was caused in a Switchyard environment (which integrates jbpm5/drools) when the knowledge agent in our switchyard service attempted to query guvnor and build a KnowledgeBase from those results.

this problem was resolved by upgrading the drools libraries found in Switchyard's  $EAP6_HOME/modules/org/drools directory such that those libraries are consistent with the drools libraries embedded in the WEB-INF/lib directory of the guvnor web archive in use.  (background:  Switchyard packages drools/jbpm5 dependencies as JBoss modules )

however, it would be really nice if instead of trying to coordinate drools libraries that switchyard deploys as modules with libraries buried in  guvnor's web archive ...... BRMS itself included a script that configures JBoss modules.
Projects building upon BRMS in EAP 6, along with BRMS's own web artifacts, could all then leverage the exact drools/jbpm5 module dependencies.

thoughts ?

thank you,    jeff
Comment 2 Jeffrey Bride 2012-07-31 10:32:14 EDT
one more additional comment :

seems that it would be important to keep in mind a customer's EAP6.* environment built using BRMS-Deployable, in particular.

so in addition to a WEB-INF/jboss-deployment-structure.xml added to each BRMS web archive .... maybe an extension to jbpm-installer/build.xml such that it provisions the target ${jboss.home}/modules  directory with the appropriate drools/jbpm5/mvel modules ?
Comment 3 Jeffrey Bride 2012-07-31 12:10:23 EDT
looks like we have several parallel efforts (from various projects all downstream to brms deployable) accomplishing pretty much the same thing (provisioning an AS7/EAP6 runtime with jbpm5/drools modules):

Maciej's ant-based approach :

PFP's ant-based approach :
https://github.com/jboss-sso/processFlowProvision/blob/master/config-build.xml (in particular the "configure.jboss.modules" target )

switchyard's maven-based approach:
Comment 4 Marco Rietveld 2012-09-13 09:04:49 EDT
Starting with 5.3.1, we'll be producing EAP6/AS7 compatible wars (that use JPA2 and do NOT package Hibernate 3 in the wars). 

Given that we have that as a starting point, this should be a lot easier, right? 

The approach used for the EAP6 war creationg currently produced is maven/assembly based. @jbride: thanks for the link to the switchyard configuration, it looks like we can use that.
Comment 5 Jeffrey Bride 2013-04-06 08:32:49 EDT
as an example, the switchyard project provides the following distribution of JBoss modules specific to their project :

providing a similar distribution of jbpm6 modules would be perfect.
Comment 6 Ryan Zhang 2013-04-08 02:48:30 EDT
This is exactly what we need to do for BRMS/BPMS 6.
 Could we move the "product" field to "BRMS Platform 6" and BPMS Platform 6" instead of "BRMS 5"?
Comment 9 Marek Baluch 2013-10-15 01:55:41 EDT
${summary} says BRMS -> moving to product BRMS
Comment 11 Lukáš Petrovický 2013-11-23 16:25:31 EST
ER5 includes the modularization work. The fallout (if any) will be filed as separate regression bugs.

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