Monday, March 31, 2008

Using FindBugs in JDeveloper 10g

by Fábio Souza

FindBugs Logo
These days I've been looking for a good way to incorporate FindBugsTM within my JDeveloper 10g and I couldn't find anything about it on the net. I talked with Eduardo and we both thought it would be a good idea to configure FindBugs as a JDeveloper External Tool (and it is indeed).

Ok, before I start listing the steps to do it, I must say I'm pretty much aware of the fact that you will probably notice that I'm using Eduardo's JAXB 2.0 configuration steps listed on his previous post "JAXB 1.0 vs. 2.0 in JDeveloper 10g". Well... what can I say? I am a CTRL+C/CTRL+V addicted and I just can't help it! :D
  1. Click the menu item "Tools -> External Tools..."

  2. Press the "New..." button to start the "Create External Tool" wizard

  3. Select "External Program" as the "Tool Type" and press "Next"

  4. Fill the 3 displayed fields as follows:

    1. Program Executable:

      full path to the "java.exe" from your preferred JAVA_HOME (must be Java 5.0 or greater)

    2. Arguments:

      -Dfindbugs.home=. -Xmx256m -jar lib\findbugs.jar -sourcepath "${project.first.sourcepath}" -auxclasspath "${project.classpath}" -html -output "${project.dir}\${}.findbugs.html" "${project.outputdirectory}" "${project.outputdirectory}"

      The arguments above will be passed to "java.exe". Notice that we're bypassing "findbugs.bat" and executing the FindBugs JAR file directly. We must do this way because the batch file requires the classpath passed after "-auxclasspath" to be enclosed in double quotes (") and the macro "${project.classpath}" will match that requirement only when there's at least one path including one ore more blank spaces in its directories names.

    3. Run Directory:

      full path where FindBugs is installed.

  5. Press "Next" to advance to "Display" step and fill the 3 fields as you like. I suggest the following:

    1. Caption for Menu Items:


    2. ToolTip Text:

      Run FindBugs on your project.

    3. Icon location:

      Download and configure this one -> FingBugs icon

    4. Press "Next" to advance to "Integration" step where I recommend selecting "Tools Menu" and "Navigator Context Menu"

    5. Press "Next" to advance to the final step "Availability". Here, you have to choose the option "When Specific File Types are Selected" and then move only the item "Java Project" from list "Available Types" to list "Selected Types"

    6. Press "Finish" and done!

Attention! I got an error while trying to use FindBugs in my JDeveloper When "${project.classpath}" is expanded after "-auxclasspath", it includes the Java library paths as well. But, I don't know why, the default JDeveloper's Java SE library has i18n.jar, sunrasign.jar and the "classes" folder included in its classpath but these three items actually don't exist, so FindBugs will abort when it tries to locate them. I had to remove these items from my JDeveloper Java SE Library classpath to solve this problem.

Now it's all set to use FindBugs! Just right-click on a project in the Application Navigator and select "FindBugs". An HTML report will be generated in project's folder and standard output and error will be sent to JDev's Message View.

Enjoy your new tool!

Thursday, March 13, 2008

Important Tip for Clustered OracleAS

by Eduardo Rodrigues

Hi everybody!

Recently we've upgraded OracleAS environments in one of our biggest clients here in Brazil from version to version To do that, we've applied patchset #6148874 (which can be downloaded from Oracle Metalink) carefully following all the instructions found in its installation guide. As expected, the patchset application went perfectly fine and all of our configured containers and applications were still there, up and running, and everybody was happy... until we noticed that one of our oldest and most annoying problems was still there: using ASControl to manage our clustered production environment sometimes was just impossible due to its unacceptable performance when trying to access anything in cluster topology context.

Unfortunately, the only workaround we knew was to restart ASControl application in the cluster's "master node" (the node elected to run the ascontrol application). Fortunately, today I found the problem and also the solution for this situation.

There's a documented bug on Metalink (bug #6601697) explaining that this problem is caused by the underlying RMI communication between the ASControl and the other components of the cluster. ASControl uses RMI protocol to connect to other nodes, makes some request and then waits for a response. The problem is that there's no timeout for this response waiting. If one or more components are in a heavy load situation, for example, ASControl will keep waiting for their responses, which can take too long, causing the impression that ASControl stopped working.

In fact, this problem is known since version but it seems that patchset does not include the correction as it should. So, for now, the solution is to apply the one-off patch #6124143, also found on Metalink. This patch is originally targeted to OracleAS but, as written in bug #6601697, it's ok to apply it on version though. We just have to follow these simple instructions, found in the bug, before actually applying it:
  1. Edit the patch file etc/config/actions and replace by

  2. Edit etc/config/inventory and replace by

Once it's successfully applied, we must use ASControl to navigate to the OC4J instance where ascontrol application is running (typically the "home" instance). Click on Administration -> Server Properties -> Command Line Options -> Start-parameters: Java Options and add "-Drmi.client.connection.timeout=X", where "X" should be the number of seconds to wait for a RMI response before timeout. The bug suggests 5 seconds.

We've successfully applied this one-off patch in our OracleAS environment and, until now, it seems to have solved the problem.

I feel this might be a problem faced by many other OracleAS 10.1.3 users so I hope this post can help them.

Cheers and... keep reading!