One thing I would note is that JBoss 7 is shipping with Hibernate 4.x so you may as well jump from 2 to 4 as long as you are going to change it.
It is a lot to bite off (as someone who is currently going from JBoss 5 to 7 and all the other libraries with it). On the other hand, if you do it piecemeal you will find yourself doing things like trying to make Hibernate 2.2 work on JBoss 7, i.e. things that are not really progressing you towards the end goal.
1 of 1 people found this helpful
If you use no special things, mean that you are (more or less) only use JEE spec without glue to JBoss special solutions, you might try to deploy your app to AS7.
But there are some changes (i.e. jboss.xml beside ejb-jar.xml is now different from name and schema).
The client access to EJBs will be different.
I would recommend to remove XDoclet, I wrote custom annotations and Interceptors instead.
So at least it depends on the size of the application and the requirements what is possible.
If you have only EJB2 SLSBs it might be not a huge effort to migrate it to EJB3, you might have EJB2 interfaces to call it.
From my experience the multiple steps will cost a lot more time (min double) because of workarounds and the compatibility.
You dont want to have many steps of this with incompatible changes.
Thanks for the quick response.
The Hibernate 4 item was news to me. I don't believe Hibernate shipped with JBoss 4.2.3, we just included it as our persistence provider and supplied the jars with our application.
So how does Hibernate 4 fit into AS7 and how is it configured? Is it a separate optional module or compoent that you can choose to use or not?
1 of 1 people found this helpful
Everything in JBoss 7 is split into modules. BTW, the whole structure of the application server is forgeign coming from JBoss 5. It really seems like migrating to a completely new server.
JBoss uses Hibernate as the JPA implementation. So when you use JPA in an application deployed under JBoss, you use Hibernate under the hood (although your app need not be aware of that). My application uses Hibernate directly, so I include a dependency on Hibernate in jboss-deployment-structure.xml to inform JBoss I want the module to be available to my application.
Thanks for the quick response. We have tried to stay close to JEE spec since we also supported Weblogic and didn't want to get into problems with vendor specific implementations. As of our latest release, we no longer support Weblogic, so that is helping a bit.
Can you explain a little bit more about the custom annotations and interceptors? Are the standard annotations not enough? Was there something out of the ordinary that necessitated custom annotations?
It is just as you state that you want to keep XDoclet for some custom things.
But remember that XDoclet1.2.3 is dead (Java 1.5 is not full supported) and I see no activity for 2.x
So I have written some Interceptors (that is EE standard) and some annotations that are handled by the interceptor for some cross cutting concerns (e.g. logging or set some log environment, track UserTransactions, configurable pre- and post-plugins)
But that is not a big deal and it is handy for development, no XDoclet generated classes compiled every run
I am also having the same issue that our applications are with below configuration
1. JDK 1.5
11. ActiveMQ 5.1
12. Tomcat 6.0.1
and the requirement is update all the above with latest stable version
JDK 1.7, JBOSS 7.x+, Spring 3.x+, Axis 2.x+, Jquery 1.x+, Tomcat 7/8...NO EJB.
I have suggested the approach instead of directly JBoss 4.x to JBoss 7.x AS. We will go for JBoss 4.x to JBoss 5.x, so it will controlled and atleast JEE5 compliance.
Then from JBoss 5.x to JBoss 7.x we will go along with JDK 7 and other relative library changes.
It will be grateful, if you answer me whether my apprach is right or wrong?
One thing I would recommend in that scenario is too ignore any JBoss 5 specific issues. Solving them will not help you get to JBoss 7. (Unless you are planning a JBoss 5 hase for production, then obviously you need to get that 100%.)
The JDK should not be a problem if you use 6 or 7.
I don't think that you will have a benefit if you migrate to 5.1 first, only (more maybe unnecessary) work to do.
If possible you should split the applicaiton in several parts and migrate from XML to annotations.
If it can be useful, in  i've reported all changes in technologies between the two platforms (please, correct if any details is wrong).
In our specific case, we also need:
- not to impair development of new features being constantly added
- not to disrupt support to Weblogic 10.x (Java EE 5)
- keep multiple DB compatibility (Oracle, DB2)
To add detail, we are have the following - quite common - scenario:
- Maven 3 w/ advanced Cargo configuration for IT
- One Ear, one War, many EJB/JAR
My question is: are all techs we're using  compatible and/or supported in JBoss 7 (even with some hack) or do we have to chain-change all of them (because of conflicting/incompatible jar/dependencies)?
Thanks in advance!
Could you provide me the access to the doc that you have shared the link for.
It could be helpful to us as we are also planning to migrate from 4.2.3 to 7.1.1.
by the way, I recommend to use a newer version of AS7, maybe the EAP6.1.0.Alpha (which is free for use) or the WildFly8.
As this versions include a lot of fixes and enhancements.
WildFly 8 requires JDK7 as it is requirement for EE7.
In any case JDK6 is EOL for some time now, it is wise to upgrade to 7 even if you are running AS7.