cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: JAX-RS 2.0 compliance
Date Thu, 28 Nov 2013 16:54:06 GMT
On 28/11/13 15:01, António Mota wrote:
> 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.
No problems, constructive criticism is always welcome

>
>
>
> On 27 November 2013 15:41, Sergey Beryozkin <sberyozkin@gmail.com> 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.
>

You must be doing something sophisticated; FYI, you can register either 
Application itself or services and providers as simple servlet 
parameters, not sure where is the complexity you are referring to is 
coming from


>
>
>>
>>
>>>
>>>> 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.
>

I'm just sure what is happening in your case, so if you are happy with 3 
then it is good enough for me :-)

Cheers, Sergey

>
> 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 <sberyozkin@gmail.com>
>>>>> 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 <sberyozkin@gmail.com>
>>>>>>> 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 <amsmota@gmail.com>
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 <amsmota@gmail.com>
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ò
<
>>>>>>>>>>> ilgrosso@apache.org
>>>>>>>>>>>
>>>>>>>>>>>    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

Mime
View raw message