You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Klevenz, Stephan" <st...@sap.com> on 2012/01/28 14:33:52 UTC
Jersey / CXF compatibility
Hi,
I'm having a strange problem while executing a compatibility tests suite for Jersey and CXF. All tests running twice as parameterized unit tests where the first run uses Jersey and the second run is with CXF. Unfortunately CXF is throwing an WebApplicationException as you can see from the trace below. If I disable the Jersey run then CXF does not show errors. It seems that CXF struggle with side effects caused by Jersey. Question is how can this be evaluated. The trace is the only hint that I have.
Thanks in advance.
Regards,
Stephan
2012-01-28 14:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ******************************************************************
2012-01-28 14:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: Activated Server Type = CXF
2012-01-28 14:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ******************************************************************
2012-01-28 14:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ---------------------------------------------------------------
2012-01-28 14:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: test class: org.example.test.compatibility.SimpleCompatibilityTest
2012-01-28 14:21:17,744 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: test method: testSimple
2012-01-28 14:21:17,744 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ---------------------------------------------------------------
2012-01-28 14:21:17,764 INFO [main] org.apache.cxf.endpoint.ServerImpl: Setting the server's publish address to be /
2012-01-28 14:21:17,765 INFO [main] org.apache.cxf.jaxrs.provider.ProviderFactory: Problem with setting the default provider org.apache.cxf.jaxrs.provider.JSONProviderorg/codehaus/jettison/mapped/TypeConverter
2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl: Server is starting.
2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.transport.servlet.ServletDestination: registering incoming observer: org.apache.cxf.transport.ChainInitiationObserver@3c095f75
2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl: register the server to serverRegistry
2012-01-28 14:21:17,775 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: uri: http://localhost:8810/test/test.svc/root/simple
2012-01-28 14:21:17,775 DEBUG [main] org.example.test.compatibility.jersey.JerseyTestClient: getResource(), uri = http://localhost:8810/test/test.svc/root/simple
2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42] org.apache.cxf.transport.servlet.ServletController: Service http request on thread: Thread[qtp1692156427-42,5,main]
2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42] org.apache.cxf.transport.http.AbstractHTTPDestination: Create a new message for processing
2012-01-28 14:21:17,959 DEBUG [qtp1692156427-42] org.apache.cxf.transport.http.Headers: Request Headers: {Accept=[text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2], Cache-Control=[no-cache], connection=[keep-alive], Content-Type=[null], Host=[localhost:8810], Pragma=[no-cache], User-Agent=[Java/1.6.0_29]}
2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.ServiceInvokerInterceptor@7bc2f501 to phase invoke
2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.OutgoingChainInterceptor@1d286180 to phase post-invoke
2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974<tel:46192974> to phase pre-logical
2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0 to phase unmarshal
2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e to phase pre-stream
2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Chain org.apache.cxf.phase.PhaseInterceptorChain@24c98b07 was created. Current flow:
pre-stream [CertConstraintsInterceptor]
unmarshal [JAXRSInInterceptor]
pre-logical [OneWayProcessorInterceptor]
invoke [ServiceInvokerInterceptor]
post-invoke [OutgoingChainInterceptor]
2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on interceptor org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e
2012-01-28 14:21:17,978 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0
2012-01-28 14:21:17,983 WARN [qtp1692156427-42] org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: WebApplicationException has been caught : no cause is available
2012-01-28 14:21:17,984 DEBUG [qtp1692156427-42] org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: no cause is available
javax.ws.rs.WebApplicationException
at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:139)
at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:89)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:127)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:115)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:680)
2
Re: Jersey / CXF compatibility
Posted by Sergey Beryozkin <sb...@gmail.com>.
The issue with a single '*' must be fixed now, there was some code there
dealing with it but it was not trimming the data...
Apache JIRA seems to be down right now, so was not able to open a new
JIRA before merging
Cheers, Sergey
On 01/02/12 14:01, Sergey Beryozkin wrote:
> Hi Stephan
>
> On 01/02/12 06:45, Klevenz, Stephan wrote:
>> Hi,
>>
>> would it make sense to open a Jira issue?
>>
>> I'm interested in getting this fixed
>
> sure, this can be fixed very easily.
>> and also interested in getting a
>> better separation of JAX-RS runtime classes if an other implementation
>> like Jersey is reachable by classloader.
>>
>
> I'm not sure yet how realistic this can be, having Jersey loaded by the
> same loader which loads CXF, and have it working.
>
> We can indeed, as suggested by Dan, replace all calls like
> MediaType.valueOf() (and similar) with direct calls to concrete
> implementation classes. This may be worth it on its own, it will be
> CXF's best effort.
>
> But we will be 'powerless' once the application code or filter does
> Response.ok() which will create a custom ResponseBuilder impl, or use
> some CacheControl utility, or ETag one, which depend on static factory
> methods...
>
> Cheers, Sergey
>
>> Regards,
>> Stephan
>>
>>
>> -----Original Message-----
>> From: K Fung<kf...@gmail.com>
>> Reply-To: "users@cxf.apache.org"<us...@cxf.apache.org>
>> Date: Tue, 31 Jan 2012 18:07:05 +0100
>> To: "users@cxf.apache.org"<us...@cxf.apache.org>
>> Subject: Re: Jersey / CXF compatibility
>>
>>> Hi Sergey,
>>>
>>>>> By sending an explicit Accept header, this will block
>>>>> HttpUrlConnection
>>>>> from sending an invalid header to CXF. CXF was (correctly!) spitting
>>>>> out a
>>>>> 406 when the HttpUrlConnection was sending:
>>>>>
>>>>> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>>>>
>>>> is it a single '*' which causes CXF to reply with 406 ? May be CXF
>>>> should be more tolerable to single "*" which I guess is a legacy
>>>> wildcard value...I think it should.
>>>>
>>>
>>> Yes, it's throwing the IllegalArgumentException on the single star
>>> (it's expecting<something>/<something>). CXF could be more lenient on
>>> that.
>>>
>>> -kl
>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Jersey / CXF compatibility
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Stephan
On 01/02/12 06:45, Klevenz, Stephan wrote:
> Hi,
>
> would it make sense to open a Jira issue?
>
> I'm interested in getting this fixed
sure, this can be fixed very easily.
> and also interested in getting a
> better separation of JAX-RS runtime classes if an other implementation
> like Jersey is reachable by classloader.
>
I'm not sure yet how realistic this can be, having Jersey loaded by the
same loader which loads CXF, and have it working.
We can indeed, as suggested by Dan, replace all calls like
MediaType.valueOf() (and similar) with direct calls to concrete
implementation classes. This may be worth it on its own, it will be
CXF's best effort.
But we will be 'powerless' once the application code or filter does
Response.ok() which will create a custom ResponseBuilder impl, or use
some CacheControl utility, or ETag one, which depend on static factory
methods...
Cheers, Sergey
> Regards,
> Stephan
>
>
> -----Original Message-----
> From: K Fung<kf...@gmail.com>
> Reply-To: "users@cxf.apache.org"<us...@cxf.apache.org>
> Date: Tue, 31 Jan 2012 18:07:05 +0100
> To: "users@cxf.apache.org"<us...@cxf.apache.org>
> Subject: Re: Jersey / CXF compatibility
>
>> Hi Sergey,
>>
>>>> By sending an explicit Accept header, this will block HttpUrlConnection
>>>> from sending an invalid header to CXF. CXF was (correctly!) spitting
>>>> out a
>>>> 406 when the HttpUrlConnection was sending:
>>>>
>>>> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>>>
>>> is it a single '*' which causes CXF to reply with 406 ? May be CXF
>>> should be more tolerable to single "*" which I guess is a legacy
>>> wildcard value...I think it should.
>>>
>>
>> Yes, it's throwing the IllegalArgumentException on the single star
>> (it's expecting<something>/<something>). CXF could be more lenient on
>> that.
>>
>> -kl
>
Re: Jersey / CXF compatibility
Posted by "Klevenz, Stephan" <st...@sap.com>.
Hi,
would it make sense to open a Jira issue?
I'm interested in getting this fixed and also interested in getting a
better separation of JAX-RS runtime classes if an other implementation
like Jersey is reachable by classloader.
Regards,
Stephan
-----Original Message-----
From: K Fung <kf...@gmail.com>
Reply-To: "users@cxf.apache.org" <us...@cxf.apache.org>
Date: Tue, 31 Jan 2012 18:07:05 +0100
To: "users@cxf.apache.org" <us...@cxf.apache.org>
Subject: Re: Jersey / CXF compatibility
>Hi Sergey,
>
>>> By sending an explicit Accept header, this will block HttpUrlConnection
>>> from sending an invalid header to CXF. CXF was (correctly!) spitting
>>>out a
>>> 406 when the HttpUrlConnection was sending:
>>>
>>> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>>
>> is it a single '*' which causes CXF to reply with 406 ? May be CXF
>>should be more tolerable to single "*" which I guess is a legacy
>>wildcard value...I think it should.
>>
>
>Yes, it's throwing the IllegalArgumentException on the single star
>(it's expecting <something>/<something>). CXF could be more lenient on
>that.
>
>-kl
Re: Jersey / CXF compatibility
Posted by K Fung <kf...@gmail.com>.
Hi Sergey,
>> By sending an explicit Accept header, this will block HttpUrlConnection
>> from sending an invalid header to CXF. CXF was (correctly!) spitting out a
>> 406 when the HttpUrlConnection was sending:
>>
>> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>
> is it a single '*' which causes CXF to reply with 406 ? May be CXF should be more tolerable to single "*" which I guess is a legacy wildcard value...I think it should.
>
Yes, it's throwing the IllegalArgumentException on the single star
(it's expecting <something>/<something>). CXF could be more lenient on
that.
-kl
Re: Jersey / CXF compatibility
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi KL
On 31/01/12 02:26, K Fung wrote:
> Hi Stephan,
>
> (this e-mail is based off revision 14 of your source code, da71e69dfdcd)
>
> I have some good news and bad news. The good news is that I have a
> workaround that can make all of your parameterized tests pass. The bad news
> is that CXF and Jersey binaries are indeed getting mixed up when you run
> these tests.
>
> For the workaround, In JerseyTestClient, change your getResource method so
> that it looks like the following:
>
> public String getResource(URI uri) {
> JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
> WebResource webResource = new Client().resource(uri);
> return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
> }
>
> By sending an explicit Accept header, this will block HttpUrlConnection
> from sending an invalid header to CXF. CXF was (correctly!) spitting out a
> 406 when the HttpUrlConnection was sending:
>
> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
is it a single '*' which causes CXF to reply with 406 ? May be CXF
should be more tolerable to single "*" which I guess is a legacy
wildcard value...I think it should.
thanks for the analysis
Sergey
>
> (I'm not sure why HttpUrlConnection was sending this invalid accept. I
> didn't drill down into this too deeply. Perhaps the JDK team can tell us
> why).
>
> This would obviously imply that your test clients should always be sending
> an Accept header but this shouldn't be too much of a burden for you (and it
> seems you've already done it in the latest version of CxfTestClient).
>
> Nevertheless, as I feared, CXF and Jersey code are getting mixed up on the
> server-side. You can see this in the stack:
>
> 012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
> java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:77)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:50)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:136)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:88)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:126)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:112)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at
> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at
> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:52)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.text.ParseException: Expected separator '/' instead of ';'
> at
> com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:112)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTypeProvider.java:88)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:75)
> ... 37 more
>
> Regards,
> kl
>
> P.S. I assume you deliberately wanted a Jersey client to connect to a CXF
> server.
>
Re: Jersey / CXF compatibility
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, January 30, 2012 6:33:45 PM K Fung wrote:
> Sorry Johan, I'm not sure what you're asking :(
>
> - Can we do anything on the CXF server side to make JSR311 chose CXF?
In this particular case, the JAX-RS MediaType class has a static singleton
delegate. Whichever impl is detected first "wins".
A solution on our side could be every place we call MediaType.valueOf(...) we
replace that with a direct call into our own class. That would make sure we
get the right version.
Dan
> - Can we ask Sun/Oracle to see if they can do anything about the invalid
> MediaType being sent in the HttpUrlConnection
> - ...something else?
>
> -kl
>
> On Mon, Jan 30, 2012 at 6:29 PM, Johan Edstrom <se...@gmail.com> wrote:
> > Even more interestingly - how do we fix it? :)
> >
> > On Jan 30, 2012, at 7:26 PM, K Fung wrote:
> > > Hi Stephan,
> > >
> > > (this e-mail is based off revision 14 of your source code, da71e69dfdcd)
> > >
> > > I have some good news and bad news. The good news is that I have a
> > > workaround that can make all of your parameterized tests pass. The bad
> >
> > news
> >
> > > is that CXF and Jersey binaries are indeed getting mixed up when you run
> > > these tests.
> > >
> > > For the workaround, In JerseyTestClient, change your getResource method
> >
> > so
> >
> > > that it looks like the following:
> > > public String getResource(URI uri) {
> > >
> > > JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
> > > WebResource webResource = new Client().resource(uri);
> > > return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
> > >
> > > }
> > >
> > > By sending an explicit Accept header, this will block HttpUrlConnection
> > > from sending an invalid header to CXF. CXF was (correctly!) spitting out
> >
> > a
> >
> > > 406 when the HttpUrlConnection was sending:
> > >
> > > text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> > >
> > > (I'm not sure why HttpUrlConnection was sending this invalid accept. I
> > > didn't drill down into this too deeply. Perhaps the JDK team can tell us
> > > why).
> > >
> > > This would obviously imply that your test clients should always be
> >
> > sending
> >
> > > an Accept header but this shouldn't be too much of a burden for you (and
> >
> > it
> >
> > > seems you've already done it in the latest version of CxfTestClient).
> > >
> > > Nevertheless, as I feared, CXF and Jersey code are getting mixed up on
> >
> > the
> >
> > > server-side. You can see this in the stack:
> > >
> > > 012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
> > > org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> > > interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
> > > java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
> > > at
> >
> > com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
> > aTypeProvider.java:77)>
> > > at
> >
> > com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
> > aTypeProvider.java:50)>
> > > at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
> > > at
> >
> > org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097
> > )
> >
> > > at
> >
> > org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
> >
> > > at
> >
> > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSIn
> > Interceptor.java:136)>
> > > at
> >
> > org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInI
> > nterceptor.java:88)>
> > > at
> >
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
> > in.java:263)>
> > > at
> >
> > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> > Observer.java:123)>
> > > at
> >
> > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPD
> > estination.java:206)>
> > > at
> >
> > org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servl
> > etController.java:213)>
> > > at
> >
> > org.apache.cxf.transport.servlet.ServletController.invoke(ServletControlle
> > r.java:154)>
> > > at
> >
> > org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringSe
> > rvlet.java:126)>
> > > at
> >
> > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abstrac
> > tHTTPServlet.java:184)>
> > > at
> >
> > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPSer
> > vlet.java:112)>
> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> > > at
> >
> > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPS
> > ervlet.java:163)>
> > > at
> > > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
> > > at
> >
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
> >
> > > at
> >
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.ja
> > va:225)>
> > > at
> >
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.ja
> > va:940)>
> > > at
> > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406
> > > )
> > > at
> >
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.jav
> > a:186)>
> > > at
> >
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.jav
> > a:874)>
> > > at
> >
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:1
> > 17)>
> > > at
> >
> > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollectio
> > n.java:149)>
> > > at
> >
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java
> > :110)>
> > > at org.eclipse.jetty.server.Server.handle(Server.java:349)
> > > at
> >
> > org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:
> > 441)>
> > > at
> >
> > org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(Http
> > Connection.java:919)>
> > > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> > > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> > > at
> >
> > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.ja
> > va:52)>
> > > at
> >
> > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoin
> > t.java:586)>
> > > at
> >
> > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint
> > .java:44)>
> > > at
> >
> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.jav
> > a:598)>
> > > at
> >
> > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java
> > :533)>
> > > at java.lang.Thread.run(Thread.java:662)
> > > Caused by: java.text.ParseException: Expected separator '/' instead of
> >
> > ';'
> >
> > > at
> >
> > com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeade
> > rReader.java:112)>
> > > at
> >
> > com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTy
> > peProvider.java:88)>
> > > at
> >
> > com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
> > aTypeProvider.java:75)>
> > > ... 37 more
> > >
> > > Regards,
> > > kl
> > >
> > > P.S. I assume you deliberately wanted a Jersey client to connect to a
> > > CXF
> > > server.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Jersey / CXF compatibility
Posted by K Fung <kf...@gmail.com>.
Sorry Johan, I'm not sure what you're asking :(
- Can we do anything on the CXF server side to make JSR311 chose CXF?
- Can we ask Sun/Oracle to see if they can do anything about the invalid
MediaType being sent in the HttpUrlConnection
- ...something else?
-kl
On Mon, Jan 30, 2012 at 6:29 PM, Johan Edstrom <se...@gmail.com> wrote:
> Even more interestingly - how do we fix it? :)
>
> On Jan 30, 2012, at 7:26 PM, K Fung wrote:
>
> > Hi Stephan,
> >
> > (this e-mail is based off revision 14 of your source code, da71e69dfdcd)
> >
> > I have some good news and bad news. The good news is that I have a
> > workaround that can make all of your parameterized tests pass. The bad
> news
> > is that CXF and Jersey binaries are indeed getting mixed up when you run
> > these tests.
> >
> > For the workaround, In JerseyTestClient, change your getResource method
> so
> > that it looks like the following:
> >
> > public String getResource(URI uri) {
> > JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
> > WebResource webResource = new Client().resource(uri);
> > return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
> > }
> >
> > By sending an explicit Accept header, this will block HttpUrlConnection
> > from sending an invalid header to CXF. CXF was (correctly!) spitting out
> a
> > 406 when the HttpUrlConnection was sending:
> >
> > text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> >
> > (I'm not sure why HttpUrlConnection was sending this invalid accept. I
> > didn't drill down into this too deeply. Perhaps the JDK team can tell us
> > why).
> >
> > This would obviously imply that your test clients should always be
> sending
> > an Accept header but this shouldn't be too much of a burden for you (and
> it
> > seems you've already done it in the latest version of CxfTestClient).
> >
> > Nevertheless, as I feared, CXF and Jersey code are getting mixed up on
> the
> > server-side. You can see this in the stack:
> >
> > 012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
> > org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> > interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
> > java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
> > at
> >
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:77)
> > at
> >
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:50)
> > at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
> > at
> >
> org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097)
> > at
> >
> org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
> > at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:136)
> > at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:88)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> > at
> >
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> > at
> >
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206)
> > at
> >
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
> > at
> >
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
> > at
> >
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:126)
> > at
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
> > at
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:112)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> > at
> >
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163)
> > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
> > at
> >
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
> > at
> >
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)
> > at
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
> > at
> >
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)
> > at
> >
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> > at
> >
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
> > at
> >
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> > at org.eclipse.jetty.server.Server.handle(Server.java:349)
> > at
> >
> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> > at
> >
> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
> > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> > at
> >
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:52)
> > at
> >
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> > at
> >
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> > at
> >
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> > at
> >
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> > at java.lang.Thread.run(Thread.java:662)
> > Caused by: java.text.ParseException: Expected separator '/' instead of
> ';'
> > at
> >
> com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:112)
> > at
> >
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTypeProvider.java:88)
> > at
> >
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:75)
> > ... 37 more
> >
> > Regards,
> > kl
> >
> > P.S. I assume you deliberately wanted a Jersey client to connect to a CXF
> > server.
>
>
Re: Jersey / CXF compatibility
Posted by Johan Edstrom <se...@gmail.com>.
Even more interestingly - how do we fix it? :)
On Jan 30, 2012, at 7:26 PM, K Fung wrote:
> Hi Stephan,
>
> (this e-mail is based off revision 14 of your source code, da71e69dfdcd)
>
> I have some good news and bad news. The good news is that I have a
> workaround that can make all of your parameterized tests pass. The bad news
> is that CXF and Jersey binaries are indeed getting mixed up when you run
> these tests.
>
> For the workaround, In JerseyTestClient, change your getResource method so
> that it looks like the following:
>
> public String getResource(URI uri) {
> JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
> WebResource webResource = new Client().resource(uri);
> return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
> }
>
> By sending an explicit Accept header, this will block HttpUrlConnection
> from sending an invalid header to CXF. CXF was (correctly!) spitting out a
> 406 when the HttpUrlConnection was sending:
>
> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>
> (I'm not sure why HttpUrlConnection was sending this invalid accept. I
> didn't drill down into this too deeply. Perhaps the JDK team can tell us
> why).
>
> This would obviously imply that your test clients should always be sending
> an Accept header but this shouldn't be too much of a burden for you (and it
> seems you've already done it in the latest version of CxfTestClient).
>
> Nevertheless, as I feared, CXF and Jersey code are getting mixed up on the
> server-side. You can see this in the stack:
>
> 012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
> java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:77)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:50)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:136)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:88)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:126)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:112)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at
> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at
> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:52)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.text.ParseException: Expected separator '/' instead of ';'
> at
> com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:112)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTypeProvider.java:88)
> at
> com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:75)
> ... 37 more
>
> Regards,
> kl
>
> P.S. I assume you deliberately wanted a Jersey client to connect to a CXF
> server.
Re: Jersey / CXF compatibility
Posted by "Klevenz, Stephan" <st...@sap.com>.
Hi Kl,
Thanks for this detailed analysis. For my example project I decided to get
out Jersey just to avoid side effects and for making progress with my
original task which is CXF support for odata4j.
Usually there is no deploy scenario using CXF and Jersey at the same time.
With that it is not a show stopper.
For mid or longterm it would anyhow nice to get both implementations
running at the same time. odata4j has a huge test suite (several hundred
test cases) and it would be useful to mix up Jersey and CXF client and
server in any combination.
Regards,
Stephan
-----Original Message-----
From: K Fung <kf...@gmail.com>
Reply-To: "users@cxf.apache.org" <us...@cxf.apache.org>
Date: Tue, 31 Jan 2012 03:26:57 +0100
To: "users@cxf.apache.org" <us...@cxf.apache.org>
Subject: Re: Jersey / CXF compatibility
>Hi Stephan,
>
>(this e-mail is based off revision 14 of your source code, da71e69dfdcd)
>
>I have some good news and bad news. The good news is that I have a
>workaround that can make all of your parameterized tests pass. The bad
>news
>is that CXF and Jersey binaries are indeed getting mixed up when you run
>these tests.
>
>For the workaround, In JerseyTestClient, change your getResource method so
>that it looks like the following:
>
> public String getResource(URI uri) {
> JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
> WebResource webResource = new Client().resource(uri);
> return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
> }
>
>By sending an explicit Accept header, this will block HttpUrlConnection
>from sending an invalid header to CXF. CXF was (correctly!) spitting out a
>406 when the HttpUrlConnection was sending:
>
>text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
>
>(I'm not sure why HttpUrlConnection was sending this invalid accept. I
>didn't drill down into this too deeply. Perhaps the JDK team can tell us
>why).
>
>This would obviously imply that your test clients should always be sending
>an Accept header but this shouldn't be too much of a burden for you (and
>it
>seems you've already done it in the latest version of CxfTestClient).
>
>Nevertheless, as I feared, CXF and Jersey code are getting mixed up on the
>server-side. You can see this in the stack:
>
>012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
>org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
>interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
>java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
>at
>com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
>aTypeProvider.java:77)
> at
>com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
>aTypeProvider.java:50)
>at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
> at
>org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097
>)
>at
>org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
> at
>org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSIn
>Interceptor.java:136)
>at
>org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInI
>nterceptor.java:88)
> at
>org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
>in.java:263)
>at
>org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
>Observer.java:123)
> at
>org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPD
>estination.java:206)
>at
>org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servl
>etController.java:213)
> at
>org.apache.cxf.transport.servlet.ServletController.invoke(ServletControlle
>r.java:154)
>at
>org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringSe
>rvlet.java:126)
> at
>org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(Abstrac
>tHTTPServlet.java:184)
>at
>org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPSer
>vlet.java:112)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>at
>org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPS
>ervlet.java:163)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
>at
>org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
> at
>org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.ja
>va:225)
>at
>org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.ja
>va:940)
> at
>org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
>at
>org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.jav
>a:186)
> at
>org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.jav
>a:874)
>at
>org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:1
>17)
> at
>org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollectio
>n.java:149)
>at
>org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java
>:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
>at
>org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:
>441)
> at
>org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(Http
>Connection.java:919)
>at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
>at
>org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.ja
>va:52)
> at
>org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoin
>t.java:586)
>at
>org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint
>.java:44)
> at
>org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.jav
>a:598)
>at
>org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java
>:533)
> at java.lang.Thread.run(Thread.java:662)
>Caused by: java.text.ParseException: Expected separator '/' instead of ';'
>at
>com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeade
>rReader.java:112)
> at
>com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTy
>peProvider.java:88)
>at
>com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(Medi
>aTypeProvider.java:75)
> ... 37 more
>
>Regards,
>kl
>
>P.S. I assume you deliberately wanted a Jersey client to connect to a CXF
>server.
Re: Jersey / CXF compatibility
Posted by K Fung <kf...@gmail.com>.
Hi Stephan,
(this e-mail is based off revision 14 of your source code, da71e69dfdcd)
I have some good news and bad news. The good news is that I have a
workaround that can make all of your parameterized tests pass. The bad news
is that CXF and Jersey binaries are indeed getting mixed up when you run
these tests.
For the workaround, In JerseyTestClient, change your getResource method so
that it looks like the following:
public String getResource(URI uri) {
JerseyTestClient.LOGGER.debug("getResource(), uri = " + uri);
WebResource webResource = new Client().resource(uri);
return webResource.accept(MediaType.WILDCARD_TYPE).get(String.class);
}
By sending an explicit Accept header, this will block HttpUrlConnection
from sending an invalid header to CXF. CXF was (correctly!) spitting out a
406 when the HttpUrlConnection was sending:
text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
(I'm not sure why HttpUrlConnection was sending this invalid accept. I
didn't drill down into this too deeply. Perhaps the JDK team can tell us
why).
This would obviously imply that your test clients should always be sending
an Accept header but this shouldn't be too much of a burden for you (and it
seems you've already done it in the latest version of CxfTestClient).
Nevertheless, as I feared, CXF and Jersey code are getting mixed up on the
server-side. You can see this in the stack:
012-01-30 17:40:18,785 DEBUG [qtp525030058-29]
org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1ff61bcf
java.lang.IllegalArgumentException: Error parsing media type '*; q=.2'
at
com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:77)
at
com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:50)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.parseMediaTypes(JAXRSUtils.java:1097)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.sortMediaTypes(JAXRSUtils.java:1189)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:136)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:206)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:126)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:184)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:163)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:940)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:874)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:52)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.text.ParseException: Expected separator '/' instead of ';'
at
com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:112)
at
com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTypeProvider.java:88)
at
com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:75)
... 37 more
Regards,
kl
P.S. I assume you deliberately wanted a Jersey client to connect to a CXF
server.
RE: Jersey / CXF compatibility
Posted by "Klevenz, Stephan" <st...@sap.com>.
Hi kl,
The problem occurs at [1] which is a OData REST library originally implemented using Jersey. Right now we are adapting the project to support CXF alternatively. At [2] I have created an example test suite to isolate compatibility issues and this can be used to reproduce the problem.
@Sergey: If I run CXF first, then the suite is working and don't throws errors.
Maybe I change the test strategy to run CXF and Jersey isolated from each other. Actually this is not a real scenario and it was just convenient to run both together.
Regards,
Stephan
[1] http://code.google.com/p/odata4j/
[2] https://bitbucket.org/sklevenz/example/overview
From: K Fung [mailto:kfung4cxf@gmail.com]
Sent: Sonntag, 29. Januar 2012 01:50
To: users@cxf.apache.org
Cc: Klevenz, Stephan
Subject: Re: Jersey / CXF compatibility
Hi Stephan,
This just pure speculation on my part but I don't think the jsr311-api-<version>.jar supports more than 1 JAX-RS runtime in the same process. Inside jsr311, there is some logic that instantiates objects that implement the JAX-RS interfaces. The WebApplicationException you're seeing may be due to a JAX-RS object from Jersey's namespace being passed to CXF (which would like be incompatible). If this is indeed he issue, you may be able get around this by separating CXF and Jersey so that they're in their own OSGI bundles (each with its own copy of JSR311). However, you'll likely want to confirm this is the cause first before going down this avenue.
Do you have a Maven project that illustrates this problem? Also what version of CXF are you using?
Regards,
kl
On Sat, Jan 28, 2012 at 5:33 AM, Klevenz, Stephan <st...@sap.com>> wrote:
Hi,
I'm having a strange problem while executing a compatibility tests suite for Jersey and CXF. All tests running twice as parameterized unit tests where the first run uses Jersey and the second run is with CXF. Unfortunately CXF is throwing an WebApplicationException as you can see from the trace below. If I disable the Jersey run then CXF does not show errors. It seems that CXF struggle with side effects caused by Jersey. Question is how can this be evaluated. The trace is the only hint that I have.
Thanks in advance.
Regards,
Stephan
2012-01-28 14<tel:2012-01-28%2014>:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ******************************************************************
2012-01-28 14<tel:2012-01-28%2014>:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: Activated Server Type = CXF
2012-01-28 14<tel:2012-01-28%2014>:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ******************************************************************
2012-01-28 14<tel:2012-01-28%2014>:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ---------------------------------------------------------------
2012-01-28 14<tel:2012-01-28%2014>:21:17,743 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: test class: org.example.test.compatibility.SimpleCompatibilityTest
2012-01-28 14<tel:2012-01-28%2014>:21:17,744 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: test method: testSimple
2012-01-28 14<tel:2012-01-28%2014>:21:17,744 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: ---------------------------------------------------------------
2012-01-28 14<tel:2012-01-28%2014>:21:17,764 INFO [main] org.apache.cxf.endpoint.ServerImpl: Setting the server's publish address to be /
2012-01-28 14<tel:2012-01-28%2014>:21:17,765 INFO [main] org.apache.cxf.jaxrs.provider.ProviderFactory: Problem with setting the default provider org.apache.cxf.jaxrs.provider.JSONProviderorg/codehaus/jettison/mapped/TypeConverter
2012-01-28 14<tel:2012-01-28%2014>:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl: Server is starting.
2012-01-28 14<tel:2012-01-28%2014>:21:17,766 DEBUG [main] org.apache.cxf.transport.servlet.ServletDestination: registering incoming observer: org.apache.cxf.transport.ChainInitiationObserver@3c095f75<ma...@3c095f75>
2012-01-28 14<tel:2012-01-28%2014>:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl: register the server to serverRegistry
2012-01-28 14<tel:2012-01-28%2014>:21:17,775 INFO [main] org.example.test.compatibility.SimpleCompatibilityTest: uri: http://localhost:8810/test/test.svc/root/simple
2012-01-28<http://localhost:8810/test/test.svc/root/simple%0d%0a2012-01-28> 14:21:17,775 DEBUG [main] org.example.test.compatibility.jersey.JerseyTestClient: getResource(), uri = http://localhost:8810/test/test.svc/root/simple
2012-01-28<http://localhost:8810/test/test.svc/root/simple%0d%0a2012-01-28> 14:21:17,952 DEBUG [qtp1692156427-42] org.apache.cxf.transport.servlet.ServletController: Service http request on thread: Thread[qtp1692156427-42,5,main]
2012-01-28 14<tel:2012-01-28%2014>:21:17,952 DEBUG [qtp1692156427-42] org.apache.cxf.transport.http.AbstractHTTPDestination: Create a new message for processing
2012-01-28 14<tel:2012-01-28%2014>:21:17,959 DEBUG [qtp1692156427-42] org.apache.cxf.transport.http.Headers: Request Headers: {Accept=[text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2], Cache-Control=[no-cache], connection=[keep-alive], Content-Type=[null], Host=[localhost:8810], Pragma=[no-cache], User-Agent=[Java/1.6.0_29]}
2012-01-28 14<tel:2012-01-28%2014>:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.ServiceInvokerInterceptor@7bc2f501<ma...@7bc2f501> to phase invoke
2012-01-28 14<tel:2012-01-28%2014>:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.OutgoingChainInterceptor@1d286180<ma...@1d286180> to phase post-invoke
2012-01-28 14<tel:2012-01-28%2014>:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974<tel:46192974<mailto:org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974%3ctel:46192974>> to phase pre-logical
2012-01-28 14<tel:2012-01-28%2014>:21:17,976 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0<ma...@1df0a2a0> to phase unmarshal
2012-01-28 14<tel:2012-01-28%2014>:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e<ma...@653cca0e> to phase pre-stream
2012-01-28 14<tel:2012-01-28%2014>:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Chain org.apache.cxf.phase.PhaseInterceptorChain@24c98b07<ma...@24c98b07> was created. Current flow:
pre-stream [CertConstraintsInterceptor]
unmarshal [JAXRSInInterceptor]
pre-logical [OneWayProcessorInterceptor]
invoke [ServiceInvokerInterceptor]
post-invoke [OutgoingChainInterceptor]
2012-01-28 14<tel:2012-01-28%2014>:21:17,977 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on interceptor org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e<ma...@653cca0e>
2012-01-28 14<tel:2012-01-28%2014>:21:17,978 DEBUG [qtp1692156427-42] org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0<ma...@1df0a2a0>
2012-01-28 14<tel:2012-01-28%2014>:21:17,983 WARN [qtp1692156427-42] org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: WebApplicationException has been caught : no cause is available
2012-01-28 14<tel:2012-01-28%2014>:21:17,984 DEBUG [qtp1692156427-42] org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: no cause is available
javax.ws.rs.WebApplicationException
at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:139)
at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:89)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:127)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:115)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:349)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:680)
2
Re: Jersey / CXF compatibility
Posted by Sergey Beryozkin <sb...@gmail.com>.
Forgot to mention,
The exception occurs after a
JAXRSUtils.sortMediaTypes(acceptTypes);
call which would internally call
MediaType.valueOf(stringValue)
Sergey
On 29/01/12 17:56, Sergey Beryozkin wrote:
> Hi
>
>
> On 29/01/12 00:50, K Fung wrote:
>> Hi Stephan,
>>
>> This just pure speculation on my part but I don't think
>> the jsr311-api-<version>.jar supports more than 1 JAX-RS runtime in the
>> same process. Inside jsr311, there is some logic that instantiates
>> objects
>> that implement the JAX-RS interfaces. The WebApplicationException you're
>> seeing may be due to a JAX-RS object from Jersey's namespace being passed
>> to CXF (which would like be incompatible). If this is indeed he issue,
>> you
>> may be able get around this by separating CXF and Jersey so that
>> they're in
>> their own OSGI bundles (each with its own copy of JSR311). However,
>> you'll
>> likely want to confirm this is the cause first before going down this
>> avenue.
>>
>> Do you have a Maven project that illustrates this problem? Also what
>> version of CXF are you using?
>
> It's probably 2.5.3-SNAPSHOT,
>
> Indeed, looks like the problem is to do with the fact that the
> implementation classes loaded from 2 different implementations interfere.
>
> Interesting, would running CXF tests first would do the same effect on
> the Jersey tests run afterwards ?
>
> Cheers, Sergey
>
>>
>> Regards,
>> kl
>>
>> On Sat, Jan 28, 2012 at 5:33 AM, Klevenz, Stephan
>> <st...@sap.com>wrote:
>>
>>> Hi,
>>>
>>> I'm having a strange problem while executing a compatibility tests suite
>>> for Jersey and CXF. All tests running twice as parameterized unit tests
>>> where the first run uses Jersey and the second run is with CXF.
>>> Unfortunately CXF is throwing an WebApplicationException as you can see
>>> from the trace below. If I disable the Jersey run then CXF does not show
>>> errors. It seems that CXF struggle with side effects caused by Jersey.
>>> Question is how can this be evaluated. The trace is the only hint that I
>>> have.
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Stephan
>>>
>>>
>>>
>>>
>>> 2012-01-28 14:21:17,743 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest:
>>> ******************************************************************
>>> 2012-01-28 14:21:17,743 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest: Activated Server
>>> Type = CXF
>>> 2012-01-28 14:21:17,743 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest:
>>> ******************************************************************
>>> 2012-01-28 14:21:17,743 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest:
>>> ---------------------------------------------------------------
>>> 2012-01-28 14:21:17,743 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest: test class:
>>> org.example.test.compatibility.SimpleCompatibilityTest
>>> 2012-01-28 14:21:17,744 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest: test method:
>>> testSimple
>>> 2012-01-28 14:21:17,744 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest:
>>> ---------------------------------------------------------------
>>> 2012-01-28 14:21:17,764 INFO [main] org.apache.cxf.endpoint.ServerImpl:
>>> Setting the server's publish address to be /
>>> 2012-01-28 14:21:17,765 INFO [main]
>>> org.apache.cxf.jaxrs.provider.ProviderFactory: Problem with setting the
>>> default provider
>>> org.apache.cxf.jaxrs.provider.JSONProviderorg/codehaus/jettison/mapped/TypeConverter
>>>
>>> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
>>> Server is starting.
>>> 2012-01-28 14:21:17,766 DEBUG [main]
>>> org.apache.cxf.transport.servlet.ServletDestination: registering
>>> incoming
>>> observer: org.apache.cxf.transport.ChainInitiationObserver@3c095f75
>>> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
>>> register the server to serverRegistry
>>> 2012-01-28 14:21:17,775 INFO [main]
>>> org.example.test.compatibility.SimpleCompatibilityTest: uri:
>>> http://localhost:8810/test/test.svc/root/simple
>>> 2012-01-28 14:21:17,775 DEBUG [main]
>>> org.example.test.compatibility.jersey.JerseyTestClient:
>>> getResource(), uri
>>> = http://localhost:8810/test/test.svc/root/simple
>>> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.transport.servlet.ServletController: Service http
>>> request on
>>> thread: Thread[qtp1692156427-42,5,main]
>>> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.transport.http.AbstractHTTPDestination: Create a new
>>> message
>>> for processing
>>> 2012-01-28 14:21:17,959 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.transport.http.Headers: Request Headers:
>>> {Accept=[text/html,
>>> image/gif, image/jpeg, *; q=.2, */*; q=.2], Cache-Control=[no-cache],
>>> connection=[keep-alive], Content-Type=[null], Host=[localhost:8810],
>>> Pragma=[no-cache], User-Agent=[Java/1.6.0_29]}
>>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>>> org.apache.cxf.interceptor.ServiceInvokerInterceptor@7bc2f501 to phase
>>> invoke
>>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>>> org.apache.cxf.interceptor.OutgoingChainInterceptor@1d286180 to phase
>>> post-invoke
>>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>>> org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974<tel:46192974>
>>>
>>> to phase pre-logical
>>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0 to phase
>>> unmarshal
>>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>>> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e to
>>> phase pre-stream
>>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Chain
>>> org.apache.cxf.phase.PhaseInterceptorChain@24c98b07 was created. Current
>>> flow:
>>> pre-stream [CertConstraintsInterceptor]
>>> unmarshal [JAXRSInInterceptor]
>>> pre-logical [OneWayProcessorInterceptor]
>>> invoke [ServiceInvokerInterceptor]
>>> post-invoke [OutgoingChainInterceptor]
>>>
>>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
>>> interceptor
>>> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e
>>> 2012-01-28 14:21:17,978 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
>>> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0
>>> 2012-01-28 14:21:17,983 WARN [qtp1692156427-42]
>>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper:
>>> WebApplicationException has been caught : no cause is available
>>> 2012-01-28 14:21:17,984 DEBUG [qtp1692156427-42]
>>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: no cause is
>>> available
>>> javax.ws.rs.WebApplicationException
>>> at
>>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:139)
>>>
>>> at
>>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:89)
>>>
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
>>>
>>> at
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
>>>
>>> at
>>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
>>>
>>> at
>>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
>>>
>>> at
>>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
>>>
>>> at
>>> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:127)
>>>
>>> at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
>>>
>>> at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:115)
>>>
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>>> at
>>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
>>>
>>> at
>>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
>>> at
>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
>>>
>>> at
>>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
>>>
>>> at
>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
>>>
>>> at
>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
>>>
>>> at
>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
>>>
>>> at
>>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
>>>
>>> at
>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
>>>
>>> at
>>> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
>>>
>>> at
>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
>>>
>>> at org.eclipse.jetty.server.Server.handle(Server.java:349)
>>> at
>>> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
>>>
>>> at
>>> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
>>>
>>> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
>>> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
>>> at
>>> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
>>>
>>> at
>>> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
>>>
>>> at
>>> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
>>>
>>> at
>>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
>>>
>>> at
>>> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
>>>
>>> at java.lang.Thread.run(Thread.java:680)
>>> 2
>>>
>>
Re: Jersey / CXF compatibility
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 29/01/12 00:50, K Fung wrote:
> Hi Stephan,
>
> This just pure speculation on my part but I don't think
> the jsr311-api-<version>.jar supports more than 1 JAX-RS runtime in the
> same process. Inside jsr311, there is some logic that instantiates objects
> that implement the JAX-RS interfaces. The WebApplicationException you're
> seeing may be due to a JAX-RS object from Jersey's namespace being passed
> to CXF (which would like be incompatible). If this is indeed he issue, you
> may be able get around this by separating CXF and Jersey so that they're in
> their own OSGI bundles (each with its own copy of JSR311). However, you'll
> likely want to confirm this is the cause first before going down this
> avenue.
>
> Do you have a Maven project that illustrates this problem? Also what
> version of CXF are you using?
It's probably 2.5.3-SNAPSHOT,
Indeed, looks like the problem is to do with the fact that the
implementation classes loaded from 2 different implementations interfere.
Interesting, would running CXF tests first would do the same effect on
the Jersey tests run afterwards ?
Cheers, Sergey
>
> Regards,
> kl
>
> On Sat, Jan 28, 2012 at 5:33 AM, Klevenz, Stephan
> <st...@sap.com>wrote:
>
>> Hi,
>>
>> I'm having a strange problem while executing a compatibility tests suite
>> for Jersey and CXF. All tests running twice as parameterized unit tests
>> where the first run uses Jersey and the second run is with CXF.
>> Unfortunately CXF is throwing an WebApplicationException as you can see
>> from the trace below. If I disable the Jersey run then CXF does not show
>> errors. It seems that CXF struggle with side effects caused by Jersey.
>> Question is how can this be evaluated. The trace is the only hint that I
>> have.
>>
>> Thanks in advance.
>>
>> Regards,
>> Stephan
>>
>>
>>
>>
>> 2012-01-28 14:21:17,743 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest:
>> ******************************************************************
>> 2012-01-28 14:21:17,743 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest: Activated Server
>> Type = CXF
>> 2012-01-28 14:21:17,743 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest:
>> ******************************************************************
>> 2012-01-28 14:21:17,743 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest:
>> ---------------------------------------------------------------
>> 2012-01-28 14:21:17,743 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest: test class:
>> org.example.test.compatibility.SimpleCompatibilityTest
>> 2012-01-28 14:21:17,744 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest: test method:
>> testSimple
>> 2012-01-28 14:21:17,744 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest:
>> ---------------------------------------------------------------
>> 2012-01-28 14:21:17,764 INFO [main] org.apache.cxf.endpoint.ServerImpl:
>> Setting the server's publish address to be /
>> 2012-01-28 14:21:17,765 INFO [main]
>> org.apache.cxf.jaxrs.provider.ProviderFactory: Problem with setting the
>> default provider
>> org.apache.cxf.jaxrs.provider.JSONProviderorg/codehaus/jettison/mapped/TypeConverter
>> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
>> Server is starting.
>> 2012-01-28 14:21:17,766 DEBUG [main]
>> org.apache.cxf.transport.servlet.ServletDestination: registering incoming
>> observer: org.apache.cxf.transport.ChainInitiationObserver@3c095f75
>> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
>> register the server to serverRegistry
>> 2012-01-28 14:21:17,775 INFO [main]
>> org.example.test.compatibility.SimpleCompatibilityTest: uri:
>> http://localhost:8810/test/test.svc/root/simple
>> 2012-01-28 14:21:17,775 DEBUG [main]
>> org.example.test.compatibility.jersey.JerseyTestClient: getResource(), uri
>> = http://localhost:8810/test/test.svc/root/simple
>> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
>> org.apache.cxf.transport.servlet.ServletController: Service http request on
>> thread: Thread[qtp1692156427-42,5,main]
>> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
>> org.apache.cxf.transport.http.AbstractHTTPDestination: Create a new message
>> for processing
>> 2012-01-28 14:21:17,959 DEBUG [qtp1692156427-42]
>> org.apache.cxf.transport.http.Headers: Request Headers: {Accept=[text/html,
>> image/gif, image/jpeg, *; q=.2, */*; q=.2], Cache-Control=[no-cache],
>> connection=[keep-alive], Content-Type=[null], Host=[localhost:8810],
>> Pragma=[no-cache], User-Agent=[Java/1.6.0_29]}
>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor@7bc2f501 to phase
>> invoke
>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>> org.apache.cxf.interceptor.OutgoingChainInterceptor@1d286180 to phase
>> post-invoke
>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>> org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974<tel:46192974>
>> to phase pre-logical
>> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0 to phase
>> unmarshal
>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
>> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e to
>> phase pre-stream
>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Chain
>> org.apache.cxf.phase.PhaseInterceptorChain@24c98b07 was created. Current
>> flow:
>> pre-stream [CertConstraintsInterceptor]
>> unmarshal [JAXRSInInterceptor]
>> pre-logical [OneWayProcessorInterceptor]
>> invoke [ServiceInvokerInterceptor]
>> post-invoke [OutgoingChainInterceptor]
>>
>> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
>> interceptor
>> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e
>> 2012-01-28 14:21:17,978 DEBUG [qtp1692156427-42]
>> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
>> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0
>> 2012-01-28 14:21:17,983 WARN [qtp1692156427-42]
>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper:
>> WebApplicationException has been caught : no cause is available
>> 2012-01-28 14:21:17,984 DEBUG [qtp1692156427-42]
>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: no cause is
>> available
>> javax.ws.rs.WebApplicationException
>> at
>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:139)
>> at
>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:89)
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
>> at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
>> at
>> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
>> at
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
>> at
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
>> at
>> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:127)
>> at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
>> at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:115)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>> at
>> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
>> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
>> at
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
>> at
>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
>> at
>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
>> at
>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
>> at
>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
>> at
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
>> at
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
>> at
>> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
>> at
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
>> at org.eclipse.jetty.server.Server.handle(Server.java:349)
>> at
>> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
>> at
>> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
>> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
>> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
>> at
>> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
>> at
>> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
>> at
>> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
>> at
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
>> at
>> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
>> at java.lang.Thread.run(Thread.java:680)
>> 2
>>
>
Re: Jersey / CXF compatibility
Posted by K Fung <kf...@gmail.com>.
Hi Stephan,
This just pure speculation on my part but I don't think
the jsr311-api-<version>.jar supports more than 1 JAX-RS runtime in the
same process. Inside jsr311, there is some logic that instantiates objects
that implement the JAX-RS interfaces. The WebApplicationException you're
seeing may be due to a JAX-RS object from Jersey's namespace being passed
to CXF (which would like be incompatible). If this is indeed he issue, you
may be able get around this by separating CXF and Jersey so that they're in
their own OSGI bundles (each with its own copy of JSR311). However, you'll
likely want to confirm this is the cause first before going down this
avenue.
Do you have a Maven project that illustrates this problem? Also what
version of CXF are you using?
Regards,
kl
On Sat, Jan 28, 2012 at 5:33 AM, Klevenz, Stephan
<st...@sap.com>wrote:
> Hi,
>
> I'm having a strange problem while executing a compatibility tests suite
> for Jersey and CXF. All tests running twice as parameterized unit tests
> where the first run uses Jersey and the second run is with CXF.
> Unfortunately CXF is throwing an WebApplicationException as you can see
> from the trace below. If I disable the Jersey run then CXF does not show
> errors. It seems that CXF struggle with side effects caused by Jersey.
> Question is how can this be evaluated. The trace is the only hint that I
> have.
>
> Thanks in advance.
>
> Regards,
> Stephan
>
>
>
>
> 2012-01-28 14:21:17,743 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest:
> ******************************************************************
> 2012-01-28 14:21:17,743 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest: Activated Server
> Type = CXF
> 2012-01-28 14:21:17,743 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest:
> ******************************************************************
> 2012-01-28 14:21:17,743 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest:
> ---------------------------------------------------------------
> 2012-01-28 14:21:17,743 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest: test class:
> org.example.test.compatibility.SimpleCompatibilityTest
> 2012-01-28 14:21:17,744 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest: test method:
> testSimple
> 2012-01-28 14:21:17,744 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest:
> ---------------------------------------------------------------
> 2012-01-28 14:21:17,764 INFO [main] org.apache.cxf.endpoint.ServerImpl:
> Setting the server's publish address to be /
> 2012-01-28 14:21:17,765 INFO [main]
> org.apache.cxf.jaxrs.provider.ProviderFactory: Problem with setting the
> default provider
> org.apache.cxf.jaxrs.provider.JSONProviderorg/codehaus/jettison/mapped/TypeConverter
> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
> Server is starting.
> 2012-01-28 14:21:17,766 DEBUG [main]
> org.apache.cxf.transport.servlet.ServletDestination: registering incoming
> observer: org.apache.cxf.transport.ChainInitiationObserver@3c095f75
> 2012-01-28 14:21:17,766 DEBUG [main] org.apache.cxf.endpoint.ServerImpl:
> register the server to serverRegistry
> 2012-01-28 14:21:17,775 INFO [main]
> org.example.test.compatibility.SimpleCompatibilityTest: uri:
> http://localhost:8810/test/test.svc/root/simple
> 2012-01-28 14:21:17,775 DEBUG [main]
> org.example.test.compatibility.jersey.JerseyTestClient: getResource(), uri
> = http://localhost:8810/test/test.svc/root/simple
> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
> org.apache.cxf.transport.servlet.ServletController: Service http request on
> thread: Thread[qtp1692156427-42,5,main]
> 2012-01-28 14:21:17,952 DEBUG [qtp1692156427-42]
> org.apache.cxf.transport.http.AbstractHTTPDestination: Create a new message
> for processing
> 2012-01-28 14:21:17,959 DEBUG [qtp1692156427-42]
> org.apache.cxf.transport.http.Headers: Request Headers: {Accept=[text/html,
> image/gif, image/jpeg, *; q=.2, */*; q=.2], Cache-Control=[no-cache],
> connection=[keep-alive], Content-Type=[null], Host=[localhost:8810],
> Pragma=[no-cache], User-Agent=[Java/1.6.0_29]}
> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
> org.apache.cxf.interceptor.ServiceInvokerInterceptor@7bc2f501 to phase
> invoke
> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
> org.apache.cxf.interceptor.OutgoingChainInterceptor@1d286180 to phase
> post-invoke
> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
> org.apache.cxf.interceptor.OneWayProcessorInterceptor@46192974<tel:46192974>
> to phase pre-logical
> 2012-01-28 14:21:17,976 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0 to phase
> unmarshal
> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Adding interceptor
> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e to
> phase pre-stream
> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Chain
> org.apache.cxf.phase.PhaseInterceptorChain@24c98b07 was created. Current
> flow:
> pre-stream [CertConstraintsInterceptor]
> unmarshal [JAXRSInInterceptor]
> pre-logical [OneWayProcessorInterceptor]
> invoke [ServiceInvokerInterceptor]
> post-invoke [OutgoingChainInterceptor]
>
> 2012-01-28 14:21:17,977 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> interceptor
> org.apache.cxf.transport.https.CertConstraintsInterceptor@653cca0e
> 2012-01-28 14:21:17,978 DEBUG [qtp1692156427-42]
> org.apache.cxf.phase.PhaseInterceptorChain: Invoking handleMessage on
> interceptor org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@1df0a2a0
> 2012-01-28 14:21:17,983 WARN [qtp1692156427-42]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper:
> WebApplicationException has been caught : no cause is available
> 2012-01-28 14:21:17,984 DEBUG [qtp1692156427-42]
> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper: no cause is
> available
> javax.ws.rs.WebApplicationException
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:139)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:89)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:122)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:127)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:187)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:115)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:166)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at
> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at
> org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:680)
> 2
>