One of the biggest changes incorporated in WildFly 8 was the WildFly web container. Undertow was designed to provide great performance and a huge number of simultaneous connections and, of course, not to miss the fact that WildFly is 100 percent Java EE7-certified while AS7 is Java EE6-certified.
We also have a visible improvement in the number of ports that WildFly has when compared to AS 7; so, if our application is using a specific service such as JMX Remoting, it is necessary to change this inside your application; for example, the WildFly JMX subsystem URL is service:jmx:http-remoting-jmx://127.0.0.1:9990.
Whereas, in JBoss AS 7, the JMX subsystem is service:jmx:rmi:///jndi/rmi://10.81.0.227:1090/jmxrmi.
For example, in JBoss AS 7, we have:
integer portInteger = Integer.valueOf(port);
Hashtable h = new Hashtable();
JMXServiceURL address = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://"+hostname+":"+port+"/jmxrmi");
connector = JMXConnectorFactory.connect(address,null);
connection = connector.getMBeanServerConnection();Whereas, in WildFly, we have:
integer portInteger = Integer.valueOf(port);
Hashtable h = new Hashtable();
JMXServiceURL address = new JMXServiceURL("service:jmx:http-remoting-jmx://"+hostname+":"+port);
connector = JMXConnectorFactory.connect(address,null);
connection = connector.getMBeanServerConnection();Another important point is the default modules directory; note the difference between the two:
|
Module Directory | |
|---|---|
|
WildFly |
|
|
Jboss AS 7 |
|
So, if your application uses a specific module that was present in JBoss AS 7, it should be reconfigured in WildFly on your new default modules directory.
The clustering has several changes, and you can refer to it at https://community.jboss.org/wiki/ClusteringChangesInWildfly8.
Another change can be verified on the WildFly page at http://wildfly.org/news/2014/02/11/WildFly8-Final-Released/.
Other important things to know as well that make a difference and can generate errors are explained in the following sections.
If you use the cargo container, you need to check some settings that should be changed in order to make it work in WildFly. Basically, you only need to be aware of the following information:
The cargo container ID must be changed from jboss71x to wildfly8x.
For example, from the Java code, change the ID container to the following:
ContainerFactory.createContainer("wildfly8x"...)WildFly supports Version 1.4.2 onwards, and more detailed information about cargo can be found at http://cargo.codehaus.org/Home.
In some cases, it is also important to know that some source codes of the application have changed, and it is necessary to make minor adjustments to the code to ensure that the application works perfectly in WildFly; let's see some of these changes.
A singleton service is not in clustering anymore but instead it is a clustering server package. In addition, there is a new singleton service builder functionality that is needed to create singleton services. For more information and examples, please visit https://community.jboss.org/wiki/ClusteringChangesInWildFly8 in the new Singleton Service Builder API section.
Some applications need to use Hibernate 3 and are often incompatible with the native version of WildFly. For these exceptions, we can configure the application or WildFly to use Hibernate 3.
Remember that these settings apply only to Versions 3.5 or higher, and it would be ideal to use Version 3.6.x.
For this, you need to include the dependencies of Hibernate 3 in your project, and this can be done by inserting the libs in the lib directory of your project or through Maven. To configure this, add the following code in your persistence.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="test_pu">
<description>Hibernate3-PU</description>
<jta-data-source>java:jboss/datasources/testDS</jta-data-source>
<properties>
<property name="hibernate.show_sql" value="false" />
<property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
</properties>
</persistence-unit>
</persistence>For this, we need to change the Hibernate 3 module inside WildFly modules and access the Hibernate 3 module directory:
# cd $JBOSS_HOME/modules/system/layers/base/org/hibernate/3/
Copy all Hibernate 3 JARs to this directory (hibernate3-core.jar, hibernate3-commons-annotations.jar, and hibernate3-entitymanager.jar).
Edit the module.xml file and add the resource-root JAR files:
# vim module.xml
Use the information as follows:
<?xml version="1.0" encoding="UTF-8"?><!-- Represents the Hibernate 3.x module --> <module xmlns="urn:jboss:module:1.1" name="org.hibernate" slot="3"> <resources> <resource-root path="jipijapa-hibernate3-1.0.1.Final.jar"/> <resource-root path="hibernate3-core.jar"/> <resource-root path="hibernate3-commons-annotations.jar"/> <resource-root path="hibernate3-entitymanager.jar"/> </resources> <dependencies> <module name="asm.asm"/> <module name="javax.api"/> <module name="javax.annotation.api"/> <module name="javax.enterprise.api"/> <module name="javax.persistence.api"/> <module name="javax.transaction.api"/> <module name="javax.validation.api"/> <module name="javax.xml.bind.api"/> <module name="org.antlr"/> <module name="org.apache.commons.collections"/> <module name="org.dom4j"/> <module name="org.javassist"/> <module name="org.jboss.as.jpa.spi"/> <module name="org.jboss.jandex"/> <module name="org.jboss.logging"/> <module name="org.slf4j"/> <module name="org.jboss.vfs"/> </dependencies> </module>
And your persistence.xml file will look like the following code:
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="test_pu">
<description>Hibernate3-PU</description>
<jta-data-source>java:jboss/datasources/testDS</jta-data-source>
<properties>
<property name="hibernate.show_sql" value="false" />
<property name="jboss.as.jpa.providerModule" value="org.hibernate:3" />
</properties>
</persistence-unit>
</persistence>Now, your application must work with Hibernate 3.
Another big improvement that happened in WildFly was the class loader. Now even if you have, for example, JSF in your project, there will be no conflict with the JSF lib provided by WildFly because, as we saw earlier, all deployments, by default, have your class loader isolated. However, if you are using libs that are provided by the container, an error can occur, but a version error; to solve this, just set the lib to be packaged along with the application.