-
1. Re: [JBASMP-2] Create an Undeploy Mojo
guignome Oct 6, 2008 4:04 AM (in response to alrubinger)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 Oct 6, 2008 10:15 AM (in response to 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 Oct 8, 2008 8:54 AM (in response to alrubinger)"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 Oct 12, 2008 1:10 AM (in response to alrubinger)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 Oct 12, 2008 2:41 AM (in response to 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 Oct 14, 2008 3:08 AM (in response to 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