1 of 1 people found this helpful
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
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.
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?
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.
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?
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.
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.
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.