cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Resolved: (CXF-1758) Simple front end does not figure out generic implementation beans.
Date Tue, 15 Dec 2009 14:15:18 GMT


Daniel Kulp resolved CXF-1758.

       Resolution: Fixed
    Fix Version/s: 2.2.6
         Assignee: Daniel Kulp

This is now somewhat resolved, about as good as we can get it. 

One note:
You need a concrete bean subclass for this to work.  Thus, something like:

svrBean.setServiceBean(new TestServiceImpl<String>());

will not work, but if you do:

svrBean.setServiceBean(new TestServiceImpl<String>() { })

It will work as the compiler will generate a subclass that would retain the type information.

> Simple front end does not figure out generic implementation beans.
> ------------------------------------------------------------------
>                 Key: CXF-1758
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Simple Frontend
>    Affects Versions: 2.1.2
>         Environment: linux debian stable (etch) tomcat 5.5.20-2etch3
>            Reporter: Vassilis Virvilis
>            Assignee: Daniel Kulp
>             Fix For: 2.2.6
> The real issue in the description below is that the SimpleFrontEnd is not dealing with
an implementation bean like
> MyClass<String> as it must. It isn't figuring out the actual types, it's just allowing
type erasure to mislead it into treating all instances of the type parameters as Object, which
is to say xsd:anyType. This happened to trigger an obscure explosion in the Javascript generator.
> If anyone wants to fix this badly enough, they need to contemplate 
>    List<P> doSomething(P someItem)
> in terms of the complexity of the code that will trace that P down there in the list
up to the SEB.
> I managed to get a javascript client example working but it barfs in some cases.
> All my server classes are pojos and I am using the simple frontend (I think) with Aegis.
I am very pleased with java2java communication since I can pass complex types with no annotations
at all.
> The problematic cases are of the form. (All other cases are working with js client)
> public interface Service<T, P> {
>     public int open(P args);
>     public void close(int handle);
>     public int getValue(int handle);
> }
> My guess is it barfs in the generic P type argument.
> When I am trying to do http://localhost/ws/SomeService?js tomcat produces an error
> Aug 20, 2008 7:14:43 AM org.apache.cxf.transport.servlet.ServletController invoke
> WARNING: org.apache.cxf.javascript.JavascriptQueryHandler Exception caught writing response.
> java.lang.ClassCastException: cannot be cast
>         at org.apache.cxf.javascript.types.SchemaJavascriptBuilder.deserializeElement(
>         at org.apache.cxf.javascript.types.SchemaJavascriptBuilder.domDeserializerFunction(
>         at org.apache.cxf.javascript.types.SchemaJavascriptBuilder.generateCodeForSchema(
>         at org.apache.cxf.javascript.JavascriptQueryHandler.writeResponse(
>         at org.apache.cxf.transport.servlet.ServletController.invoke(
>         at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(
>         at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(
>         at javax.servlet.http.HttpServlet.service(
>         at javax.servlet.http.HttpServlet.service(
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at$
>         at Method)
>         at
>         at
>         at
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>         at org.apache.catalina.core.ApplicationFilterChain.access$0(
>         at org.apache.catalina.core.ApplicationFilterChain$
>         at Method)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(
>         at org.apache.catalina.core.StandardWrapperValve.invoke(
>         at org.apache.catalina.core.StandardContextValve.invoke(
>         at org.apache.catalina.core.StandardHostValve.invoke(
>         at org.apache.catalina.valves.ErrorReportValve.invoke(
>         at org.apache.catalina.core.StandardEngineValve.invoke(
>         at org.apache.catalina.connector.CoyoteAdapter.service(
>         at org.apache.jk.server.JkCoyoteHandler.invoke(
>         at org.apache.jk.common.HandlerRequest.invoke(
>         at org.apache.jk.common.ChannelSocket.invoke(
>         at org.apache.jk.common.ChannelSocket.processConnection(
>         at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(
>         at org.apache.tomcat.util.threads.ThreadPool$
>         at

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message