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




Reply via email to