On Fri, Jul 17, 2009 at 3:59 AM, Gregg Wonderly<[email protected]> wrote:
> I'm trying to get first hand reports and > recommendations on what is valuable to those who have used it and deployed > things using it. Here is my take; When I put Jini (1.x) to work in a commercial application back in 2000/2001, I had quite a lot of problems related to classloading. And just as Jini is built on a solid foundation of Network Understanding (8 fall... and so on), OSGi has tackled (in Release 4) the classloading problem straight on. A R4 container will build class spaces, where compatible versions of classes are clustered together, and where multiple versions are allowed to co-exist. It also provides well-defined lifecycle for classloading, for instance; If a bundle is unloaded, the classes will remain in memory until a "refresh" is made, when the container will drop the class space affected and rebuild it, and meanwhile stopping the bundles affected. Compare that to the RMI/Jini classloader model where "I have no clue what is going on, and when it goes wrong..." state of mind is the norm rather than the exception. Hierarchical classloader are primitive at best, and the JDK implementation is "naive". Or in other words, I think OSGi is to classloading what Jini is to networking --> The better solution. OSGi *also* defines a Service mechanism as well as a bunch of standard services. Until the current D-OSGi spec (soon out in OSGi Release 4.2 spec), all the service stuff was in-JVM only, *although* in OSGi Release 3, there was a specification for Jini integration, but lack of Jini expertise in OSGi combined with 'not easily resolvable issues' (i.e. spec might not have been properly implementable) led to it being dropped from Release 4.0 (which ironically contained the advanced classloading mechanisms that Jini could benefit from). D-OSGi is a specification of *how* to hook in a resolution mechanism for remote access, either in-coming or out-going. From an OSGi PoV it is fairly simple stuff. Basically, you can register resolvers in the Service Registry, that are involved in the "register service" and "lookup service" method calls. Making a Jini implementation is probably easier than some of the other that are being attempted. OSGi zealots don't like Jini for many reasons, probably in reality driven by politics more than technology. One key technology that has repeatedly been mentioned to me as a show-stopper for even considering Jini in a more central role, is the differences in "service attributes/properties". Jini's 'exact-match' Entry matching is considered inferior of the LDAP expressions of OSGi. Somehow it feels like a weak argument, and I think River today would consider convergence on this point. Personally, I don't think there is any point trying to convince the River community that they should bet on OSGi. The interests here are too diverse for reaching consensus and would probably lead to another round of 'paralysis'. Instead, I would encourage a subproject in River that makes an OSGi RFC-119 implementation with the knowledge and source code available here (if only I had more time/money). If the work is well done, it becomes plug-n-play for OSGi developers and possibly quick fresh breath of air in River. I would also recommend that such effort is not stopping the people who want to push River forward. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
