It's about the trailing slash really: Jersey requestContext.getUriInfo().getBaseUri().toString() -> " http://app.antoniom:8080/core31/rest/";
CXF requestContext.getUriInfo().getBaseUri().toString() -> " http://app.antoniom:8080/core31/rest"; Cheers. * Melhores cumprimentos / Beir beannacht / Best regards * *______________________________________________________* *António Manuel dos Santos Mota <http://gplus.to/amsmota>* *http://www.linkedin.com/in/amsmota* <http://www.linkedin.com/in/amsmota> *______________________________________________________* On 27 November 2013 16:05, Sergey Beryozkin <[email protected]> wrote: > On 27/11/13 15:59, António Mota wrote: > >> That's a detail, I don't know if there is a specification for that, but >> >> requestContext.getUriInfo().getBaseUri().toString(); >> requestContext.getUriInfo().getAbsolutePath().toString(); >> >> return slightly different values in CXF and jersey. It has to do with >> initial / if you want tomorrow I can send you exactly what's different. >> >> That would be helpful, please do. > It must've been all tested in TCK, UriInfo methods specifically, but I'd > like to check it, > > Sergey > > > Cheers. >> >> >> >> >> >> On 27 November 2013 15:43, Sergey Beryozkin <[email protected]> wrote: >> >> By the way, you mentioned something about modifying >>> ContainerRequestContext, something to do with URIs, is it a CXF issue ? >>> >>> Sergey >>> >>> On 27/11/13 15:41, Sergey Beryozkin wrote: >>> >>> On 27/11/13 15:28, António Mota wrote: >>>> >>>> I think I'm lost now... Please note my comments inline. >>>>> >>>>> >>>>> On 26 November 2013 17:29, Sergey Beryozkin <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> Well, typically users would not use Application while also working >>>>>> >>>>>>> with >>>>>>> >>>>>>> Spring, they would just register roots/providers with jaxrs:server. >>>>>> >>>>>> >>>>>> My Application defines the classes (or instances) that provide the >>>>>> >>>>> services >>>>> itself, and those services are (can be) quite complex and have lots of >>>>> injected beans (be it injected with Spring or another DI container). >>>>> If I >>>>> let the instantiation of my service classes to the Application itself >>>>> (and >>>>> the JAX-RS implementation behind it) how can I assure those dependency >>>>> injections? >>>>> >>>>> I don't know, may be you can your Application explicitly loading an >>>> application context and extracting the service beans from it; or avoid >>>> using Application and use CXF jaxrs:server endpoint in a Spring context >>>> >>>> >>>> >>>>> >>>>> CXFNonSpringJaxrsServlet will work with Application, and will >>>>>> initialize >>>>>> the server as needed. >>>>>> >>>>>> >>>>>> I did try CXFNonSpringJaxrsServlet, and in all the cases I mentioned >>>>> before >>>>> I always got the same error: >>>>> >>>>> javax.servlet.ServletException: At least one resource class should >>>>> be >>>>> specified >>>>> at >>>>> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet. >>>>> getServiceClasses( >>>>> CXFNonSpringJaxrsServlet.java:266) >>>>> >>>>> at >>>>> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.init( >>>>> CXFNonSpringJaxrsServlet.java:118) >>>>> >>>>> >>>>> You have to specify your Application as a servlet parameter, per the >>>>> >>>> spec >>>> >>>> >>>>> >>>>> Application is supposed to be a completely portable 'container', >>>>>> JAX-RS >>>>>> supports the injection of JAX-RS contexts into Application, but if >>>>>> you'd >>>>>> like to mix it up with Spring/etc, then I guess it is becoming the >>>>>> implementation/framework specific. >>>>>> >>>>>> >>>>>> It still be portable since I'm using the javax.inject.Inject >>>>>> >>>>> annotation and >>>>> not the Spring-dependent autowired annotation. But otherwise how do you >>>>> take care of DI? >>>>> >>>>> >>>>> >>>>> May be we can support the auto-discovery of Applications from Spring >>>>> >>>>>> application contexts, we are investigating what can be done in this >>>>>> regard >>>>>> right now >>>>>> >>>>>> >>>>>> If I understand correctly and the Application is discovered after >>>>> being >>>>> instantiated (and bean-wired) by Spring that would work, but that would >>>>> imply to use the getSingletons() and not the getClasses(). Otherwise, >>>>> the >>>>> services are instantiated per-request and I'll loose all the DI... >>>>> >>>>> You are right >>>>> >>>> >>>> I'm getting a little confused, yes. I don't see the use of having >>>>> services >>>>> being instantiated per-request when those services normally depend on >>>>> other >>>>> services... >>>>> >>>>> You can control per-request service classes in Spring with CXF >>>>> >>>> SpringResourceFactory >>>> http://cxf.apache.org/docs/jaxrs-services-configuration.html# >>>> JAXRSServicesConfiguration-FromSpring >>>> >>>> >>>> Sergey >>>> >>>> >>>> >>>>> >>>>> Sergey >>>>>> >>>>>> Cheers, Sergey >>>>>> >>>>>> >>>>>> >>>>>> Cheers. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>> *______________________________________________________* >>>>>>> >>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>> *http://www.linkedin.com/in/amsmota* >>>>>>> <http://www.linkedin.com/in/amsmota> >>>>>>> *______________________________________________________* >>>>>>> >>>>>>> >>>>>>> On 26 November 2013 16:23, Sergey Beryozkin <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> >>>>>>>> On 26/11/13 13:41, António Mota wrote: >>>>>>>> >>>>>>>> Hi again. >>>>>>>> >>>>>>>> >>>>>>>>> Sorry for not having explained myself correctly. What I'm trying >>>>>>>>> to do >>>>>>>>> is >>>>>>>>> to have CXF+Spring configured in a Servlet 3 "non-xml" fashion. SO >>>>>>>>> I >>>>>>>>> have >>>>>>>>> my WebApplicationInitializer initializing >>>>>>>>> a AnnotationConfigWebApplicationContext with some @Configuration >>>>>>>>> classes. >>>>>>>>> SO I have not only to instantiate the RS Applications but also all >>>>>>>>> the >>>>>>>>> Spring beans and make them available to each other. I did that with >>>>>>>>> Jersey >>>>>>>>> but found out some problems with the jersey-spring3 integration, >>>>>>>>> and >>>>>>>>> since >>>>>>>>> we're planning the use of probably Fuse (or at least Camel) I'm now >>>>>>>>> testing >>>>>>>>> CXF. I started with the example here [1] (that is indeed a example >>>>>>>>> using >>>>>>>>> the standalone container), from which i picked and adapted parts >>>>>>>>> of the >>>>>>>>> code, so I ended up in my configuration with >>>>>>>>> >>>>>>>>> @Bean(destroyMethod = "shutdown") >>>>>>>>> public SpringBus cxf() { >>>>>>>>> SpringBus springBus = new SpringBus(); >>>>>>>>> return springBus; >>>>>>>>> } >>>>>>>>> >>>>>>>>> @Bean >>>>>>>>> public Server jaxRsServer() { >>>>>>>>> JAXRSServerFactoryBean factory = >>>>>>>>> RuntimeDelegate.getInstance().createEndpoint(restApplication(), >>>>>>>>> JAXRSServerFactoryBean.class); >>>>>>>>> >>>>>>>>> >>>>>>>>> factory.setServiceBean(testService()); >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> This line appears to be redundant to me, as you are already >>>>>>>>> setting >>>>>>>>> >>>>>>>> it up >>>>>>>> in the application. If it does not work without this line then it >>>>>>>> is a >>>>>>>> bug >>>>>>>> which must be fixed. >>>>>>>> >>>>>>>> I think we have a demo (in our distro) where a server is started >>>>>>>> with >>>>>>>> RuntimeDelegate, and it works >>>>>>>> >>>>>>>> Can you double check it please ? >>>>>>>> >>>>>>>> Thanks, Sergey >>>>>>>> >>>>>>>> >>>>>>>> return factory.create(); >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>>> >>>>>>>>> and then the beans referring my javax.ws.rs.core.Application and my >>>>>>>>> testService. If I don't have the above 2 beans nothing is >>>>>>>>> instantiated. >>>>>>>>> To >>>>>>>>> have the TestService registered in the Application like in my >>>>>>>>> previous >>>>>>>>> post >>>>>>>>> it's irrelevant. >>>>>>>>> >>>>>>>>> >>>>>>>>> My servlet is configured as >>>>>>>>> >>>>>>>>> ServletRegistration.Dynamic dispatcher = >>>>>>>>> container.addServlet("dispatcher","org.apache.cxf. >>>>>>>>> transport.servlet.CXFServlet"); >>>>>>>>> >>>>>>>>> It is working until now, but I really don't know if this is the >>>>>>>>> right >>>>>>>>> way >>>>>>>>> to do it, but nevertheless this *is* a test phase... >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://aredko.blogspot.ca/2013/01/going-rest-embedding- >>>>>>>>> jetty-with-spring.html >>>>>>>>> >>>>>>>>> >>>>>>>>> BTW, the @PreMatching is working now, I just had to do some small >>>>>>>>> changes >>>>>>>>> in the way ContainerRequestContext retrieves the service paths (!) >>>>>>>>> and >>>>>>>>> changed the Jersey specific HttpBasicAuthFilter to use the http >>>>>>>>> header >>>>>>>>> directly. >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>>>> *______________________________________________________* >>>>>>>>> >>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>>>> *http://www.linkedin.com/in/amsmota* <http://www.linkedin.com/in/ >>>>>>>>> amsmota> >>>>>>>>> *______________________________________________________* >>>>>>>>> >>>>>>>>> >>>>>>>>> On 26 November 2013 11:39, Sergey Beryozkin <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> >>>>>>>>> On 26/11/13 11:32, António Mota wrote: >>>>>>>>>> >>>>>>>>>> Sorry, @PreMatching does work, after I registered it in >>>>>>>>>> >>>>>>>>>> my javax.ws.rs.core.Application instead of rootContext. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That leads me to a question however. Why do I have to register my >>>>>>>>>>> classes >>>>>>>>>>> with the JAXRSServerFactoryBean itself and not doing it only has >>>>>>>>>>> the >>>>>>>>>>> JAX-RS >>>>>>>>>>> spec says, like in >>>>>>>>>>> >>>>>>>>>>> @ApplicationPath("rest") >>>>>>>>>>> public class RestApplication extends Application { >>>>>>>>>>> >>>>>>>>>>> @Override >>>>>>>>>>> public Set<Class<?>> getClasses() { >>>>>>>>>>> Set<Class<?>> s = new HashSet<Class<?>>(); >>>>>>>>>>> s.add(TestService.class); -----------------------> >>>>>>>>>>> this >>>>>>>>>>> one I >>>>>>>>>>> had >>>>>>>>>>> to register in JAXRSServerFactoryBean >>>>>>>>>>> s.add(PreMatchingFilter.class); >>>>>>>>>>> return s; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> I'm a bit confused now :-). >>>>>>>>>>> >>>>>>>>>>> You can have Application activated with >>>>>>>>>>> CXFNonSpringJaxrsServlet, you >>>>>>>>>>> >>>>>>>>>>> don't have to work with JAXRSServerFactoryBean, unless you have >>>>>>>>>> you >>>>>>>>>> application running in the standalone Jetty container. >>>>>>>>>> >>>>>>>>>> What is that 'rootContext' you are referring to ? Is it something >>>>>>>>>> we >>>>>>>>>> need >>>>>>>>>> to fix ? >>>>>>>>>> >>>>>>>>>> Sergey >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>>>>>> *______________________________________________________* >>>>>>>>>>> >>>>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>>>>>> *http://www.linkedin.com/in/amsmota* < >>>>>>>>>>> http://www.linkedin.com/in/ >>>>>>>>>>> amsmota> >>>>>>>>>>> *______________________________________________________* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 26 November 2013 11:16, António Mota <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Well, the services works well, however I detected some >>>>>>>>>>> points: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - if I point to my root address as before it still give me the >>>>>>>>>>> >>>>>>>>>>>> address >>>>>>>>>>>> of >>>>>>>>>>>> the WADLs and WSDLs. The WSDL links still work but the WADLs >>>>>>>>>>>> give a >>>>>>>>>>>> 404 >>>>>>>>>>>> >>>>>>>>>>>> - @PreMatching does not seems to work, beside the annotated >>>>>>>>>>>> class I >>>>>>>>>>>> also >>>>>>>>>>>> registered my annotated class it in the application >>>>>>>>>>>> with rootContext.register(MyPreMatchingFilter.class); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>> >>>>>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>>>>>>> *http://www.linkedin.com/in/amsmota* < >>>>>>>>>>>> http://www.linkedin.com/in/ >>>>>>>>>>>> amsmota >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> On 26 November 2013 11:05, António Mota <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes, I just found out >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cxf.apache.org/docs/30-migration-guide.html >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> But the problem is, how stable is this and what's teh roadmap >>>>>>>>>>>>> until >>>>>>>>>>>>> Release? If I tell my boss to use a Milestone1 he'll laugh... >>>>>>>>>>>>> >>>>>>>>>>>>> Nevertheless I will do test, I'll be happy if I can help >>>>>>>>>>>>> somehow. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota* < >>>>>>>>>>>>> http://www.linkedin.com/in/ >>>>>>>>>>>>> amsmota> >>>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 26 November 2013 11:02, Francesco Chicchiriccò < >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/2013 11:58, Sergey Beryozkin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> CXF 3.0.0-milestone1 has just been released, give it a try >>>>>>>>>>>>>> please >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hey, great news: I haven't heard anything yet about this >>>>>>>>>>>>>>> (not >>>>>>>>>>>>>>> even >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> from >>>>>>>>>>>>>>> >>>>>>>>>>>>>> announce@) and http://cxf.apache.org/download.html does not >>>>>>>>>>>>>> show >>>>>>>>>>>>>> anything new... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Anyway, is there any migration procedure (or just hints) for >>>>>>>>>>>>>> people >>>>>>>>>>>>>> upgrading from 2.7.X (2.7.8-SNAPSHOT, actually)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 26/11/13 10:49, António Mota wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As part of my POC (that ultimately is aimed at aiding us to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> choose >>>>>>>>>>>>>>>> between >>>>>>>>>>>>>>>> CXF, CXF+Camel or Jersey) I'm now trying to port some use >>>>>>>>>>>>>>>> cases >>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>> Jersey >>>>>>>>>>>>>>>> to CXF. It was going very well except for a use case where >>>>>>>>>>>>>>>> I'm >>>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>> javax.ws.rs.client.ClientBuilder, but it seems that this >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>> present in javax.ws.rs-api:2.0 and CXF 2.7.7 uses >>>>>>>>>>>>>>>> javax.ws.rs-api:2.10-m10. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I tried to just import the RS 2.0 jars and it went OK until >>>>>>>>>>>>>>>> CXF >>>>>>>>>>>>>>>> tries >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> instantiate a ResponseImpl that uses >>>>>>>>>>>>>>>> a javax.ws.rs.MessageProcessingException that seems to be >>>>>>>>>>>>>>>> present >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> RS >>>>>>>>>>>>>>>> 2.0-m10 but not in 2.0. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So my question is, is there a milestone that uses the final >>>>>>>>>>>>>>>> RS >>>>>>>>>>>>>>>> 2.0? >>>>>>>>>>>>>>>> If >>>>>>>>>>>>>>>> yes, >>>>>>>>>>>>>>>> how stable is it and when it will be available as Release? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Melhores cumprimentos / Beir beannacht / Best regards * >>>>>>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>* >>>>>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota* < >>>>>>>>>>>>>>>> http://www.linkedin.com/in/ >>>>>>>>>>>>>>>> amsmota> >>>>>>>>>>>>>>>> *______________________________________________________* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Francesco Chicchiriccò >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Tirasa - Open Source Excellence >>>>>>>>>>>>>> http://www.tirasa.net/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member >>>>>>>>>>>>>> http://people.apache.org/~ilgrosso/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sergey Beryozkin >>>>>>>>>> >>>>>>>>>> Talend Community Coders >>>>>>>>>> http://coders.talend.com/ >>>>>>>>>> >>>>>>>>>> Blog: http://sberyozkin.blogspot.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>> Sergey Beryozkin >>>>>>>> >>>>>>>> Talend Community Coders >>>>>>>> http://coders.talend.com/ >>>>>>>> >>>>>>>> Blog: http://sberyozkin.blogspot.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> Sergey Beryozkin >>>>>> >>>>>> Talend Community Coders >>>>>> http://coders.talend.com/ >>>>>> >>>>>> Blog: http://sberyozkin.blogspot.com >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com >
