-
1. Re: sar vs ear packaging
aguizar Sep 5, 2008 8:17 PM (in response to aguizar)I've created JBPM-1717, an issue whose resolution depends on the packaging we settle on.
-
2. Re: sar vs ear packaging
thomas.diesler Sep 8, 2008 4:35 AM (in response to aguizar)Before jumping to a conclusion, I'd like to understand how it *should* work.
Generally, components expose their management interface through JMX. This is how third party management applications connect to JBoss for their management concerns. The jbpm-console might want to duplicate/extend some management aspects. The minimum required set should however be accessible through JMX.
evidence in the forums that users are deploying it to every other major appserver
Lets get this to work properly in JBoss first before we extend the set of Supported Target Containers
http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedTargetContainers
Currently we use the notion of service, to dynamically deploy the jBPM login config.
Except for ejb-link and message-destination-link what does EAR packaging give you? -
3. Re: sar vs ear packaging
tom.baeyens Sep 8, 2008 5:19 AM (in response to aguizar)what i like in Thomas' work is that all of the jboss configurations are inside the deploy/jbpm directory. this is a great improvement over what we had because now we don't need to touch any of the configuration files of jboss installation outside of that.
an ear is an easier starting point for people that want to get it running on other app servers. ideally they would contribute their appserver specific deployment descriptors and the .ear would become deployable out of the box on other app servers.
i don't know if those two options are mutually exclusive. ideal would be a deployment in an ear file with still no configurations outside the deploy/jbpm directory. -
4. Re: sar vs ear packaging
aguizar Sep 8, 2008 10:56 AM (in response to aguizar)Currently we have:
jbpm/ jbpm-console.war/ jbpm-enterprise.jar jbpm-service.sar/ jbpm-hsqldb-ds.xml/
How about:jbpm/ jbpm-enterprise.ear/ jbpm-console.war/ jbpm-enterprise.jar jbpm-service.sar jbpm-hsqldb-ds.xml/
This way we keep the jbpm/ directory, the management interface and the ear's advantages. -
5. Re: sar vs ear packaging
thomas.diesler Sep 8, 2008 11:27 AM (in response to aguizar)But why?
Isn't the enterprise jar supposed to expose some functionality remotely? If so, the console would be a client of that functionality like any other component deployed on the container, like in fact a remote test case.
If test cases could use the enterprise beans to deploy processes remotely, all that cactus stuff would not be needed, right?
So what is the actual benefit of using the ear packaging? From my perspective it only adds another level of component packaging. In fact, since the enterprise beans do not form an integral part with the console alone, it would be quite inappropriate to package them together with the console. -
6. Re: sar vs ear packaging
aguizar Sep 8, 2008 7:36 PM (in response to aguizar)Isn't the enterprise jar supposed to expose some functionality remotely? If so, the console would be a client of that functionality like any other component deployed on the container, like in fact a remote test case. If test cases could use the enterprise beans to deploy processes remotely, all that cactus stuff would not be needed, right?
The enterprise jar exposes the command service remotely, and the jms messaging / ejb scheduler services locally. If test cases were written in terms of commands (the EjbSchedulerTest actually is) then Cactus would not be needed.
Nevertheless, the web console is not written in terms of commands because it is meant to work either standalone or in tandem with the enterprise jar. Because (a) it relies on the local functionality and (b) it is the only client provided with the distribution, it is not like any other client component.So what is the actual benefit of using the ear packaging? From my perspective it only adds another level of component packaging. In fact, since the enterprise beans do not form an integral part with the console alone, it would be quite inappropriate to package them together with the console.
It removes a duplicate set of environment references between the console and the enterprise jar. The console may not be the only possible client, but it is the only official client for sure. The ear packaging does not affect other clients: they bind their references to the JNDI names used by the jBPM enterprise beans and voila. -
7. Re: sar vs ear packaging
camunda Sep 9, 2008 3:42 AM (in response to aguizar)I think the ear is a very convinient way for all people, starting with jBPM and don't knwo too much about deployment, sars & co. And as Tom mentioned, for everybody not using JBoss (which are quite some projects!) it is even more easy to start...
-
8. Re: sar vs ear packaging
thomas.diesler Sep 9, 2008 4:04 AM (in response to aguizar)Bernd,
jBPM3 has a defined set of supported target containers.
http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3SupportedTargetContainers
For this we do QA for others we don't. To state that jBPM will work in arbitrary target containers is an assumption and we cannot base our packaging decisions on that.
The support for various target containers is encapsulated in the installer. i.e. we install jbpm with the installer and QA that installation - no manual or hidden steps involved.
Basically, if a feature is not automatically tested or not properly documented it is not there. -
9. Re: sar vs ear packaging
thomas.diesler Sep 9, 2008 4:06 AM (in response to aguizar)Alejandro,
The enterprise jar exposes the command service remotely, and the jms messaging / ejb scheduler services locally. If test cases were written in terms of commands (the EjbSchedulerTest actually is) then Cactus would not be needed.
Nevertheless, the web console is not written in terms of commands because it is meant to work either standalone or in tandem with the enterprise jar. Because (a) it relies on the local functionality and (b) it is the only client provided with the distribution, it is not like any other client component.
Ok, in that case the ear serves an actual purpose and we should stick to it. I'll do the ear as you suggested. -