cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@gmail.com>
Subject Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Date Fri, 10 May 2013 18:33:41 GMT
The entire sample works now: 
https://github.com/gmazza/jersey-samples-on-cxf/commit/13168735076039ee364441c30d1dbdd6a06522a3

Thanks,
Glen

On 05/08/2013 07:04 AM, Sergey Beryozkin wrote:
> Glen, the last example does not work because the 3rd test expects the 
> exception message contain the name of exception class removed from CXF 
> 2.7.x, instead of CXF specific ClientWebApplicationException a JAX-RS 
> m10 ClientException is returned. Note, in the latest 2.0 API that will 
> become ProcessingException
>
> Cheers, Sergey
>
> On 07/05/13 22:46, Sergey Beryozkin wrote:
>> Hi Glen
>> On 07/05/13 12:47, Glen Mazza wrote:
>>> Hi Sergey, one out of three samples fixed:
>>>
>>> On 05/05/2013 02:46 PM, Sergey Beryozkin wrote:
>>>> Hi Glen
>>>>
>>>> On 04/05/13 02:18, Glen Mazza wrote:
>>>>> --------------------
>>>>> https-server-glassfish
>>>>> (http://people.apache.org/~gmazza/restexamples/https-server-glassfish):

>>>>>
>>>>>
>>>> It is related to the previous issue but the problem is coming from a
>>>> different 'direction'. In this case you 1.1 JAX-RS API loaded so what
>>>> happens is that CXF, when it tries to copy the 'foreign' Response,
>>>> invokes on 2.0 Response.getHeaders method which is not available in
>>>> 1.1 API,
>>>> See
>>>> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/Response.html

>>>>
>>>>
>>>>
>>>> It has a nearly deprecated getMetadata() method available from 1.1 API
>>>> and new getHeaders method.
>>>> I'm updating CXF to use an older method to have such cases supported.
>>>>
>>>
>>> This one works fine now on CXF 2.7.6-SNAPSHOT.
>>>
>> Cool,
>>
>>>
>>>>>
>>>>> -------------------
>>>>> jsonp example
>>>>> (http://people.apache.org/~gmazza/restexamples/jsonp.html):
>>>>> After deploying via "mvn clean compile exec:java", the last cURL
>>>>> statement in the above HTML:
>>>>>
>>>>> 2.7.5-SNAPSHOT returns this error:
>>>>> gmazza@gmazza-work:/media/work1/jersey-samples-on-cxf/jsonp$ curl
>>>>> -HAccept:application/x+javascript
>>>>> http://localhost:9998/jsonp/changes?_jsonp=myCallback
>>>>> myCallback(No message body writer has been found for response class
>>>>> LinkedList.)
>>>>
>>>> In CXF 2.7.5 the refactoring has been made which exposed some issues
>>>> with JSONP setups (I recall I had to do something similar in our
>>>> system tests), looks like in this case you have
>>>> https://github.com/gmazza/jersey-samples-on-cxf/blob/master/jsonp/src/main/java/com/sun/jersey/samples/jsonp/Main.java

>>>>
>>>>
>>>>
>>>>
>>>> JSONP in interceptors 'accepting' application/json, but it needs to
>>>> match "application/x+javascript", the actual value of HTTP Accept
>>>>
>>>
>>> No luck. I checked in the change to the Main method given above and
>>> tried with CXF 2.7.6-SNAPSHOT, but the same error occurs.
>>>
>>>
>>>>> 2.6.7 works:
>>>>> gmazza@gmazza-work:/media/work1/jersey-samples-on-cxf/jsonp$ curl
>>>>> -HAccept:application/x+javascript
>>>>> http://localhost:9998/jsonp/changes?_jsonp=myCallback
>>>>> myCallback([{"madeByAdmin":false,"linesChanged":2,"logMessage":"title
>>>>> \"User Guide\"
>>>>> updated"},{"madeByAdmin":true,"linesChanged":1,"logMessage":"fixed
>>>>> metadata"},{"madeByAdmin":false,"linesChanged":91,"logMessage":"added
>>>>> index"},{"madeByAdmin":false,"linesChanged":650,"logMessage":"\"Troubleshoothing\"

>>>>>
>>>>>
>>>>>
>>>>> chapter"},{"madeByAdmin":false,"linesChanged":1,"logMessage":"fixing
>>>>> typo"}]);gmazza@gmazza-work:/media/work1/jersey-samples-on-cxf/jsonp$
>>>>> -------------------
>>
>> Ok, I've looked into it closer. The reason it did not work with CXF
>> 2.7.6 was that Jackson provider is not typed to support
>> application/x+javascript. Setting "application/json" on JSONP in
>> interceptor is needed to get the runtime successfully selecting the
>> Jackson provider, however in CXF 2.7.6 the way the response type is
>> handled has changed (in the better way), so what happened was that JSONP
>> out pre-stream interceptor was actually setting
>>
>> "application/x+javascript" (so that a proper response type is returned),
>> but it does it too early actually though that worked in CXF 2.6.7 as
>> this type was not affecting the selection of MBW.
>>
>> Basically, if you update your example to set a mediaType property on the
>> out stream interceptor as "application/json" the example will start
>> working, but that will return "application/json" content type to the
>> browser.
>>
>> I've just added JAX-RS 2.0 out filter which should be used from now on,
>> it will set a response content type after Jackson has been selected but
>> before it is actually invoked, in the end resulting in a proper content
>> type returned too, so remove
>>
>> bean.getOutInterceptors().add(new JsonpPreStreamInterceptor());
>>
>> and add
>>
>> providerList.add(new
>> org.apache.cxf.jaxrs.provider.jsonp.JsonpJaxrsWriterInterceptor());
>>
>> It is a long story :-), but it has become better. And IMHO is still
>> cleaner than using JSONPadding objects within the application code
>>
>>
>>
>>>>>
>>>>> https-clientserver-grizzly example
>>>>> (http://people.apache.org/~gmazza/restexamples/https-clientserver-grizzly)

>>>>>
>>>>>
>>>>>
>>>>> just need to run "mvn clean test"
>>>>>
>>>>> 2.6.7 works:
>>>>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
>>>>>
>>>>> 2.7.5-SNAPSHOT fails:
>>>>> Tests run: 3, Failures: 1, Errors: 1, Skipped: 0
>>>>>
>>>>> Failed tests:
>>>>> testSSLAuth1(com.sun.jersey.samples.https_grizzly.MainTest)
>>>>> testSSLAuth1(com.sun.jersey.samples.https_grizzly.MainTest) Time
>>>>> elapsed: 0.99 sec <<< FAILURE!
>>>>> java.lang.AssertionError
>>>>> at org.junit.Assert.fail(Assert.java:86)
>>>>> at org.junit.Assert.assertTrue(Assert.java:41)
>>>>> at org.junit.Assert.assertTrue(Assert.java:52)
>>>>> at
>>>>> com.sun.jersey.samples.https_grizzly.MainTest.testSSLAuth1(MainTest.java:124)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tests in error:
>>>>> testHTTPBasicAuth1(com.sun.jersey.samples.https_grizzly.MainTest)
>>>>> testHTTPBasicAuth1(com.sun.jersey.samples.https_grizzly.MainTest) 
>>>>> Time
>>>>> elapsed: 0.144 sec <<< ERROR!
>>>>> java.lang.NullPointerException
>>>>> at
>>>>> com.sun.jersey.samples.https_grizzly.MainTest.testHTTPBasicAuth1(MainTest.java:104)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
>>>>> at
>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The source code for the two failed tests:
>>>>> https://github.com/gmazza/jersey-samples-on-cxf/blob/master/https-clientserver-grizzly/src/test/java/com/sun/jersey/samples/https_grizzly/MainTest.java#L97

>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> I'll test this 3rd example tomorrow
>>>>
>>
>> Will resolve it in the next couple of days
>>
>> Thanks, Sergey
>>>>
>>>
>>> OK, thanks.
>>>
>>> Glen
>>>
>
>


Mime
View raw message