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] Envoyé : lundi 26 septembre 2016 18:01 À : 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/
