cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: JAX-RS 2.0 compliance
Date Fri, 29 Nov 2013 10:02:28 GMT
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 <sberyozkin@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 <sberyozkin@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 <sberyozkin@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 <sberyozkin@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 <sberyozkin@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>      Hi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   On 26/11/13 13:41, António Mota wrote:
>>>>>>>>>>>
>>>>>>>>>>>      Hi again.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   Sorry for not having explained myself correctly.
What I'm trying
>>>>>>>>>>>> to do
>>>>>>>>>>>> is
>>>>>>>>>>>> to have CXF+Spring configured in a Servlet
3 "non-xml" fashion.
>>>>>>>>>>>> SO
>>>>>>>>>>>> I
>>>>>>>>>>>> have
>>>>>>>>>>>> my WebApplicationInitializer initializing
>>>>>>>>>>>> a AnnotationConfigWebApplicationContext with
some @Configuration
>>>>>>>>>>>> classes.
>>>>>>>>>>>> SO I have not only to instantiate the RS
Applications but also
>>>>>>>>>>>> all
>>>>>>>>>>>> the
>>>>>>>>>>>> Spring beans and make them available to each
other. I did that
>>>>>>>>>>>> with
>>>>>>>>>>>> Jersey
>>>>>>>>>>>> but found out some problems with the jersey-spring3
integration,
>>>>>>>>>>>> and
>>>>>>>>>>>> since
>>>>>>>>>>>> we're planning the use of probably Fuse (or
at least Camel) I'm
>>>>>>>>>>>> now
>>>>>>>>>>>> testing
>>>>>>>>>>>> CXF. I started with the example here [1]
(that is indeed a
>>>>>>>>>>>> example
>>>>>>>>>>>> using
>>>>>>>>>>>> the standalone container), from which i picked
and adapted parts
>>>>>>>>>>>> of the
>>>>>>>>>>>> code, so I ended up in my configuration with
>>>>>>>>>>>>
>>>>>>>>>>>> @Bean(destroyMethod = "shutdown")
>>>>>>>>>>>>        public SpringBus cxf() {
>>>>>>>>>>>> SpringBus springBus = new SpringBus();
>>>>>>>>>>>>        return springBus;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> @Bean
>>>>>>>>>>>>        public Server jaxRsServer() {
>>>>>>>>>>>> JAXRSServerFactoryBean factory =
>>>>>>>>>>>> RuntimeDelegate.getInstance().createEndpoint(restApplication(),
>>>>>>>>>>>> JAXRSServerFactoryBean.class);
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>          factory.setServiceBean(testService());
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      This line appears to be redundant to me,
as you are already
>>>>>>>>>>>> setting
>>>>>>>>>>>>
>>>>>>>>>>>>   it up
>>>>>>>>>>> in the application. If it does not work without
this line then it
>>>>>>>>>>> is a
>>>>>>>>>>> bug
>>>>>>>>>>> which must be fixed.
>>>>>>>>>>>
>>>>>>>>>>> I think we have a demo (in our distro) where
a server is started
>>>>>>>>>>> with
>>>>>>>>>>> RuntimeDelegate, and it works
>>>>>>>>>>>
>>>>>>>>>>> Can you double check it please ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Sergey
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       return factory.create();
>>>>>>>>>>>
>>>>>>>>>>>         }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> and then the beans referring my javax.ws.rs.core.Application
and
>>>>>>>>>>>> my
>>>>>>>>>>>> testService. If I don't have the above 2
beans nothing is
>>>>>>>>>>>> instantiated.
>>>>>>>>>>>> To
>>>>>>>>>>>> have the TestService registered in the Application
like in my
>>>>>>>>>>>> previous
>>>>>>>>>>>> post
>>>>>>>>>>>> it's irrelevant.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> My servlet is configured as
>>>>>>>>>>>>
>>>>>>>>>>>> ServletRegistration.Dynamic dispatcher =
>>>>>>>>>>>> container.addServlet("dispatcher","org.apache.cxf.
>>>>>>>>>>>> transport.servlet.CXFServlet");
>>>>>>>>>>>>
>>>>>>>>>>>> It is working until now, but I really don't
know if this is the
>>>>>>>>>>>> right
>>>>>>>>>>>> way
>>>>>>>>>>>> to do it, but nevertheless this *is* a test
phase...
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>>>>> http://aredko.blogspot.ca/2013/01/going-rest-embedding-
>>>>>>>>>>>> jetty-with-spring.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, the @PreMatching is working now, I just
had to do some small
>>>>>>>>>>>> changes
>>>>>>>>>>>> in the way ContainerRequestContext retrieves
the service paths
>>>>>>>>>>>> (!)
>>>>>>>>>>>> and
>>>>>>>>>>>> changed the Jersey specific HttpBasicAuthFilter
to use the http
>>>>>>>>>>>> header
>>>>>>>>>>>> directly.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * Melhores cumprimentos / Beir beannacht
/ Best regards *
>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>
>>>>>>>>>>>> *António Manuel dos Santos Mota <http://gplus.to/amsmota>*
>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota* <
>>>>>>>>>>>> http://www.linkedin.com/in/
>>>>>>>>>>>> amsmota>
>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 26 November 2013 11:39, Sergey Beryozkin
<
>>>>>>>>>>>> sberyozkin@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>       Hi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    On 26/11/13 11:32, António Mota wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>       Sorry, @PreMatching does work,
after I registered it in
>>>>>>>>>>>>>
>>>>>>>>>>>>>     my javax.ws.rs.core.Application instead
of rootContext.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That leads me to a question however.
Why do I have to register
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> classes
>>>>>>>>>>>>>> with the JAXRSServerFactoryBean itself
and not doing it only
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> JAX-RS
>>>>>>>>>>>>>> spec says, like in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @ApplicationPath("rest")
>>>>>>>>>>>>>> public class RestApplication extends
Application {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>            public Set<Class<?>>
getClasses() {
>>>>>>>>>>>>>>                Set<Class<?>>
s = new HashSet<Class<?>>();
>>>>>>>>>>>>>>                s.add(TestService.class);
>>>>>>>>>>>>>> ----------------------->
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> one I
>>>>>>>>>>>>>> had
>>>>>>>>>>>>>> to register in JAXRSServerFactoryBean
>>>>>>>>>>>>>>                s.add(PreMatchingFilter.class);
>>>>>>>>>>>>>>                return s;
>>>>>>>>>>>>>>            }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        I'm a bit confused now :-).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      You can have Application activated
with
>>>>>>>>>>>>>> CXFNonSpringJaxrsServlet, you
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    don't have to work with JAXRSServerFactoryBean,
unless you
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>
>>>>>>>>>>>>> you
>>>>>>>>>>>>> application running in the standalone
Jetty container.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What is that 'rootContext' you are referring
to ? Is it
>>>>>>>>>>>>> something
>>>>>>>>>>>>> we
>>>>>>>>>>>>> need
>>>>>>>>>>>>> to fix ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sergey
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Melhores cumprimentos / Beir beannacht
/ Best regards *
>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *António Manuel dos Santos Mota
<http://gplus.to/amsmota>*
>>>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota*
<
>>>>>>>>>>>>>> http://www.linkedin.com/in/
>>>>>>>>>>>>>> amsmota>
>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 26 November 2013 11:16, António
Mota <amsmota@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Well, the services works well,
however I detected some
>>>>>>>>>>>>>> points:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     - if I point to my root address
as before it still give me
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   address
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the WADLs and WSDLs. The WSDL
links still work but the WADLs
>>>>>>>>>>>>>>> give a
>>>>>>>>>>>>>>> 404
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - @PreMatching does not seems
to work, beside the annotated
>>>>>>>>>>>>>>> class I
>>>>>>>>>>>>>>> also
>>>>>>>>>>>>>>> registered my annotated class
it in the application
>>>>>>>>>>>>>>> with rootContext.register(MyPreMatchingFilter.class);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Melhores cumprimentos / Beir
beannacht / Best regards *
>>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *António Manuel dos Santos Mota
<http://gplus.to/amsmota>*
>>>>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota*
<
>>>>>>>>>>>>>>> http://www.linkedin.com/in/
>>>>>>>>>>>>>>> amsmota
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        *_____________________________
>>>>>>>>>>>>>>> _________________________*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   On 26 November 2013 11:05,
António Mota <amsmota@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        Yes, I just found out
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     http://cxf.apache.org/docs/30-migration-guide.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But the problem is, how stable
is this and what's teh roadmap
>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>> Release? If I tell my boss
to use a Milestone1 he'll laugh...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nevertheless I will do test,
I'll be happy if I can help
>>>>>>>>>>>>>>>> somehow.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Melhores cumprimentos /
Beir beannacht / Best regards *
>>>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *António Manuel dos Santos
Mota <http://gplus.to/amsmota>*
>>>>>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota*
<
>>>>>>>>>>>>>>>> http://www.linkedin.com/in/
>>>>>>>>>>>>>>>> amsmota>
>>>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 26 November 2013 11:02,
Francesco Chicchiriccò <
>>>>>>>>>>>>>>>> ilgrosso@apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>         On 26/11/2013
11:58, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      CXF 3.0.0-milestone1
has just been released, give it a
>>>>>>>>>>>>>>>>> try
>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>       Hey, great
news: I haven't heard anything yet about
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> (not
>>>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     from
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   announce@) and
http://cxf.apache.org/download.html does
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> show
>>>>>>>>>>>>>>>>> anything new...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyway, is there any
migration procedure (or just hints) for
>>>>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>>>> upgrading from 2.7.X
(2.7.8-SNAPSHOT, actually)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>         On 26/11/13 10:49,
António Mota wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>         Hi again.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     As part of my
POC (that ultimately is aimed at aiding
>>>>>>>>>>>>>>>>>> us to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   choose
>>>>>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>>>>>> CXF, CXF+Camel
or Jersey) I'm now trying to port some use
>>>>>>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>> Jersey
>>>>>>>>>>>>>>>>>>> to CXF. It was
going very well except for a use case where
>>>>>>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>> javax.ws.rs.client.ClientBuilder,
but it seems that this
>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> present in javax.ws.rs-api:2.0
and CXF 2.7.7 uses
>>>>>>>>>>>>>>>>>>> javax.ws.rs-api:2.10-m10.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I tried to just
import the RS 2.0 jars and it went OK
>>>>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>>>>> CXF
>>>>>>>>>>>>>>>>>>> tries
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> instantiate a
ResponseImpl that uses
>>>>>>>>>>>>>>>>>>> a javax.ws.rs.MessageProcessingException
that seems to be
>>>>>>>>>>>>>>>>>>> present
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> RS
>>>>>>>>>>>>>>>>>>> 2.0-m10 but not
in 2.0.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So my question
is, is there a milestone that uses the
>>>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>>>> RS
>>>>>>>>>>>>>>>>>>> 2.0?
>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>> yes,
>>>>>>>>>>>>>>>>>>> how stable is
it and when it will be available as Release?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * Melhores cumprimentos
/ Beir beannacht / Best regards *
>>>>>>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *António Manuel
dos Santos Mota <http://gplus.to/amsmota
>>>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>>>> *http://www.linkedin.com/in/amsmota*
<
>>>>>>>>>>>>>>>>>>> http://www.linkedin.com/in/
>>>>>>>>>>>>>>>>>>> amsmota>
>>>>>>>>>>>>>>>>>>> *______________________________________________________*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>         --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>       Francesco
Chicchiriccò
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   Tirasa - Open Source
Excellence
>>>>>>>>>>>>>>>>> http://www.tirasa.net/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ASF Member, Apache Syncope
PMC chair, Apache Cocoon PMC
>>>>>>>>>>>>>>>>> Member
>>>>>>>>>>>>>>>>> http://people.apache.org/~ilgrosso/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>         --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Sergey Beryozkin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Talend Community Coders
>>>>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>      --
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   Sergey Beryozkin
>>>>>>>>>>>
>>>>>>>>>>> Talend Community Coders
>>>>>>>>>>> http://coders.talend.com/
>>>>>>>>>>>
>>>>>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     --
>>>>>>>>>>
>>>>>>>>> Sergey Beryozkin
>>>>>>>>>
>>>>>>>>> Talend Community Coders
>>>>>>>>> http://coders.talend.com/
>>>>>>>>>
>>>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>>
>>>
>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Mime
View raw message