8 Replies Latest reply on Jul 23, 2007 7:15 AM by Thomas Diesler

    Usage of the new jboss50 new deployer architecture

    Adrian Brock Master

      To update jbossws to the new deployers, I must have had to modify
      at least three files that organise thirdparty dependencies.

      But even having done that, it didn't build the jboss50 integeration.
      So I went to that directory and did a build there, and I got this:

      [ejort@warjort jboss50]$ ant
      Buildfile: build.xml
      
      prepare:
      
      thirdparty-init:
      
      thirdparty-get:
      
      thirdparty-classpath:
      
      thirdparty:
      
      init:
      
      BUILD FAILED
      /home/ejort/jbossws/integration/jboss50/build.xml:41: Not available: ${jboss50.home}/client/jboss-ejb3-client.jar
      


      Why is it compiling over non-versioned jars??????!!!!!!!

      This makes the whole build unreproducable.

      How do I know which version of jboss-ejb3-client.jar I need to reproduce a
      customer problem from source?

        • 1. Re: The JBossWS build is a joke - the project is unmaintaina
          Adrian Brock Master

          Anyway, back to the reason why I want to modify the jbossws project.

          I'm trying to integrate the new deployer updates:
          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181

          I started to copy the code into varia as a temporary measure so at least
          I know what versions I'm compiling over and the integration gets maintained
          in step with the JBossAS code, like EJB3.

          What do I find, you've reinvented the wheel again (the deployers framework)
          with something called DeployerHooks. Why??????

          I also started commenting a number of other stupidities like using the
          Thread Context Classloader instead of the DeploymentUnit.getClassLoader()
          and the ever handling is the usual mess.
          e.g. aop has the same problem:
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058739#4058739

          But more importantly, the DeploymentContext is used everywhere!
          Even though this has been deprecated method from the start with a comment on
          getDeploymentContext() saying "think about it before using this method".

          Not only that it is referenced inside JBossWS itself, so I can't even just rewrite
          the deployers inside JBossAS (as a temporary measure)
          because the api is broken in jbossws-spi.jar

          I can understand you having your own abstraction for deployment
          that is a good thing. But not when you are just munging
          http://en.wikipedia.org/wiki/Munging
          somebody else's api and exposing implementation details that should never
          have been exposed.

          • 3. Re: The JBossWS build is a joke - the project is unmaintaina
            Adrian Brock Master

            I'm going to go back to the jbossws codebase instead of the varia strategy
            and try to fix the build so at least it becomes reproducable.

            Once that is done, I'll do the updates for the new deployers.
            Then we can finally do a release and get webservices working again in the appserver.

            Even after this, there are lots of issues about whether webservices should be
            depending on things like ejb3 at all. It should certainly have access to its metadata for
            deployment purposes, which is one of the reasons we have started a
            "metadata" project so projects can share each others models.

            Webservices seems to have one (WebservicesMetaData) which should be moved there.

            I don't understand why you wrote your own parsing routines instead of using the
            ObjectModelParsing deployer.

            Well, actually I do, its because you're doing some stupid double parse
            where you first parse to DOM to check the namespace then parse again
            using JBossXB?????

            • 4. Re: The JBossWS build is a joke - the project is unmaintaina
              Adrian Brock Master

               

              "thomas.diesler@jboss.com" wrote:
              I already updated to the new deployer architecture

              http://jbws.dyndns.org:8280/hudson/job/Core-Tests-AS-5.0/57/changes


              :-)

              Ok, but my other concerns still stand.

              1) Fix the build so it is reproducable
              2) Don't reinvent the deployers framework
              3) Fix the error handling
              4) Reuse the already developed code instead of re-inventing it and introducing
              alternate bugs. If it is doesn't quite do do what you want then add some new callbacks
              like the accepts() I added to the parsing deployers so EJB3 can do its hacks. :-)

              One example of (2) is how do I modify the webserivices metadata with a new deployer?
              I can't. I have to use a different api, the DeployersHook to do this.
              This is just stupid.

              • 5. Re: The JBossWS build is a joke - the project is unmaintaina
                Adrian Brock Master

                One other point. You shouldn't be using the main deployer to create webcontexts.
                You should just be adding WebMetaData to your deployment.

                That was one of the main reasons for the Deployers changes.
                A single deployment can be both a web deployment and an ejb deployment,
                exactly because this occurs in webservices.

                The hack to create a new deployment for the web-app is a hangover from the JBoss4
                limitiations.

                • 6. Re: Usage of the new jboss50 new deployer architecture
                  Thomas Diesler Master

                  1) Fix the build so it is reproducable

                  yes, this is an outstanding issue which is caused by dependencies of our integration layers on projects that have no tagged release. It definitely needs to be done.

                  2) Don't reinvent the deployers framework

                  We are taking the concepts of the deployer architecture and make them available accross AS50, AS42, AS40

                  3) Fix the error handling

                  Please be more specific

                  4) Reuse the already developed code instead of re-inventing it and introducing
                  alternate bugs. If it is doesn't quite do do what you want then add some new callbacks
                  like the accepts() I added to the parsing deployers so EJB3 can do its hacks. :-)

                  No comment.

                  • 7. Re: Usage of the new jboss50 new deployer architecture
                    Adrian Brock Master

                     

                    "thomas.diesler@jboss.com" wrote:

                    3) Fix the error handling

                    Please be more specific


                    You've got the same bugs as AOP,
                    to repeat what I said on that post, except with your code e.g.

                    AbstractWebServiceDeployer
                    
                     @Override
                     public void deploy(DeploymentUnit unit) throws DeploymentException
                     {
                     for (DeployerHook deployer : deployerHooks)
                     deployer.deploy(unit);
                     }
                    


                    So when the second hook fails, the stuff the first hook did, is not rolled back.

                     @Override
                     public void undeploy(DeploymentUnit unit)
                     {
                     for (DeployerHook deployer : deployerHooks)
                     deployer.undeploy(unit);
                     }
                    


                    So an error on the first hook means nothing else gets undeployed.
                    And the order should be reversed for undeployment.

                    • 8. Re: Usage of the new jboss50 new deployer architecture
                      Thomas Diesler Master

                      The hooks work mutually exclusive. i.e. there is one hook for every type of deployment. The hooks themselves delegate to a DeloymentAspectManager, which excecutes the DeploymentAspects - the work of those aspects are rolled back on failure.

                       // start the deployment
                       for (int i = 0; i < getDeploymentAspects().size(); i++)
                       {
                       DeploymentAspect aspect = getDeploymentAspects().get(i);
                       try
                       {
                       logInvocation(aspect, "Start");
                       aspect.start(dep);
                       }
                       catch (RuntimeException rte)
                       {
                       while (i-- >= 0)
                       {
                       // destroy the deployment
                       failsafeDestroy(aspect, dep);
                       }
                       throw rte;
                       }
                       }