[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
FW: [corona-dev] FW: Extending OSGi Console
|
Here is the original link:
http://balfes.net/cgi-bin/blog.cgi/2006/04/17/
there was also some discussion here:
http://dev.eclipse.org/newslists/news.eclipse.technology.equinox/msg01042.html
From: corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn
Sent: Wednesday, October 18, 2006
1:24 PM
To: Corona
development
Subject: [corona-dev] FW:
Extending OSGi Console
I thought maybe it made sense to let more
people know this capability exists it may spark some ideas that will simplify
finding and fixing some of the issues we will encounter server side
Glenn Everitt
From: Everitt, Glenn
Sent: Wednesday, October 18, 2006
12:56 PM
To: Hawkins, Joel
Cc: O'Flynn, Dennis
Subject: Extending OSGi Console
Seems like it we should be able to expose MUSE api through
console command assuming they only take strings
|
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.
|
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
|
_______________________________________________
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
