I'm using declarative services to register my endpoints, so it would be
useful for me to specify the provider property using class names rather than
instances in the service properties. Perhaps something like this?
<property name="org.apache.cxf.rs.provider">
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
</property>
Or is there some way to reference an object instance in DS that I'm unaware
of?
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin <sbery...@progress.com>wrote:
> Oh, this is exactly the sort of message I was in need for in the end of the
> long and difficult day :-)
> Cool. If you could verify (later on today or next week when you're back)
> that you could do
>
> Dictionary props = new Hashtable();
> props.put("org.apache.cxf.rs.provider", new Object[]{new
> FooReaderWriter()});
> bundleContext.registerService(YourApplicationService.class.getName, new
> YourApplicationServiceImpl(), properties);
>
> This option will allow users to register per-service tuned
> FooReaderWriters, something one can do today with registering different
> FooReaderWriter instances on a per-endpoint basis with jaxrs:endpoints
>
> then it would be of help.
>
> thanks for your help
>
> Sergey
>
> ----- Original Message ----- From: "Josh Holtzman" <jholtz...@berkeley.edu
> >
> To: <dev@cxf.apache.org>
> Sent: Wednesday, August 26, 2009 5:37 PM
>
> Subject: Re: Integrating JAX-RS runtime into DOSGi
>
>
> Bah, my isReadable and isWriteable were wrong. Sorry, false alarm. This
>> works like a charm!
>>
>> Thanks,
>> Josh
>>
>> On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin <sbery...@progress.com
>> >wrote:
>>
>> Hi Josh
>>>
>>> Thanks, this is exactly how providers are expected to be registered.
>>> http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
>>>
>>> shows my changes have been picked up so it's a bug then. Have you tries
>>> the
>>> lastest build from snapshots or built the trunk yourself, including a
>>> trunk/distributuon ?
>>>
>>> I'll look into it...
>>>
>>> cheers, Sergey
>>>
>>> P.S. was about to ping you on #cxf but somehow I lost the connection
>>> ----- Original Message ----- From: "Josh Holtzman" <
>>> jholtz...@berkeley.edu
>>> >
>>> To: <dev@cxf.apache.org>
>>> Sent: Wednesday, August 26, 2009 5:02 PM
>>> Subject: Re: Integrating JAX-RS runtime into DOSGi
>>>
>>>
>>>
>>> Great, thanks Sergey. I just tried this, and wasn't able to read/write
>>> an
>>>
>>>> arbitrary object.
>>>>
>>>> I've registered a MessageBodyReader and a MessageBodyWriter (actually,
>>>> the
>>>> same object) like so:
>>>>
>>>> FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
>>>> context.registerService(MessageBodyReader.class.getName(),
>>>> fooReaderWriter, null);
>>>> context.registerService(MessageBodyWriter.class.getName(),
>>>> fooReaderWriter, null);
>>>>
>>>> I see that these services are in fact registered:
>>>>
>>>> -----------------------------------------------
>>>> objectClass = javax.ws.rs.ext.MessageBodyReader
>>>> service.id = 41
>>>> ----
>>>> objectClass = javax.ws.rs.ext.MessageBodyWriter
>>>> service.id = 42
>>>> ----
>>>>
>>>> But when I try to access a Foo via JAX-RS, I get this:
>>>>
>>>> [9853...@qtp-998044-0 - /inspection/rest/foo] WARN
>>>> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
>>>> writer found for response class : Foo.
>>>>
>>>> Please let me know if I misunderstood the recipe for registering JAX-RS
>>>> providers. I'll be out of the office until Monday, and will start
>>>> digging
>>>> into the CXF code to see what's going on when I return.
>>>>
>>>> Many thanks,
>>>> Josh
>>>>
>>>>
>>>> On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin <
>>>> sergey.beryoz...@iona.com
>>>>
>>>> wrote:
>>>>>
>>>>>
>>>>
>>>> Hi Josh
>>>>>
>>>>> I've updated the JAX-RS layer in DOSGi such that it will now discover
>>>>> JAXRS
>>>>> (and CXF specific providers) which have been registered as (global)
>>>>> OSGI
>>>>> services. At the moment I've decided not to use a ServiceTracker and
>>>>> instead
>>>>> a calling BundleContext is asked to exercise a filter expression which
>>>>> should catch JAXRS MessageBodyReader, MessageBodyWriter,
>>>>> ExceptionMapper,
>>>>> as
>>>>> well as CXF RequestHandler, ResponseHandler & ParameterHandler. I'll
>>>>> attempt
>>>>> to optimize it later on....
>>>>>
>>>>> One can disable such queries for such providers and also insist that
>>>>> only
>>>>> those global providers which have identified themselves (through a
>>>>> specific
>>>>> property) that they will work reliably with CXF can be used.
>>>>>
>>>>> Alternatively, one can register an array of service/endpoint -specific
>>>>> providers by using "org.apache.cxf.rs.provider" property, when
>>>>> registering
>>>>> an application service.
>>>>> Will document it tomorrow
>>>>>
>>>>> Give it a try please whenever you get a chance and let me know if it
>>>>> works
>>>>> for you
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>>
>>>>> Josh Holtzman wrote:
>>>>> >
>>>>> > Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS
>>>>> endpoints.
>>>>> >
>>>>> > Josh
>>>>> >
>>>>> > On Aug 21, 2009 6:28 PM, "Sergey Beryozkin" <sbery...@progress.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi Josh
>>>>> >
>>>>> > Can you please let me know if JAXB is being used for your JAX-RS
>>>>> endpoints
>>>>> > ?
>>>>> > I've spotted that for HTTP Service based JAX-RS endpoints no
>>>>> AegisProvider
>>>>> > is being set - I'would actually like JAXB being used by default for
>>>>> JAXRS
>>>>> > endpoints which will be consistent with the expectations of JAX-RS
>>>>> users
>>>>> > in
>>>>> > general - but I'd like to confirm first that JAXB is working ok in
>>>>> your
>>>>> > case...
>>>>> >
>>>>> > thanks, Sergey
>>>>> >
>>>>> >> Sergey, > Thanks again for the detailed documentation you've
>>>>> provided
>>>>> in
>>>>> > this thread. > I was ab...
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>> http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
>>>>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
