Talk:OSGi

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)

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)

/ If I do anything in Linux for pmnigomrrag, I use Eclipse if I need an IDE. I also like doing as much as I can in terminal or even a note pad-like program. On Windows (for school), I really like using Notepad++, so the best alternative in Linux for NP++ that I've found is Geany.

--Sergey 14:15, 23 October 2013 (CEST)

"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?"

In OSGi, a bundle which has not been started can provide packages (classes), but not services (objects). To me at least, this makes intuitive sense; classes don't need to be initialized*, but objects do.

You may object that a class might, e.g., make use of a singleton which does need initialization. This would be one reason that an OSGi best practice is to only expose an API (i.e., interfaces, exceptions, maybe some simple beans) through your exported packages, and to leave the implementation to service objects defined by private classes. This way, your exported packages remain initialization-free, and references may be made to them without worry regardless of the state of the system.

You may then ask what the point is in allowing an API to be used when the implementation is not available. Even if the API does not, in itself, require initialization, it doesn't necessarily seem useful to have access to it when no implementation is available. In many systems, there's no point at all, and you'd be entirely right to note this as a shortcoming!

But other systems take advantage of OSGi's dynamic nature by doing things like watching for services that implement the API. In the whiteboard pattern (an OSGi-specific variant of the observer pattern) an "observable" object registers no services, instead listening for observers to register services that act as callbacks. When it boots up, the observable code is probably not yet aware of any concrete implementations of the callback interface. Nevertheless, it needs to know about the interface so that it can listen for new implementations that later become available. It is therefore necessary that the API be available even when implementors are not.

* This isn't always true, but if a class does need to be initialized, it can usually just be a singleton object instead, which is what OSGi would recommend.

"However I understand the OSGi may have problem - there does not seem to be a bulk start operation."

This is indeed a problem. Launching OSGi applications is tedious. Various abstractions, like Karaf's "features" and (I think) WebSphere Application Server's "Enterprise Bundle Archives", have been layered on top of OSGi to express structures composed of multiple bundles which may be started and stopped together. There is no standard, though, and I can't vouch for how well any of them actually accomplish the goal of simplifying OSGi deployment.

"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."

I, for one, agree. OSGi is too complex to ask every application developer to fully understand it. The assembly language analogy is spot on – OSGi is largely a good thing, but it's in desperate need of higher-level abstractions. Until we have those, we should regard it as a useful way to solve specific problems, but only to be used when actually necessary.

--Malnormalulo 16:39, 15 March 2017 (CET)