You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Carl-Erik Kopseng <ca...@gmail.com> on 2012/10/24 15:25:50 UTC
Re: Registering interceptors through web.xml
Waking up a year old thread, as the problem at hand is more or less a
direct followup - just with regards to problems with the newly
released CXF 2.7.0. As can be seen from the discussion below,
interceptors can be injected by specifying them in web.xml, if one is
not using Spring for setup. Today I tried out CXF 2.7.0 and I now got
a ClassNotFoundException:
LifecycleException: java.lang.ClassNotFoundException:
org.apache.cxf.jaxrs.provider.jsonp.JsonpPostStreamInterceptor
org.apache.cxf.jaxrs.provider.jsonp.JsonpPreStreamInterceptor
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4979)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5376)
at com.sun.enterprise.web.WebModule.start(WebModule.java:345)
As can be seen, the classname that was looked up was split over three
lines, so this means that somehow, this logic has changed in 2.7.0.
This works fine in 2.6.2. Is this an intentional change? I could not
see anything explicit in the changelog.
Using Glassfish 2.1.1, Java 1.6.0_37, OS X, CXF 2.7.0
>> The fixes in 2.4.2-SNAPSHOT (and trunk) now makes it possible to
>> register the interceptor using init-params, but I have two problems:
>>
>> 1. JSONP support demands two outinterceptors (in addition to the
>> ininterceptor); a pre-stream interceptor and a post-stream
>> interceptor. How can I specify multiple interceptors using init-param?
>> I have tried with
>> <init-param>
>> <param-name>jaxrs.outInterceptors</param-name>
>> <param-value>org.apache.cxf.jaxrs.provider.jsonp.JsonpPreStreamInterceptor,
>> org.apache.cxf.jaxrs.provider.jsonp.JsonpPostStreamInterceptor
>> </init-param>
>> , but it only picks up the last one, not both (reversing the two
>> outinterceptors above showes it).
>>
> The values are space-separated,
>
> <init-param>
> <param-name>jaxrs.outInterceptors</param-name>
> <param-value>
>
> org.apache.cxf.jaxrs.provider.jsonp.JsonpPreStreamInterceptor
>
> org.apache.cxf.jaxrs.provider.jsonp.JsonpPostStreamInterceptor
> </param-value>
> </init-param>
--
Carl-Erik Kopseng
Re: Registering interceptors through web.xml
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Carl-Erik
On 24/10/12 16:19, Carl-Erik Kopseng wrote:
>>> As can be seen from the discussion below,
>>> interceptors can be injected by specifying them in web.xml, if one is
>>> not using Spring for setup. Today I tried out CXF 2.7.0 and I now got
>>> a ClassNotFoundException:
> (snip(
>>>
>>> As can be seen, the classname that was looked up was split over three
>>> lines, so this means that somehow, this logic has changed
>
> Found the problem by looking at the code revisions for
> CXFNonSpringJaxrsServlet
> (https://fisheye6.atlassian.com/browse/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java?r2=1366746&r1=1359097)
>
> Turns out that the default parameter splitting character changed July
> 18 from using a default of " " (space) to "," (comma). This broke the
> configuration. By specifying class.parameter.split.char one can decide
> which character should do the splitting. The following would need to
> be added in order not to change the former configuration:
>
> <init-param>
> <param-name>class.parameter.split.char</param-name>
> <param-value> </param-value>
> </init-param>
> <init-param>
>
> Using comma is fine anyhow, so using that from now on.
>
I recall it now, there were issues with using " " by default when each
of the interceptors had the additional properties set, example
"myInterceptor1(a=2,
b=3)
myInterceptor2(a=2,
b=3)"
etc, it was splitting it the wrong way so
"myInterceptor1(a=2
b=3)
,
myInterceptor2(a=2
b=3)"
works
Thanks, Sergey
> regards
> Carl-Erik
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Registering interceptors through web.xml
Posted by Carl-Erik Kopseng <ca...@gmail.com>.
>> As can be seen from the discussion below,
>> interceptors can be injected by specifying them in web.xml, if one is
>> not using Spring for setup. Today I tried out CXF 2.7.0 and I now got
>> a ClassNotFoundException:
(snip(
>>
>> As can be seen, the classname that was looked up was split over three
>> lines, so this means that somehow, this logic has changed
Found the problem by looking at the code revisions for
CXFNonSpringJaxrsServlet
(https://fisheye6.atlassian.com/browse/cxf/branches/2.4.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java?r2=1366746&r1=1359097)
Turns out that the default parameter splitting character changed July
18 from using a default of " " (space) to "," (comma). This broke the
configuration. By specifying class.parameter.split.char one can decide
which character should do the splitting. The following would need to
be added in order not to change the former configuration:
<init-param>
<param-name>class.parameter.split.char</param-name>
<param-value> </param-value>
</init-param>
<init-param>
Using comma is fine anyhow, so using that from now on.
regards
Carl-Erik
Re: Registering interceptors through web.xml
Posted by Carl-Erik Kopseng <ca...@gmail.com>.
2012/10/24 Carl-Erik Kopseng <ca...@gmail.com>:
> Waking up a year old thread, as the problem at hand is more or less a
> direct followup - just with regards to problems with the newly
> released CXF 2.7.0. As can be seen from the discussion below,
> interceptors can be injected by specifying them in web.xml, if one is
> not using Spring for setup. Today I tried out CXF 2.7.0 and I now got
> a ClassNotFoundException:
>
> LifecycleException: java.lang.ClassNotFoundException:
> org.apache.cxf.jaxrs.provider.jsonp.JsonpPostStreamInterceptor
>
> org.apache.cxf.jaxrs.provider.jsonp.JsonpPreStreamInterceptor
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4979)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:5376)
> at com.sun.enterprise.web.WebModule.start(WebModule.java:345)
>
> As can be seen, the classname that was looked up was split over three
> lines, so this means that somehow, this logic has changed in 2.7.0.
> This works fine in 2.6.2. Is this an intentional change? I could not
> see anything explicit in the changelog.
>
> Using Glassfish 2.1.1, Java 1.6.0_37, OS X, CXF 2.7.0
Correction. This worked fine in 2.4.2, not 2.6.2. The problem is the same there.