RE: Blueprint issue with generics
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:gno...@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
element:
...
Cheers,
Guillaume
2016-09-30 10:55 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@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.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : mardi 27 septembre 2016 11:12
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : RE: Blueprint issue with generics
This example is a bit particular as “3” 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
which is kind of incorrect but, in Java there cannot be two methods, one with a
List and another with a List. So there can be only one match.
Or it’s a bug which will lead to a ClassCastException somewhere but this is
another story, not a Blueprint concern.
So I would say:
• If the injected object has no type, then yes, there is no other
choice than trying to convert to the closest type including generic part
• If the injected object has a type then it should be taken as
assumption that the generic type part is correct as it is the only solution
that is available with regards to the Java type erasure specificity
Moreover, what’s the failure added value? Could be more interesting to have a
fallback strategy isn’t it?
JP
De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 26 septembre 2016 21:36
À : user@aries.apache.org<mailto: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:
3
5
With
public class MyBean {
public MyBean(List values) {
}
}
If we were to enable the conversion globally, all those use cases would run
into ClassCastException.
See for example
http://stackoverflow.com/questions/7738305/spring-conversion-service-from-lista-to-listb
So blueprint does not simply reject things, it does indeed try to convert to
the correct type to ensure no ClassCastException can be thrown.
I also think that it's the way Spring 4 and CDI work...
Guillaume
2016-09-26 18:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Yep… or maybe have a flag in order Aries to use either the current
generic-aware converter or the non-generic one :)
(please please please!)
Regards,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
I checked the code, but that's currently the only way.
However, one possibility would be to move those 2 lines into a different
blueprint xml file, so that the same file can be included in all your bundles
more easily at build time, as blueprint will by default load all
OSGI-INF/blueprint/*.xml
Cheers
Guillaume Nodet
2016-09-26 17:47 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
Yep, did not had time to make a full test on all bundles, but the few bundles
with the Blueprint addition I tested start without the “unable to find
matching…” errors:
So it’s another workaround possibility, thanks! I’m not too sure
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
element:
...
Cheers,
Guillaume
2016-09-30 10:55 GMT+02:00 CLEMENT Jean-Philippe <
jean-philippe.clem...@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 “3” 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 which is kind of incorrect but, in Java there cannot be two
> methods, one with a List and another with a List. So there
> can be only one match. Or it’s a bug which will lead to a
> ClassCastException somewhere but this is another story, not a Blueprint
> concern.
>
>
>
> So I would say:
>
> · If the injected object has no type, then yes, there is no other
> choice than trying to convert to the closest type including generic part
>
> · If the injected object has a type then it should be taken as
> assumption that the generic type part is correct as it is the only solution
> that is available with regards to the Java type erasure specificity
>
>
>
> Moreover, what’s the failure added value? Could be more interesting to
> have a fallback strategy isn’t it?
>
>
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org <gno...@apache.org>]
> *Envoyé :* lundi 26 septembre 2016 21:36
> *À :* user@aries.apache.org
> *Objet :* Re: Blueprint issue with generics
>
>
>
> Again, I'm really not sure that would be a good idea.
>
> Some use cases are really useful when actually leveraging parameterized
> types and conversions.
>
> For example, you can have:
>
>
>
>
>
>
>
>
>
> 3
>
> 5
>
>
>
>
>
>
>
>
>
> With
>
>
>
> public class MyBean {
>
>public MyBean(List 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:
>
>
>
> rainbow.Converter”/>
>
>
>
>
>
> So it’s another workaround possibility, thanks! I’m not too sure of the
> overall start
RE: Blueprint issue with generics
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.clem...@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 “3” 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
which is kind of incorrect but, in Java there cannot be two methods, one with a
List and another with a List. So there can be only one match.
Or it’s a bug which will lead to a ClassCastException somewhere but this is
another story, not a Blueprint concern.
So I would say:
· If the injected object has no type, then yes, there is no other
choice than trying to convert to the closest type including generic part
· If the injected object has a type then it should be taken as
assumption that the generic type part is correct as it is the only solution
that is available with regards to the Java type erasure specificity
Moreover, what’s the failure added value? Could be more interesting to have a
fallback strategy isn’t it?
JP
De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 26 septembre 2016 21:36
À : user@aries.apache.org<mailto: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:
3
5
With
public class MyBean {
public MyBean(List values) {
}
}
If we were to enable the conversion globally, all those use cases would run
into ClassCastException.
See for example
http://stackoverflow.com/questions/7738305/spring-conversion-service-from-lista-to-listb
So blueprint does not simply reject things, it does indeed try to convert to
the correct type to ensure no ClassCastException can be thrown.
I also think that it's the way Spring 4 and CDI work...
Guillaume
2016-09-26 18:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Yep… or maybe have a flag in order Aries to use either the current
generic-aware converter or the non-generic one :)
(please please please!)
Regards,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
I checked the code, but that's currently the only way.
However, one possibility would be to move those 2 lines into a different
blueprint xml file, so that the same file can be included in all your bundles
more easily at build time, as blueprint will by default load all
OSGI-INF/blueprint/*.xml
Cheers
Guillaume Nodet
2016-09-26 17:47 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
Yep, did not had time to make a full test on all bundles, but the few bundles
with the Blueprint addition I tested start without the “unable to find
matching…” errors:
So it’s another workaround possibility, thanks! I’m not too sure of the overall
startup time impact, but I hope it would be small.
The thing is it’s a bit heavy to declare the workaround (although it’s three
lines of XML) in almost every bundle. Is there a way to declare a global
converter available everywhere?
Thanks,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Have you been able to try the converter ?
2016-09-23 13:07 GMT+02:00 Guillaume Nodet
<gno...@apache.org<mailto:gno...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
We do have a lot of classes used in the blueprint which use generics and fail.
As far as I understand each of those classes should have a converter and each
bundle making use of them should declare the 2-3 lines you mentioned per
converter, correct?
The converters are always called. I don't see why you'd need multiple
converters, it should be fairly easy to write one which will simply convert all
erased types to the equivalent with a generic, and that should solve all your
problems.
Having said that, why having extra converters and Blueprint to get no added
value?
Because that's how the spec has been written. We already implemented more that
what the spec says with ARIES-1500, and I th
RE: Blueprint issue with generics
This example is a bit particular as “3” 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
which is kind of incorrect but, in Java there cannot be two methods, one with a
List and another with a List. So there can be only one match.
Or it’s a bug which will lead to a ClassCastException somewhere but this is
another story, not a Blueprint concern.
So I would say:
· If the injected object has no type, then yes, there is no other
choice than trying to convert to the closest type including generic part
· If the injected object has a type then it should be taken as
assumption that the generic type part is correct as it is the only solution
that is available with regards to the Java type erasure specificity
Moreover, what’s the failure added value? Could be more interesting to have a
fallback strategy isn’t it?
JP
De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 26 septembre 2016 21:36
À : user@aries.apache.org
Objet : Re: Blueprint issue with generics
Again, I'm really not sure that would be a good idea.
Some use cases are really useful when actually leveraging parameterized types
and conversions.
For example, you can have:
3
5
With
public class MyBean {
public MyBean(List values) {
}
}
If we were to enable the conversion globally, all those use cases would run
into ClassCastException.
See for example
http://stackoverflow.com/questions/7738305/spring-conversion-service-from-lista-to-listb
So blueprint does not simply reject things, it does indeed try to convert to
the correct type to ensure no ClassCastException can be thrown.
I also think that it's the way Spring 4 and CDI work...
Guillaume
2016-09-26 18:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Yep… or maybe have a flag in order Aries to use either the current
generic-aware converter or the non-generic one :)
(please please please!)
Regards,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
I checked the code, but that's currently the only way.
However, one possibility would be to move those 2 lines into a different
blueprint xml file, so that the same file can be included in all your bundles
more easily at build time, as blueprint will by default load all
OSGI-INF/blueprint/*.xml
Cheers
Guillaume Nodet
2016-09-26 17:47 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
Yep, did not had time to make a full test on all bundles, but the few bundles
with the Blueprint addition I tested start without the “unable to find
matching…” errors:
So it’s another workaround possibility, thanks! I’m not too sure of the overall
startup time impact, but I hope it would be small.
The thing is it’s a bit heavy to declare the workaround (although it’s three
lines of XML) in almost every bundle. Is there a way to declare a global
converter available everywhere?
Thanks,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Have you been able to try the converter ?
2016-09-23 13:07 GMT+02:00 Guillaume Nodet
<gno...@apache.org<mailto:gno...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
We do have a lot of classes used in the blueprint which use generics and fail.
As far as I understand each of those classes should have a converter and each
bundle making use of them should declare the 2-3 lines you mentioned per
converter, correct?
The converters are always called. I don't see why you'd need multiple
converters, it should be fairly easy to write one which will simply convert all
erased types to the equivalent with a generic, and that should solve all your
problems.
Having said that, why having extra converters and Blueprint to get no added
value?
Because that's how the spec has been written. We already implemented more that
what the spec says with ARIES-1500, and I think there's an easy work around.
So please try the workaround first, and we'll see how it goes.
Here's the converter code you can try:
public class ErasureConverter implements Converter {
@Override
public boolean canConvert(Object sourceObject, ReifiedType targetType) {
return targetType.getRawClass().isInsta
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:
3
5
With
public class MyBean {
public MyBean(List 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:
>
>
>
> rainbow.Converter”/>
>
>
>
>
>
> 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>:
>
> De
RE: Blueprint issue with generics
Yep… or maybe have a flag in order Aries to use either the current
generic-aware converter or the non-generic one :)
(please please please!)
Regards,
JP
De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 26 septembre 2016 18:01
À : user@aries.apache.org
Objet : Re: Blueprint issue with generics
I checked the code, but that's currently the only way.
However, one possibility would be to move those 2 lines into a different
blueprint xml file, so that the same file can be included in all your bundles
more easily at build time, as blueprint will by default load all
OSGI-INF/blueprint/*.xml
Cheers
Guillaume Nodet
2016-09-26 17:47 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
Yep, did not had time to make a full test on all bundles, but the few bundles
with the Blueprint addition I tested start without the “unable to find
matching…” errors:
So it’s another workaround possibility, thanks! I’m not too sure of the overall
startup time impact, but I hope it would be small.
The thing is it’s a bit heavy to declare the workaround (although it’s three
lines of XML) in almost every bundle. Is there a way to declare a global
converter available everywhere?
Thanks,
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 26 septembre 2016 15:19
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Have you been able to try the converter ?
2016-09-23 13:07 GMT+02:00 Guillaume Nodet
<gno...@apache.org<mailto:gno...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
We do have a lot of classes used in the blueprint which use generics and fail.
As far as I understand each of those classes should have a converter and each
bundle making use of them should declare the 2-3 lines you mentioned per
converter, correct?
The converters are always called. I don't see why you'd need multiple
converters, it should be fairly easy to write one which will simply convert all
erased types to the equivalent with a generic, and that should solve all your
problems.
Having said that, why having extra converters and Blueprint to get no added
value?
Because that's how the spec has been written. We already implemented more that
what the spec says with ARIES-1500, and I think there's an easy work around.
So please try the workaround first, and we'll see how it goes.
Here's the converter code you can try:
public class ErasureConverter implements Converter {
@Override
public boolean canConvert(Object sourceObject, ReifiedType targetType) {
return targetType.getRawClass().isInstance(sourceObject);
}
@Override
public Object convert(Object sourceObject, ReifiedType targetType) throws
Exception {
return sourceObject;
}
}
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Have you tried using a Converter ? This should fix all your problems quite
easily, it's only 2 or 3 lines to add to your blueprint.
2016-09-23 11:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Dear Aries Team,
The Jira (ARIES-1607) is not assigned. Does it mean it won’t be fixed?
Regards,
JP
De : CLEMENT Jean-Philippe
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : RE: Blueprint issue with generics
I finally opened a Jira about this issue as I still get problems caused by the
injection checking system which goes far beyond expectations.
https://issues.apache.org/jira/browse/ARIES-1607
I hope it could be fixed :)
Thank you!
Kind regards,
JP
De : Benjamin Doerr [mailto:crafts...@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Also would love to see this fixed. My workaround is usually this:
void setSomething(Something s)
to
> setSomething(S s)
which maintains the compile type checking. And like Jean-Philippe, third-party
APIs mean that if I can I have to create a local extension with a hacked setter
just to make blueprint happy.
Best Regards,
Benjamin Doerr
On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>
wrote:
Dear Aries Team,
I
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:
>
>
>
> rainbow.Converter”/>
>
>
>
>
>
> 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 s)
>
> to
>
> > 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 sett
RE: Blueprint issue with generics
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:
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<mailto:gno...@apache.org>>:
2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,
We do have a lot of classes used in the blueprint which use generics and fail.
As far as I understand each of those classes should have a converter and each
bundle making use of them should declare the 2-3 lines you mentioned per
converter, correct?
The converters are always called. I don't see why you'd need multiple
converters, it should be fairly easy to write one which will simply convert all
erased types to the equivalent with a generic, and that should solve all your
problems.
Having said that, why having extra converters and Blueprint to get no added
value?
Because that's how the spec has been written. We already implemented more that
what the spec says with ARIES-1500, and I think there's an easy work around.
So please try the workaround first, and we'll see how it goes.
Here's the converter code you can try:
public class ErasureConverter implements Converter {
@Override
public boolean canConvert(Object sourceObject, ReifiedType targetType) {
return targetType.getRawClass().isInstance(sourceObject);
}
@Override
public Object convert(Object sourceObject, ReifiedType targetType) throws
Exception {
return sourceObject;
}
}
JP
De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : vendredi 23 septembre 2016 11:36
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Have you tried using a Converter ? This should fix all your problems quite
easily, it's only 2 or 3 lines to add to your blueprint.
2016-09-23 11:30 GMT+02:00 CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Dear Aries Team,
The Jira (ARIES-1607) is not assigned. Does it mean it won’t be fixed?
Regards,
JP
De : CLEMENT Jean-Philippe
[mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>]
Envoyé : vendredi 16 septembre 2016 14:29
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : RE: Blueprint issue with generics
I finally opened a Jira about this issue as I still get problems caused by the
injection checking system which goes far beyond expectations.
https://issues.apache.org/jira/browse/ARIES-1607
I hope it could be fixed :)
Thank you!
Kind regards,
JP
De : Benjamin Doerr [mailto:crafts...@bendoerr.me]
Envoyé : jeudi 11 février 2016 22:39
À : user@aries.apache.org<mailto:user@aries.apache.org>
Objet : Re: Blueprint issue with generics
Also would love to see this fixed. My workaround is usually this:
void setSomething(Something s)
to
> setSomething(S s)
which maintains the compile type checking. And like Jean-Philippe, third-party
APIs mean that if I can I have to create a local extension with a hacked setter
just to make blueprint happy.
Best Regards,
Benjamin Doerr
On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>
wrote:
Dear Aries Team,
I have an issue with the way generics are handled in Blueprint. I get an
exception claiming that the bean conversion is not possible, but it should.
Let's say I have a bean with the method setSomething(Something) 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 @@]
--
Guill
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 s)
>>
>> to
>>
>> > 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) 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/
Re: Blueprint issue with generics
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 s)
>
> to
>
> > 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) 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/
RE: Blueprint issue with generics
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: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<mailto:jean-philippe.clem...@fr.thalesgroup.com>>: Dear Aries Team, The Jira (ARIES-1607) is not assigned. Does it mean it won’t be fixed? Regards, JP De : CLEMENT Jean-Philippe [mailto:jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>] Envoyé : vendredi 16 septembre 2016 14:29 À : user@aries.apache.org<mailto:user@aries.apache.org> Objet : RE: Blueprint issue with generics I finally opened a Jira about this issue as I still get problems caused by the injection checking system which goes far beyond expectations. https://issues.apache.org/jira/browse/ARIES-1607 I hope it could be fixed :) Thank you! Kind regards, JP De : Benjamin Doerr [mailto:crafts...@bendoerr.me] Envoyé : jeudi 11 février 2016 22:39 À : user@aries.apache.org<mailto:user@aries.apache.org> Objet : Re: Blueprint issue with generics Also would love to see this fixed. My workaround is usually this: void setSomething(Something s) to > setSomething(S s) which maintains the compile type checking. And like Jean-Philippe, third-party APIs mean that if I can I have to create a local extension with a hacked setter just to make blueprint happy. Best Regards, Benjamin Doerr On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>> wrote: Dear Aries Team, I have an issue with the way generics are handled in Blueprint. I get an exception claiming that the bean conversion is not possible, but it should. Let's say I have a bean with the method setSomething(Something) called via blueprint with another bean implementing Something => exception. If I change the method signature without the generic type setSomething(Something), then it works as expected. Until now I did workaround by changing the method signatures and logging a warning but now I'm blocked with a third-party API. So I have to find a real solution. I don't catch why Blueprint cares for the generic type as Java is type erasure. So it seems to exceed Java spec. Is there a way to comply with Java type erasure, i.e. discard generic types when "converting" beans? Regards, JP [@@ OPEN @@] -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com<mailto:gno...@redhat.com> Web: http://fusesource.com<http://fusesource.com/> Blog: http://gnodet.blogspot.com/
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 s) > > to > > > 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) 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/
RE: Blueprint issue with generics
I finally opened a Jira about this issue as I still get problems caused by the injection checking system which goes far beyond expectations. https://issues.apache.org/jira/browse/ARIES-1607 I hope it could be fixed :) Thank you! Kind regards, JP De : Benjamin Doerr [mailto:crafts...@bendoerr.me] Envoyé : jeudi 11 février 2016 22:39 À : user@aries.apache.org Objet : Re: Blueprint issue with generics Also would love to see this fixed. My workaround is usually this: void setSomething(Something s) to > setSomething(S s) which maintains the compile type checking. And like Jean-Philippe, third-party APIs mean that if I can I have to create a local extension with a hacked setter just to make blueprint happy. Best Regards, Benjamin Doerr On Thu, Feb 11, 2016 at 4:10 AM, CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>> wrote: Dear Aries Team, I have an issue with the way generics are handled in Blueprint. I get an exception claiming that the bean conversion is not possible, but it should. Let's say I have a bean with the method setSomething(Something) 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
Also would love to see this fixed. My workaround is usually this: void setSomething(Something s) to > 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) 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 @@] > > >
