Ermm....I didn't mean you should embed the framework into the app :) I
meant exactly the opposite - you should put the App inside an OSGi
framework. I'm sorry I wasn't clear enough. Here goes another attempt :)
You should make it so that you start the framework which in turn will
start your app. To do this you make a single bundle out of the entire
app. You must package it all into a jar, add a BundleActivator and an
OSGi manifest. In the activator you do almost the same things you do in
main(). Except you must not hog the thread that calls
BundleActivator.start() - spin off another thread to drive the app. At
this point your application is an OSGi-citizen. A big-fat citizen :)
To make real use of OSGi you should proceed to gradually chop this fat
bundle into smaller bundles. E.g. make more bundle jars, add an OSGi
manifest to each one, code a BundleActivator for each. If you use common
libraries you should look for ready-made bundles for those. You will
also have to add code that talks to the OSGi service registry: this is
the only way your bundles will be able to talk to each other at runtime.
At the end of this process your app will become a bunch of
interconnected bundles.
Finally instead of coding BundleActivators by hand and talking to the
service registry by yourself you can use iPojo - it will do it all for
you. An added bonus is you will not have to spread OSGi API classes into
the code of your App.
Depending on the size,complexity and quality of design (the "design
level" modularization) of you app this process can become really hard.
For example if you use external libraries that insist to class-load your
code you will hit a nasty problem because you want to delegate this job
to OSGi now. Also if you use libraries for which you can't find
ready-made bundles you again will have trouble. Finally if your code
happens to be too monolithic you might have to redesign.
Hope this helps more,
Todor
Todor,
Thanks so much for your feedback. Embedding the framework in the application
sounds like a solid approach. One concern I have though is with the framework
embedded I lose the ability to use any tools (console, JMX-based manager, etc.)
to interact with and control the framework. Have you simply provided that
support in the application via an API for such things, for example installing
and starting new bundles?
-----Original Message-----
From: Todor Boev [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 4:40 AM
To: [email protected]
Subject: Re: OSGi best practices
William Drew wrote:
I am looking for some guidance on best practices or well known approaches to
building OSGi "enabled" applications. Currently I have an application that
is started from the command line calling a class with a static main().
Ø java -classpath <whatever> com.mycompany.MyApplication
I'd like to take advantage of the modularity and adability of OSGi but I'm
not sure of the best way of approaching it. Do I embed an OSGi framework in
the existing application? Do I start an OSGi framework and install the
required bundles which would "start" the application? Any guidance on how to
approach this or how others are OSGi enabling their applications or systems
would be appreciated.
The best way is to split your existing code into bundles - bundelize the
app. That is also the most work :) To do this you follow the natural
modularization of the code - you must have some "design level" modules
right? With OSGi you make them explicit and call them bundles. You can
do this gradually: put all the code in one bundle and start splitting
off pieces from it into other bundles. This goes much like you would
refactor a fat class. I advise you to use iPojo or Dependency Manager to
hide the OSGi API. Using the raw API will require much more boilerplate
coding and unless you are extra careful it is very easy to introduce
dependencies to BundleContext deep into your code - that will hinder
unit testing.
When you are done you will have a configuration of N bundles placed in
directory somewhere. You start the app by simply starting the OSGi
container and pointing it to that directory (Felix works this way if im
not mistaken). The container starts the bundles. One of these bundles
contains the code that used to be in "main". When it starts it should
launch a thread that will drive the application (the thread that calls
"start()" to the bundle should not be blocked). Most of the other
bundles simply compose some services in order to produce their own
service. They do not start threads. In fact if you use iPojo you won't
have to think at all about who drives the application and all of this
threading business.
Hope this helps,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
