[
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