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]> 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 @@] > > >
