java – Struts 1 to Spring Migration – Strategy

java – Struts 1 to Spring Migration – Strategy

My friend, it is so good to read your question! I lived the same hell you are about to enter using the very same stack…

Approach 3

Honestly I would never try it. The reason would be simple, we wouldnt want the risk of having old project and new project mixing with each other. Libraries from the legacy are very likely to conflict with libraries from the new project (same libraries, different versions) and you would then need to either refactor old code to allow use of the new version, or change libraries completely.

When migrating, you will want to keep your work on the legacy code to a minimal, to none if possible.

Approach 2

The perfect one, but as you said, it wont pay the bills. If you have the cash to work on it, then great, go for it, otherwise, you are for…

Approach 1

Strangulation, thats what worked for me. Start with a working shared login and then move to small functionalities. Think of a tree, you start by removing some small branches, them you move to nodes, until you are able to cut everything. As you remove the small functionalities, they should be made available on the new product (obviously you cant disrupt service otherwise you would go with approach 2).

More specifically, my suggestion is:

Back-end

1) Get the login working. In my case, legacy was all about session, but we didnt want that on the new product. So we implemented a method on the legacy code during login, which would call Oauth from the new product and store in the database the login information, just as you mentioned. The reason for this is on the front-end part of my reply.

2) Define how your legacy and back-end will live together and the resources to have both of them working (ram and CPU to be more precise).

2.1) If by any chance, your legacy runs on tomcat with custom libraries, you might have problems running your new product in a different context. If that happens, my suggestions, go for Docker (just get a close look on memory usage and make sure to limit them on your container(s)).

3) Start very small, replace functionalities related to creating new stuff which hold little to no logic (small crud, such as users, etc) then move to things that have mid-sized logic or that are really ugly on the legacy product and are used on day-to-day basis by your end-users.

4) All of the rest (by the time I left the company, we were not in this phase yet, so I cant provide much info on that).

5) Dont treat this project as a migration only. Get everyone on the page that this a new product. Old code should not be copied and pasted, it should be understood and improved using best practices.

5.1) Unit and integration tests as soon as possible, if your legacy have them, GREAT, compare results to make sure your refactoring didnt break anything or changed the expected outputs. THIS IS ESSENTIAL.

Front-end

1) Once you have the unified login working, you will be able to load the pages from the new product as if they were part of the legacy (you could even add a frame on the jsp of the legacy that will load your angular page, we did it and it works like a charm).

1.1) Not cute from a UI/UX perspective to have old and new pages, but it will add value to end-user and provide you with feedback from them once you release the pieces to production. Since your legacy now have access to the token (or whatever auth method you are using, that will be feasible).

2) Define the styles from the beginning. Dont get the job of UI/UX to later (like my team did). The sooner you figure out things such as colors, design, icons, etc, the less time you will waste on meetings that should discuss the release and its impact but are wasted discussing this is not the color I wanted or similar. Honestly, get UX defined before UI and make that crystal clear.

3) Design it as if you were designing a micro-services front-end. You might take a lot of time to get to that point, but if and when you do, the migration from the new architecture to micro-services will be much less traumatic.

Culture

I dont know the culture of your workplace, but mine was far from perfect, old people with old thinking into their comfort zones.

Get to change the workplace culture to adapt to what we currently have on the marketplace, old people sometimes tend to resist change, specially when they are technical and do not update on whats new out there. It will make much easier to replace people when they leave the company (because people do move on).

I heard they are still trying to run Scrum (as I mentioned I am no longer there), so there was a huge headache for developers defining What and How the migration of functionalities will take place.

Those are my two cents, hope they help you in some way, and I wish you the best of luck.

Since option 2 is not considerable because of business feasibility let’s talk about the other two.

Approach 1

If you push your session state as far back as appropriate datastore ( Redis/Memcache) and use a transparent mechanism to get the
session data and update any changes made by app server then you would not need to change any code interacting with session.
Any call to get session object from any piece of code in your application is delegated to container and it is container which
provides you with the object ( usually a mapping of sessionid and object is maintained). For container such as Tomcat I am aware of
session manager which can be replaced by just putting the jar in the container and pointing the config to the backend store. I have used
memcache based session manager successfully in production for a high traffic internet application.
Check this for Redis (https://github.com/pivotalsoftware/session-managers) and Redisson Tomcat manager (https://github.com/redisson/redisson/tree/master/redisson-tomcat), Memcache (https://github.com/magro/memcached-session-manager)
Using this will tranparently fetch/store session in respective datastore without changing any session related code in your application.

So the request with session id in cookie can land up on any of the tomcats ( hosting struts or Spring MVC app) and get the session
fetched from the backend store, made changes upon and tranparently stored back.

Approach 3

Is technically possible ( they are after all different servlets with different configuration responding to different url patterns)
but opens a lots of problems areas in terms of
dependency jars conflicts. But if you freeze the library versions of both the framework during the migration and somehow dont get any
conflict with a certain versions of your mix then it can be worth trying as eventually the struts library and its dependencies will go away.

As for the Angular part – you can still still have the user info in the session and rest of the stateful interaction will need to be designed
in a series of stateless ( stateless on the middle tier as eventually you will need some state – just that it will be pushed to the database) interactions.

java – Struts 1 to Spring Migration – Strategy

Leave a Reply

Your email address will not be published. Required fields are marked *