Re: CXF crashing, unable to process a Collection type

[Brad O'Hearne]

Dan,

Thanks for the reply. I think I may have been in error, but perhaps I 
stumbled across something new. I actually did have one more change. The 
two methods mentioned were both annotated with the same @WebResult name, 
though the types were different, as follows:

   @Post
   @HttpResource(location="/authenticate")
   @WebResult (name = "ServiceResponse")
   AuthenticateResponse authenticate(AuthenticateRequest request) 
throws KilterException;

   @Post
   @HttpResource(location="/getEntities")
   @WebResult (name = "ServiceResponse")
   Collection<User> getUsers(GetUsersRequest request) throws 
KilterException;

I am sure this probably is due to the web service underpinnings here -- 
and that schema types have to be unique. But as I'm not using WSDLs or 
SOAP, but RESTful services, this didn't immediately occur to me. 
However, it may or may not be worth pointing out that what was trying to 
be accomplished here was a common wrapper placed on the response, for 
processing on the client. It might seem an alternative to accomplish 
this via a common return type, as in this:

   @Post
   @HttpResource(location="/authenticate")
   ServiceResponse authenticate(AuthenticateRequest request) throws 
KilterException;

   @Post
   @HttpResource(location="/getEntities")
   ServiceResponse getUsers(GetUsersRequest request) throws 
KilterException;

This is actually what I originally tried, but the problem is that in 
order to return different data, ServiceResponse has to look something 
like this:

public class ServiceResponse {
   public Object data;
}

In this case, CXF croaks on the data property, as each method will 
assign an object of different structure. I do not know the internals of 
CXF, but what would be really great is if one of two things (or both) 
could be possible in the non-SOAP, non-schema-bound world of RESTful 
services:

1) @WebResult name annotations were namespaced by the method they were 
associated with, so that multiple web methods could have the same result 
name, thereby resulting in a common wrapper object returned, though the 
internal structure was different.

2) Perhaps an alternative to 1), or maybe in addition to, dynamic, 
runtime databinding to property types sent in, so that a class like the 
ServiceResponse object above can be assigned different object structures 
to its data property, and be successfully processed.

As it is, the client receiving the response cannot be response-agnostic 
to a common response wrapper, but must have carnal knowledge of the 
literal response name/type in order to receive it. Doing either of the 
two above might preserve a polymorphic ability of payload processing on 
the client end.

Anyway, I'd be interested in knowing if the annotation issue above was 
something known -- I'm sure it is, but want to make sure that I was 
dealing with the actual problem, not merely a symptom of something else.

Thanks,

Brad

Dan Diephouse wrote:
JAXB tends to not work very well with Collections/Lists IMO - at least 
not
right on the parameter class. You may want to try using the Aegis
databinding which works quite well with them. I'll see if I can churn 
out a
test case though for this and see what might be wrong.

- Dan

On 7/15/07, Brad O'Hearne <[EMAIL PROTECTED]> wrote:

The plot thickens. I changed the code back, so that Collection was no
longer there, and the orginal ArrayList is there. The code is *still*
crashing however. My input has not changed -- it is hard-coded, so I
know for a fact it has not changed. I am now suspecting some new
resource that may have been posted to an online maven repository,
because that's the only thing I can think of that could have injected
new code into my code-base, as I am building with maven. Is anyone aware
of any new CXF artifact or dependency that has hit public maven
repositories within the last day?

Thanks,

Brad

Brad O'Hearne wrote:
> I have a RESTful service configured with Spring. Here is the 
interface:
>
> @WebService
> public interface IUserService {
>      @Post
>    @HttpResource(location="/authenticate")
>    AuthenticateResponse authenticate(AuthenticateRequest request)
> throws KilterException;
>
>    @Post
>    @HttpResource(location="/getEntities")
>    ArrayList<User> getUsers(GetUsersRequest request) throws
> KilterException;
>
> }
>
>
> This service works without error. However, I made one change, which
> was changing the return type of the getUsers method from the ArrayList
> listed to a Collection, as follows:
>
>    @Post
>    @HttpResource(location="/getEntities")
>    Collection<User> getUsers(GetUsersRequest request) throws
> KilterException;
>
>
> This was the ONLY change made. Though my server loaded the service
> without error, oddly, invoking the authenticate method, in the same
> way as before, with the same exact data, resulted in the following
> exception (NOTE: the code of my actual service was never invoked, this
> exception occurred in the CXF API which was processing parameters). So
> apparently, this Collection type, though on the getUsers method,
> prevented the authenticate method from being invoked. ??? Does anyone
> have any idea why this would be, and how to rectify it? The exception
> is below:
>
> INFO: Invoking POST on /authenticate
> Jul 15, 2007 8:59:17 PM
> org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor
> handleMessage
> INFO: URIParameterInterceptor handle message on path [/authenticate]
> with content-type [application/xml]
> Jul 15, 2007 8:59:17 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> java.lang.NullPointerException
>    at
> org.apache.cxf.binding.http.IriDecoderHelper.interopolateParams(
IriDecoderHelper.java:264)
>
>    at
>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.mergeParams 

(URIParameterInInterceptor.java:124)
>
>    at
>
org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleMessage 

(URIParameterInInterceptor.java:105)
>
>    at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
PhaseInterceptorChain.java:206)
>
>    at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(
ChainInitiationObserver.java:67)
>
>    at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
ServletDestination.java:100)
>
>    at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(
ServletController.java:224)
>
>    at
> org.apache.cxf.transport.servlet.ServletController.invoke(
ServletController.java:103)
>
>    at
> 
org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.java:261)
>    at
> 
org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.java:239)
>    at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
>    at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>    at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:270)
>
>    at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:191)
>
>    at
> org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:227)
>
>    at
> org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:174)
>
>    at
> 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:127)
>
>    at
> 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:104)
>
>    at
> org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:108)
>
>    at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:211)
>
>    at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:817)
>
>    at
> 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:623)
>
>    at
> 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:444)
>    at java.lang.Thread.run(Thread.java:595)
>
> Thanks,
>
> Brad