Hi Josh
I've got some code that allows OSGI bundles to use the whiteboard pattern to
register restful services. When a service is registered with a specific
property, say, "jaxrs.resource=true" the JAX-RS implementation registers
that service as a JAX-RS resource. The same could be done with message body
readers and writers, too. In my implementation, the JAX-RS servlet is
registered under the "/rest/*" URL, and all of the JAX-RS resources fall
below that, so /rest/foo can be provided by one bundle and /rest/bar could
be provided by another.
I'd like to ask your opinion about providing JAXRS providers through this
pattern.
In DOSGi we can now handle the registration of services and expose them as web services using whatever style/frontend is needed
(ws/rs).
As far as JAX-RS providers are concerned, we can only handle at the moment a limited number of them, specifically JAXB/Aegis
MessageBodyReaders/Writers. It would be easy to add shortcuts for other ones, say if a databinding property says 'atom' or
'xmlbeans' then we can figure out what to do.
But in JAX-RS we can also have exception mappers, CXF specific exception mappers which are used to handle exceptions on the client
side, filters, etc, they all can act as providers. Now, one option would be to scan an implementation bundle for provider classes,
those which have @Provider annotation.
This may or may not always work as these providers may actually come from some other bundle, say from some bundle acting as a
providers repository.
So my thinking is that it should possible to supply provider instances during the service registration or lookup from a given
activator, as an array value of some service property. This will make it possible to configure individual provider instances too.
Does it make sense ? Any other ideas ?
cheers, Sergey
