How to manage multiple version of classes at the same time?

Question

We are implementing an enterprise financial Web application software. We're using spring, hibernate, oracle(DB), JSF. The requirements are changing over maintenance phase of software and we must have multiple version of some entities(also managers, forms, ... classes) at the same time because of compatibility of previous version of software. This changes of classes include : Add/Remove fiels, Change fields, Add/Remove Class, ... In general this problem is running multiple version of software at the same time. Please help me to find a solution for this problem.

Clarification:

This problem is similar with "variability in time" in software product line (See elsner_vamos2010 for more information). This means that we may have multiple version of one class at the same time and we must get class with (or date) parameter. In each date one version of class must be used Because of compatibility with state of program on that date. We solve this problem on Bean class with XML file and get version of class with date. So, The program knows what bean must be run for this state of program (date of other entities).

But we can't solve it for other object types in spring such as entity, jsp, form?

Answer 1

you can deploy different versions of your project in different WARs/EARs. In this case your container will take care about them automatically. Each war will be loaded with its own classloader, so the different versions of the same class (package and class name) will not intersect. Is this option good enough?

Answer 2

Hard to tell if this is feasible in your case, but I would try hard to avoid fooling around with Classloaders. Its a difficult area on its own, and WebAppServers tend to do their own thing with Classloaders as well.

I would try to make it two separate webapplications, possibly hosted on the same server and communicating through the database (assuming you have one in place for your app anyway)

Answer 3

Have you looked into OSGi? One of the features it provides is the ability for different client classes to simultaneously access different versions of the classes they depend on. That's how I understand it anyway, although I haven't used it myself.

Answer 4

Take the advice of Jens Schauder and avoid funny classloading tampering.

If we're talking about WebServices, EJBs or similar interfaces that your application has to support across multiple versions perhaps you can take the approach of an ESB mediator that translates (where possible) Vn-x requests and responses into Vn ones (where n is your latest version). This if you can transform one message into another using only mappings, simple functions or aggregations (think XSLT or XQuery processing) and need no state to be kept between requests. Any decent service bus would do that.

For the cases where a stateless transformation is not feasible, you can develop/adapt your code in a way that Vn version supports the Vn, Vn-1, Vn-2... APIs. You may have to use version façades to disambiguate operations/methods with the same signature (v1 putX may have a different behaviour than v2 putX). This allows you to change their implementation name in the Vn code while maintaining it in the façade for their respective version. The external systems only see the façades, obviously.

If you cannot do this, then have your different applications deployed separately.

Lastly, your schema.

If you adopt the approach where the last version supports previous APIs, then your application Vn is the only accessing the database. You have to adapt your schema to its needs and migrate data from older schema version if they exist. Done.

If you do not, you have have several versions of your application running and accessing the DB. In this case you have to have your DB "concrete schema" support different "logical schemas". See this book about database refactoring. This involves using several techniques whereby your schema supports interaction with more than one version of your application through clever uses of triggers, views, synonyms, etc. It seems tricky but is very doable.