1

I was used to manage versions with a tag in Git. But that was a long time ago, for stand-alone applications. Now the problem is that I have a web application, and at the same application might connect clients that expect to communicate to different versions of the application.

So, I added to the input a path variable for the version in that way :

@PathParam("version") String version

And the client can specify the version in the URL:

https://whatever.com/v.2/show

Then across the code I added conditions like this:

if(version.equals("v.2") {
    // Do something
}
else if(version.equals("v.3") {
    // Do something else
}
else {
    // Or something different
}

The problem is that my code is becoming very messy. So I decided to do in a different way. I added this condition only in one point of the code, and from there I call different classes according to the version:

MyClassVersion2.java
MyClassVersion3.java
MyClassVersion4.java

The problem now is that I have a lot of duplication.

And I want to solve this problem as well. How can I do now to have a web application that:

1) Deal with multiple versions
2) It is not messy (with a lot of conditions)
3) Doesn't have much duplication
user1883212
  • 7,539
  • 11
  • 46
  • 82
  • This seems like a question for CodeReview (codereview.stackexchange.com) but even then you'd have to post more code to somewhat give a sense of the overall structure behind `calling different classes according to the version`. – EpicPandaForce Feb 06 '15 at 11:32
  • Implement a parent class `MyClassVersion` with the methods shared – Jordi Castilla Feb 06 '15 at 11:32
  • See Approach 2 in this answer: http://stackoverflow.com/questions/18936264/rest-web-service-versioning-in-practice (use polymorphism, and a separate controller / handler / service / whatever for v2, v3, v4. – vikingsteve Feb 06 '15 at 11:34
  • The problem is... I cannot really solve this with polymorphism if I have version-aware code five levels of abstraction below the controller. – user1883212 Feb 06 '15 at 11:53

2 Answers2

1

Normally, when we speak of an old version of an application, we mean that the behavior and appearance of that version is cast in stone and does not change. If you make even the slightest modification to the source files of that application, then its behavior and/or appearance may change, (and according to Murphy's law it will change,) which is unacceptable.

So, if I were you, I would lock all the source files of the old version in the source code repository, so that nobody can commit to them, ever. This approach solves the problem and dictates how you have to go about everything else: Every version would have to have its own set of source files which would be completely unrelated to the source files of all other versions.

Now, if the old versions of the application must have something in common with the newest version, and this thing changes, (say, the database,) then we are not exactly talking about different versions of the application, we have something more akin to different skins: The core of the application evolves, but users who picked a skin some time ago are allowed to stick with that skin. In this case, the polymorphism solution which has already been suggested by others might be a better approach.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142
0

your version number is in a place in the URL named the 'Context Root'. You could release multiple different WAR files each of which is configured to respond on different Context Roots. So one war for version 1, one war for version 2 etc.

This leaves you with code duplication. So what you are really asking is, "how do I efficiently modularise Java web applications?".

This is a big question, and leads you into "Enterprise Java". Essentially you need to solve it by abstracting your common code to a different application. Usually this is called 'n-tier' design. So you'd create an 'integration tier' application which your 'presentation' layer war files speaks to. The Integration tier contains all the common code so that it isn't repeated.

Your integration tier could be EJB or webservices etc. Or you could investigate using OSGi.

Richard
  • 1,070
  • 9
  • 22