-
1. Re: Migrating from 2.7.2
Hi,
As far as I know, there is not really a document, for this.
Globaly, this is not so difficult, no big problems... But a lot of work.
Here are a few things to look at, before to start :
A) Need to migrate to JBoss AS 7, now called WildFly.
For the new version of a portal, it is recommended to use JBoss AS 7.
This migration is a wide technological jump : all plateform component are upgraded, hence, a lot to do to migrate.
Here are a few things about this :
Hibernate upgrade : should not be lot of work.
Ejb : adaptation of the code... And more work on setting up the whole to run, and tuning.
JSF : migrate ro jsf 2. Adaptation of config ...And more work on setting up the whole to run, and tuning.
Richface : migrate to RF 4. You will need to quite review all the code... While keeping the conception and the bases of code. This is quite heavy.
B) GateIn : it has been toadly rewritten from jb portal.
There won't be a lot of things to keep from your jb portal application and codes.
You can use your conception and some mecanisme... But the portal is roughly to rebuild.
As an example : the management of the Users has been rewritten. It keeps some of the good principles, but the code is different, hence, you will probably need to adapt your configuration. You can keep the conception, the principles, ... but need to rewrite the code and configuration.
Think also to migrate, and adapte the Users data and profiles.
Same for the Layout and Design.
C) Miscellanous
"Responsive" and Web 2.0 interface with ajax : may be include some of this in the migration and rebuild.
Ejb and beans : idem. You may want to rewrite some part of them, using annotations.
*************
Here after, a few things about the way to handle and start this kind of migration :
Main strategy : cut a perimeter and make small bytes... To make it by step.
The main (most obvious) cut i can see is : separate the application layer from the business layer. The ejbs and jpa one side, the portal and webapps with jsf an richfaces on the other side.
Then, you will be able to migrate the portal to jboss 7... While keeping the ejb on the jb 4 server for a while.
This will enhanced the reliability of the migration... And it might also bring some advantages for the future.
**************
All this depends, of course, of the details of your portal and the applications it provides to the users.
Regards,
Antoine
-
2. Re: Migrating from 2.7.2
Layers are separated, portlets UI are with JSP with their "little" business layers in their backbeans. The "real" business is in the EJB and then is the data access.
Reading your answer seems that there is a lot of job, and seems better to think in it as a new project, having the know how, but starting de developmen as new...
-
3. Re: Migrating from 2.7.2
Hi,
Layers are separated, portlets UI are with JSP with their "little" business layers in their backbeans. The "real" business is in the EJB and then is the data access.
Thats good.
What I mean is : take advantage of this separation, to make them run in two servers, with different versions of servers on each.
As an example : keep the real business EJB on a JBoss 4.3.2 (or 5 if so). You don't migrate them, for the time being.
And start to migrate the portal and application side (portlets, JSP, application backbeans,...) to the new version, with JBoss 7, JSF 2, RichFaces 4, etc...
you will have, if not yet done, to make the two layers communicate, with the network, between the two servers.
This may need some tuning : for performance, and for the versions that are not the same and may cause few tuning problems.
For performance, it depends on what do the application, and how the EJB are called and sollicited.
Usually, with a good network, properly configured, the performances are good...
I would recommend to start upgrading the portal side... and let the business side in the former version.
It is, as my opinion, more reliable, and more "judicious" (but not simple to explained writing).
***********************
Reading your answer seems that there is a lot of job, and seems better to think in it as a new project, having the know how, but starting de developmen as new...
Yes, exactly.
keep the know how of the application, keep some (big) pieces of code, keep the experience of this application.... and make a new application, with a full new development project.
Usually, this is the opportunity to make the functional enhancements, to rewrite technical "things" that was done "quick and dirty", etc...
And still, this is the opportunity to propose a "Responsive" interface, and to make the new function that the users asks.... which is sometime a good way to drive the new project.
Most of the time, it is not enough to say you need only technical update...."to explain the bill".
And it is better, usually, to drive a project, with the users needs,... than only technical aims.
Regards,
Antoine