2

What is the best/correct way to manage patches version information on j2ee WAR file
I would like to maintain patch information on a WAR file, so this info could be displayed inside the application once it’s running for maintenance purposes.
was thinking of few possible ways:

  1. Using DB table – (I would like to avoid this method)
    • Disadvantages
      • Couple the WAR versions to a DB
      • Additional overhead of database script with the patch.
  2. Adding internal XML file to the resources then reading and analyzing/parsing it
    • Disadvantages
      • Issues accessing the XML (Physical path issues?)
  3. Adding the patch info to MANFIEST file
    • Disadvantages
      • Impossible to display it in the app?

I would like to know if there are more ways and what is the best one for such requirement.
Thank you

JavaSheriff
  • 7,074
  • 20
  • 89
  • 159
  • Would you like to do it with maven? – Pramod S. Nikam May 29 '14 at 14:04
  • Process to update the version will be done manually. (Exploding the war and updating the files) – JavaSheriff May 29 '14 at 14:19
  • Regarding 1, look into SQLite and embedding the file in the WAR. It's essentially 2, with with something more DB-like. You can avoid path issues by doing [getResourceAsStream()](https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletContext.html#getResourceAsStream(java.lang.String)). – David Ehrmann Jun 02 '14 at 23:42
  • I would go with the second option. It is convinient to open XML file stored in classes directory. – Leos Literak Jun 03 '14 at 06:57
  • 1
    Patching a web application is not a great practice as it is rarely repeatable. You're better off building and shipping an entire new WAR file with a new version. – Steve C Jun 04 '14 at 11:22
  • If you are using tomcat, it has some thing called tags.. http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Deploy_A_New_Application_Remotely – Jayan Jun 06 '14 at 04:25

3 Answers3

2

Considering your question, you can store your version in many ways:

1.DB table

pro : ?
cons: infra dependant, need to update db, can be desynchronized
conclusion :please avoid that, it is dependant of your infrastructure.

2. Properties File : BEST OPTION !

pro: simple to integrate, ressource is localized by java.util.Properties, implement in 15 min.
cons: ? 
conclusion: Simple and easy; the best choice for me. Take a look to the code

3. Manifest

pro: may work
cons: bad practice to use a defined component for another purpose, bad architecture practice
conclusion: Avoid this solution, it's a bad architecture practice.

WINNER: Properties Code example, test it in less than 15 min.

public static Properties loadProperties() {
        String resourceName = "version.properties";

        Properties prop = new Properties();
        try {
            prop.load(DBTools.class.getResourceAsStream(resourceName));
            logger.trace(String.format("config file %s loadded with success !", resourceName));
        } catch (IOException e) {
            logger.error(String.format("config file %s is not loaded!", resourceName));
        }
        return prop;
    }



  version.properties File 
    APP-VERSION=1.12.4-REV2345-NIGHT

in your app when you want to retrieve the app_version, simply do :

property.getProperty("APP-VERSION");
jeorfevre
  • 2,286
  • 1
  • 17
  • 27
  • User wants changelog, not just the version. And for the version, he can use the MANIFEST file already for this. See my answer – Bruno Borges Jun 09 '14 at 23:34
  • 1
    You're right, we can do it like that. It's only a question of architecture / Design Philosophy. – jeorfevre Jun 10 '14 at 18:10
1

with the manifest.mf, this file must be regenerated with every build including this entries:

Implementation-Title: The value is a string that defines the title of the extension implementation.
Implementation-Version: The value is a string that defines the version of the extension implementation.
Implementation-Vendor: The value is a string that defines the organization that maintains the extension implementation.
Implementation-Vendor-Id: The value is a string id that uniquely defines the organization that maintains the  extension implementation.
Implementation-URL: This attribute defines the URL from which the extension implementation can be downloaded from.
Specification-Title: The value is a string that defines the title of the extension specification.
Specification-Version: The value is a string that defines the version of the extension specification.
Specification-Vendor: The value is a string that defines the organization that maintains the extension specification.

here is the discution about how to read it from a servlet How to read MANIFEST.MF inside WAR application?

Community
  • 1
  • 1
Emilio Navarrete Lineros
  • 119
  • 3
1

Do not use MANIFEST for this. Create your own changelog file format, bundle it inside your WAR file in a location known by your application, and create a feature in your application to display this. MANIFEST was not designed for storing changelogs and on the long term will only bring you problems if you go this way. I suggest you add a property that tells you where the changelog of that version is located. For example:

--- MANIFEST ----
Application-Version: 1.2.5
My-App-Changelog: /WEB-INF/changelogs/version-1.2.5.xml
-----------------

Depending on the application server or web container you are using, you may be able to create an extension or another app= that introspect all deployed WARs and displays this information. You will be required to use vendor-specific APIs.

Everytime you release a new version, that archive will contain the version number and changelogs of all versions, which is good for quick tracking of changes.

Bruno Borges
  • 853
  • 7
  • 24