4 Replies Latest reply on Sep 27, 2006 7:56 AM by Tom Baeyens

    removing the sar packaging

    Tom Baeyens Master

      i'm going remove the sar packaging unless someone can show me the need for a sar package.

      here's my reasoning:

      The sar is only used to publish a JbpmConfiguration in JNDI. I currently don't see why we can't use the static singleton pattern for that.

      If we need something for publishing into JNDI, i would prefer the use of a JCA resource archive instead. With that, we can do the same in a standard way that is supported on other app servers as well. But that doesn't have a high priority for me.

      I realize that BPEL still has a dependency on the sar package. Alex, is it OK if i do the work of doing all the updates and that you check if everything works. We could organize a time when i commit and that we can review together afterwards.

      Am i missing some crucial advantage of the sar packaging ?

        • 1. Re: removing the sar packaging
          Alejandro Guizar Master

          There are a number of features we'd lose: the managed lifecycle, the nice packaging of libraries and configuration files. Not to mention consistency with the deployment model of other JBoss products (JBossWS for instance) or the clean report of missing dependencies (e.g. the datasource).

          For someone who is used to these features, this will be a bad surprise. Why not retain the convenience of the service archive until the JCA-based alternative becomes available?

          • 2. Re: removing the sar packaging
            Tom Baeyens Master

            i don't think we currently use or need managed lifecycle. the thing that we might use eventually is have a convenience for verifying and optionally creating the database upon start of the sar. but that would equally be possible with a static singleton pattern.

            i disagree with the nice packaging of configuration files. it's for the sar that we have to wrap the configuration files in a jar file. i would prefer them to be easier editable. (not in a jar file).

            i'm not yet convinced on the consistency argument. while that is true from a jbossWS standpoint, i think that common knowledge is more important. average developers know how .war's and .ears are composed. but they typically don't know how a .sar works.

            missing datasource will also be reported in case of static singlton instance.

            overall, i'm just in the middle, i think. no necessity to keep it in, and not a big issue to take it out.

            I didn't really specified my main argument, which is simplification of the deployment model. Reduce jBPM maintenance and reduce the ways how our users can screw up.

            would you have a problem with accessing jBPM through the static singleton ?

            • 3. Re: removing the sar packaging
              Alejandro Guizar Master

              Not at all. Providing a simple, unique, portable deployment model is a good idea.

              I'd like to see a model where adding bpel capabilities to a jbpm installation only required throwing in the bpel jar. The hibernate configuration is an issue. Isn't there a way to discover mapping files automatically? It'd be great if users could only specify the connection properties and let Hibernate find the mapping resources.

              Suddenly I'm starting to like this 'return' to the jBPM-as-a-library-only concept.

              • 4. Re: removing the sar packaging
                Tom Baeyens Master

                i believe we should go for 2 default deployments: 1 ear file to deploy bpel and one ear file to deploy jbpm. both of these could optionally also be offered as web archives.

                hibernate configurations will always have to be separate for jpdl as for bpel. so we can't offer a drop-in type of addition to enhance a jpdl to a bpel. it will always have to be a replacement. but since bpel > jpdl, this should be easy.

                but we should minimize the number of variations that we offer.

                the jboss packages will already have to be customized to jboss, since jboss has got hibernate in it's global class path.

                so i would pick one type of package .ear or .war and use that as the default distribution package. then describe how to tweak the libs in case of deployment on other servers. then describe how to make .sar or other packages from that. optionally supported by means of ant scripts.