Release Management

Friday, May 9, 2008

QuickBuild and PMD

My team started using PMD as tool for preemptive defect detection and enforcing coding standards. Quickbuild and PMD set up was easy, I just copied four jar files asm-3.1.jar, jaxen-1.1.1.jar, junit-4.4.jar, pmd-4.2.2.jar from pmd-4.2.2\lib folder to ANT 1.7.0 lib folder on QuickBuild server and slightly modified Ant example described in PMD manual. As I wanted I turned on only most obvious rule set 'Java Logging Rules' for our Java projects and deliver to developers as HTML report. The following poor logging practices were detected with PMD almost immediately: using System.out or System.err rather than a dedicated logging facility, printStackTrace() method should not be used, because its output goes to the standard error device System.err rather than the log file managed by log4j and logger variable declaration does not contain the static and final modifiers.

Labels: , , ,

Thursday, March 27, 2008

Finding problems in Java code with PMD

In order to enforce correct and consistent invocation of log4j logging framework in application code, I decided to take a look at PMD – Java source code analyzer. My initial intention is to run PMD with 'Java Logging ruleset' only during each build executed with QuickBuild (LuntBuild). The build will fail, if violation is found. It may be annoying for our development team, but on the long run I'm certain that the whole team using code analysis tool like PMD will progress faster and finally developers would learn to write better code. Personally I would like to detected log4j problem in advance, but not after the code deployed to any environment. Perhaps in the future we would want to integrate PMD with Eclipse IDE, so developers would see log4j issues directly on the Eclipse IDE and commit only good code to Subversion.

Labels: ,

Thursday, March 20, 2008

Logging Best Practices

Recently I helped developers and QA teams to identify the cause of performance issues in one of Weblogic applications and I noticed that current way of using log4j framework for all Weblogic applications is unsystematic and inconsistent:

  • loggers, appenders and layouts set up differently for different applications
  • applications do not have properly defined SMTPAppender appender (no notification is sent when error is happening)
  • applications continue to write to Weblogic server logs by using System.out.print or printStackTrace() instead of using logger call.

I proposed the following solution and I have to implement it as soon as possible

  • Create common log4j template
  • define proper logger, appenders, layouts
  • applications should define their own log file outside server logs
  • application should broadcast error messages via email
  • Configure QuickBuild to use new log4j template
  • Update log4j template for all WebLogic applications
  • Enforce correct and consistent invocation of logging framework in application code by integrating static code analysis tools in SDLC ( for example JTest, PMD, FindBugs)
  • Include verification for proper application logging and error notifications to test plans
  • Acquire log reader tools (for example Chainsaw, LogMX, SuperTracer)

Labels: , , ,


All posts in one place

  • Doxygen vs JavaDoc
  • Installing JNetDirect's JSQLConnect driver
  • Finding problems in Java code wtih PMD
  • Log4j best practices
  • Can't open activity db: Permission denied error for SVN commits
  • Jira Subversion Plugin
  • Implementing Subversion post-commit hook
  • Troubleshooting Subversion and TortoiseSVN
  • IIS 6.0 does not serve files with .docx
  • Installing ANT on Windows XP
  • Luntbuild dealing with SMTP response 554
  • Confluence and Jira OutOfMemory errors
  •