Hi Robin, Rob- Robin, the problem with expecting the Restlet project to use the OSGi service registry to support their extension architecture deplopyed in a OSGi container is that there's no "halfway" when talking about OSGi services. As you probably know, OSGi really means two things: #1) classloading modularity, #2) dynamic services.
Most of us in OSGi land feel that complying with #1 is reasonable to ask for, since much of it is (or should be) best-practice in java anyhow. #2 is a different beast- the dynamic nature of the service registry really mandates adopting this dynamism throughout software that uses it. In particular, this means doing something reasonable when services go away, The Restlet extension architecture seems to me to primarily serve the purpose of code modularity. Therefore it's _might_ be able to be shoehorned into #1 above. But it's really not designed to deal with extensions coming and going. For instance, when you start up a Restlet Component and Connector, it chooses an implementation Helper from the set of available extensions. If these extension bundles are stopped (or if, as services, they are unregistered), what does that mean for a running server that's using that extension for listening to web requests? Should the Component be restarted? So, my point above is that there's no halfway with services. And besides, not everything fits into the dynamic architecture that the service registry implies. It seems to me that one way to understand the Restlet extension design is simply that of a _configuration_ tool: it seems to function as a way to make reasonable choices for configuring the Component by looking at what's available in the (classloading) environment. In this regard, we might even say that, as written, the Restlet extension design doesn't really even fit well into #1 above, since even #1 involves a level of dynamism that exceeds the requirements of a configuration mechanism mostly concerned with how to start things up. So, all of that is why in my company we use a modified local build of Restlet where we have made the following changes: A) In the main restlet.org module, we modify the MANIFEST.MF file to remove the included Bundle-Activator entry. Tthe Restlet folks put this in as a solution to loading extensions in the OSGi environment, but I found it to be unreliable, and also it creates a bundle start order dependency which isn't really appropriate in OSGi. B) For each restlet extension that we need, we change the MANIFEST.MF file to declare that module to be an OSGi Fragment bundle, by adding the "Fragment-Host: org.restlet" manifest entry. Basically, by making Restlet extensions into bundle Fragments of the core Restlet module, the existing restlet extension mechanism is able to operate as if it's deployed in a tradition monolithic classloader (it uses what is confusingly called the ServiceLoader pattern, which uses classpath-scanning to find extension metadata files. This pattern is the cause of much of the pain for OSGi users because it is essentially incompatible with OSGi, since it makes terrible assumptions about the classloading environment, even for traditional java projects. It's become a commonly used mechanism anyway.) I believe that this fragment strategy is the only real choice when using Restlet in OSGi, since otherwise one ends up with bundles that cause unpredictable behavior when stopped, refreshed, and restarted, plus startup order issues. The other option would be for the Restlet project to adopt a more OSGi-friendly model w.r.t extensions, and stop using the ServiceLoader pattern. But this would probably involve a step backward with respect to the auto-configuration aspect of the extension process- users would likely have to specify, for instance, precisely which http server implementation they want to use. This seems fine to me (I suspect most users know ahead of time whether they want to deploy on jetty, grizzly, simple, etc), but this may be a barrier to adopting a new approach for the Restlet project. So, to sum up: 1) Restlet extensions don't fit the OSGi service registry model at all (they're generally not services, instead they are really libraries), and only partially fit into the bundle lifecycle model as currently used. 2) I prefer, and currently use via a custom build, the bundle _fragment_ approach for restlet extensions. I would, of course, love to see these issues sorted out before Restlet 2.0 is finalized, and I'm willing to help in any way I can... -Dave Fogel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382532
