cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Holtzman <jholtz...@berkeley.edu>
Subject Re: Whiteboard pattern for JAX-RS services
Date Fri, 12 Jun 2009 15:38:33 GMT
In the patch I submitted, I don't think there's a way to expose a service as
both a wsdl-based endpoint and a restful endpoint.  I've been using the
wsdl-based endpoints for DOSGi communication (hence, my initial focus on
JAX-WS and the JAXB databinding), and registering jax-rs resources
separately.  I suppose I could register the same service instance twice,
each with different service properties.  Do you think that is the best
solution for exposing multiple endpoints per service?

Thanks,
Josh


On Fri, Jun 12, 2009 at 8:11 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Yeah, so simply putting the property
>  osgi.remote.interfaces=*
> on an OSGi service that is put in the OSGi service registry makes it
> available remotely through CXF/DOSGi. If you select the JAX/RS
> configueration type (which is currently being worked on) it should
> make it available via JAX-RS
>
> Isn't that exactly the whiteboard pattern as desired? I don't really
> see the value of picking *another* osgi service property for this
> purpose as well...
>
> David
>
> 2009/6/12 Sergey Beryozkin <sberyozk@progress.com>:
> > Hi Josh
> >
> > It seems that in DOSGi RI this is actually what is being done. When a
> > service is being registered a DSW provider picks up this event and
> > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS
> > with the help of properties you introduced in your patch.
> >
> > David told me that if a property osgi.remote.interfaces is set to '*'
> > then it should let DSW to handle unbounded number of interfaces.
> >
> > I like the idea of message providers being picked up from the
> > whiteboard, it is certainly bound to work better in OSGI than say
> > scanning the classpath.
> > I'll consider enhancing the DOSGi DSW accordingly.
> >
> > Enhancing the CXF bundle on its own (possibly indirectly by introducing
> > another helper bundle as you suggested) is an interesting idea but the
> > question is what to do next - that is how to configure such services for
> > ex.
> >
> > What do you think ? Do you have some scenarios in mind that may not be
> > easy to do with DOSGi ?
> >
> > Thanks, Sergey
> >
> >
> > -----Original Message-----
> > From: jmholtzman@gmail.com [mailto:jmholtzman@gmail.com] On Behalf Of
> > Josh Holtzman
> > Sent: 12 June 2009 15:00
> > To: dev@cxf.apache.org
> > Subject: Whiteboard pattern for JAX-RS services
> >
> > 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.
> >
> > Is this something the CXF folks would be interested in adding?  If so,
> > does
> > it belong in the cxf-minimal bundle, or as its own add-on bundle?  If
> > people
> > are familiar with pax-web and pax-web-extender-whiteboard, they'll
> > recognize
> > that this kind of thing can be broken out into its own bundle.  In the
> > pax-web case, though, they decided to merge the whiteboard functionality
> > into their main bundle.
> >
> > Full disclosure: I've been using another JAX-RS impl to do this, but
> > with
> > the CXF impl passing the 1.0 TCK, I figured that it's time to
> > re-evaluate :)
> >
> > Thanks,
> > Josh
> >
>

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