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]
