• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Supporting multiple versions of a given application

 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am hoping that this is the right forum to post my question.
This is not related to any technology but related to the procedures that is followed by the most of the vendors to support multiple versions of the given project/module/tool.

We have an internal application that is being used by all other applications. Parallely this application is also updated with new features And every time when a new feature added/updated/removed/bug fixed, the version of the application is updated and deployed with the version number. This application is a .war file that holds library of JS files.
Example: if intial version of the application is app.war, then next version will be app1_0.war.

In order to pickup the changes/updates, other applications using this app has to be updated with the latest version. That is manually go and search in all files where "app" is reffered and replace it with app1_0. ofcourse application need to be tested thoroughly to see if new version did not break any functionality.

The war filename is updated with new version name inorder to support earlier versions.

Are there any guidelines/procedures to handle such scenario?.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Saritha,
I prefer using the same file name for each version. It's annoying to pull in a library and then have to update a bunch of my paths to accomodate it. You can include a version.txt file in the war so people know what version they are on.

ofcourse application need to be tested thoroughly to see if new version did not break any functionality.


Right. This part has to be done no matter what.
 
Saritha Penumudi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Jeanne,
Even I like to have same name for different versions. I don't like changing my code just to change paths.

But yesterday evening I learned that they would deploy this application in a sperate box and based on the url, apache would redirect this url to that box. This box will contain different versions of the same app. Hence they have to rename .war file with version number to support different versions.

I such scenario, can you think of any better approach to this problem?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Saritha,
So you would have multiple versions of the app deployed. In that case, yes you would need to have different war file names.

So the callers wouldn't need to update their paths since they would be referring to the URL instead of including the ware files in their apps.
 
Saritha Penumudi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:

So the callers wouldn't need to update their paths since they would be referring to the URL instead of including the ware files in their apps.



The callers will need to change the paths.
Example:
lets say APP1 is the main application and has reference to APP2.
APP1 and APP2 can be deployed in two different servers.

When there are bug fixes in APP2, they change version to update war file to APP2_1_0.

APP1 need to pickup changes made in new version, hence all path references need to be updated from APP2 to APP2_1_0.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm confused. Is the war deployed separately (with the callers going through URLs) or is it being distributed and deployed with other ears?
 
Saritha Penumudi
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
I'm confused. Is the war deployed separately (with the callers going through URLs) or is it being distributed and deployed with other ears?



Sorry,
If I had created any confusion..
Yes, WAR is deployed separately. It is not distributed with other ears.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Saritha ventrapragada:
Yes, WAR is deployed separately. It is not distributed with other ears.


Right. So the other applications, need to refer to a different URL, not rebuild their application with a different WAR name. This makes things easier. The applications can store the URL path in a property file. Then they just have to update this property file when they want to point to a newer version of the WAR.
 
reply
    Bookmark Topic Watch Topic
  • New Topic