RE: Blueprint issue with generics

[CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>]

Dear Aries Team,

It is really a pain to use Blueprint with generics. I hope a fix could be done. I opened the following Jira for this: https://issues.apache.org/jira/browse/ARIES-1500

Thank you.

Kind regards,
JP

De : Benjamin Doerr [mailto:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org
Objet : Re: Blueprint issue with generics

Also would love to see this fixed. My workaround is usually this:

void setSomething(Something<T> s)
to
<S extends Something<T>> setSomething(S s)

which maintains the compile type checking. And like Jean-Philippe, third-party APIs mean that if I can I have to create a local extension with a hacked setter just to make blueprint happy.

Best Regards,
Benjamin Doerr

On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>> wrote:
Dear Aries Team,

I have an issue with the way generics are handled in Blueprint. I get an exception claiming that the bean conversion is not possible, but it should.

Let's say I have a bean with the method setSomething(Something<T>) called via blueprint with another bean implementing Something => exception. If I change the method signature without the generic type setSomething(Something), then it works as expected.

Until now I did workaround by changing the method signatures and logging a warning but now I'm blocked with a third-party API. So I have to find a real solution.

I don't catch why Blueprint cares for the generic type as Java is type erasure. So it seems to exceed Java spec. Is there a way to comply with Java type erasure, i.e. discard generic types when "converting" beans?

Regards,
JP

[@@ OPEN @@]

Re: Blueprint issue with generics

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi JP,

thanks for the update.

Let's take a look on that.

Regards
JB

On 03/02/2016 04:58 PM, CLEMENT Jean-Philippe wrote:
> Dear Aries Team,
>
> It is really a pain to use Blueprint with generics. I hope a fix could
> be done. I opened the following Jira for this:
> https://issues.apache.org/jira/browse/ARIES-1500
>
> Thank you.
>
> Kind regards,
>
> JP
>
> *De :*Benjamin Doerr [mailto:craftsman@bendoerr.me]
> *Envoyé :* jeudi 11 février 2016 22:39
> *À :* user@aries.apache.org
> *Objet :* Re: Blueprint issue with generics
>
> Also would love to see this fixed. My workaround is usually this:
>
> void setSomething(Something<T> s)
>
> to
>
> <S extends Something<T>> setSomething(S s)
>
> which maintains the compile type checking. And like Jean-Philippe,
> third-party APIs mean that if I can I have to create a local extension
> with a hacked setter just to make blueprint happy.
>
> Best Regards,
>
> Benjamin Doerr
>
> On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe
> <jean-philippe.clement@fr.thalesgroup.com
> <ma...@fr.thalesgroup.com>> wrote:
>
> Dear Aries Team,
>
> I have an issue with the way generics are handled in Blueprint. I get an
> exception claiming that the bean conversion is not possible, but it should.
>
> Let's say I have a bean with the method setSomething(Something<T>)
> called via blueprint with another bean implementing Something =>
> exception. If I change the method signature without the generic type
> setSomething(Something), then it works as expected.
>
> Until now I did workaround by changing the method signatures and logging
> a warning but now I'm blocked with a third-party API. So I have to find
> a real solution.
>
> I don't catch why Blueprint cares for the generic type as Java is type
> erasure. So it seems to exceed Java spec. Is there a way to comply with
> Java type erasure, i.e. discard generic types when "converting" beans?
>
> Regards,
> JP
>
> [@@ OPEN @@]
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com