Hi Guillaume, We do have a lot of classes used in the blueprint which use generics and fail. As far as I understand each of those classes should have a converter and each bundle making use of them should declare the 2-3 lines you mentioned per converter, correct?
Having said that, why having extra converters and Blueprint to get no added value? JP De : Guillaume Nodet [mailto:[email protected]] Envoyé : vendredi 23 septembre 2016 11:36 À : [email protected] Objet : Re: Blueprint issue with generics Have you tried using a Converter ? This should fix all your problems quite easily, it's only 2 or 3 lines to add to your blueprint. 2016-09-23 11:30 GMT+02:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: Dear Aries Team, The Jira (ARIES-1607) is not assigned. Does it mean it won’t be fixed? Regards, JP De : CLEMENT Jean-Philippe [mailto:[email protected]<mailto:[email protected]>] Envoyé : vendredi 16 septembre 2016 14:29 À : [email protected]<mailto:[email protected]> Objet : RE: Blueprint issue with generics I finally opened a Jira about this issue as I still get problems caused by the injection checking system which goes far beyond expectations. https://issues.apache.org/jira/browse/ARIES-1607 I hope it could be fixed :) Thank you! Kind regards, JP De : Benjamin Doerr [mailto:[email protected]] Envoyé : jeudi 11 février 2016 22:39 À : [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 @@] -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected]<mailto:[email protected]> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/
