I finally opened a Jira about this issue as I still get problems caused by the 
injection checking system which goes far beyond expectations.


I hope it could be fixed :)

Thank you!

Kind regards,

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)
<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 
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 

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?


[@@ OPEN @@]

Reply via email to