cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Holtzman <jholtz...@berkeley.edu>
Subject Re: Integrating JAX-RS runtime into DOSGi
Date Mon, 31 Aug 2009 12:04:10 GMT
This works when specifying a single property, but not as an array.  In other
words, this is fine:

  <property name="org.apache.cxf.rs.provider"
value="org.whatever.MyJaxRsReaderWriter" />

but this does not work:

  <property name="org.apache.cxf.rs.provider">
    org.whatever.MyJaxRsReaderWriter,
    org.whatever.SomeOtherReaderOrWriter
  </property>

I seem to recall a general CXF issue with array properties in DS, so this
may be completely unrelated to the JAX-RS stuff.

Thanks,
Josh


On Mon, Aug 31, 2009 at 1:35 PM, Sergey Beryozkin <sberyozk@progress.com>wrote:

> Hi
>
> I've implemented just now on the trunk. I have the unit test only
> assuming that the calling BundleContext will be used to load the classes
> - can you please verify it?
>
> I'm not sure when exactly the Hudson build at
> http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/
>
> Will start and finish, hopefully soon enough, tomorrow will be ready for
> sure.
>
> Alternatively please rebuild dsw/cxf-dsw and then the distribution
> (single or multi) that you use...
>
> thanks, Sergey
>
> -----Original Message-----
> From: jmholtzman@gmail.com [mailto:jmholtzman@gmail.com] On Behalf Of
> Josh Holtzman
> Sent: 31 August 2009 10:38
> To: dev@cxf.apache.org
> Subject: Re: Integrating JAX-RS runtime into DOSGi
>
> 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
> <sberyozk@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"
> <jholtzman@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
> <sberyozk@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" <
> >>> jholtzman@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:
> >>>>
> >>>> [9853182@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.beryozkin@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"
> <sberyozk@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-tp2412
> 7832p25138636.html<http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp2412%0A7832p25138636.html>
> >>>>> Sent from the cxf-dev mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message