Bug 1017327

Summary:	Deployment descriptor per deployment
Product:	[Retired] JBoss BPMS Platform 6	Reporter:	Kris Verlaenen <kverlaen>
Component:	jBPM Core	Assignee:	Alessandro Lazarotti <alazarot>
Status:	CLOSED EOL	QA Contact:	Marek Baluch <mbaluch>
Severity:	low	Docs Contact:
Priority:	medium
Version:	6.0.0	CC:	althomas, athomas, ddoyle, eschabel, jbride, paradhya, rrajasek, smcgowan
Target Milestone:	ER3
Target Release:	6.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-27 20:04:41 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kris Verlaenen 2013-10-09 15:50:35 UTC

We should have some sort of deployment descriptors and the deployment service would make the plumbing based on that descriptor. So with that descriptor we could configure following:
- class loading, what besides the normal dependencies defined should be added to class loader of the project
- what persistence unit it shall use
- shall it use persistence at all (something that Jeff mentioned on early access list)
- logger - JPA, JMS, none
- strategy (singleton, per process instance, per request)
- work item handler configuration (and other session configurations)
- interceptors?
- might be more

Such a descriptor could be added:
 - to the kjar
 - related to a deployment (system repo?)
 - as default (where the defaults should be configurable themselves as well)

Comment 1 Kris Verlaenen 2013-10-09 15:51:39 UTC

Future feature

Comment 3 Prakash Aradhya 2013-10-17 17:46:41 UTC

Its the stuff that helps with system administration also.
JON like tool can take advantage of these descriptors.

Comment 4 Kris Verlaenen 2014-02-03 00:52:30 UTC

One more could be initializing various types of listeners.

It would also be useful to make sure that these deployment descriptors, when part of the kjar, can be inherited (basically all deployment descriptors of dependent jars would be combined with the deployment descriptor of the jar itself, would need to be to detect / handle conflict though).

Comment 5 Eric D. Schabell 2014-02-14 10:59:28 UTC

I think all the various grains of control are what you strive for:

- configure it per project
- configure it per deployment (then have a way for the project to select the deployment to run in)
- per server such as the default is always per_instance if not defined instead of SINGLETON as is now.

I guess the solutions offered in previous posts would all be possible and may be desirable depending on the above configuration needs:

- configure per project (in the kjar)
- configure per deployment (via UI, some xml file on server to override defaults)
- configure per server (same as deployments?)

If you use kjars and allow dependencies, what level wins? project or deployment or server overrides? 

Just my thoughts after playing with it a bit today.

Comment 6 Maciej Swiderski 2014-05-12 09:20:26 UTC

deployment descriptors have beed added to 6.1 code base, for those interested here are some docs about it: http://hudson.jboss.org/hudson/view/Drools%20jBPM/job/droolsjbpm-knowledge/lastSuccessfulBuild/artifact/kie-docs/jbpm-docs/target/docbook/publish/en-US/html/jBPMRuntimeManagement.html#d0e10446

feedback more than welcome

Comment 7 jbride@redhat.com 2014-05-12 12:05:38 UTC

very nice!!

Comment 8 Eric D. Schabell 2014-05-12 13:11:26 UTC

Excellent addition!

Comment 9 Marek Baluch 2014-12-15 12:56:39 UTC

Verified on 6.1.0.ER3.

The feature is present.