I checked the code, but that's currently the only way. However, one possibility would be to move those 2 lines into a different blueprint xml file, so that the same file can be included in all your bundles more easily at build time, as blueprint will by default load all OSGI-INF/blueprint/*.xml
Cheers Guillaume Nodet 2016-09-26 17:47 GMT+02:00 CLEMENT Jean-Philippe < jean-philippe.clem...@fr.thalesgroup.com>: > Hi Guillaume, > > > > Yep, did not had time to make a full test on all bundles, but the few > bundles with the Blueprint addition I tested start without the “unable to > find matching…” errors: > > <type-converters> > > <bean class=”somewhere.above.the. > rainbow.Converter”/> > > </type-converters> > > > > So it’s another workaround possibility, thanks! I’m not too sure of the > overall startup time impact, but I hope it would be small. > > > > The thing is it’s a bit heavy to declare the workaround (although it’s > three lines of XML) in almost every bundle. Is there a way to declare a > global converter available everywhere? > > > > Thanks, > > JP > > > > *De :* Guillaume Nodet [mailto:gno...@apache.org] > *Envoyé :* lundi 26 septembre 2016 15:19 > > *À :* user@aries.apache.org > *Objet :* Re: Blueprint issue with generics > > > > Have you been able to try the converter ? > > > > 2016-09-23 13:07 GMT+02:00 Guillaume Nodet <gno...@apache.org>: > > > > > > 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe < > jean-philippe.clem...@fr.thalesgroup.com>: > > 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? > > > > The converters are always called. I don't see why you'd need multiple > converters, it should be fairly easy to write one which will simply convert > all erased types to the equivalent with a generic, and that should solve > all your problems. > > > > > > Having said that, why having extra converters and Blueprint to get no > added value? > > > > Because that's how the spec has been written. We already implemented more > that what the spec says with ARIES-1500, and I think there's an easy work > around. > > So please try the workaround first, and we'll see how it goes. > > > > Here's the converter code you can try: > > *public class *ErasureConverter *implements *Converter { > > @Override > *public boolean *canConvert(Object sourceObject, ReifiedType targetType) { > *return *targetType.getRawClass().isInstance(sourceObject); > } > > @Override > *public *Object convert(Object sourceObject, ReifiedType targetType) > *throws *Exception { > *return *sourceObject; > } > } > > > > > > JP > > > > *De :* Guillaume Nodet [mailto:gno...@apache.org] > *Envoyé :* vendredi 23 septembre 2016 11:36 > > > *À :* user@aries.apache.org > *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 < > jean-philippe.clem...@fr.thalesgroup.com>: > > 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:jean-philippe.clement@ > fr.thalesgroup.com] > *Envoyé :* vendredi 16 septembre 2016 14:29 > *À :* user@aries.apache.org > *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:crafts...@bendoerr.me > <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> 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: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/