“With JBoss EAP 7 having been on the market since May 2016, and 7.1 expected towards the end of Q1 2017, JBoss EAP 5 and EAP 6 customers will be acutely aware that product support for those versions is moving inevitably towards the end of its lifecycle. Now more than ever, thoughts are turning to upgrade and migration, with target architectures that should be looking towards RHEL 7, EAP 7 and Java 1.8.”
Brian Randell - c2b2 Principal Consultant
and JBoss Middleware Specialist
Part 2 - Transcript
Hello, and welcome to the second in a series of videos related to JBoss EAP2 7 migration. In this video, as we’re working down our ‘What’ stack, we’re going to look at the ‘How’ – and how we work through our development challenges.
So, what challenges do we face?
Well, we’ve got some underlying technology changes when we move to EAP 7. There are three things that are going to change.
- We’re going to change our Java SE, I would have thought
- We’re definitely going to change our JEE version
- And we’re going to change JBoss components
These will be fundamental to the challenges we face with our code. Just in case we’re using things that have been deprecated or removed, we might want to utilise the new functions, methods and components.
Also, we need to look at our compatibility with any frameworks that we might use within our deployments – in interfaces we might be using, or web services. And there might be some server configuration changes – cluster configuration as an example of things that may change - and there may be new standards to follow that we need to be aware of.
So, within the code base, there’s a bunch of challenges that we need to look at and plan before we deploy, to make sure they work with our new version. And there are some tools to help us do that. There’s a tool called Windup, and there’s a tool called the JBoss Migration Toolkit - and we’ll have a little look at those.
For those organisations with JBoss EAP 5.x or 6.x environments, our essential JBoss EAP 7 Migration Guide by Brian Randell is intended to assist in identifying the key challenges and assist in planning the migration tasks required to deliver a successful implementation.
First though, we’ll have a look at the JEE specification. Now, from this slide, there’s a lot of different colours (!), but what you can see is the darker blues are the new JEE 7 modules (JSRs), and the very dark ones are new, and which have been introduced in this particular JEE. The lighter colours are from the previous JEEs that have now been removed. So, as you can see, there are an awful lot of JSRs in the new JEE, and it’s quite a large specification - so therefore, there could be lot of changes in your code required if you make use of the JSRs in previous versions. And there could be new features of course, that you can add because of the new JSRs that have been added.
It’s worth studying these at some point just to make sure that you know what the changes are within those JSRs of that JEE version – that’s the biggest change you’ll probably find.
Of course, we’ve now got versions of JBoss and Java updated, and you can see there – as we saw in a previous talk – that the EAP 7 components had a few major changes in terms of the JBoss Web and HornetQ. So, whilst you can get some backwards compatibility for HornetQ, there are changes that you need to be aware of.
Fundamentally the EAP 7 core has changed from AS to WildFly, and though some of that shouldn’t be a problem for you, but you should always check on that kind of thing, and with Java 1.8, I’m not a developer, but there has been a lot of changes within Java 1.8, and there are some things there – I mean, it should be backwards compatible with any Java 1.7 code that you’ve got running, and you shouldn’t really need to recompile that, but again, testing, testing, testing is valid for all of your code changes.
Some other things that you can see up there on the list that maybe worth pointing out is the security updates. There are always security updates within the different versions of Java, and if you are using any of the security facilities there, then you should double check those because it’s likely that they will cause you an issue.
So onto the tools.
Windup is at version 3 at the moment, and what it does is that it analyses code, and gives you a report on the compatibility of JBoss EAP. It’s part of the migration tool kit – in fact it’s the only thing on the migration tool kit, I think, at the moment. There are only a few versions it does, so it does 5 to 7 , so you’ll be fine with that, and actually it does produce a very high-level quality report now, and actually allows you to provide planning and effort estimations, so it will provide you with a report that shows you how much effort it will take you to modify the code – and it will categorise those in terms of how important they are and the priority you should give them – and you can add your own rules if there are certain things that you want to particularly report on, then you can add your own rules to the standard set. So definitely worth looking up and using Windup when migrating to EAP 7 - and that should solve a lot of your headaches.
In terms of configuration code, there’s a product called the server migration tool, which has recently gone into CR1 version 1 - now that is very limited in the versions that it can migrate from. It currently only does EAP 6.4 to 7. Basically what it is doing there is that it’s configuring your standalone and domain XML files to utilise the new JBoss EAP 7 components – renaming and remanufacturing. So, it will keep an original copy of of the previous file, but it also change all the different ones as well, and also provide you with a report. I think that’s limited in its use because of the version issue, but if you are on 6.4 and moving to 7 , you might as well use it, as it automatically does a lot of the hard work for you.
So, it’s been a fairly brief run through of the development challenges. Primarily you’ve also got to look at the Java JEE and JBoss changes – the component changes, and this is all part of your migration planning. You may need to redevelop if necessary, and you need to test, test, test. For successful migration, your full testing cycle is key. So thank you for listening, and next time we’ll be looking at how we create that migration strategy.
See you next time