In my stupidity innocence I just hoped that deploying the application on the new JBoss (from 4.2.2-GA to 5.1.0-GA) should be just a simple matter of changing paths in ant. Here are some problems I encountered and was able to fix.

application.xml

The format of this file has changed from:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/j2ee" version="1.4"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com /xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
 <display-name>My application</display-name>
 <description>My server interface</description>
...

to

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd"
 version="5">
 <display-name>My application</display-name>

The description field is now no longer required and schema has changed. A minor change in itself but as you will see further there are a lot of minor changes of this type.

Unified classloader

In JBoss 4 in order to unify tomcat and jboss classloaders one had to change

<attribute name="UseJBossWebLoader">true</attribute>

in jboss/server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml . It is no longer the case in JBoss 5, instead the following has to be commented:

<!-- Allow for war local class loaders: in testing -->
 <!--
 <bean name="WarClassLoaderDeployer">
 <property name="relativeOrder">-1</property>
 <property name="filteredPackages">javax.servlet,org.apache.commons.logging</property>      
 </bean>
 -->

in jboss-5.1.0.GA/server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml.

Hibernate har’s

This is by far one of the change I found stupid. The hibernate-service.xml is now named service-hibernate.xml and it’s content has changed using the following rules:

  • attribute elements are now called property
  • the name attribute was starting with an uppercase and now it’s lowercase

Example before:

<server>
 <mbean code="org.jboss.hibernate.jmx.Hibernate" name="com.mccsoft:name=MyOracleSessionFactory">
 <attribute name="DatasourceName">java:/DiapasonOracleDS</attribute>
 <attribute name="Dialect">org.hibernate.dialect.Oracle10gDialect</attribute>

and after:

<hibernate-configuration xmlns="urn:jboss:hibernate-deployer:1.0">
 <session-factory name="java:/hibernate/MyOracleSessionFactory"
 bean="jboss.test.har:service=Hibernate,testcase=TimersUnitTestCase">
 <property name="datasourceName">java:/DiapasonOracleDS</property>
 <property name="dialect">org.hibernate.dialect.Oracle10gDialect</property>

TreeCache

Also jbossCache configuration has changed from:

<attribute name="CacheProviderClass">org.hibernate.cache.TreeCacheProvider</attribute>

to:

<property name="cacheRegionFactoryClass">org.hibernate.cache.jbc2.MultiplexedJBossCacheRegionFactory</property>

I am not quite sure yet how the cache parameters have changed, still searching for more documentation.

ActiveMQ

Since the application was using activemq a strange error occured when deploying:

Specification violation [EJB3 JPA 6.2.1.2] activemq

Actually it seems this is related to the format of the persistence.xml file which is unfortunately bundled in the activemq jar. I was simple however to upgrade from 5.2.0 to 5.3.0 which solved the problem.

Ear service dependency

One of the problems which causes the most head bumping was related to the ear service dependency. In short a service was depending on the deployment of an ear using the following syntax:

<depends>jboss.j2ee:service=EARDeployment,url=’my.ear'</depends>

The EARDeployment does not exist in JBoss 5 and I could not find it’s proper replacement. After some trial and error I switched the dependency on a war inside the ear using the following syntax:

<depends>jboss.web.deployment:war=/my</depends>

as an alternative a service provided by the ear could be used:

<depends>com.len.queue:service=Listener</depends>

In all I lost a bunch of time which could have been better spend otherwise. Here are some links which helped:

One of the more sad results is that starting time jumped from < 1m to > 2m in the base config so there is surely still a lot of config to change.

Comments:

Pieter -

Thanks for the post! We just did the same thing and i have very little to add to the problems you encountered, except the following point: all your web.xml files will be validated strictly now. If you mixed and tags before, you now need to put all tags before all the tags. The same with and it’s mapping. Luckily, there will be relatively good error messages. Also, if you have a META-INF directory in a war, for example facelets custom taglibs, it will no longer be part of the classpath. You will need to move it to a separate jar with a META-INF directory and it will work again.

Ryan Wood -

Hi Len. I appreciate the post. I recently also went from JBoss 4.2.2 to 5.1.0 and am having an issue with ActiveMQ. The deployment error I get is the following: Deployment “jboss.j2ee:jndiName=local/GMSECLogMessageBridge@4832247,service=EJB” is in error due to the following reason(s): java.lang.UnsupportedOperationException: Message driven beans are not bound into remote jndi I was just wondering if you saw anything like this or may know how to fix it. Thanks for your time and help.

len -

Hi Ryan, unfortunately I have not seen this problem but it sounds to me to be one of the following problems: - trying to deploy something which requires (depends on) something which is no longer deployed. The syntax has changed for deployed beans for instance - trying to access a bean registered only as local using remote naming. Just an idea, I hope you will find the solution. Len