4

I am responsible for a number of java application servers, which host apps from different developers from different teams.

A common problem is that some app is sent that does not work as expected, and it turns out that the app was developed on some other platform, i.e. openJDK on winXp or 7, and then deployed to Linux running Oracle JDK, or vice versa.

It would be nice to be able to enforce something up front, but this is practically not possible.

Hence are there any techniques to detect problems upon deployment I mean, without the source code, by scanning the class files?

If that is not possible, what is the tool I can use to send to the developers so they can identify from their source code what incompatible they have relied upon?

Tom
  • 3,324
  • 1
  • 31
  • 42
  • 2
    It sounds like you have a problem that coding guidelines for your teams would better address. Unless you're using platform specific libraries (which you shouldn't, because this is what happens) you won't have this issue. – Brian Roach Aug 18 '12 at 02:22
  • +1 Totally agreed that it would be best addressed by coding guidelines and unit tests. – Tom Aug 18 '12 at 02:23

1 Answers1

3

It's not possible to detect all such problems in a totally automated way. For example, it is extremely difficult to detect hard coded pathnames which are probably the single biggest issue with cross-platform deployments.

My suggestion would be to compensate for this with more automated testing at deployment time.

For example, in a similar environment I used to insist on deployment test suites: typically implemented as a secure web page that I could navigate to as the administrator which would run a suite of tests on the deployed application and display all the results.

If anything failed, it was an immediate rollback.

Some of the tests were the same as the tests used in development, but some were different ones (e.g. checking the expected configuration of the environment being deployed into)

Obviously, this means you have to bundle at least some of your test code into your production application, but I think it is well worth it. As an administrator, you are going to be much more confident pushing a release to production if you've just seen a big screen full of green ticks in your staging environment.

mikera
  • 105,238
  • 25
  • 256
  • 415
  • surely detecting hard coded paths, would be fairly easy to detect. Certainly more so than some jruby issue I experienced recently, where some jruby library relied on a win extension in jruby (rather than underlying java). – Tom Aug 18 '12 at 02:26
  • @Tom - well you could try scanning all the strings in the class files - but it would need manual review as you would get false positives all over the place from forward/backward slashes in text. Even then that is not going to catch everything since filenames often get constructed by code.... – mikera Aug 18 '12 at 02:30
  • For the specific example, findbugs may help. In general it is better to have the Continuous Integration done which could deploy the app on multiple configuration and perform some tests. – Jayan Aug 18 '12 at 02:35
  • 1
    You can use back slash in regular expressions, or you can use a back slash in file paths. A back slash in a regex is fine, unless its being used to parse a file path, in which case its not. This is very hard to detect automatically. – Peter Lawrey Aug 18 '12 at 08:00