cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject Re: generics and type mapping in Aegis
Date Tue, 01 Sep 2009 11:21:58 GMT
Hi Benson

----- Original Message ----- 
From: "Benson Margulies" <bimargulies@gmail.com>
To: "CXF Dev" <dev@cxf.apache.org>
Sent: Monday, August 31, 2009 6:33 PM
Subject: generics and type mapping in Aegis


> Sergey's issues with JAX-RS have started me looking at how Aegis maps types.
> The following temptation now occurs: allow the fundamental aegis type
> mechanism to map generics. Somene could thus add a mapping from any X<y,x,q>
> -> XML via a custom type. Of course, with type erasure, this only will pay
> attention to the declared type, not the dynamic type.
>
> Somehow, I feel as if this is a slippery slope we don't want to start down.
> However, the defined APIs for JAX-RS have started us there, with their extra
> arguments for generic type specs. Apparently, someone thinks that it's so
> important to be able to write a Collection<X> to the top of JAX-RS to
> justify adding an asymmetry.

Have a look at this JAXRS resource class :

http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/fortest/BookEntity.java

and this one :

http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/fortest/AbstractEntity.java

At runtime the parameter type of BookEntity.postEntity(new Book()) is Object but its Type
is TypeVariable that leads to Book.class.
CXF takes care of hiding these details from JAXRS providers but I'm not sure it is the case
with all other JAXRS impls so one can 
imagine custom writers actually needing to deal with Type params...And if it were the case
then it would make life more complicated 
for users - thus having seperate parameters lets some implemetations to avoid it.
Perhaps there've been some other or just completely different motivations behind introducing
Class and Type - for ex, 
MessageBodyWriter/Reader interfaces are parameterized so say

CustomBodyWriter implements MessageBodyWriter<Foo>

would lead to Class<Foo> being generated in some method signatures, thus allowing the
runtimes to do some additional checks, with 
Types alone it would not be possible

cheers, Sergey

> Anybody else got a thought here?
> 


Mime
View raw message