On Sep 2, 2009, at 8:25 PM, Tatu Saloranta wrote:
> On Wed, Sep 2, 2009 at 12:44 AM, Paul Sandoz<Paul.Sandoz_at_sun.com>
> wrote:
>> On Sep 1, 2009, at 7:38 PM, Tatu Saloranta wrote:
> ...
>>
>> Yes, Jersey can support the resolving of T for a request entity by
>> traversing the class hierarchy and that is the solution i will use
>> to solve
>> the resolving of T in all contexts with the "abstract model" and
>> will be
>> able to report errors if T cannot be resolved.
>>
>> But say we have:
>>
>> public class X<T> {
>> @GET
>> public Collection<T> get() { ... }
>> }
>>
>> public class Y extends X<MyJAXBBean> { ... }
> ...
>> Then there is no way to directly resolve the parameterized type
>> Collection<T>, or Collection<V>, to Collection< MyJAXBBean> as the
>> latter
>> type does not exist at runtime using reflection, and would have to be
>> created, and AFAIK the only way to create it would be to actually
>> define a
>> class, for example:
>>
>> public class _Collection_MyJAXBBean_ {
>> public Collection<MyJAXBBean> _x;
>> }
>>
>> which means using some ASM. Essentially we are attempting to do
>> what the
>> compiler does, in part, to perform static typing.
> ...
>
> Ok I see.
>
> Personally I would probably be fine by declaring this as something to
> be done later if ever. :-)
OK :-) intellectually it would be an interesting challenge (i think i
know what steps need to be done), but there are currently other more
important things that need to be done.
Paul.
> (given complexity of what it takes to tackle them)
> But if this does end up being addressed, I'll be interested in seeing
> the solution obviously.
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>