12 Replies Latest reply on Feb 20, 2008 8:04 AM by Thomas Diesler

    Simplify deploy/undeploy cycles for different stacks

    Thomas Diesler Master

      This relates to

      http://jira.jboss.org/jira/browse/JBWS-1982



      This need to be looked at again.

      * The knowledge of how to (un)deploy stack X should not leak into framework
      * If AS has stack X.0.0 deployed and you want to deploy stack Y.0.1, how can framework that comes with Y.0.1 know how to undeploy X.0.0?


      One possible solution I see is to use the same set of (file) artifacts for all supported stacks. i.e. The SAR would always be called jbossws.sar

      In which case we won't need an undeploy at all, simply deploying the respective stack should be sufficient.

      This of course relies on the idea that everything is contained within that top-level deployment and no additional artifacts are splattered around lib, bin, etc

      Comments?

        • 1. Re: Simplify deploy/undeploy cycles for different stacks
          Thomas Diesler Master

          AFAICS client jars would be the problem with this approach

           <!-- CLIENT JARS -->
           <copy todir="${jboss501.home}/client" overwrite="true">
           <fileset dir="@{stacklibs}">
           <include name="jboss-jaxrpc.jar"/>
           <include name="jboss-jaxws.jar"/>
           <include name="jboss-jaxws-ext.jar"/>
           <include name="jboss-saaj.jar"/>
           <include name="jbossws-client.jar"/>
           </fileset>
           <fileset dir="@{thirdpartylibs}">
           <include name="policy.jar"/>
           <include name="jaxb-api.jar"/>
           <include name="jaxb-impl.jar"/>
           <include name="jaxb-xjc.jar"/>
           <include name="jaxws-tools.jar"/>
           <include name="jaxws-rt.jar"/>
           <include name="stax-ex.jar"/>
           <include name="streambuffer.jar"/>
           <include name="wsdl4j.jar"/>
           </fileset>
           </copy>
           <copy todir="${jboss501.home}/lib" overwrite="true">
           <fileset dir="@{thirdpartylibs}">
           <include name="jaxb-api.jar"/>
           <include name="jaxb-impl.jar"/>
           </fileset>
           </copy>
          


          • 2. Re: Simplify deploy/undeploy cycles for different stacks
            Richard Opalka Master

            Here are my two cents:

            During the deploy-jbossXYZ we could generate text or property file listing all artifacts (batch scripts, jars, directories) that have to be removed on undeploy.

            • 3. Re: Simplify deploy/undeploy cycles for different stacks
              Thomas Diesler Master

              Hmm ... a generic undeploy - not bad. Other ideas?

              • 4. Re: Simplify deploy/undeploy cycles for different stacks
                Richard Opalka Master

                 

                "richard.opalka@jboss.com" wrote:
                During the deploy-jbossXYZ we could generate text or property file listing all artifacts (batch scripts, jars, directories) that have to be removed on undeploy.


                Of course such text or property files must be distributed with AS as well.

                What about other ideas I can't think out better one at the moment :(

                • 5. Re: Simplify deploy/undeploy cycles for different stacks
                  Alessio Soldano Master

                  I like the idea of having the information of what have to be removed upon undeploy included in the deployed stuff itself. Having all the stacks deploy the same jbossws.sar file would also help imho; perhaps we could even put the property file inside it.
                  An issue I see is how to undeploy previous versions that do not have the property file; perhaps we could find out the union of the files that need to be removed for each stacks undeployment right now? mmhh...

                  • 6. Re: Simplify deploy/undeploy cycles for different stacks
                    Richard Opalka Master

                     

                    "alessio.soldano@jboss.com" wrote:
                    I like the idea of having the information of what have to be removed upon undeploy included in the deployed stuff itself. Having all the stacks deploy the same jbossws.sar file would also help imho; perhaps we could even put the property file inside it.

                    Yes, I think it's a good place where such text or property file could reside :)
                    "alessio.soldano@jboss.com" wrote:
                    An issue I see is how to undeploy previous versions that do not have the property file; perhaps we could find out the union of the files that need to be removed for each stacks undeployment right now? mmhh...

                    Yes, that's the issue.

                    • 7. Re: Simplify deploy/undeploy cycles for different stacks
                      Adrian Brock Master

                      Guys, why are you writing the deployment framework in the JBossWS project?

                      I've said this many times before, concentrate on webservices
                      and let the AS handle deployment/integration

                      If you have an issue with deployment that needs addressing then deal with
                      it in the deployment project, don't reinvent the wheel in an incompatible way
                      yourself.

                      e.g. in JBoss5 which deployments get deployed (and how they are configured/managed)
                      with be a property of the profile service not some internal hackery by you.
                      Choosing and redeploying the WS stack must be doable there
                      (which is potentially a remote management console managing and
                      provisiong a cluster).

                      All that will happen in the long term is that we will have to unpick your hackery.

                      ASIDE:

                      You're still providing your own as integration in the webservices project.
                      The responsibility of the webservices project is to provide the services
                      the AS project should do the integration that's what it is for.

                      If you don't understand what I mean then consider whether it is upto the webservices
                      project to define the configuration and packaging (a sar) for webservices
                      or whether you should provide the functionality and let the appserver
                      define its own configuration.
                      http://repository.jboss.com/jboss/jbossws-native50/2.0.3.GA/lib/

                      A few obvious examples of why this is broken:

                      1) The sar includes thirdparty jars that are not chosen by the AS project

                      2) The "sar" is in deploy mixing deployment and runtime configuration
                      in its beans.xml

                      The deployers should be the in the deployers folder not the runtime,
                      it should not require runtime dependencies to get the deployers in place
                      they should only deal with metadata (for validation purposes
                      inside a management console the runtime will be mocked or the alternatively
                      the runtime maybe "on-demand" dependent on whether there is a relevant
                      deployment).

                      3) You have your own "deployer" which means we can't use the AS deployers
                      to "interleave" new behaviour (modification of metadata to change/introduce
                      semantics)

                      The aop and messaging projects have similar problems, although I recently
                      decided to ignore aop's delivery of a sar and recreated it with the configuration
                      required INSIDE THE AS's ASPECT PROJECT
                      (which is only really a partial solution).

                      These complaints will probably fall on deaf ears again? :-(

                      • 8. Re: Simplify deploy/undeploy cycles for different stacks
                        Thomas Diesler Master

                        We are providing a community project that people can download in a new version every 8 weeks. With that binary it is possible to call

                        ant deploy-jboss421
                        ant deploy-jboss422
                        ant deploy-jboss423
                        ant deploy-jboss500

                        against an already released AS version.

                        AFAICS, your comments relates to AS50 only and how the AS decides to provide the WS funtionality. Much of it I understand and would agree.

                        However, what we are discussing here is how we can enable the community to replace/update the web service stack that comes with any supported version of an already released AS version.

                        Generally, we welcome constructive feedback in the form of "Instead of xxxx please consider yyyy"

                        • 9. Re: Simplify deploy/undeploy cycles for different stacks
                          Thomas Diesler Master

                          Please show us how a component targeted for AS50 should be released to the repository in the proper way , such that it satisfies the requirements you state above.

                          • 10. Re: Simplify deploy/undeploy cycles for different stacks
                            Adrian Brock Master

                             

                            "thomas.diesler@jboss.com" wrote:

                            AFAICS, your comments relates to AS50 only and how the AS decides to provide the WS funtionality. Much of it I understand and would agree.


                            The same problem exists in all versions. I was using AS5.0 as an example.

                            As for the correct way to do it, look at how the MC/deployers are integrated.

                            The jars are provided with suitable integration hooks
                            - a SPI (system programmer interface) e.g. MainDeployer, classloading, parsing, etc.

                            These are well defined and "stable" interfaces, implementations and helpers
                            (I quote stable because we still haven't done our CR1 release yet :-)

                            The AS project (system and system-jmx) then uses (and extends them
                            in some places - e.g. legacy jmx integration) them.

                            The deployments (the configuration files) are created by the appserver project
                            where it can modify the behaviour to suit its own requirements.

                            In principle your project should not have to change. Instead what changes
                            is the way it is integrated into the different releases of the appserver
                            (using the mechanism defined by that version/release).

                            For your "community updates" this should just be case of replacing the jars
                            if you have paid any attention to the backwards (and forwards) compatibility
                            of your spi.

                            ANOTHER ASIDE:

                            In principle, going forward, the jboss-integration project should define
                            a webservices spi (interfaces and helpers) which you (or anybody
                            else) can implement to provide webservices for any jboss project that
                            integrates using our standard spi (e.g. AS, embedded, esb, etc.)

                            It would then be a case of writing a JBoss4 subdeployer or a JBoss5 deployer
                            on top of that spi. (I doubt it will ever get done for JBoss4 ;-)

                            This would then embody the three different roles
                            (currently you do all three yourself):

                            * Policy - what needs doing (the user - e.g. JBossAS)
                            * Wiring - How to go about doing it (the api/spi - e.g. jboss-integration)
                            * Implementation - Do it (you - JBossWS)

                            • 11. Re: Simplify deploy/undeploy cycles for different stacks
                              Adrian Brock Master

                               

                              "adrian@jboss.org" wrote:

                              As for the correct way to do it, look at how the MC/deployers are integrated.


                              NOTE: I'm not saying the MC project is perfect. e.g. the POJO MC
                              (unlike the deployers) defines the spi and implementation in the same project
                              which is obiviously not ideal.

                              And there's a number of (minor) places where policy, wiring and implementation details
                              are mixed together - meaning re-use or changing behaviour is harder than
                              it should be. ;-(