Release Management

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: , , ,

Monday, March 3, 2008

Can't open activity db: Permission denied error for SVN commits

On my way to work this morning I got an emergency call from developer who unsuccessfully tried to commit latest java code changes to Subversion repository using TortoiseSVN. The developers was getting "Can't open activity db: Permission denied" error in TortoiseSVN client when he tried to commit or create a new tag in SVN.

The Apache error log had this lines related to SVN commit problem
Could not create activity /!svn/act/9dac40a3-4acf-3456-b328-a2598c258d06
Could not open dbm files
Can't open activity db: Permission denied

Just in case I have run svnadmin verify on Subversion repository, but as expected there was no problem at all. Then I noticed that the files on the dav folder of the SVN repository are not writable by Apache server. I changed files permission and successfully committed files with TortoiseSVN again.

The configuration used in this solution

• SVN 1.4.6
• Apache 2.0.49
• Tortoise 1.4.7

Unfortunately no references related to SVN commit problem were found in Subversion FAQ or TortoiseSVN FAQ

Update: I set permissions for "activites.pag" and "activities.dir" files in dav folder to 777

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
  •