Correct persistence.xml for embedded KIE in my EJB?

[jay.guidos-bidstrading.com]

Hi All,

I have a JBOSS EAR project where I want to access KIE from an EJB.  The EJB will be responsible for loading deployments, starting sessions, kicking off processes etc.

I closely followed the integration outlined in Chapter 20: Integration, but that chapter does not mention what persistence.xml is required.  The examples refer to a persistence unit named org.jbpm.domain, which happens to be the name of the persistence unit defined in jbpm-console.war.  I stripped that XML file out of the war and stuffed it in my EJB and it seems to work.  My questions are:

1. Is that a good persistence.xml to use?
2. is there a better way to get an integration-capable persistence.xml file included into my EJB?

The examples were terse but helpful.  A POM you could distribute that did an example JBOSS application with KIE integrated into the EJB would be fairly easy to make (for someone better acquainted with the API than I am) and would be very useful.

[swiderski.maciej]

Jay Guidos wrote:

Hi All,

I have a JBOSS EAR project where I want to access KIE from an EJB.  The EJB will be responsible for loading deployments, starting sessions, kicking off processes etc.

I closely followed the integration outlined in Chapter 20: Integration, but that chapter does not mention what persistence.xml is required.  The examples refer to a persistence unit named org.jbpm.domain, which happens to be the name of the persistence unit defined in jbpm-console.war.  I stripped that XML file out of the war and stuffed it in my EJB and it seems to work.  My questions are:

1. Is that a good persistence.xml to use?

yes, it includes all entities that you might be using in your system as kie-wb/jbpm-console provides all the functionality

Jay Guidos wrote:

1. is there a better way to get an integration-capable persistence.xml file included into my EJB?

that pretty much depends on your needs, the one taken from console/kie-wb has all entities defined (including bam summary data or task audit) which might or might not be really important for your use case. So removing some of the entities could be reasonable in some cases but there are just two or three of them.

Jay Guidos wrote:

The examples were terse but helpful.  A POM you could distribute that did an example JBOSS application with KIE integrated into the EJB would be fairly easy to make (for someone better acquainted with the API than I am) and would be very useful.

that sounds like a nice contribution, of course cooperation with the jbpm team is included so if you would like to work on that let me know.

HTH

[jay.guidos-bidstrading.com]

Hi Maciej,

Sure I would be happy to provide an example project that showed KIE presented as an EJB, with deployments controlled by a little REST module.

Give me the repo you want me to fork out from and in a couple of days I will get you a pull request. 

BTW I used a deployment service to manage deployments, but I could not use KModuleDeploymentService (jbpm-kie-services).  There is a bug/limitation in that class that allows a KJar to be deployed only once. Our requirement is to have many Runtimes attached to a module where each is effectively a singleton with a different collection of facts in each.  Your new KIE Runtime management handles this nicely by simply redeploying to get multiple Runtimes, but the internals of KModuleDeploymentService index by GAV instead of the supplied runtime ID.  So even though I give different runtime IDs for each deployment to signal I want a different instance, I get an exception complaining about duplicate GAVs.

I patched KModuleDeploymentService to index on runtime ID instead of GAV (as it implies it does) and it works great.

Jay 

[swiderski.maciej]

Jay Guidos wrote:

Hi Maciej,

Sure I would be happy to provide an example project that showed KIE presented as an EJB, with deployments controlled by a little REST module.

Give me the repo you want me to fork out from and in a couple of days I will get you a pull request.

great! Feel free to form this one for now.

Jay Guidos wrote:

BTW I used a deployment service to manage deployments, but I could not use KModuleDeploymentService (jbpm-kie-services).  There is a bug/limitation in that class that allows a KJar to be deployed only once. Our requirement is to have many Runtimes attached to a module where each is effectively a singleton with a different collection of facts in each.  Your new KIE Runtime management handles this nicely by simply redeploying to get multiple Runtimes, but the internals of KModuleDeploymentService index by GAV instead of the supplied runtime ID.  So even though I give different runtime IDs for each deployment to signal I want a different instance, I get an exception complaining about duplicate GAVs.

I patched KModuleDeploymentService to index on runtime ID instead of GAV (as it implies it does) and it works great.

Jay

don't think that KModuleDeploymentService needs to be patched as it simply relies on the DeploymentUnit you want to deploy on it. So I guess extending KModuleDeploymentUnit and overriding getIdentifier() method should do the trick.

HTH

[jay.guidos-bidstrading.com]

Hi Maciej!

Well that was the bug, because I had exactly the same idea you just suggested.

Here is the part of KModuleDeploymentService that messes up:

        KModuleDeploymentUnit kmoduleUnit = (KModuleDeploymentUnit) unit;

        DeployedUnitImpl deployedUnit = new DeployedUnitImpl(unit);

        KieServices ks = KieServices.Factory.get();

        MavenRepository repository = getMavenRepository();

        repository.resolveArtifact(kmoduleUnit.getIdentifier());

You see here that instead of looking up the module in the repo by GAV it looks it up by identifier, forcing the identifier to be a GAV.  There is no contract that the identifier be a GAV anywhere, but this code assumes it is one.

My patch was to form the GAV from the DeploymentUnit contents when I wanted to look up the module.

        ReleaseId releaseId = ks.newReleaseId(kmoduleUnit.getGroupId(), kmoduleUnit.getArtifactId(), kmoduleUnit.getVersion());

        MavenRepository repository = getMavenRepository();

        repository.resolveArtifact(releaseId.toExternalForm());

Jay

[swiderski.maciej]

Jay, could you point me out the line that it uses GAV and not DeploymentUnit.getIdentifier()? I am looking through the code and can't find any place where it does so. The map is actually in the AbstractDeploymentService and it cannot be bound to GAV there any more. Or I am totally blind....

[jay.guidos-bidstrading.com]

Hi Maceij,

My answer was slightly unclear - I edited my response to show you the problem code area.

Jay

[swiderski.maciej]

good catch, could you please file jira issue with that and if you like pull request as well?

Thanks

[jay.guidos-bidstrading.com]

JIRA: https://issues.jboss.org/browse/JBPM-4216

Pull Request: https://github.com/droolsjbpm/jbpm/pull/186

Jay