Hi Jerome- Let me first say that I wasn't trying to criticize the timeliness of your answers (in fact I feel that the Restlet project is one of the better-supported open-source projects out there, because of your (and Theirry) presence on the discussion list, as well as your diligence in keeping the Issues up to date. I was lamenting the small number of users of Restlet who seem to be using it in an OSGi environment. I hope we can all change that! With respect to commercial support, well, I promise to purchase support if our current project using Restlet ends up generating any significant income for us :-)
To continue the discussion (and thanks again for taking a look at these things): Regarding the Restlet bundle manifest: Thanks for the fix. I think you're still missing javax.xml.xpath, which you import in the file DomRepresentation.java. In general, I'd suggest that you test OSGi-related features of Restlet outside the eclipse environment. When you launch an OSGi target inside eclipse, there are differences with what classes are available by default from an independent OSGi launch- I'm not sure why. Additionally, there are differences in which packages can be expected to be auto-exported from the framework bundle between JDK 1.5 and JDK 1.6. Testing outside of eclipse doesn't mean not using equinox, it just means that you have to start equinox from outside of eclipse. Despite their stated goals, Eclipse's PDE environment is clearly more tuned towards developing Eclipse plugins, and sometimes that bias causes problems. Regarding connectors and the missing bundle Activator: Over the weekend I finally discovered the missing Activator, and I was able to get the Jetty and Simple connectors working in my OSGi environment. What was particularly confusing was that the result of the way this activator works means that there is now a bundle load-order dependency issue for Restlet. Depending on whether the ext bundle is resolved at the time that your application instantiates a Component or Server, your application will get either the internal connector or the ext connector. I discovered that restarting my application bundle would result in getting the desired ext connector. In your new OSGi Deployment page, you suggest setting the startlevel of the restlet bundle to be lower (earlier) than other bundles. This will work (although there are still scenarios where it won't work due to the allowed dynamism of OSGi- I could install and start the restlet bundle and my bundle, and then after I could install the extension, and it would be too late) but it is against OSGi best-practices to rely on bundle start order in this manner. see, e.g., this blog post: http://www.osgi.org/blog/2009/02/ordering-get-over-it.html I think that while dynamic extension discovery may be appropriate (or at least convenient) for non-osgi environments, that in OSGi containers it would be better to make the dependency more explicit. It might be better to have, at Component creation time, a mechanism to specify the extension Helper class. If this was a parameter that actually took a Class instance, instead of a class name, this would be good because it would force the user to explicitly include a Import-Package line on their bundle specifying the ext bundle. Then there wouldn't be any issues about having _more than one_ restlet connector extension active in the OSGi container- they would all be hooked up be explicit bundle dependency management. Thanks again, -Dave Fogel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1298972
