Hi again, let me point some more observations/clarifications. Please note that I'm in no way criticising CXF, my aim here is to understand what's going on so I can rely the most possible on standards and not on features that can change in future versions. Even if I don't have a problem with going to some degree of dependency on platform/framework, I will avoid it if I can.
On 27 November 2013 15:41, Sergey Beryozkin <[email protected]> wrote: > 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 > > OK, I did that alright, but that is tying my app to CXF specifics completely, I don't see any advantage over using Application+Injected singletons, that ties only with javax.inject.Inject+any DI container that suports it. > > >> >> >>> 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 You meant my services, not the Application, right? OK, I did that also (uff, it took me awhile) but since the service is instantiated (as a Singleton) by the CXF servlet, I again lose my bean injection capability. > > >> >>> 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 That seems way too complicated, since I have easier ways to instantiate the services without the use of a Factory: 1- let the Application instantiate the services, they are instantiated per-request and if I want DI I have to do it every time by using some @Context 2- let the JAXRSServerFactoryBean create the endpoints without Application and setting the already autowired services (as Singletons) in it 3- let the JAXRSServerFactoryBean create the endpoints with a Application and use the getSingletons (instead getClasses) to set the already autowired services Am I correct in this? If yes, 1 will be a "pure" independent JAX-RS way to do it, but with the overhead of always have to inject what I need. 2 will be totally CXF dependent and not JAX-RS portable. 2 will be only slightly CXF dependent, in a way that is portable to other JAX-RS containers. So, since I have to use Spring as a DI container anyway, it seems 3 is a good choice for my case scenario. Thanks for your continuing help with this :) > > > 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 >>> >>> >> > >
