Classloader issue with JBoss 4.0.5GA

Today I was asked to help solving an issue with an application that was deployed on JBoss 4.0.5.GA. It had been running for some months without a problem, until a new application had to be deployed. This new application demanded that the isolation level in the ‘ear-deployer.xml’ config file had to be set to its default value ‘false’. However, the setting was set to ‘true’ for some reason.

Here is the content of the file:

<?xml version="1.0" encoding="UTF-8"?>
<!-- The JBoss service configuration file for the EAR deployer service.
$Id: ear-deployer.xml 60679 2007-02-19 21:35:39Z scott.stark@jboss.org $
-->
<server>
   <!-- EAR deployer, remove if you are not using ear deployments -->
   <mbean code="org.jboss.deployment.EARDeployer"
      name="jboss.j2ee:service=EARDeployer">
      <!-- A flag indicating if ear deployments should have their own scoped
      class loader to isolate their classes from other deployments.
      -->
      <attribute name="Isolated">false</attribute>
      <!-- A flag indicating if the ear components should have in VM call
      optimization disabled.
      -->
      <attribute name="CallByValue">false</attribute>
      <!-- A flag the enables the default behavior of the ee5 library-directory. If true,
      the lib contents of an ear are assumed to be the default value for library-directory
      in the absence of an explicit library-directory. If false, there must be an
      explicit library-directory.
      -->
      <attribute name="EnablelibDirectoryByDefault">true</attribute>
   </mbean>
</server>

By setting the parameter back to ‘false’ and test the applications that were deployed on the JBoss instance, it was quickly found which application went wrong. One of the applications was giving the following exception:

Caused by: java.lang.NoSuchMethodError: org.apache.commons.httpclient.methods.PostMethod.getParams()Lorg/apache/commons/httpclient/params/HttpMethodParams;
at net.pascalalma.components.sms.SmsServiceBean.postSmsRequest(SmsServiceBean.java:220)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.java:127)
at net.pascalalma.components.sms.SmsServiceBean.sendSms(SmsServiceBean.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)

After some further investigation I found out that the problem was caused by the commons-httpclient.jar. The application needs to use tthe version 3.0.1 while the JBoss is supplied with version 2.0 (it’s in the JBOSS_HOME/lib/ directory). So instead of setting the isolation level at JBoss instance level I tried to set this ‘property’ at application level by supplying a ‘jboss-app.xml’ with the .ear file of the application. The content of the ‘jboss-app.xml’ is:

<jboss-app>
  <loader-repository>
  net.pascalalma.appl:archive=my-app.ear
     <loader-repository-config>
     java2ParentDelegation=false
     </loader-repository-config>
  </loader-repository>
</jboss-app>

After testing this configuration the application worked fine, but I ran into another issue….
We are building and packaging our application with Maven2. To generate the ear-file, we use this maven-ear plugin. I found out that the plugin offers the possibility to generate the necessary ‘jboss-app.xml’ file by configuring the plugin in the corresponding pom file like this:

<project>
  ...
  ...
  <build>
    <plugins>
       <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>jboss-maven-plugin</artifactId>
          <configuration>
                  <jbossHome>${jboss.home}</jbossHome>
                  <serverName>default</serverName>
                  <port>8080</port>
          </configuration>
       </plugin>
       <plugin>
          <artifactId>maven-ear-plugin</artifactId>
          <configuration>
             <displayName>My Application</displayName>
             <description>My apliation using HttpClient3.0.1</description>
             <version>2.3.1</version>
             <modules>
                <ejbModule>
                   <groupId>net.pascalalma</groupId>
                   <artifactId>
                      my-ejb-app
                   </artifactId>
                </ejbModule>
                <webModule>
                   <groupId>net.pascalalma</groupId>
                   <artifactId>
                      my-web-app
                   </artifactId>
                   <contextRoot>/my-app</contextRoot>
                </webModule>
             </modules>
             <jboss>
                <version>4</version>
                <loader-repository>
                  net.pascalalma.appl:archive=my-app.ear
                </loader-repository>
                <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
             </jboss>
             <archive>
                <manifest>
                   <addClasspath>true</addClasspath>
                </manifest>
             </archive>
          </configuration>
       </plugin>
    </plugins>
  </build>
</project>

Unfortunately, the plugin ignores the tag ‘loader-repository-config’ in the pom file. So this setting is not added to the ‘jboss-app.xml’ while this is the most important setting in our case! So for now I add the correct file by hand, but if someone knows a nice way to do this, I am very eager to hear it.

Advertisement

About Pascal Alma

Pascal is a senior IT consultant and has been working in IT since 1997. He is monitoring the latest development in new technologies (Mobile, Cloud, Big Data) closely and particularly interested in Java open source tool stacks, cloud related technologies like AWS and mobile development like building iOS apps with Swift. Specialties: Java/JEE/Spring Amazon AWS API/REST Big Data Continuous Delivery Swift/iOS
This entry was posted in JBoss and tagged . Bookmark the permalink.