You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by António Mota <am...@gmail.com> on 2013/11/26 11:49:03 UTC
JAX-RS 2.0 compliance
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>
*______________________________________________________*
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Note, new Client API is in cxf-rt-rs-client module
Sergey
On 26/11/13 10:58, Sergey Beryozkin wrote:
> Hi,
> CXF 3.0.0-milestone1 has just been released, give it a try please
>
> Thanks, Sergey
> 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>
>> *______________________________________________________*
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 30/11/13 17:33, KARR, DAVID wrote:
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Friday, November 29, 2013 8:42 AM
>> To: users@cxf.apache.org
>> Subject: Re: JAX-RS 2.0 compliance
>>
>> On 29/11/13 16:09, António Mota wrote:
>>> On 29 November 2013 10:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>>> Well, URI.resolve won't work correctly without a trailing slash. Hmm...
>>>> I will need to investigate it further
>>>>
>>>> Sergey
>>>>
>>>>
>>> I'm glad I gave you something to think... :))))))
>>>
>> Yea, one extra problem to deal with, thanks :-)
>> FYI:
>> https://java.net/jira/browse/JAX_RS_SPEC-438
>
> Sergey, you might want to provide more justification in the ticket for why the lack of clarification on this is causing problems.
>
yes, I added a comment
Cheers, Sergey
Re: JAX-RS 2.0 compliance
Posted by Euan Milton <eu...@hotmail.co.uk>.
Has the big man stepped up?
Sent from my iPhone
On 30 Nov 2013, at 17:34, "KARR, DAVID" <dk...@att.com> wrote:
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Friday, November 29, 2013 8:42 AM
>> To: users@cxf.apache.org
>> Subject: Re: JAX-RS 2.0 compliance
>>
>> On 29/11/13 16:09, António Mota wrote:
>>> On 29 November 2013 10:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>>> Well, URI.resolve won't work correctly without a trailing slash. Hmm...
>>>> I will need to investigate it further
>>>>
>>>> Sergey
>>> I'm glad I gave you something to think... :))))))
>> Yea, one extra problem to deal with, thanks :-)
>> FYI:
>> https://java.net/jira/browse/JAX_RS_SPEC-438
>
> Sergey, you might want to provide more justification in the ticket for why the lack of clarification on this is causing problems.
>
RE: JAX-RS 2.0 compliance
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Friday, November 29, 2013 8:42 AM
> To: users@cxf.apache.org
> Subject: Re: JAX-RS 2.0 compliance
>
> On 29/11/13 16:09, António Mota wrote:
> > On 29 November 2013 10:23, Sergey Beryozkin <sb...@gmail.com> wrote:
> >
> >> Well, URI.resolve won't work correctly without a trailing slash. Hmm...
> >> I will need to investigate it further
> >>
> >> Sergey
> >>
> >>
> > I'm glad I gave you something to think... :))))))
> >
> Yea, one extra problem to deal with, thanks :-)
> FYI:
> https://java.net/jira/browse/JAX_RS_SPEC-438
Sergey, you might want to provide more justification in the ticket for why the lack of clarification on this is causing problems.
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 29/11/13 16:09, António Mota wrote:
> On 29 November 2013 10:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>> Well, URI.resolve won't work correctly without a trailing slash. Hmm...
>> I will need to investigate it further
>>
>> Sergey
>>
>>
> I'm glad I gave you something to think... :))))))
>
Yea, one extra problem to deal with, thanks :-)
FYI:
https://java.net/jira/browse/JAX_RS_SPEC-438
Thanks, Sergey
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
On 29 November 2013 10:23, Sergey Beryozkin <sb...@gmail.com> wrote:
> Well, URI.resolve won't work correctly without a trailing slash. Hmm...
> I will need to investigate it further
>
> Sergey
>
>
I'm glad I gave you something to think... :))))))
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Well, URI.resolve won't work correctly without a trailing slash. Hmm...
I will need to investigate it further
Sergey
On 29/11/13 10:02, Sergey Beryozkin wrote:
> Hi António
> On 28/11/13 15:18, António Mota wrote:
>> Yes, I just checked again. I don't know if it matters, but I'm getting
>> the requestContext from a filter
>>
>> public void filter(ContainerRequestContext requestContext) throws
>> IOException {
>> String fromPath =
>> requestContext.getUriInfo().getBaseUri().toString();
>> String pathInfo =
>> requestContext.getUriInfo().getAbsolutePath().toString();
>>
>>
>
> This is one of those grey areas in the spec/API. I do not see anything
> in UriInfo documentation suggesting that a base URI has to end with the
> trailing slash, it seems not quite right to me, though, to be honest, both
>
> http://www.bar.com
> and
> http://www.bar.com/
>
> both qualify well as base URIs.
>
> I'm not sure why Jersey adds a trailing slash, one theory can be that it
> is done so that it can concatenate literally with the root resource's
> Path value, example,
>
> @Path("foo")
> public class MyRoot {
> }
>
> so if you have
> http://www.bar.com/
>
> then it will concatenate as is with "foo".
>
> This is a theory though.
>
> The developers are not expected to do such kind of calculations
> manually, UriInfo.getBaseUriBuilder() needs to be used if the base URI
> will be used to build some other link, etc, or even do
> UriInfo.getBaseUri().resolve("foo"), in either case the issue of
> ensuring a proper path segment separator is added (or not) will be taken
> care of.
>
> Purely from the reporting point of view, IMHO "http://www.bar.com" reads
> a little bit better than the version with the trailing slash, but it is
> really a minor issue; I will open a spec request to clarify how the base
> URI is expected to be calculated but I think the maximum we can get
> there is a *recommendation* on the use of the trailing slash as opposed
> to a *requirement*
>
> 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 28 November 2013 11:37, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>>>
>>> On 28/11/13 10:32, António Mota wrote:
>>>
>>>> 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"
>>>>
>>>
>>> Thanks, are you sure it is not the other way around ?
>>> I see CXF ServletController adding a trailing "/" to the correctly
>>> calculated base URL which is not exactly right.
>>>
>>> If it is indeed the case in your scenario, then I'd say Jersey might be
>>> not correct, where does it take "/" from ?
>>>
>>> It might make sense to open a JAX-RS spec JIRA to ensure
>>> UriInfo.getBaseUri() produces consistent values. Though it can be
>>> hard to
>>> make it consistent across multiple containers.
>>>
>>> For example, Jetty HttpServletRequest.getServletPath() returns "/test"
>>> for a url pattern "/test/*". You may get the other implementation
>>> returning
>>> "/test/"...
>>>
>>> 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 27 November 2013 16:05, Sergey Beryozkin <sb...@gmail.com>
>>>> 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 <sb...@gmail.com>
>>>>>> 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 <sb...@gmail.com>
>>>>>>>>> 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
>>>>>>>>>>> <sb...@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 <am...@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
>>>>>>>>>>>>>>>>> <am...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi António
On 28/11/13 15:18, António Mota wrote:
> Yes, I just checked again. I don't know if it matters, but I'm getting
> the requestContext from a filter
>
> public void filter(ContainerRequestContext requestContext) throws
> IOException {
> String fromPath = requestContext.getUriInfo().getBaseUri().toString();
> String pathInfo =
> requestContext.getUriInfo().getAbsolutePath().toString();
>
>
This is one of those grey areas in the spec/API. I do not see anything
in UriInfo documentation suggesting that a base URI has to end with the
trailing slash, it seems not quite right to me, though, to be honest, both
http://www.bar.com
and
http://www.bar.com/
both qualify well as base URIs.
I'm not sure why Jersey adds a trailing slash, one theory can be that it
is done so that it can concatenate literally with the root resource's
Path value, example,
@Path("foo")
public class MyRoot {
}
so if you have
http://www.bar.com/
then it will concatenate as is with "foo".
This is a theory though.
The developers are not expected to do such kind of calculations
manually, UriInfo.getBaseUriBuilder() needs to be used if the base URI
will be used to build some other link, etc, or even do
UriInfo.getBaseUri().resolve("foo"), in either case the issue of
ensuring a proper path segment separator is added (or not) will be taken
care of.
Purely from the reporting point of view, IMHO "http://www.bar.com" reads
a little bit better than the version with the trailing slash, but it is
really a minor issue; I will open a spec request to clarify how the base
URI is expected to be calculated but I think the maximum we can get
there is a *recommendation* on the use of the trailing slash as opposed
to a *requirement*
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 28 November 2013 11:37, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>>
>> On 28/11/13 10:32, António Mota wrote:
>>
>>> 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"
>>>
>>
>> Thanks, are you sure it is not the other way around ?
>> I see CXF ServletController adding a trailing "/" to the correctly
>> calculated base URL which is not exactly right.
>>
>> If it is indeed the case in your scenario, then I'd say Jersey might be
>> not correct, where does it take "/" from ?
>>
>> It might make sense to open a JAX-RS spec JIRA to ensure
>> UriInfo.getBaseUri() produces consistent values. Though it can be hard to
>> make it consistent across multiple containers.
>>
>> For example, Jetty HttpServletRequest.getServletPath() returns "/test"
>> for a url pattern "/test/*". You may get the other implementation returning
>> "/test/"...
>>
>> 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 27 November 2013 16:05, Sergey Beryozkin <sb...@gmail.com> 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 <sb...@gmail.com>
>>>>> 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 <sb...@gmail.com>
>>>>>>>> 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 <sb...@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 <am...@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 <am...@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
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
Yes, I just checked again. I don't know if it matters, but I'm getting
the requestContext from a filter
public void filter(ContainerRequestContext requestContext) throws
IOException {
String fromPath = requestContext.getUriInfo().getBaseUri().toString();
String pathInfo =
requestContext.getUriInfo().getAbsolutePath().toString();
* 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 28 November 2013 11:37, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> On 28/11/13 10:32, António Mota wrote:
>
>> 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"
>>
>
> Thanks, are you sure it is not the other way around ?
> I see CXF ServletController adding a trailing "/" to the correctly
> calculated base URL which is not exactly right.
>
> If it is indeed the case in your scenario, then I'd say Jersey might be
> not correct, where does it take "/" from ?
>
> It might make sense to open a JAX-RS spec JIRA to ensure
> UriInfo.getBaseUri() produces consistent values. Though it can be hard to
> make it consistent across multiple containers.
>
> For example, Jetty HttpServletRequest.getServletPath() returns "/test"
> for a url pattern "/test/*". You may get the other implementation returning
> "/test/"...
>
> 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 27 November 2013 16:05, Sergey Beryozkin <sb...@gmail.com> 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 <sb...@gmail.com>
>>>> 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 <sb...@gmail.com>
>>>>>>> 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 <sb...@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 <am...@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 <am...@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
>>>
>>>
>>
>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 28/11/13 10:32, António Mota wrote:
> 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"
Thanks, are you sure it is not the other way around ?
I see CXF ServletController adding a trailing "/" to the correctly
calculated base URL which is not exactly right.
If it is indeed the case in your scenario, then I'd say Jersey might be
not correct, where does it take "/" from ?
It might make sense to open a JAX-RS spec JIRA to ensure
UriInfo.getBaseUri() produces consistent values. Though it can be hard
to make it consistent across multiple containers.
For example, Jetty HttpServletRequest.getServletPath() returns "/test"
for a url pattern "/test/*". You may get the other implementation
returning "/test/"...
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 27 November 2013 16:05, Sergey Beryozkin <sb...@gmail.com> 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 <sb...@gmail.com> 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 <sb...@gmail.com>
>>>>>> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>>
>
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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 <sb...@gmail.com> 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 <sb...@gmail.com> 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 <sb...@gmail.com>
>>>>> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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 <sb...@gmail.com>
>>>> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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.
Cheers.
On 27 November 2013 15:43, Sergey Beryozkin <sb...@gmail.com> 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 <sb...@gmail.com>
>>> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>>>>
>>>>
>>>
>>
>>
>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>>>
>>
>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Can you consider providing a test project showing a single root REST
resource being instantiated and injected, the way it's currently done ?
That will help me to see what exactly you do in your project (around
JAX-RS) and may give some ideas on what can be improved, or may be I can
suggest something else. Otherwise it is difficult to advice anything
specific
Thanks, Sergey
On 29/11/13 16:09, António Mota wrote:
> On 28 November 2013 16:54, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>>
>>>
>>> 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
>>
>>
> Well, I don't have a term of comparison for complexity, our current app has
> 38 REST resources with 288 sub-resources in total, and those 38 resources
> have 71 beans injected. Hence my worries about having the beans
> instantiated and injected in a easy and clean manner.
>
>
> 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 :-)
>>
>>
> Well, my problem is not so much about happiness but choosing the best way
> to do things, and the best way should be as close as possible to standards.
> It is possible that this option looks now the best option but it may happen
> that I'm not seeing the complete picture, or that I'm ignorant of other
> ways to do the same things... I'm by no means a expert in JAX-RS or CXF or
> Jersey (even if I work with REST-based architectures from quite a number of
> years now).
>
> On the other hand way, you *are* a expert in CXF, that's why is usefull to
> hear what to have to say :)
>
>
> Thanks again for you support.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
On 28 November 2013 16:54, Sergey Beryozkin <sb...@gmail.com> wrote:
>
>>
>> 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
>
>
Well, I don't have a term of comparison for complexity, our current app has
38 REST resources with 288 sub-resources in total, and those 38 resources
have 71 beans injected. Hence my worries about having the beans
instantiated and injected in a easy and clean manner.
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 :-)
>
>
Well, my problem is not so much about happiness but choosing the best way
to do things, and the best way should be as close as possible to standards.
It is possible that this option looks now the best option but it may happen
that I'm not seeing the complete picture, or that I'm ignorant of other
ways to do the same things... I'm by no means a expert in JAX-RS or CXF or
Jersey (even if I work with REST-based architectures from quite a number of
years now).
On the other hand way, you *are* a expert in CXF, that's why is usefull to
hear what to have to say :)
Thanks again for you support.
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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 <sb...@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 <sb...@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 <am...@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 <am...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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 <sb...@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.
>
>
>>
>>> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>>>
>>>
>>
>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>>
>
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
I think I'm lost now... Please note my comments inline.
On 26 November 2013 17:29, Sergey Beryozkin <sb...@gmail.com> 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?
>
> 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)
>
> 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...
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...
>
> 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 <sb...@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 <sb...@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 <am...@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 <am...@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
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 26/11/13 17:06, António Mota wrote:
> That was complicated... I tested like this:
>
> 1) removed factory.setServiceBean(testService());
> it throws a org.apache.cxf.service.factory.ServiceConstructionException: No
> resource classes found
>
> 2) in my Application changed
> s.add(TestService.class)
>
> - a interface - to s.add(TestService
> Impl.class)
> it worked but none of the properties
> in the service
> were injected
>
> 3) removed the getClasses and overrided getSingletons instead, passing a
> injected testService
> IT WORKS
>
> So I guess it was my mistake in first place...
> Nevertheless let me ask, in my use case scenario (CXF+Spring) using the
> RuntimeDelegate is the correct way to instantiate a server?
>
Well, typically users would not use Application while also working with
Spring, they would just register roots/providers with jaxrs:server.
CXFNonSpringJaxrsServlet will work with Application, and will initialize
the server as needed.
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.
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
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 <sb...@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 <sb...@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 <am...@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 <am...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
That was complicated... I tested like this:
1) removed factory.setServiceBean(testService());
it throws a org.apache.cxf.service.factory.ServiceConstructionException: No
resource classes found
2) in my Application changed
s.add(TestService.class)
- a interface - to s.add(TestService
Impl.class)
it worked but none of the properties
in the service
were injected
3) removed the getClasses and overrided getSingletons instead, passing a
injected testService
IT WORKS
So I guess it was my mistake in first place...
Nevertheless let me ask, in my use case scenario (CXF+Spring) using the
RuntimeDelegate is the correct way to instantiate a server?
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 <sb...@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 <sb...@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 <am...@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 <am...@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
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@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 <am...@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 <am...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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());
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 <sb...@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 <am...@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 <am...@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
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <am...@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 <am...@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ò <il...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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;
}
}
* 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 <am...@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 <am...@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ò <il...@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/
>>>
>>>
>>
>
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
Opps, I just answered it on my own question, please see my other post.
Thanks for your excelent support :)
* 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:31, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> On 26/11/13 11:16, António Mota wrote:
>
>> Well, the services works well, however I detected some points:
>>
>> That was fast :-)
>
> - 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
>>
>> Yes, WADL auto-generator has been moved to a new module: to continue
> improving the modularity of CXF JAX-RS related artifacts and minimize the
> size of the main module, and also save few milliseconds on the runtime path
> by skipping an extra filter check when no WADL support is required for RS
> clients
>
>
> - @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);
>>
>>
> Can you clarify please ? Do you do it from a DynamicFeature ?
>
> Thanks, 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 11:05, António Mota <am...@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
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 26/11/13 11:16, António Mota wrote:
> Well, the services works well, however I detected some points:
>
That was fast :-)
> - 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
>
Yes, WADL auto-generator has been moved to a new module: to continue
improving the modularity of CXF JAX-RS related artifacts and minimize
the size of the main module, and also save few milliseconds on the
runtime path by skipping an extra filter check when no WADL support is
required for RS clients
> - @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);
>
Can you clarify please ? Do you do it from a DynamicFeature ?
Thanks, 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 11:05, António Mota <am...@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ò <il...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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 <am...@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ò <il...@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/
>>
>>
>
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 26/11/13 11:05, António Mota wrote:
> Yes, I just found out
>
> http://cxf.apache.org/docs/30-migration-guide.html
See also
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-FromCXF2.7.xtoCXF3.0.0
>
> 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...
>
LOL myself, I can nearly hear you boss laughing :-)
Seriously though, JAX-RS 2.0 work has been complete for a while, I can
see you reporting the issues against the milestone which will be fixed,
we are now in the bug fixing mode as far as JAX-RS 2.0 work is concerned.
It is milestone because more CXF worl is still ongoing, major WS
security related work, etc..
> Nevertheless I will do test, I'll be happy if I can help somehow.
Sounds good
Thanks, 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 11:02, Francesco Chicchiriccò <il...@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
Re: JAX-RS 2.0 compliance
Posted by António Mota <am...@gmail.com>.
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ò <il...@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/
>
>
Re: JAX-RS 2.0 compliance
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 26/11/2013 12:19, Sergey Beryozkin wrote:
> Hi
>
> On 26/11/13 11:02, Francesco Chicchiriccò 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...
>
> The artifacts were released yesterday so the page will be updated shortly
>
>>
>> Anyway, is there any migration procedure (or just hints) for people
>> upgrading from 2.7.X (2.7.8-SNAPSHOT, actually)?
>>
> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS
>
> Please see
> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-FromCXF2.7.xtoCXF3.0.0
>
>
> (I just added a couple of extra notes there)
Hi Sergey,
thanks for information: FYI, I've just opened SYNCOPE-450 for migrating
Syncope trunk to CXF 3.0.0-milestone1.
Regards.
--
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/
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 26/11/13 11:02, Francesco Chicchiriccò 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...
The artifacts were released yesterday so the page will be updated shortly
>
> Anyway, is there any migration procedure (or just hints) for people
> upgrading from 2.7.X (2.7.8-SNAPSHOT, actually)?
>
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS
Please see
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-FromCXF2.7.xtoCXF3.0.0
(I just added a couple of extra notes there)
Thanks, Sergey
> 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>
>>> *______________________________________________________*
>
Re: JAX-RS 2.0 compliance
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/
Re: JAX-RS 2.0 compliance
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
CXF 3.0.0-milestone1 has just been released, give it a try please
Thanks, Sergey
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>
> *______________________________________________________*
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com