Hi guys, Ok, I've read all this thread from the start... and much more actually :). Really enlightening!
#1: In order to disable the default discovery mechanism, you need to call this static method before using any Restlet API class: org.restlet.engine.Engine.register(false); #2: Regarding the bundle fragment approach, my last post in the developers list was quite supportive of it [1]. Dave, if you can provide us a patch for the various manifests, I'd be happy to drop our current mechanism altogether. #3: Regarding the OSGi services, I'm also very excited about their potential. I think they would bring most of their value for Restlet user applications. One should be able to dynamically deploy and undeploy applications, attaching them to specific virtual hosts with a given URI path. Also, while using different HTTP servers at the same time might not be a common need, it would be very useful to be able to dynamically add/remove new types of connectors. Like a SMTP client that a newly deployed application would need. Same thing for converters: you might want to dynamically add them to let the ConverterService convert new classes/representations dynamically. Currently, some of this is possible by manually configuring the engine helper lists but it isn't very dynamic. It should also be possible to register new extensions as bundle fragments and refresh the engine helper lists using the current "META-INF/services" pattern. #4: I've updated the specification page in the wiki with references to all OSGi discussion we had so far in the Restlet lists and much more, see [2]. #5: Regarding a new Restlet edition for OSGi, I'm also tempted because it would let us fully embrace OSGi. The issue I see is that OSGi is somewhat orthogonal to our current editions. It is usable with JSE, JEE of course, and some versions are available for Android [3]. Even if OSGi doesn't work yet with GWT and or GAE (see [4] and [5]), it might be supported in the future. After closer analysis, it seems that OSGi is not playing at the platform (or "execution environment") level, but just above. The action plan I propose is: 1) Leverage Dave's bundle fragment approach 2) Provide a way to refresh the helper lists via "META-INF/services" inspection 3) Add an OSGi extension to expose Restlet applications as OSGi services. What do you think? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com [1] http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=15756 44 [2] http://wiki.restlet.org/developers/172-restlet/124-restlet.html [3] http://mobileosgi.blogspot.com/2009/06/update-on-osgi-for-android.html [4] http://eclipsesource.com/blogs/2009/04/10/osgi-on-appengine/ [5] http://jmj-eclipse.blogspot.com/2009/08/osgi-r3-implementation-running-on.ht ml -----Message d'origine----- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : mercredi 12 août 2009 17:06 À : discuss@restlet.tigris.org Objet : RE: Re: OSGi vs. Service Provider patterns Felix' support for fragments should be good in 1.8.x and is actually passing the TCK in the trunk build...I won't claim it is without bugs, though. :-) I am not convinced the fragments are the best way to do this, but I agree that it is a workable approach. Using META-INF/services is not great in OSGi, largely due to its design. The most common approach, as mentioned, is to use the extender pattern where you probe bundles for META-INF/services and then inject them were appropriate. However, as pointed out, this can be problematic if the code getting injected doesn't ever expect those to go away, which can happen with a bundle. To follow a more OSGi-like approach you can have the extender just register services for each META-INF/services object (or directly create wrapper bundles for each that does this). Then you could have a wrapper bundle for the core that listens for the appropriate services in the OSGi registry and injects them appropriately. This way, you only need to have OSGi API in the wrappers/extender, not in the core or the extensions. Of course, dynamism is still an issue here. Not sure if such an approach is possible here, but some thoughts... -> richard (Apache Felix) ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23829 17 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2386301
