You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com> on 2016/02/11 10:10:26 UTC
Blueprint issue with generics
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 @@]
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
Ah ok. If it’s a matter of toggling the mode, could be even more easy to have a flag in the config.properties. Something like “org.apache.aries.blueprint.allow-erasure-conversion”.
I may give it a try to look at the code and maybe find a solution, but I doubt I would be able to push back the code as we have access restrictions. Anyway if the patch is not big I may send the files via emails.
Where to start?
PS: Guillaume, are you the entire Aries team?
JP
De : Guillaume Nodet [mailto:gnodet@apache.org]
Envoyé : vendredi 30 septembre 2016 12:07
À : user@aries.apache.org
Objet : Re: Blueprint issue with generics
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 <je...@fr.thalesgroup.com>>:
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<ma...@fr.thalesgroup.com>]
Envoyé : mardi 27 septembre 2016 11:12
À : user@aries.apache.org<ma...@aries.apache.org>
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:gnodet@apache.org]
Envoyé : lundi 26 septembre 2016 21:36
À : user@aries.apache.org<ma...@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<ma...@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<ma...@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 <gn...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<ma...@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
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 <
jean-philippe.clement@fr.thalesgroup.com>:
> 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
>
> *À :* user@aries.apache.org
> *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:gnodet@apache.org <gn...@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.clement@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:gnodet@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.clement@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:gnodet@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 <gn...@apache.org>:
>
>
>
>
>
> 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clement@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:gnodet@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.clement@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:craftsman@bendoerr.me
> <cr...@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.clement@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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
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
À : user@aries.apache.org
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:gnodet@apache.org]
Envoyé : lundi 26 septembre 2016 21:36
À : user@aries.apache.org<ma...@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<ma...@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<ma...@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 <gn...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<ma...@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
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:gnodet@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<ma...@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<ma...@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 <gn...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<ma...@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
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.clement@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:gnodet@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.clement@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:gnodet@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 <gn...@apache.org>:
>
>
>
>
>
> 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clement@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:gnodet@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.clement@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:craftsman@bendoerr.me
> <cr...@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.clement@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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@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:gnodet@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 <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<ma...@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 <gn...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<ma...@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
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.clement@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:gnodet@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 <gn...@apache.org>:
>
>
>
>
>
> 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clement@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:gnodet@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.clement@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:craftsman@bendoerr.me
> <cr...@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.clement@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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@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:gnodet@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 <gn...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <je...@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:gnodet@apache.org<ma...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<ma...@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
Have you been able to try the converter ?
2016-09-23 13:07 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
>
>
> 2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clement@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:gnodet@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.clement@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:craftsman@bendoerr.me
>> <cr...@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.clement@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: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <
jean-philippe.clement@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:gnodet@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.clement@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:craftsman@bendoerr.me
> <cr...@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.clement@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: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@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?
Having said that, why having extra converters and Blueprint to get no added value?
JP
De : Guillaume Nodet [mailto:gnodet@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 <je...@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<ma...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<ma...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: Blueprint issue with generics
Posted by Guillaume Nodet <gn...@apache.org>.
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.clement@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:craftsman@bendoerr.me
> <cr...@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.clement@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: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@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:craftsman@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<ma...@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 <je...@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 @@]
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
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:craftsman@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 <je...@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 @@]
Re: Blueprint issue with generics
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi JP,
thanks for the update.
Let's take a look on that.
Regards
JB
On 03/02/2016 04:58 PM, CLEMENT Jean-Philippe wrote:
> Dear Aries Team,
>
> It is really a pain to use Blueprint with generics. I hope a fix could
> be done. I opened the following Jira for this:
> https://issues.apache.org/jira/browse/ARIES-1500
>
> Thank you.
>
> Kind regards,
>
> JP
>
> *De :*Benjamin Doerr [mailto:craftsman@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.clement@fr.thalesgroup.com
> <ma...@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 @@]
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Blueprint issue with generics
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
Dear Aries Team,
It is really a pain to use Blueprint with generics. I hope a fix could be done. I opened the following Jira for this: https://issues.apache.org/jira/browse/ARIES-1500
Thank you.
Kind regards,
JP
De : Benjamin Doerr [mailto:craftsman@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 <je...@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 @@]
Re: Blueprint issue with generics
Posted by Benjamin Doerr <cr...@bendoerr.me>.
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.clement@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 @@]
>
>
>