Should I upgrade to JBoss 7.1 with JBoss 5.1

Question

Our production environment is currently launching JBoss 5.1, and we are discussing whether it is worth migrating to JBoss 7.1. If it were a simple server upgrade, that would not be a problem. But, unfortunately, we would have to change the configuration, and this will require some effort. In addition, our server runs in a cluster, and I read that JBoss 7.1 has more cluster support.

Is it worth it or not?

thanks

Answer 1

We are currently in the same situation.

On the plus side, there seem to be a lot of things:

• We need to transfer 5.1 at one moment. We need a complete profile and not many alternatives to OSS (GlassFish and possibly Geronimo). Only this point is likely to sell migration, since PCI-DSS forbids us to use EoL'd software.
• The configuration is much better and simpler. It no longer extends to more than 20 XML files in which you customize aspects in XML files, but one central place. All ports are configured in one central location; there is no longer an XSL file that converts server.xml. You can understand the configuration file without knowing the details of the implementation of the classes. This is very important if you have never configured JBoss.
• In remote mode, EJB no longer uses a stream for each socket.
• Removing a subsystem that you do not need is much easier.
• The loding class model looks reasonable and you get a lot of control through jboss-deployment-structure.xml
• The EJB client library looks much more refined. This is up to 10 JARs with 20, half of them are even OSGi packages (our client is the RCP Eclipse application).
• Although we are not too happy that Java EE 6 replaced some of our SLSBs with @Singleton beans, and some of our SARs with EJB timers certainly look interesting.
• Faster startup and less memory use (at least for an empty server or small deployments). We have not tested a large deployment yet.
• By default, the deployment folder is empty.

Things we still need to learn:

• We are a little concerned about the performance of Infinispan. We are currently using the TreeCache API for JBoss Cache. Although there is an adapter for Infinispan that provides the same API, some theoretical tests show worse write performance. This applies only to the Infinispan tree API.
• ExternalContext is no longer supported, we are currently using it to populate the JNDI tree from the .bindings file.
• The JMX console has disappeared, if you have something that relies on it, you need to adapt it, Change , in fact, there is a JMX-Console AS7-2227 port

We do not start in the cluster, so I can not comment on this.

For us, perhaps the biggest effort is to transfer all shell scripts (installation, integration tests, ...) that interact with JBoss in one way or another.

Update

We migrated, and it was definitely worth it. Some of the updates mentioned above:

• Even large deployments are performed with minimal settings.
• Centralized logging (Slf4j, JUL, JCL, Log4j, ...) is really nice.
• 7.1 has so many errors that it was unsuitable for us, so we are on 7.2 / EAP 6.1 and plan to move on to 7.3 / EAP 6.2. Still has its share of mistakes, but we can get around them. We especially rely on role-based access control for the management interface, which will allow us to run our scripts with minimal privileges.
• There will be no supported version of GlassFish 4, which puts a big question mark for its use.
• EJB remote access security is much less flexible. We had to apply some workarounds, as we previously mixed authenticated and not authenticated EJB calls - this is no longer possible.
• JOM 6 BOM POM by JBoss is a mixed bag. This is theoretically good because it manages versions of all JEE dependencies. In practice, the coordinates are terrible with the version in artifactId, which will be annoying when we switch to JEE 7. It is also not very useful if you want to enable the JEE API implementation for tests.
• The performance of the Infinispan tree API was not a problem.
• We replaced the JMX-Console scripts with DMR scripts.

Update 2

• There is a dead end using EJB remote access over SSL. This deadlock is present even in EAP 6.2. Now we are at a point where we have a pretty set of feature patches passed from WildFly to AS 7.

Answer 2

Does everything work on JBoss 5.1.0? Can you live with your work?

I'm currently in the middle of upgrading from JBoss 5.1.0GA to JBoss 7.1.1, and it was not easy. You basically upgrade to the new application server. You will have to pay a lot of dollars for this effort, which I suppose.

Having said that, JBoss 7.1.1 is VERY fast compared to 5.1.0 (at least the startup time). I think that in the next 6 months (or so), most of the "hard" problems of migration and transition will be hidden on jboss forums or through bug fixes. At this point, you and your team can overestimate whether you want to migrate.

Good luck

Answer 3

If you use SSL, one advantage to upgrade is that JBoss 7.1.1 runs on jdk 1.7, which supports TLS 1.1 and 1.2, while jdk 1.6 only supports up to TLS 1.0. JBoss 5 will not work on java 1.7, so you are subject to a BEAST attack.

Answer 4

Regardless, I would wait a bit.

AS 5 is an EE5 server, AS 7.1 is an EE6 server (and the EE6 specification appeared in 2009). So there is a lot of work for a great new runtime, but it will not give you any hot architectural possibilities.

The WildFly 8.0.0.CR1 already exists and the EE7 server provides you with many interesting new development opportunities, such as WebSockets and JAX-RS 2.0 ( http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof ). New admin features such as Single Instance Patching. And he is not sure that AS7-to-WildFly8 will become an ultralight migration, as more important material is introduced, for example, Undertow instead of JBossWeb / Tomcat.

If you need to go, you need to go - and if U turns off the 7.x dead path, be sure to take on the significantly improved 7.2.0.Final tag (a few hundred questions are better than 7.1. 1). But if you think you can start development / migration now using Beta / CR releases and wait a few months for a good stable version of WildFly 8.xx, you can sit longer until the next major update.

br, jens