Yea. I think some of the fixes you did to the servlet transport around the
path processing need to be pushed down into the osgi transport. Actually,
I'd kind of prefer it the other way around. The osgi transport should be
pushed into CXF and it and the servlet transports refactored a bit to share as
much code as possible. :-)
Dan
On Thu April 23 2009 6:35:48 am Sergey Beryozkin wrote:
> Hi,
>
> > Eoghan Glynn-4 wrote:
> >> BTW in addition to the fix for SMX4-278, I believe you'll also need to
> >> change your @Path annotation from:
> >>
> >> @Path("/")
> >>
> >> to:
> >>
> >> @Path("/cxf/news")
> >
> > Ok now this is strange. It means that my service is now bound to CXF
> > implementation. This "/cxf" prefix is not making any sense on top of
> > Jersey/RestEasy/...
>
> I agree. If jaxrs:server added some uniqueness with "/news" then there's no
> need to propogate "/news" into the actual Path value, same way as it can be
> done with jaxws:endpoint. And I'm not quite sure where "/cxf/" is coming
> from...Unless the osgi HTTP listener is configured on some
> http://localhost:8080/cxf ? But then again there should be no need to push
> "/cxf/news/" into @Path...
>
> cheers, Sergey
>
> > Also, the @Path annotation can no longer represent a resource, strictly
> > speaking.
> >
> > What are your thoughts on that?
> >
> > JS.
> > --
> > View this message in context:
> > http://www.nabble.com/Deploying-REST-service-on-CXF-Transport-for-OSGi-fa
> >ils-tp23164054p23164896.html Sent from the cxf-user mailing list archive
> > at Nabble.com.
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
