I certainly would not oppose extending the ext namespace, or adding a new namespace for that. But I also don't plan to spend a day on that, as there is an easy workaround : this is already available by adding a few lines of xml, or even adding a new file, those can be easily done from the pom without any change to your code. This file (along with the converter I gave you) can be added and inline easily using the correct maven bundle plugin instructions. But please go ahead, I'd suggest you start implementing a small external namespace handler that will provide an attribute on the main <blueprint /> element: <blueprint cnv:allow-erasure-conversion="true"> ...
Cheers, Guillaume 2016-09-30 10:55 GMT+02:00 CLEMENT Jean-Philippe < [email protected]>: > Hi Guillaume, > > > > Do you think a fallback converter option (or via a fragment) might be > added to Aries? > > > > JP > > > > *De :* CLEMENT Jean-Philippe [mailto:jean-philippe.clement@ > fr.thalesgroup.com] > *Envoyé :* mardi 27 septembre 2016 11:12 > > *À :* [email protected] > *Objet :* RE: Blueprint issue with generics > > > > This example is a bit particular as “<value>3</value>” has no type. This > is not the case in the issue I’m facing: both bean, injected one and > injection receiver have a type. Maybe it would be List<?> injected in a > List<String> which is kind of incorrect but, in Java there cannot be two > methods, one with a List<String> and another with a List<Number>. So there > can be only one match. Or it’s a bug which will lead to a > ClassCastException somewhere but this is another story, not a Blueprint > concern. > > > > So I would say: > > · If the injected object has no type, then yes, there is no other > choice than trying to convert to the closest type including generic part > > · If the injected object has a type then it should be taken as > assumption that the generic type part is correct as it is the only solution > that is available with regards to the Java type erasure specificity > > > > Moreover, what’s the failure added value? Could be more interesting to > have a fallback strategy isn’t it? > > > > JP > > > > *De :* Guillaume Nodet [mailto:[email protected] <[email protected]>] > *Envoyé :* lundi 26 septembre 2016 21:36 > *À :* [email protected] > *Objet :* Re: Blueprint issue with generics > > > > Again, I'm really not sure that would be a good idea. > > Some use cases are really useful when actually leveraging parameterized > types and conversions. > > For example, you can have: > > > > <bean class="org.foo.MyBean"> > > <argument> > > <list> > > <value>3</value> > > <value>5</value> > > </list> > > </argument> > > </bean> > > > > With > > > > public class MyBean { > > public MyBean(List<Integer> values) { > > } > > } > > > > If we were to enable the conversion globally, all those use cases would > run into ClassCastException. > > See for example http://stackoverflow.com/questions/7738305/spring- > conversion-service-from-lista-to-listb > > > > So blueprint does not simply reject things, it does indeed try to convert > to the correct type to ensure no ClassCastException can be thrown. > > > > I also think that it's the way Spring 4 and CDI work... > > > > Guillaume > > > > > > 2016-09-26 18:30 GMT+02:00 CLEMENT Jean-Philippe < > [email protected]>: > > Yep… or maybe have a flag in order Aries to use either the current > generic-aware converter or the non-generic one :) > > > > (please please please!) > > > > Regards, > > JP > > > > *De :* Guillaume Nodet [mailto:[email protected]] > *Envoyé :* lundi 26 septembre 2016 18:01 > > > *À :* [email protected] > *Objet :* Re: Blueprint issue with generics > > > > 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 < > [email protected]>: > > 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:[email protected]] > *Envoyé :* lundi 26 septembre 2016 15:19 > > > *À :* [email protected] > *Objet :* Re: Blueprint issue with generics > > > > Have you been able to try the converter ? > > > > 2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[email protected]>: > > > > > > 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe < > [email protected]>: > > 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:[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]>: > > 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 > *À :* [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] > <[email protected]>] > *Envoyé :* jeudi 11 février 2016 22:39 > *À :* [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]> 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] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > > > > > > -- > > ------------------------ > Guillaume Nodet > ------------------------ > > Red Hat, Open Source Integration > > > > Email: [email protected] > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
