6 Replies Latest reply on Oct 14, 2008 3:08 AM by alrubinger

    [JBASMP-2] Create an Undeploy Mojo

    alrubinger

      For Community Contributor Guillaume Radde.

      @see https://jira.jboss.org/jira/browse/JBASMP-2

      The JBossAS Maven Plugins[1] ease integration testing within a Maven environment. These are powered by facilities located in server-manager[2].

      I've just added support to server-manager to allow for generic invocations over the JMX Bus[3] (ported from legacy code in the jboss-test[4] project).

      This means that we can now access the MainDeployer to perform deployment. As you'll see, I've already implemented the "deploy" Mojo.

      What now needs to be done is a similar handling to create an "undeploy" Mojo, centralizing common code with "deploy" along the way, and self-documenting/testing by configuring "undeploy" in the maven-jboss-as-control-example project.

      The integration tests in maven-jboss-as-control-example will all run by using the "it" profile:

      $> mvn clean install -Pit


      You'll need to configure Maven to include JBoss-specific repositories[5].

      S,
      ALR

      References:

      [1] http://anonsvn.jboss.org/repos/maven/plugins/jboss/trunk/
      [2] http://anonsvn.jboss.org/repos/jbossas/projects/server-manager/trunk
      [3] https://jira.jboss.org/jira/browse/JBASM-13
      [4] http://anonsvn.jboss.org/repos/jbossas/projects/test/trunk/
      [5] http://wiki.jboss.org/wiki/MavenSettings

        • 1. Re: [JBASMP-2] Create an Undeploy Mojo
          guignome

          Trying to deploy then undeploy, I'm getting this error

          Caused by: java.lang.ClassCastException: org.jboss.security.plugins.JBossSecurityContext
           at org.jboss.security.SecurityContextFactory.createSecurityContext(SecurityContextFactory.java:71)
           at org.jboss.security.SecurityContextFactory.createSecurityContext(SecurityContextFactory.java:51)
           at org.jboss.security.SecurityContextFactory.createSecurityContext(SecurityContextFactory.java:87)
           at org.jboss.proxy.SecurityActions$1.createSecurityContext(SecurityActions.java:108)
           at org.jboss.proxy.SecurityInterceptor.createSecurityContext(SecurityInterceptor.java:113)
           at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:73)
           at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
           at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101)
           at $Proxy1.invoke(Unknown Source)
           at org.jboss.jbossas.servermanager.Server.invoke(Server.java:690)
           at org.jboss.jbossas.servermanager.Server.invoke(Server.java:679)
           at org.jboss.jbossas.servermanager.Server.undeploy(Server.java:646)
           at org.jboss.maven.plugins.as.control.mojo.JbossAsControlUndeployMojo.execute(JbossAsControlUndeployMojo.java:76)
           ... 18 more


          What's interesting is that I get the same exception if I try to deploy two files in a row. I'm guessing there is connection that isn't closed somewhere. I'll post again when I figure this out :-)


          • 2. Re: [JBASMP-2] Create an Undeploy Mojo
            alrubinger

             

            "guignome" wrote:
            I'm guessing there is connection that isn't closed somewhere.


            Is there anything other than the error posted which leads you to think this?

            The stack trace points to a CCE, my first impression is due to a version incompatibility between a dependency defined by the project and the AS you're running.

            If you commit so I can reproduce I'll have a look.

            S,
            ALR

            • 3. Re: [JBASMP-2] Create an Undeploy Mojo
              guignome

               

              "ALRubinger" wrote:
              "guignome" wrote:
              I'm guessing there is connection that isn't closed somewhere.


              Is there anything other than the error posted which leads you to think this?

              Just the fact that if I deploy a war once, everything goes right, but if I deploy it twice, it fails with this error.
              "ALRubinger" wrote:

              The stack trace points to a CCE, my first impression is due to a version incompatibility between a dependency defined by the project and the AS you're running.

              Yes, that would make a lot of sense. I'm deploying in jboss-5.0.0.CR2. I'm wondering if there is something wrong with my environment. Would you mind doing a test for me? The easiest way to reproduce the same error on my computer is to try to deploy the slsb twice in a row in jbossass-maven-control-plugin-examples.

              ie, in the file maven-jboss-as-control-example/pom.xml replace
               <!--
              
               Deploy into our custom JBossAS Configuration
              
               -->
               <execution>
               <id>deploy-test-slsb</id>
               <goals>
               <goal>deploy</goal>
               </goals>
               <phase>pre-integration-test</phase>
               <configuration>
               <serverConfigName>custom</serverConfigName>
               <files>
               ${project.build.directory}/${project.build.finalName}.${project.packaging}
               </files>
               <jboss.test.run>true</jboss.test.run>
               </configuration>
               </execution>
              


              with
              <!--
              
               Deploy into our custom JBossAS Configuration
              
               -->
               <execution>
               <id>deploy-test-slsb</id>
               <goals>
               <goal>deploy</goal>
               </goals>
               <phase>pre-integration-test</phase>
               <configuration>
               <serverConfigName>custom</serverConfigName>
               <files>
               ${project.build.directory}/${project.build.finalName}.${project.packaging}
               </files>
               <jboss.test.run>true</jboss.test.run>
               </configuration>
               </execution>
              <!--
              
               Deploy a second time into our custom JBossAS Configuration
              
               -->
               <execution>
               <id>deploy-test-slsb2</id>
               <goals>
               <goal>deploy</goal>
               </goals>
               <phase>pre-integration-test</phase>
               <configuration>
               <serverConfigName>custom</serverConfigName>
               <files>
               ${project.build.directory}/${project.build.finalName}.${project.packaging}
               </files>
               <jboss.test.run>true</jboss.test.run>
               </configuration>
               </execution>
              


              That should fail anyway as you cannot deploy the same war twice, but I'm curious to see if you would get the same exception as mine.

              Thanks,

              Guillaume


              • 4. Re: [JBASMP-2] Create an Undeploy Mojo
                guignome

                This is a classloader problem. In java, an object created in a classloader cannot be cast to its superclass in another classloader. This is simply because two classes loaded using the same class name from the same jar from two different class loader are different (see Java Language Specification third edition-chapter 4.3.4).

                In our case the deploy mojo creates a temporary classloader that contains jbossall-client.jar each time it does a jmx call. That's the source of the problem. I changed a bit the behaviour and store the temporary classloader as a static field. This way, classes from jbossall-client.jar are loaded only once per jvm.

                That's a hack to fix a hack and I wouldn't be surprise if that was creating some other issues. Ideally, jbossall-client should be defined as a maven dependency (as described in the comments of the classloader hack).

                Note that doing

                $ export MAVEN_OPTS=-verbose

                and using java6 instead of java5 helps a lot to debug classloader issues.
                I'll clean up my patch and send it soon.


                • 5. Re: [JBASMP-2] Create an Undeploy Mojo
                  alrubinger

                  I see you've found my dirty laundry. :D

                  Making our hack CL static isn't muddying the waters any further, though; I should have had the forethought to do that in the first place.

                  "guignome" wrote:
                  Ideally, jbossall-client should be defined as a maven dependency


                  No, the Plugin here needs to work with whatever version of jbossall-client is present in the user's installation, and the dependency would bind the Mojo to a particular AS version.

                  The genesis of that hack is to address a configuration property in the POM of the control-example:

                  <!-- Include jbossall-client.jar on the CP -->
                   <additionalClasspathElements>
                   <additionalClasspathElement>${JBOSS_HOME}/client/jbossall-client.jar</additionalClasspathElement>
                   </additionalClasspathElements>


                  ...which doesn't seem to be getting picked up. If that worked as advertised we could ditch the whole TCL replacement BS.

                  S,
                  ALR

                  • 6. Re: [JBASMP-2] Create an Undeploy Mojo
                    alrubinger

                    On some further thought, I think we're going to need the explicit ClassLoader no matter what. Which promotes it from "hack" to "necessary evil".

                    Surefire does similar things to get the CP right when running tests. We simply can't define an explicit dependency to get jbossall-client on the client CP, so we've gotta define our own CL.

                    I've applied one of Guillaume's patches which ensures there's no CCE due to the wrong CL being used.

                    S,
                    ALR