9 Replies Latest reply on Jun 6, 2013 10:35 PM by Stephen Coy

    JBoss 4.2 (w/EJB 2.0) to JBoss 7

    Richard Doust Newbie

      Hello.

       

      I have a business-critical JBoss application. I am a lone developer and a business owner. I have not been involved in mainstream Java development for quite some time. About 12 years ago, I built and deployed this JBoss application that began by using Entity Beans for persistence, and moved to using Hibernate some time later. Still uses lots of Stateless Session Beans (EJB 2.0). It uses FOP and xerces, and lots of other open source jars. The application is deployed to a server hosted somewhere in Georgia on a dedicated machine that's getting long in the tooth. The application is an e-commerce application, so it needs to maintain PCI Compliance. The age of the software running on the server is becoming problematic in that regard. I am now faced with upgrading to a modern server platform, one running JBoss AS 7. I have found some posts regarding migrating JBoss 4 to JBoss 5, and 5 to 7, but nothing about going from JBoss 4 to JBoss 7. Not surprising I suppose. The application is relatively big. There's a customer-facing site, as well as a back-office site. On the front-end, the customer-facing site was based on the then-current Sun pet store sample, and the back-office site is built using Struts. I am wondering if my strategy should be to migrate to 5 and then to 7, start from scratch, or whether anyone has some simple pointers to areas of concern that I could delve into first, or any ideas about how to go about migrating the application. My build scripts are Ant, and I'm relatively familiar with Ant, but most of what I see for doing development in JBoss 7 uses Maven for builds.

       

      Any thoughts/suggestions are welcome.

       

      Thanks.

        • 1. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
          Wolf-Dieter Fink Master

          Hello Richard,

          welcome to the forum.

           

          This is a good question, I suppose there are a lot of other peoples asking about that, but it will be difficult to answer .

           

          If you start today you might decide to use JPA, EJB3, CDI beans and injection and JSF or GWT. I prefere a 'standard' JEE way.

           

          Migrate such an application in one step will be the best way regarding a clean final solution and the costs in total (my two cents) but dificult to handle with more developers and stop the feature development.

          But as I understand as you are a 'one man show' this is not the problem (only that you are stopping feature dev for a while)

           

          Other options are to migrate stepwise

          - by layer i.e. persistence, SLSB .....

          - by business case

           

          but such partial approaches are difficult as you have to have keep old code and do some compromises. Due to that you have to spend time and money for code and workarounds that you will not have clean up later. Also it happen that you have still old unwanted code in the 'new' application.

          1 of 1 people found this helpful
          • 2. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
            Nicklas Karlsson Master

            Cleanroom projects are always fun but like W-D said, for a one-man-shop rewriting a largeish application might be unrealistic because you still have to maintain the old one. One option might be to first get it to deploy on AS7 and the clean up the backing bean layer to EJB 3.1/JPA 2. You will most likely spend most of the time fighting with the view layer. Once the backing bean layer is cleaned up, is it possible to migrate some part of the view (e.g. admin sections) to a new UI technology? It might require splitting up the application in two at this point.

            1 of 1 people found this helpful
            • 3. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
              Richard Doust Newbie

              I'm not really very concerned about the UI for either application, at least I don't think I am. The customer-facing site is all JSPs and Struts, (some Ajax) but there's nothing about AS 7 as far as I know that has any impact on that. The administrative app is also JPSs, using mostly Dojo on the front end for widgetry and also a smattering of Ajax. Attacking a rewrite of the UI is beyond what I'd like to do, at least initially (there's a lot of it). I'm hopeful that the web tier will move without changes. My big concern is in getting the beans to deploy and figuring out how to break the application up into modules. Both web-apps (and the EJB-tier, along with many of the dependencies) are currently packaged into a single EAR for ease of deployment. I've also got a JobRunner process that's often kicked off by cron on the server that executes many different kinds of long-running database activities that are best run at night in preparation for the next day. But that code is all "get a reference to a bean and invoke a method or two on it". It uses two jars produced by build that produces the EJB jar (client versions). Once I've got the beans to deploy, it shouldn't be too hard to change the code to get a reference to them. So, I've got like 5 build.xml files, 4 that build components, and one that puts those components into an ear. So, from what I know, EJB 2.0 is not supported by JBoss AS 7, and the move from 2.0 to 3.0 entails slimming down the deployment descriptors and rewriting the beans to use annotations. I think it's all about learning how to deploy modules and how to use Maven, because I think trying to modify my existing Ant scripts is probably less useful long term. Am I all wet?

              • 4. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                Stephen Coy Master

                Richard Doust wrote:

                 

                ... So, from what I know, EJB 2.0 is not supported by JBoss AS 7, and the move from 2.0 to 3.0 entails slimming down the deployment descriptors and rewriting the beans to use annotations. ...

                You should be able to get away with just updating the deployment descriptors to begin with. Note that jboss.xml has gone the way of the dodo and has been supplanted by jboss-ejb3.xml; however it is not grossly different.

                 

                The ease of migration will also depend upon whether you're using java:comp/env (ENC) JNDI names or not when looking up home interfaces.

                 

                The other gotcha is that remote EJB calls are really remote in AS7, the old in-vm "optimisation" is no longer available AFAIK.

                • 5. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                  Richard Doust Newbie

                  I'm always using java:comp (ENC) JNDI names when looking up home interfaces. One utility source file that provides the methods that retrieve the references to all of the different beans. I do have to confess to having switched to using local interfaces from the web tier for much of what's done in the EJB tier over the years however, knowing as I did that I would never deploy the EJB tier to another machine. (Probably everyone who's done the same thing says the same thing and later regrets it, but so far I've had no reason to.) I think the JobRunner is the only code still using remote interfaces. But AFAIK, (other than changes to deployment descriptors) this is all about call by reference vs. value, so I will have to go through my code and make sure that I never presume that a passed parameter has been modified upon return?

                  • 6. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                    Stephen Coy Master

                    If you're using actual javax.ejb.EJBLocalObjects then you should be fine. I seem to recall that they come along in EJB 2.1 though.

                    • 7. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                      Richard Doust Newbie

                      Sorry, it's been a long time since I wrote the code. I'm using EJBLocalObjects. I forgot which version of the EJB spec introduced them. You're probably right, it's probably 2.1.

                       

                      I see now that JSPs are deprecated in Java EE 6 in favor of Java Server Facelets. I hope all that means is that I have some work ahead of me if I want my front-end to be Java EE 6 compliant. I've extended TagSupport quite a bit. I hope those classes are only deprecated and not gone.

                      • 8. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                        Richard Doust Newbie

                        From wikipedia:

                         

                        In addition, businesses found that using EJBs to encapsulate business logic brought a performance penalty. This is because the original specification only allowed for remote method invocation through CORBA (and optionally other protocols), even though the large majority of business applications actually do not require this distributed computing functionality. The EJB 2.0 specification addressed this concern by adding the concept of local interfaces which could be called directly without performance penalties by applications that were not distributed over multiple servers.

                        • 9. Re: JBoss 4.2 (w/EJB 2.0) to JBoss 7
                          Stephen Coy Master

                          I don't think JSPs are going anywhere soon. There's no mention of deprecation in the Java EE 7 specification. And Facelets seem to be closely coupled with JSF at the moment.

                           

                          And because you had the foresight to use JNDI correctly, the migration of your EJBs will be greatly simplified. No java code changes should be required.