Finding a Plugin’s ‘Owner’

How much importance do you give to a plugin’s name?

Most developers new to rich client platform development generally name their projects not realizing the importance of the project name. You might start a new software feature with the project name MyRemoteWebServiceClient. The “problem” is that Eclipse’s plugin development environment inherits the bundle’s symbolic name from the project name. So both the project name and plugin name are MyRemoteWebServiceClient. Why is this a problem?

If you look at Lotus Notes, Sametime, or Expeditor plugin names, they appear verbose. A plugin named seems more unwieldily than just MyRemoteWebServiceClient. Naming convention becomes more useful after deployment.

Generally, plugin naming convention mimics the Java package naming within the source code. For any plugin, I’d expect the top level package in the plugin to be named the same. For example, should have a top level package called Why is this useful? Let’s assume that a product fails with the exception:

Caused by: org.xml.sax.SAXParseException: The root element is required in a well-formed document. Message being parsed:
at $Proxy28.getSystemTime(Unknown Source)

Once you move beyond the Sun packages, you’re in the plugin developer’s code . The class threw the exception, but what feature contains this plugin?  How can I find the plugin owner to fix the defect? You can start by inspecting the client platform using some OSGI commands from a previous post. To find the bundle, you might use the class’ package hierarchy and issue the command:


This might output the following.

Framework is launched.
id State Bundle
24330 ACTIVE

Now you know there are actually two bundles sharing the identifier. They’re probably related, but more importantly the bundle with ID 24329 matches the offending class’ package seen in the stack trace. There’s the offending plugin – or at least a highly suspicious one.

Leave a Reply

Your email address will not be published.