Comments on: The Rise of OSGi http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/ A man needs a little madness, or else he never dares cut the rope and be free. -Nikos Kazantzakis Wed, 07 Jan 2009 01:08:04 +0000 http://wordpress.org/?v=2.2.1 By: blog.organicelement.com http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-14128 blog.organicelement.com Tue, 06 Feb 2007 17:19:07 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-14128 <strong>OSGi Sighting - Zutubi...</strong> ... OSGi Sighting - Zutubi…

…

]]> By: a little madness » EclipseCon 2007 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-13356 a little madness » EclipseCon 2007 Thu, 01 Feb 2007 03:00:33 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-13356 [...] As Jason mentioned previously, we are in the process of introducing OSGi into the core of Pulse to handle our plugin support. Since OSGi is also the core of Eclipse, we decided to that a trip to EclipseCon 2007 would be a great way to introduce ourselves into the community and see how people are using OSGi. [...] […] As Jason mentioned previously, we are in the process of introducing OSGi into the core of Pulse to handle our plugin support. Since OSGi is also the core of Eclipse, we decided to that a trip to EclipseCon 2007 would be a great way to introduce ourselves into the community and see how people are using OSGi. […]

]]> By: Jason http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12478 Jason Tue, 23 Jan 2007 13:37:54 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12478 Hi Matt, Thanks for stopping by. Hopefully I will find the time to follow up with the details :). Hi Matt,

Thanks for stopping by. Hopefully I will find the time to follow up with the details :).

]]> By: Jason http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12477 Jason Tue, 23 Jan 2007 13:37:18 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12477 Alex, Thanks for the tip. I had discovered START_TRANSIENT in Equinox 3.3M4, and have been using it. I am still starting clean though, until I figure out if there is any other information being persisted that is not desirable. Alex,

Thanks for the tip. I had discovered START_TRANSIENT in Equinox 3.3M4, and have been using it. I am still starting clean though, until I figure out if there is any other information being persisted that is not desirable.

]]> By: Matt Ryall http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12357 Matt Ryall Mon, 22 Jan 2007 12:23:53 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12357 Thanks for the update, Jason. I'm interested to hear how you get on with including OSGi in your application. Dynamically loading and unloading plugins is one of the more interesting areas of Java development at the moment. I suspect we'll be seeing applications getting a lot more dynamic in the next couple of years. Thanks for the update, Jason. I’m interested to hear how you get on with including OSGi in your application.

Dynamically loading and unloading plugins is one of the more interesting areas of Java development at the moment. I suspect we’ll be seeing applications getting a lot more dynamic in the next couple of years.

]]> By: Alex Blewitt http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12091 Alex Blewitt Fri, 19 Jan 2007 15:22:18 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12091 OGSi 4.1 provides methods 'start(int)' and 'stop(int)' that allow you to specify flags, which includes 'start(TRANSIENT)' and 'stop(TRANSIENT)'. These have the effect of stopping the bundle (or starting it) in a non-persistent fashion, such that if a bundle was previously start()ed, then it would stop until the framework restarted; and if that a bundle wasn't automatically started that start() would bring it up, but only for the lifetime of that instance. It sounds like that may help you. Alex. OGSi 4.1 provides methods ’start(int)’ and ’stop(int)’ that allow you to specify flags, which includes ’start(TRANSIENT)’ and ’stop(TRANSIENT)’. These have the effect of stopping the bundle (or starting it) in a non-persistent fashion, such that if a bundle was previously start()ed, then it would stop until the framework restarted; and if that a bundle wasn’t automatically started that start() would bring it up, but only for the lifetime of that instance. It sounds like that may help you.

Alex.

]]> By: Jason http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12074 Jason Fri, 19 Jan 2007 11:00:16 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12074 Hi Peter, I have seen start levels, but they do not really address what I need to do. We want Pulse to have more control over plugins being enabled, disabled, installed and uninstalled. For example, we want the user to be able just to remove a jar file and have the plugin uninstalled. In a way, what we are doing is similar to the Eclipse update configurator. In both cases, the persistent state maintained by the framework is undesired. In our case, we start clean and use transient starting (we are using an Equinox 3.3 milestone). In the configurator case, they have to query the framework and redjust all the states to what they actually want. It seems a shame that the framework goes to all the effort of maintaining the state in for such cases, when it actually harms more than helps. I have to say it also surprised me at first: I didn't expect the framework to do this sort of stuff under the covers. Adding the option of transient starting is a step in the right direction: that way people can choose whether persistent state makes sense for their application. Hi Peter,

I have seen start levels, but they do not really address what I need to do. We want Pulse to have more control over plugins being enabled, disabled, installed and uninstalled. For example, we want the user to be able just to remove a jar file and have the plugin uninstalled. In a way, what we are doing is similar to the Eclipse update configurator. In both cases, the persistent state maintained by the framework is undesired. In our case, we start clean and use transient starting (we are using an Equinox 3.3 milestone). In the configurator case, they have to query the framework and redjust all the states to what they actually want.

It seems a shame that the framework goes to all the effort of maintaining the state in for such cases, when it actually harms more than helps. I have to say it also surprised me at first: I didn’t expect the framework to do this sort of stuff under the covers. Adding the option of transient starting is a step in the right direction: that way people can choose whether persistent state makes sense for their application.

]]> By: Peter Kriens http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12069 Peter Kriens Fri, 19 Jan 2007 07:12:20 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12069 Could you elaborate about the persistent state? Did you look at start levels? You can easily manage the starting of bundles through start levels. In 4.1 we also added a transient start method that is not persisted. Kind regards, Peter Kriens Could you elaborate about the persistent state? Did you look at start levels? You can easily manage the starting of bundles through start levels.

In 4.1 we also added a transient start method that is not persisted.

Kind regards,

Peter Kriens

]]> By: Jason http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12052 Jason Fri, 19 Jan 2007 00:00:53 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12052 Hi Ganeshji, Thanks! Pulse does use Spring, but at present we are not using Spring-OSGi. However, we are keeping an eye on Spring-OSGi progress, with the plan of using it in the future. Hi Ganeshji,

Thanks! Pulse does use Spring, but at present we are not using Spring-OSGi. However, we are keeping an eye on Spring-OSGi progress, with the plan of using it in the future.

]]> By: Ganeshji Marwaha http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12046 Ganeshji Marwaha Thu, 18 Jan 2007 23:32:49 +0000 http://www.alittlemadness.com/2007/01/19/the-rise-of-osgi/#comment-12046 Neat information. I have been hearing about OSGi for sometime in the context of integration with spring. Are you using its spring integration as well? Neat information. I have been hearing about OSGi for sometime in the context of integration with spring. Are you using its spring integration as well?

]]>