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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
