You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by mv...@comcast.net on 2010/09/23 21:56:24 UTC
Converting a Java app into an OSGi bundle
Gents,
Over the last few months, I've been converting a large enterprise java application into a set of OSGi bundles. The goal is to have the bundles run in Karaf and perform the same things the previous application did (read files, communicate via JMS, etc).
So far, I've successfully converted the application into a large set of bundles, and have successfully deployed them into Karaf 2.0.0 via a features.xml file.
Each of the previous .jar files had the entry in the Manifest.mf file pointing to each .jar's main class in order to make them executable from a command line. Now that I've got these deployed into Karaf, of course those main classes aren't starting up the bundles.
So, my question is, what is the most efficient way of starting these bundles so they will work properly in Karaf. One of the bundles reads files from the file system, and most of the communication between the major bundles is via JMS (a holdover from the java app).
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? 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?
v/r,
Mike Van
Re: Converting a Java app into an OSGi bundle
Posted by Donald Whytock <dw...@gmail.com>.
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 <gn...@gmail.com> 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
> <ma...@luminis.nl> wrote:
>> Hello Mike,
>>
>> On 23 Sep 2010, at 21:56 , <mv...@comcast.net> <mv...@comcast.net> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Converting a Java app into an OSGi bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
We have 2 jars with a Main class in Karaf, only one of those is an
OSGi bundle, and in this case, it has an activator defined, so yeah,
it could work I think.
On Fri, Sep 24, 2010 at 00:06, Marcel Offermans
<ma...@luminis.nl> wrote:
> On 23 Sep 2010, at 23:29 , Guillaume Nodet 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.
>
> Just out of interest, do those bundles *also* have a bundle activator (manifest entry)? If so, you could write #1 to not process those.
>
> Greetings, Marcel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Converting a Java app into an OSGi bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
On 23 Sep 2010, at 23:29 , Guillaume Nodet 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.
Just out of interest, do those bundles *also* have a bundle activator (manifest entry)? If so, you could write #1 to not process those.
Greetings, Marcel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Converting a Java app into an OSGi bundle
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<ma...@luminis.nl> wrote:
> Hello Mike,
>
> On 23 Sep 2010, at 21:56 , <mv...@comcast.net> <mv...@comcast.net> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Converting a Java app into an OSGi bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Mike,
On 23 Sep 2010, at 21:56 , <mv...@comcast.net> <mv...@comcast.net> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org