10 Replies Latest reply on Sep 9, 2008 8:25 AM by thomas.diesler

    sar vs ear packaging

    aguizar

      Was there any particular reason to switch back to a sar packaging? IMO, the ear packaging fitted our purposes better - I can't think of properties or operations in the JMX console that would not be better placed in the web console instead.

      More importantly, the ear is portable, at least conceptually. There is evidence in the forums that users are deploying it to every other major appserver, with some minor adaptations, of course.

      There is a third, albeit more distant, advantage to the ear: the ability to resolve ejb and destination references in web.xml through the ejb-link and message-destination-link elements.

        • 1. Re: sar vs ear packaging
          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

            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

              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

                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

                  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

                     

                    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

                      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

                        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

                          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.

                          • 10. Re: sar vs ear packaging
                            thomas.diesler

                            Done.