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...
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...
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:
testSSLAuth1(com.sun.jersey.samples.https_grizzly.MainTest)
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.https_grizzly.MainTest.testSSLAuth1(MainTest.java:124)
at
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 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)
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 updated the
client and server runtime to protect
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
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
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...
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
Rest Sample
Hi, I have JBoss5.1.0 and i installed jbossws-cxf-3.2.0.GA and its working correctly. Now I would like to deploy jax-rs/basic sample to this server. Can someone help as to what i have to do. Thanks, Srini
RE: Rest Sample
Is CXF JAXRS included ? If yes then it's the good news, I don't know actually, I can see from http://lists.jboss.org/pipermail/jboss-cvs-commits/2009-August/104841.ht ml the cxf-frontend-jaxrs dependency is listed - but I don't know if it is included in the final product. If yes then you probably can deploy it as a war ? I'm not quite familiar with the way JBoss deployment works Sergey -Original Message- From: srini raju [mailto:raju.sr...@gmail.com] Sent: 22 October 2009 20:44 To: users@cxf.apache.org Subject: Rest Sample Hi, I have JBoss5.1.0 and i installed jbossws-cxf-3.2.0.GA and its working correctly. Now I would like to deploy jax-rs/basic sample to this server. Can someone help as to what i have to do. Thanks, Srini
