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:gno...@apache.org] Envoyé : lundi 26 septembre 2016 21:36 À : user@aries.apache.org 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 <jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>: 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:gno...@apache.org<mailto:gno...@apache.org>] Envoyé : lundi 26 septembre 2016 18:01 À : user@aries.apache.org<mailto:user@aries.apache.org> 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 <jean-philippe.clem...@fr.thalesgroup.com<mailto: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<mailto:gno...@apache.org>] Envoyé : lundi 26 septembre 2016 15:19 À : user@aries.apache.org<mailto: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<mailto:gno...@apache.org>>: 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com<mailto: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<mailto:gno...@apache.org>] Envoyé : vendredi 23 septembre 2016 11:36 À : user@aries.apache.org<mailto: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<mailto: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.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>] Envoyé : vendredi 16 septembre 2016 14:29 À : user@aries.apache.org<mailto: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] Envoyé : jeudi 11 février 2016 22:39 À : user@aries.apache.org<mailto: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<mailto: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<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/ -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/
