Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox

Hi Rob,

Thanks for the comments.  A couple of reactions inline below:

Rob Heittman wrote:
Restlet is already fairly far down the road of "bundleization" (sounds German). The project delivers many bundles which provide different extension capabilities and compatibilities, and at least at the fundamental level, these all behave just fine in OSGi.

However, the bundles require some additional work to really talk, as by default they rely on Java service discovery (anti) patterns to discover, select, and use the present extensions. There is still some contention between different approaches for doing this in OSGi (see this long -- and aging -- thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1322152 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1322152>) but there are really two sane paths:

- Repackage some Restlet bundles as fragments (David Fogel likes/uses this approach) - Override the service discovery stuff programmatically (My company likes/uses this approach)

There is an option 3, involving hacking META-INF/services in each bundle to rig the discovery the way you want it, and yes I have a few places where I still have to do that, but it doesn't really dignify further discussion :-)

My only comment about discovery is that ECF also has a discovery API (org.eclipse.ecf.discovery), and that discovery API is also implemented by multiple providers...like zeroconf/bonjour, slp, apache zookeeper, and others (I believe that Bryan Hunt has done a discovery provider also, but am not certain of that). Like the remote services stuff I described before, the ECF OSGI remote services implementation only uses the abstract discovery API...meaning that any providers (no matter what protocol they use) will automatically be spec compliant.


So this is one area of further study and action: how, canonically speaking, should one compose a set of Restlet extensions in an OSGi container and indicate which combination should be used for a particular application? If I am using Restlet as my OSGi HttpService -- or via any other OSGi service interface -- what is the canonical path to indicate that I want it to use Jackson for JSON-based representations and run over the Jetty connector?

The OSGi remote services spec defines a thing called a 'config type'...which is just a String that uniquely identifies a type of remote service provider. ECF maps this 'config type' to identify an ECF IContainer type/factory...and this string identified the provider used underneath (e.g. ecf.r-osgi.peer, ecf.generic.client, ecf.xmpp.client, etc)...so to use a particular provider/protocol to register/publish a remote service all one has to do is create a provider with new name, specify it as the config type to use when registering a remote service, and that provider will be used. Some providers would use Jackson, or json.org json parsing (which we already have as a bundle in ECF SDK), and use the Jetty http service.

Does this answer your question?


Next ...

The routing-level plumbing of Restlet 2.x involves concrete classes which are wired together in a fairly static way. (I am thinking here of Restlet and its subclasses: especially, VirtualHost, Component, Filter, Guard, Router, Route). There is an inchoate desire to make this more dynamic and to leverage interfaces in a future Restlet release; interfaces here make me think naturally of OSGi services. For example, we have a number of different Guards which do authentication against different types of authorities. At present, these have to concretely extend the Guard class and I must define my own interfaces around them, then extra code to discover them and plug them into the application at the appropriate place. It would be nice if all this was more OSGi-native. Again -- nothing here is really at the fully formed specification level, just a hint at an area where valuable work could be done.

I see. I agree that the use of OSGi services for dynamicity is a very useful thing...and another thing that would make sense to do within Restlet...assuming OSGi runtime environment.

Scott




Back to the top