Generics as SEI/SEB

[Benson Margulies <bi...@gmail.com>]

Dev,

I'm looking at CXF-1758, which presents as the Javascript front end
choking when the SEI and SEB are generics.

In other words, the implementation bean for a service is
SomeGenericOfType<String>, and it has a method like doSomething<T>.

With the simple front end, we get a schema for this with an
xsd:anyType in it instead of the actual specific type.

To my questionable taste, this can't be right. The question is, do we
want to support this? Is there even enough reflectable information in
the face of type erasure to make it possible to support this? I can't
see supporting this as a baroque notation for a method that takes
Object.

--benson

Re: Generics as SEI/SEB

[Daniel Kulp <dk...@apache.org>]

This type of thing is EXTREMELY hard to support.   In SOME cases, the users 
would have to provide extra metadata into the RSFB/configurations as the 
parameterized types wouldn't be available.   In other cases, we could deduce 
it.   In both cases, however, we have to track a lot of extra details and 
possibly even into the databindings where we don't have complete control 
(JAXB).   

For example, something like:

class DataBean<T> {
    public List<T> foo;
}


interface MyService<X, Y> {
    public DataBean<X> doData(DataBean<Y> y);
}

For JAXB to determine the List<T> in the DataBean, it needs to know about 
stuff outside that bean.   Actually, in this case, there would need to be two 
separate "DataBean" types in the schema, one for X and one for Y.   

Also, in your specific case, if you do:

impl = new SomeGenericOfType<String>();
Endpoint.publish(impl);

we have no way to get the <String> from the impl.   If we call 
impl.getClass(), there is nothing on the class that records this is a String 
version of the impl.     Thus, the user would need to provide that extra 
information.  

However, if they had something like:
class MyServiceImpl implements MyService<String, Integer> {
....
}
then we COULD query the generic types for the interfaces it implements.  
(impl.getClass().getGenericInterfaces())

In anycase, this is a HUGE amount of work to get everything working (and as I 
mentioned, in the JAXB case, I'm not sure if it's even possible).   If you 
REALLY wanted to start going down this path, I would recommend picking a few 
small, specific cases and targetting them and not "everything using 
generics".

Dan


On Monday 25 August 2008 4:25:51 pm Benson Margulies wrote:
> Dev,
>
> I'm looking at CXF-1758, which presents as the Javascript front end
> choking when the SEI and SEB are generics.
>
> In other words, the implementation bean for a service is
> SomeGenericOfType<String>, and it has a method like doSomething<T>.
>
> With the simple front end, we get a schema for this with an
> xsd:anyType in it instead of the actual specific type.
>
> To my questionable taste, this can't be right. The question is, do we
> want to support this? Is there even enough reflectable information in
> the face of type erasure to make it possible to support this? I can't
> see supporting this as a baroque notation for a method that takes
> Object.
>
> --benson



-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog