Extending the OSGI Console

I was going to submit this to the IBM Developer Works site but I did not want to wait the four weeks to get it published. So here is the short version of the original article, I may still post a more comprehensive one but it will contain an even further extension of the console.

One of the best things a developer can do is make his code easily testable and accessible to other developers and quality assurance engineers. I have always been one to promote enablement and ease of use over complexity. The easier you can make your programs to figure out the better bugs are found and then fixed. Diagnostic tools and automation are great starts but many times the actual product itself becomes a debugging tool. I learned this very early in my career by paying attention to the way servers are created. Then an even more interesting observation occurred when I installed the client version of Quake; it had a console! Not only could you change configuration settings but you could also affect the immediate game with live bot commands.

So now, I make it a precedence to provide things like command line utilities, debug options and now OSGI console commands in my Eclipse projects. My latest attempt was to get some basic query commands for the new WED client side Property Broker. The broker basically has a registry of Wires, Actions and Properties (just like Portal server). The problem is when you have many Wires, Actions and Properties you may loose track as to which ones are enabled, disabled, registered properly, etc.

By extending the OSGI console, I now give developers and QE a way to query the broker for what is going on in its registry. Currently there are only read only commands but you are only limited to your imagination.

So how is it done?

Extending the OSGI console in Eclipse is extremely simple. You start by creating a new class and implementing org.eclipse.osgi.framework.console.CommandProvider. Once the class is created, you provide the getHelp() version for your provider and a constructor where you register your CommandProvider with the console. Here is a sample constructor that registers the current class as an OSGI Service for the CommandProvider:

public MyNewConsoleCommands(BundleContext context){

Dictionary props = new Hashtable();
props.put(Constants.SERVICE_RANKING, new Integer(Integer.MAX_VALUE-100));

context.registerService(CommandProvider.class.getName(), this, props);
}

Once your class is registered you can now start implementing commands. So what makes a command you ask? Well, its actually not very straightforward but once you hear it the concept is a piece of cake. You add commands to the console by simply creating public methods with an underscore in the front of the method name, that’s right “_”.

//This is the primary “show” command for the Property Broker
//from the console you simply type “pbsh actions and this method will be called.
//The second parameter will be the nextArgument() stored in the CommandInterpreter
//object passed in. In this case, the string next would be equal to “actions”.

public void _pbsh(CommandInterpreter ci) throws Exception {

String next = ci.nextArgument();

}

What is great about this concept is the console is only available when “-console” is added to the Eclipse executable command line. So it is only ever called if the console is in fact launched and a user types “help” and finds your commands in the console help. You can pretty much go nuts with adding commands to do all sorts of things. I noticed each release of Eclipse has more and more commands and extending the console is becoming popular even with other Eclipse based projects. You can even have undocumented commands that simply do not show up in the help. This could be considered “internal only” commands.

2 thoughts on “Extending the OSGI Console

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.