Would the main() typically be instantiating the class? If so, since the class would be instantiated at activation, wouldn't this be doubling memory?
How about gutting the main() and putting the functionality in a method that both start() and main() would then call? On Thu, Sep 23, 2010 at 5:29 PM, Guillaume Nodet <[email protected]> wrote: > I'd go with #3. Especially if you plan to deploy in Karaf, i'd avoid > #1 because Karaf has some bundles with a Main-Class attribute which > would cause undesired side effects if you scan all bundles with this > attribute and start those. > > On Thu, Sep 23, 2010 at 22:39, Marcel Offermans > <[email protected]> wrote: >> 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] >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > --------------------------------------------------------------------- > 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]
