Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Glen Mazza wrote >> >> 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 >> >> > > Hmm, I made the change: > https://github.com/gmazza/jersey-samples-on-cxf/commit/811d97be876286bfe62f2bc2e13667a25a0e5bfd > > But still isn't working: > curl -HAccept:application/x+javascript > http://localhost:9998/jsonp/changes?_jsonp=myCallback > No message body writer has been found for response class LinkedList.); jsonp example working now with 2.7.6-SNAPSHOT -- I forgot to set the media type as you detailed above. We're done. Thanks, Glen -- View this message in context: http://cxf.547215.n5.nabble.com/REST-sample-works-with-CXF-2-6-2-but-not-CXF-2-7-4-tp5727173p5727657.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Hi Glen On 10/05/13 19:33, Glen Mazza wrote: The entire sample works now: https://github.com/gmazza/jersey-samples-on-cxf/commit/13168735076039ee364441c30d1dbdd6a06522a3 Thanks for spending the time, and for helping to fix few new issues as a result Cheers, Sergey 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: testSS
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
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.9
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
On 05/07/2013 05:46 PM, Sergey Beryozkin wrote: --- 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 Hmm, I made the change: https://github.com/gmazza/jersey-samples-on-cxf/commit/811d97be876286bfe62f2bc2e13667a25a0e5bfd But still isn't working: curl -HAccept:application/x+javascript http://localhost:9998/jsonp/changes?_jsonp=myCallback No message body writer has been found for response class LinkedList.);
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
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.
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
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.htt
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
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. --- 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$ --- 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 Thanks, Sergey OK, thanks. Glen
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Hi Glen On 04/05/13 02:18, Glen Mazza wrote: Hi Sergey, I republished the blog entry today: http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf, MOXy now works after I upgraded to 2.7.5-SNAPSHOT, but three samples are still stuck at 2.6.7: https-server-glassfish (http://people.apache.org/~gmazza/restexamples/https-server-glassfish): 2.7.5-SNAPSHOT returns this after deploying and accessing https://localhost:8181/httpsBasicAuth-webapp/helloworld from a browser: java.lang.NoSuchMethodError: javax.ws.rs.core.Response.getHeaders()Ljavax/ws/rs/core/MultivaluedMap; 2.6.7 works. 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. --- 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 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$ --- 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 Thanks, Sergey Any immediate things you can spot, let me know and I'll update the sample, I can also enter in JIRA items for any issues above you see noteworthy. Thanks, Glen On 05/03/2013 03:54 PM, Sergey Beryozkin wrote: Hi Glen Nice to see you working on updating the examples, thanks for that. Please try 2.7.5-SNAPSHOT, this issue should disappear, I
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Hi Sergey, I republished the blog entry today: http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf, MOXy now works after I upgraded to 2.7.5-SNAPSHOT, but three samples are still stuck at 2.6.7: https-server-glassfish (http://people.apache.org/~gmazza/restexamples/https-server-glassfish): 2.7.5-SNAPSHOT returns this after deploying and accessing https://localhost:8181/httpsBasicAuth-webapp/helloworld from a browser: java.lang.NoSuchMethodError: javax.ws.rs.core.Response.getHeaders()Ljavax/ws/rs/core/MultivaluedMap; 2.6.7 works. --- 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.) 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$ --- 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 Any immediate things you can spot, let me know and I'll update the sample, I can also enter in JIRA items for any issues above you see noteworthy. Thanks, Glen On 05/03/2013 03:54 PM, Sergey Beryozkin wrote: Hi Glen Nice to see you working on updating the examples, thanks for that. Please try 2.7.5-SNAPSHOT, this issue should disappear, I updated the client and server runtime to protect itself from multiple RuntimeDelegates floating around, so the foreign JAX-RS Responses are copied to CXF specific instances... Thanks, Sergey On 03/05/13 19:01, Glen Mazza wrote: A similar problem occurs with https-server-glassfish example (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/https-server-glassfish) in upgrading from CXF 2.6.7 to CXF 2.7.4 on latest Glassfish Server 3.1.2.2 following instructions given in README: http://people.apache.org/~gmazza/restexamples/https-server-glassfish; CXF 2.6.7 works fine but CXF 2.7.4 raises this exception when accessing https://localhost:8181/httpsBasicAuth-webapp/helloworld after deployment: java.lang.ClassCastException: com.sun.jersey.core.spi.factory.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:179) at org.apache.cxf.jaxrs.interceptor.JAXRSOut
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Hi Glen Nice to see you working on updating the examples, thanks for that. Please try 2.7.5-SNAPSHOT, this issue should disappear, I updated the client and server runtime to protect itself from multiple RuntimeDelegates floating around, so the foreign JAX-RS Responses are copied to CXF specific instances... Thanks, Sergey On 03/05/13 19:01, Glen Mazza wrote: A similar problem occurs with https-server-glassfish example (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/https-server-glassfish) in upgrading from CXF 2.6.7 to CXF 2.7.4 on latest Glassfish Server 3.1.2.2 following instructions given in README: http://people.apache.org/~gmazza/restexamples/https-server-glassfish; CXF 2.6.7 works fine but CXF 2.7.4 raises this exception when accessing https://localhost:8181/httpsBasicAuth-webapp/helloworld after deployment: java.lang.ClassCastException: com.sun.jersey.core.spi.factory.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:179) at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:148) at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:84) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:77) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:223) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:203) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:168) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219) On 05/03/2013 01:17 PM, Glen Mazza wrote: Hi, I'm in the process of updating my Jersey/CXF samples blog article (http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf) from CXF 2.6.2 to CXF 2.7.4. 11 of the 15 samples work OOTB with no problem. One sample, Moxy (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/moxy, http://people.apache.org/~gmazza/restexamples/moxy), works fine with CXF 2.6.2 (actually works as high as CXF 2.6.7) but one of its integration tests fails with CXF 2.7.4 (fails also with CXF 2.7.0). Running "mvn clean install" from the moxy folder will activate the integration test, with 2.7.4 TestCustomer (https://github.com/gmazza/jersey-samples-on-cxf/blob/master/moxy/src/test/java/com/sun/jersey/samples/moxy/MoxyWebAppTestIT.java#L110) fails with this error message: Tests run: 2, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 2.91 sec <<< FAILURE! testCustomer(com.sun.jersey.samples.moxy.MoxyWebAppTestIT) Time elapsed: 1.32 sec <<< ERROR! javax.ws.rs.client.ClientException: java.lang.ClassCastException: org.apache.cxf.jaxrs.impl.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1086) at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1049) at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:999) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:836) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:810) at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:373) at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:552) at com.sun.jersey.samples.moxy.MoxyWebAppTestIT.testCustomer(MoxyWebAppTestIT.java:113) 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) Again, if I just change the CXF dependency to 2.6.x in the moxy/pom.xml, the problem goes away. Anyone know what changed between 2.6.x and 2.7.x for this to occur? Migration notes don't appear to have much concerning this... Thanks, Glen
Re: REST sample works with CXF 2.6.2 but not CXF 2.7.4...
A similar problem occurs with https-server-glassfish example (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/https-server-glassfish) in upgrading from CXF 2.6.7 to CXF 2.7.4 on latest Glassfish Server 3.1.2.2 following instructions given in README: http://people.apache.org/~gmazza/restexamples/https-server-glassfish; CXF 2.6.7 works fine but CXF 2.7.4 raises this exception when accessing https://localhost:8181/httpsBasicAuth-webapp/helloworld after deployment: java.lang.ClassCastException: com.sun.jersey.core.spi.factory.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:179) at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:148) at org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:84) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:77) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:223) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:203) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:168) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219) On 05/03/2013 01:17 PM, Glen Mazza wrote: Hi, I'm in the process of updating my Jersey/CXF samples blog article (http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf) from CXF 2.6.2 to CXF 2.7.4. 11 of the 15 samples work OOTB with no problem. One sample, Moxy (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/moxy, http://people.apache.org/~gmazza/restexamples/moxy), works fine with CXF 2.6.2 (actually works as high as CXF 2.6.7) but one of its integration tests fails with CXF 2.7.4 (fails also with CXF 2.7.0). Running "mvn clean install" from the moxy folder will activate the integration test, with 2.7.4 TestCustomer (https://github.com/gmazza/jersey-samples-on-cxf/blob/master/moxy/src/test/java/com/sun/jersey/samples/moxy/MoxyWebAppTestIT.java#L110) fails with this error message: Tests run: 2, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 2.91 sec <<< FAILURE! testCustomer(com.sun.jersey.samples.moxy.MoxyWebAppTestIT) Time elapsed: 1.32 sec <<< ERROR! javax.ws.rs.client.ClientException: java.lang.ClassCastException: org.apache.cxf.jaxrs.impl.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1086) at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1049) at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:999) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:836) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:810) at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:373) at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:552) at com.sun.jersey.samples.moxy.MoxyWebAppTestIT.testCustomer(MoxyWebAppTestIT.java:113) 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) Again, if I just change the CXF dependency to 2.6.x in the moxy/pom.xml, the problem goes away. Anyone know what changed between 2.6.x and 2.7.x for this to occur? Migration notes don't appear to have much concerning this... Thanks, Glen
REST sample works with CXF 2.6.2 but not CXF 2.7.4...
Hi, I'm in the process of updating my Jersey/CXF samples blog article (http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf) from CXF 2.6.2 to CXF 2.7.4. 11 of the 15 samples work OOTB with no problem. One sample, Moxy (https://github.com/gmazza/jersey-samples-on-cxf/tree/master/moxy, http://people.apache.org/~gmazza/restexamples/moxy), works fine with CXF 2.6.2 (actually works as high as CXF 2.6.7) but one of its integration tests fails with CXF 2.7.4 (fails also with CXF 2.7.0). Running "mvn clean install" from the moxy folder will activate the integration test, with 2.7.4 TestCustomer (https://github.com/gmazza/jersey-samples-on-cxf/blob/master/moxy/src/test/java/com/sun/jersey/samples/moxy/MoxyWebAppTestIT.java#L110) fails with this error message: Tests run: 2, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 2.91 sec <<< FAILURE! testCustomer(com.sun.jersey.samples.moxy.MoxyWebAppTestIT) Time elapsed: 1.32 sec <<< ERROR! javax.ws.rs.client.ClientException: java.lang.ClassCastException: org.apache.cxf.jaxrs.impl.ResponseImpl cannot be cast to org.apache.cxf.jaxrs.impl.ResponseImpl at org.apache.cxf.jaxrs.client.WebClient.handleResponse(WebClient.java:1086) at org.apache.cxf.jaxrs.client.WebClient.doResponse(WebClient.java:1049) at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:999) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:836) at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:810) at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:373) at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:552) at com.sun.jersey.samples.moxy.MoxyWebAppTestIT.testCustomer(MoxyWebAppTestIT.java:113) 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) Again, if I just change the CXF dependency to 2.6.x in the moxy/pom.xml, the problem goes away. Anyone know what changed between 2.6.x and 2.7.x for this to occur? Migration notes don't appear to have much concerning this... Thanks, Glen