1

In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...

But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.

So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?

It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.

oligofren
  • 20,744
  • 16
  • 93
  • 180

2 Answers2

2

I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.

Cedric Gatay
  • 1,553
  • 3
  • 12
  • 17
  • I have actually done just that (for one app), which is why I had my jsp comment above. This would mean adding servlets to each app that needed this solution, which is a bit of a hassle. Not a dumb idea, just not the one I would like :) – oligofren Jan 25 '12 at 13:57
1

Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:

asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear

There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv

Hope this helps.

John Clingan
  • 3,324
  • 21
  • 13
  • hmm ... does not seem to work in glassfish 2. get an error message saying that an application already uses the context path. even though I had disabled the previous version. will try with glassfish 3. – oligofren Jan 28 '12 at 11:50
  • Sorry, this is a GlassFish 3 feature. Sorry, I didn't notice GlassFish 2 as the version. – John Clingan Jan 29 '12 at 01:57
  • No worries - I like this solution, and might go for it after testing it with GF3 and seeing if the upgrade path is clear. – oligofren Jan 30 '12 at 09:04