Karthik Shiraly wrote:
About making OSGi a JavaSE and JavaEE standard:
So are there any initiatives by OSGi backers to promote OSGi into an "official" Java API, and do you think it's a good idea to do so?
OSGi actually is already standardized at the JCP in the SE and ME spaces (JSRs 291 and 232 respectively). It is a little hard to tell what will happen with the direction of Java past the next releases in SE and EE space. Within OSGi proper there is quite a bit of effort to standardize in the EE space. The Enterprise Expert Group is focused very much on these topics. Eclipse (and in particular the Eclipse Runtime initiative
http://eclipse.org/eclipsert) are moving strongly as well. We host the JPA2 reference implementation (EclipseLink), the OSGi Blueprint Services reference implementation (Virgo, formerly Spring dm Server) and various other standard implementations. Whether or not these make it into JSRs and in the
JEE distro is AFAICT not known or an explicit goal.
Karthik Shiraly wrote:
About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service.
...
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?
Best practice for programming OSGi is to not program OSGi. As Paul says, if you find yourself calling OSGi all the time, you are likely doing something wrong. Dependency injection in various forms is the order of the day. Declarative Services, Blueprint, Guice/Peaberry, ...
Karthik Shiraly wrote:
About OSGi problems in Eclipse:
I use Eclipse Galileo but don't update regularly - only about once in 3 months. When I try to update certain components, I'm informed that the request can't be completed, because one component A requires a certain older/newer version of another component B. Attempts to update component B results in similar errors at another level. Is this indicative of some deployment problem even OSGi cannot solve? What should be done to avoid such problems in my OSGi-aware applications?
Just throwing thousands of components to the wind does not make for a solution. Producers need to coordinate the things they make available to their consumers. If you stick to the Galileo release repo for example then
you should not have any problems updating. When you go broader there is less coordination in the version ranges and dependencies. Conflicts naturally occur. OSGi does not inherently cause or resolve these conflicts. The real value is that it makes them explicit so that a) they are discovered b) they can be processed and c) they can be avoided/fixed. Systems like Yoxos OnDemand (
http://ondemand.yoxos.com/geteclipse/start) manage the vast arrays of bundles in a single repo and provide consumers with "slices" that are internally self-consistent. You are free to consume anything in the slice and be confident that the dependencies will resolve.
Karthik Shiraly wrote:
Why Equinox:
There are many competing OSGi container implementations. Where does Equinox score better? When would you not recommend Equinox? Does your book throw light on these topics?
We don't go into great detail about the various framework implementations. Everyone has different requirements and ways of looking at the framework characteristics. We do tend to see Equinox used in more industrial settings where performance, scalability and robustness are key drivers. WAS, Spring dm, SAP Netweaver, ... are all using Equinox. On the client you really can't beat Equinox and Eclipse RCP for user apps. On the embedded side it depends on how embedded you are talking. Concierge is tiny but also OSGi R3 (old) and not fully compliant. The Prosyst commercial implementations are small and performant in the embedded space. Equinox is larger but still used in significant embedded deployments. You have to weigh in the full spectrum of support, performance, development experience, ...
