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>:
> 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>:
>
> 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/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
