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:crafts...@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.clem...@fr.thalesgroup.com <mailto:jean-philippe.clem...@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é jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
