Sunday Oct 14, 2007

Reuse a NetBeans Services Tab Node

In NetBeans 6.0 IDE under the "Services" tab, there are a bunch of useful nodes inside the tab, ie. Databases, AppServers, etc.  They look like this:

service tab 


Now if you are a NetBeans module developer and you want your module to re-use one of nodes, for example, you want your wizard to pop-up a JNDI-browsing window for Glassfish AppServer.  You can do the following to accomplish this.

Find a reference to the Node instance corresponding to the "Servers" node.

            FileObject fileObject =
Repository.getDefault().getDefaultFileSystem().findResource("UI/Runtime/ServerRegistry2.instance"); DataObject dataObject = DataObject.find(fileObject); Node serverNode = dataObject.getNodeDelegate(); final ResourceBrowserPanel browserPanel = new ResourceBrowserPanel(serverNode); 

"UI/Runtime/ServerRegistry2.instance" is the URL of "Servers" node as described by

This requires you to search the NetBeans' source code in order to find out the URL, after this it is straight forward to get the reference to the Node instance.  To display this Node in an Explorer view, you can use NetBeans' Exporer API.

public class ResourceBrowserPanel extends JPanel implements ExplorerManager.Provider {

private final ExplorerManager manager = new ExplorerManager();

public ResourceBrowserPanel(Node rootNode) {
BeanTreeView btv = new BeanTreeView();

setLayout(new BorderLayout());
add(btv, BorderLayout.CENTER);

public Node[] getSelectedNodes() {
return manager.getSelectedNodes();

public ExplorerManager getExplorerManager() {
return manager;


Here is the result of what it looks like when the same "Servers" node is projected in a new dialog window:

dialog servers

Sunday Aug 12, 2007

SNMP BC Part 2

In this demo, we will show how to implement the processing logic for the incoming SNMP trap, and we would refer to this processing logic as "Adaptation".  Normally, we would want to feed these incoming SNMP traps to an event-processing engine, since usually it is the occurrences of events that are most interesting.  However, for simplicity sake, in the demo we are feeding the SNMP traps to an EJB exposed as a webservice operation, and we simply print out the values for each trap in the EJB method.

Here are the main steps to create this project:

  1. Create a new Composite Application Project.
  2. Create a new WSDL document, import a pre-defined XSD file, define a one-way operation.
  3. Generate a new EJB exposed as Webservice from the created WSDL file.
  4. Writing processing logic in the EJB method.
  5. Add EJB as a component of the Composite Application Project.

Pretty simple right?

Click to see the Demo Part 2.

Wednesday Aug 08, 2007

SNMP Binding Component Demo Part 1

SNMP Binding Component (SNMP BC) is developed  as part of open-jbi-components project.  It allows network devices based on SNMP protocol to be accessed from an ESB system.

Below is Part 1 of a series of demos on how to create a SNMP based project from within NetBeans IDE.  First step in an end-to-end scenario is to create a metadata implementation for the SNMP BC, SNMP BC will use this metadata implementation to resolve information regarding network devices and how to process incoming traps from these network devices.  See design doc for details.

Click to see the Demo.


Monday May 14, 2007

JavaOne BOF on Memory Leaks

For those of you who came to Frank and myself's BOF session at JavaOne, you can download my "modified" jhat here jhat.jar.  My modification of original jhat include:

  • add exclude functionality on query results to make it easier to filter out hundreds of duplicate reference chains, this way it will be possible to find unique leaks (see Figure 1)
  • add classloader browser to nicely display classloaders' parent-child relationship, as well as number of classes loaded in each classloader (see Figure 2)

To run jhat, simple do "java -Xmx512m -jar jhat.jar <heap_file_name>"

Figure 1.

filter reference chains 


Figure 2.

 classloader browser


Update: Frank posted the presentation slides and audio recording of this BOF on his blog entry

Friday Nov 10, 2006

Find Orphaned Classloaders

This blog is in relation to Java PermGen OutOfMemory issue as described in Frank Kieviet's blog entries:

    Classloader leaks and How to fix Classloader leaks? 

To summarize, a new instance of custom Classloader is created by Application Server whenever a new application (.ear, .jar, .war) is deployed to the server, and this Classloader is used to load all the classes and resources contained in this application.  Benefit in this approach is that, this way applications are self-contained and isolated from each other, and there are no conflicts between different applications.  When an application is undeployed from server, its associated Classloader is also unloaded, and it is subject to garbage-collection by JVM.

As described in Frank's blog, there are situations in which Classloaders cannot be garbage-collected because of dangling references to them thru most unexpected places, and this will cause memory-leak in the PermGen space (a special section of heap).  To find the cause of this problem, I used JDK 6.0's jmap and jhat utility to generate memory dump and analyze memory dump, respectively.

Orphaned Classloader

jhat utility can be easily extended to include your own query on the heap snapshot, you need to download and modify the jhat source code though.  I added a new query to find all the Orphaned Classloaders in memory and display all the reference links to these Orphaned Classloaders.  By orphaned, I mean these classloader instances that have no strong-reference chains to them from the root set, except by these strong-references chains from rootset that goes through instance of Class loaded by the Classloader.  To illustrate this, see the diagram below (solid line = strong-reference, dash-line = weak-reference) :

The yellow Classloader instance is orphaned, because the only strong-reference chain to it from root set is the chain that goes through B.class, and B.class is loaded by this Classloader (all the red lines).  All other references that do not go through classes loaded by this Classloader are weak-references.  This scenario is a possible suspect of Classloader leak, because most likely Orphaned Classloaders are not intended result of programmer, there are exceptions though.  By using this query, we can easily find all the possible suspects, and then goes through each one to determine if they are real memory leak or not.




« July 2016