That's the plan. Its sortta the second pahse of SMX4-278. The initial fix was sufficient to get CXF JAX-RS support running in SMX4. The refactor will ensure that this sort of divergence between the codebases doesn't trip us up again.
Cheers, Eoghan 2009/4/23 Daniel Kulp <[email protected]>: > > 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 >
