Hi
Please see my comments with prefixed with S.B.
>>
>>>
> I'm not sure how CXF keeps track of these providers now, but I assume
>> there's a registry of some kind. Are the providers tied to specific
>> jax-rs
>> resources, or are they "global"? If it's a global registry, it should be
>> trivial to add a service tracker that watches for new services that are
>> registered with the osgi container under the MessageBodyReader,
>> MessageBodyWriter, or ExceptionMapper interfaces. The service tracker
>> would
>> add or remove the providers from the internal CXF provider registry.
>> That's
>> what I did with the resteasy spi, but I am not as familiar with how CXF
>> keeps track of providers.
>>
>
> CXF JAX-RS has a global registry which provides providers supporting
> formats/features as requested by the spec (for ex JAXB support, etc).
> These
> providers are shared. In addition, every endpoint gets the opportunity to
> register per-endpoint unique providers. Some endpoints may or may not
> share
> the same instances but it's up to the app developer. So say the same JAXB
> provider may be configured to suit a particular endpoint's needs
>
> Thus, given that the endpoint or client is created by DOSGI, I was
> thinking
> about the user bundles providing a list of additional providers using a
> service property :
>
> Dictionary props = ...
> props.put("org.apache.cxf.rs.providers", new Object[]{provider1,
> provider2});
>
> and then publish or attempt to bind...
>
> and DOSGI will use them at the point of creating the endpoint/client
>
> I'm wondering, would this approach work for you ?
>
Yes, partially. Since there are multiple scopes, I think there should be
multiple mechanisms for registering providers. A developer should be able
to register a global provider by simply publishing it as an OSGi service,
and should be able to register per-endpoint providers in the manner you
describe above.
<S.B> Yeah, registering a global provider this way sounds like a good idea.
Not sure yet how to handle it
in DOSGi. According to the spec, custom providers should be chosen instead
of any matching default providers, for ex, if one registers a provider
capable of handling WebApplicationExceptions then it should be chosen
instead of the default one. If we add such 'overlapping' providers to the
global registry then it could be tricky to meet the specs requirements.
May be in CXF JAX-RS we need to introduce another ProviderFactory instance
for keeping the shared custom handlers. So first the endpoint-specific
providers will be checked, next shared custom providers will be checked and
finally the default ones will be checked. This new ProviderFactory instance
is kind of redundant in most other cases as without OSGI users can easily
inject the same instance into endpoint-specific factories, but in OSGi it
can be handy.
Perhaps for a start, a ServiceTracker launched in DOSGI can keep this shared
custom providers state locally and provide it to individual JAX-RS config
handlers.
Endpoint specific providers would be much simpler to deal with, they'll just
have to be passed to the endpoint factory code, but a providers property
will likely need to be excluded from the service properties available for
the publication....
</S.B>
If global provider registration is not a priority for others, I'd be happy
to work on a patch. Just let me know when things settle down in this area,
so we don't wind up with a difficult-to-merge patch :)
S.B : Patch would be welcome :-) Give it a try please whenever you get a
chance/some time. We will fix the merge issues if any...Thanks
Thanks,
Josh
--
View this message in context:
http://www.nabble.com/Whiteboard-pattern-for-JAX-RS-services-tp23999480p24207585.html
Sent from the cxf-dev mailing list archive at Nabble.com.
