'. '

Talk:OSGi

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Comment provided by Reinold - via ArticleComments extension)
(Comment provided by Allie - via ArticleComments extension)
Line 83: Line 83:
--Reinold 08:12, 26 June 2013 (CEST)
--Reinold 08:12, 26 June 2013 (CEST)
 +
</div>
 +
== Allie said ... ==
 +
 +
<div class='commentBlock'>
 +
Of course, that's an itenrtsnieg point, which makes this exchange of interpretations rewarding.(On the side: From a deployment perspective, everything is a bundle. Because the plugins' folder has a history tied to the original Eclipse modularity system, the name of that folder is confusing. And perhaps a candidate for a change request.Historically, the adoption of OSGi has introduced a level of blurring which makes this discussion fairly complicated. The adoption introduced an overlap in functionality, as there are now different programming patterns available to contribute' or to extend'. As it stands today, the framework taps into those different layers at the same time, creating a mix which lies at the heart of this discussion, I think.Categorizing bundles, for example as a higher-level type such as a plug-in', has become debatable because a bundle can contain a mix of fingerprint meta-data: OSGi declarative services, plugin.xml Eclipse extensions, .Still, I find that sentences like mixing bundles and plug-ins' are still valid given the specific nature of the layers in the framework. Apart from meta-data content in the bundle, there are also life-cycle aspects to consider. I do consider the framework to have become a mix of both: bundles en plug-ins.There is enough to distinguish, enough to warrant that both names remain in existence. Unfortunately, as they are related', making the distinction in some cases is like separating Siamese twins, in which case only some convention helps to make the call. But because sometimes the distinction is clear-cut, I can't help feeling that we will never be able to use a single blanket term.
 +
 +
--Allie 19:44, 26 June 2013 (CEST)
</div>
</div>

Revision as of 17:44, 26 June 2013

Comments on OSGi <comments />


Contents

Neil Bartlett said ...

In the introduction you appear to be asking to be enlightened about OSGi, but then you go on to attack it from a position of ignorance and with heaps of bad attitude. Sorry but this is not the way to engage with people when you're asking for help.

If you have some specific questions about how or why OSGi works the way it does, then I and many others will be delighted to help you on the osgi-dev mailing list. Unfortunately this particular page is little more than a rant and can't be the basis for useful discourse.

--Neil Bartlett 00:07, 20 November 2011 (CET)

Hello Neil, thanks for your comment. Yes, you are right, the page is unlikely good start for a useful discourse. On the other hand, it nicely illustrates my frustration with OSGi. Still, I'd be glad to be enlighten about the design misconceptions.

--JaroslavTulach 10:02, 21 November 2011 (UTC)

Mirko Jahn said ...

First of all, I agree that OSGi is not perfect. In fact I do not know any technology that reached some sort of complexity that doesn't have its flaws. I guess that's nature. However, I think you're missing some background/ experience in the underlying concepts and frameworks you're referring too.

First of all, start/stop of a bundle. Here it is important to distinguish between a mere library and a state aware module. For libraries it is perfectly fine to not have an initialization (static initialization is fine here as well, but no "object" related one). In the OSGi world you then do not need to create an Activator. For all modules that are in fact state aware or need some sort of initialization (like Service dependencies), you could create you Activator (or use a declarative way of expressing that). In case a module does not comply with this contract this is a bug in the bundle code. As a general rule, you only expose API's and provide the instances as services, as long as the bundle is not started, no services will be available and no harm is done. Of course there is the "ugly" overhead of needing to know what bundles need to be started and which don't (you could also start all of them - no overhead in case of library bundles, because they won't execute any code). This seems not entirely clean as an approach, but it is powerful. Just imagine you have one bundle providing the API and a simple default service with the implementation. Once you realized the implementation is not good enough, you could just go ahead, reuse the API and not the exposed service (simply do not start the bundle) and provide your own bundle implementing the service in a way you require it.

Second, stopping order. There is an order in which bundles are stopped and they are stopped in the reverse order they were actually started, so what you saw might be a timing issue or an error in the implementation. Also Eclipse is not a perfect OSGi citizen. They did a lot to improve that but they are still not there. For instance many bundles still do not use the service registry, but a more static eclipse specific construct that has flaws with the dynamism of OSGi. I guess this might explain the problem you were experiencing. Also when done correctly (with services), a stopped bundle would not expose the service any longer and the bundle consuming such service would be able to call such bean (because it wouldn't find it) - no harm could be done here. Unfortunately the developer has to account for that or us a framework that does it for him like BluePrint for instance.

Range dependencies are tricky, I agree. Also the approach on handling the correct version, updating handles in the container, refreshing the wiring between bundles. All that is not trivial and error prone. However, I haven't seen anything even close to what is possible with OSGi. You could by designing the exposed and consumed packages correctly, a powerful and future prove API. Implementers know base on version changes when they have to take a closer look (minor version change) and simple service consumers can rely on the major version as an indicator that something might have changed that they should be aware of. Especially with many modules, keeping track of changes is hell. With such ranges, it at least gives you a way to better track where to look and what to adapt in case something happens. This is still not perfect and I am not sure there is a silver bullet at all, but it's the best thing I've seen so far.

To summarize what I am trying to say. OSGi, like many other specs, is not perfect and there might be a better one in the future, but for the time being, it is pretty good and well thought through. Unfortunately the concepts are not simple and certainly not easy to adhere. Especially with the latest version 4.3, many improvements have been done to make it easier and remove potential for errors, but like every complex system, one first has to know it to fully appreciate it. ;-)

--Mirko Jahn 19:59, 23 November 2011 (CET)

A comment by Jesse Glick left at bug 205019

I think this is a bit off the mark. Seems like Eclipse is not really using OSGi as designed. Proper OSGi bundles are (acc. to spec) supposed to work regardless of what other bundles have or have not been started; that is why dynamic services exist, and why bundles are not started in topological order. In other words, we are working around misdesign in Eclipse, not OSGi per se. The problem presumably does not affect Eclipse and its RCP apps because they are not attempting to load code from an arbitrary compliant OSGi container, and so can make assumptions about runtime behavior not guaranteed by the spec.

--Jesse Glick 14:00, 23 November 2011 (CET)

Reply to Mirko's Post

Hello Mirko, first of all - thank you for your time to write down such a long post here. I value your effort.

"I agree that OSGi is not perfect" - sure, I know that NetBeans Runtime Container is not perfect either. Over years in production you just have to come up with a lot of compromises which, when looking backward, may not seem perfect.

"distinguish between a mere library and a state aware module" - yes, I am aware that nobody needs to use Activator - however that is not the problem. I am puzzled by OSGi allowing to load classes from modules with Activator which has not been called! What kind of strange idea is that? In my opinion the fact that I provide an Activator should mean that whenever somebody wants to use me (e.g. activate me), I want that Activator to be called. Why this is not true in OSGi?

"ugly overhead of needing to know what bundles need to be started" - actually this may be the problem. NetBeans is worshiping so called Injectable Singletons. In this use-case, what ever API you link against means that the API is ready to work and is fully configured. The way Eclipse is using Activators violates this (which may be Eclipse fault as Mirko and Jesse indicate). You say "simply do not start the bundle" - sure, this is what works in NetBeans as well if you don't need a module with implementation of an API, just don't enable it. But still, I don't understand why there is the dichotomy between using and starting a bundle. To allow an API to be bundled with its implementation that is registered in Activator (so others can use the API without the implementation)? That sounds weird!

"reverse order they were actually started" - see, I did not know this. But then the problem is the start order. Obviously, those bundles with as less dependencies as possible, should be started first. However I understand the OSGi may have problem - there does not seem to be a bulk start operation. One can start just a single bundle, not a set of bundles. In NetBeans Runtime Container one just asks to enable a set of bundles and the system starts them in the correct order. The system always guarantee Activators are called on modules needed by somebody. Sounds like a deficiency in OSGi where determining the start order is fully left in hands of poor users of the OSGi API.

"Range dependencies are tricky" - RangeDependencies don't really belong into my most recent rant, but there are issues associated with them - althrough they may be mitigated to avoid NP-Complete problems.

"certainly not easy to adhere" - if a concept is not easy to adhere, then the system is not designed for clueless use. And that is a problem as most of us are completely clueless when using others APIs. Should we threat OSGi as an assembly language for modularity hoping somebody will wrap it with higher level concepts? That would support my conclusions - OSGi helped us see the value of modularity, but proper, widely used modularity should rather not expose OSGi at all.

--JaroslavTulach 18:23, 24 November 2011 (UTC)

Tristen said ...

why can't you make all 3 choices at once:-Save Page as MHTML-save html-save whole paghwey ony MHTML or only 2 last variants?

--Tristen 20:53, 25 June 2013 (CEST)

Meganedos said ...

Very nice article. I just sblutmed upon your blog and wished to say that I've truly enjoyed browsing your blog articles. After all I will be subscribing to your feed and I hope you write again soon! P.S.> Here's the solution to your quest for higher profits using easy and quick content. You can instantly download hundreds of thousands of excellent articles on over 3000+ niche topics that you might edit and use as you wish. More quality content means more search results traffic and more profit. PLR Articles Marketing is really a relatively new twist on content building and effective traffic generating. Therfore get your pack now! Versie Modrak

--Meganedos 01:46, 26 June 2013 (CEST)

Reinold said ...

Thanks, yeah, that was pretty much my point. I don't see how a new color being avalaible would spur buyer's remorse. If you hated the colors avalaible you wouldn't have bought the thing, I'm assuming. After that, what's the big deal?As far as a price drop, I was playing a bit of Michael Pachter there. There's higher potential for a price drop sooner than later because of the PSV, due to lukewarm 3DS sales and the unexpected competitive pricing of the Sony product spurring the sudden announcement of a new color pushing up the timetables. I find it hard to believe they'd announce a new color this quickly of their own volition. That's what they do, right? That's why the Wii and DS Lite were only avalaible in white for like the first 2 years or however long it took (seemed like forever), because they were selling gangbusters and there wasn't a need to kickstart sales yet with a new edition.No attempt at flamebait, and I do have a smartphone, which is why I don't have a pony in this race. I'm speaking strictly as an observer. :) If you're happy with your handheld that's all that shouldn't matter, and it shouldn't bother you that I don't care one way or the other.

--Reinold 08:12, 26 June 2013 (CEST)

Allie said ...

Of course, that's an itenrtsnieg point, which makes this exchange of interpretations rewarding.(On the side: From a deployment perspective, everything is a bundle. Because the plugins' folder has a history tied to the original Eclipse modularity system, the name of that folder is confusing. And perhaps a candidate for a change request.Historically, the adoption of OSGi has introduced a level of blurring which makes this discussion fairly complicated. The adoption introduced an overlap in functionality, as there are now different programming patterns available to contribute' or to extend'. As it stands today, the framework taps into those different layers at the same time, creating a mix which lies at the heart of this discussion, I think.Categorizing bundles, for example as a higher-level type such as a plug-in', has become debatable because a bundle can contain a mix of fingerprint meta-data: OSGi declarative services, plugin.xml Eclipse extensions, .Still, I find that sentences like mixing bundles and plug-ins' are still valid given the specific nature of the layers in the framework. Apart from meta-data content in the bundle, there are also life-cycle aspects to consider. I do consider the framework to have become a mix of both: bundles en plug-ins.There is enough to distinguish, enough to warrant that both names remain in existence. Unfortunately, as they are related', making the distinction in some cases is like separating Siamese twins, in which case only some convention helps to make the call. But because sometimes the distinction is clear-cut, I can't help feeling that we will never be able to use a single blanket term.

--Allie 19:44, 26 June 2013 (CEST)

Personal tools
buy