Hello Mike, On 23 Sep 2010, at 21:56 , <[email protected]> <[email protected]> wrote:
> I have not created bundle activators, as I was told (likely incorrectly), > that this was unnecessary if I use Spring DM, but that it required some sort > of configuration file. After further reading, it appears what they were > referring to is an OSGi 4.2 blueprint.xml document in each of the bundles. > Is this correct? There are several systems that support some form of declarative services that allow you to define components and their dependencies in the form of XML. Blueprint is one of them, Declarative Services another (and there are others). > What is the best way to convert a bundle that was previously an executable > .jar file with the following start-up method signature into a working bundle: > > public static void main(String[] args) > Should I convert the former executable portion of the .jar into a bundle > activator and use a blueprint.xml file, or is there a better way to > accomplish this? Several options, as always: 1) write a bundle that will pick up on bundles that have this Main-Class: x.y.Z header in the manifest and "run" them; 2) stick an activator in each bundle that does that; 3) stick an activator in each bundle that, from the BundleActivator's start() method simply invokes your main method directly; 4) look at the Knopflerfish OSGi implementation because they at least had a mechanism for launching main methods in bundles already (and either use that or use it as a basis for your own work) In all cases you probably want to launch a new thread for each main you invoke, as they will probably not return and you do not want to hijack any existing thread or you run the risk of your first bundle hanging the whole system. Personally, I would go for option 1) as it's the easiest to maintain and does not require anything special from the developers that are creating these bundles. Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
