Blueprint issue with generics

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Blueprint issue with generics

CLEMENT Jean-Philippe
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 @@]


Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Benjamin Doerr
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 <[hidden email]> 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 @@]



Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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 @@]

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Jean-Baptiste Onofré
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:[hidden email]]
> *Envoyé :* jeudi 11 février 2016 22:39
> *À :* [hidden email]
> *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
> <[hidden email]
> <mailto:[hidden email]>> 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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe
In reply to this post by Benjamin Doerr

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:[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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 @@]

 

Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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 @@]

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36
À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2


2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2
Have you been able to try the converter ?

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:


2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration





--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19
À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2
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.

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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 18:01


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 21:36
À : [hidden email]
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.

 

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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 18:01


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 

Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

Hi Guillaume,

 

Do you think a fallback converter option (or via a fragment) might be added to Aries?

 

JP

 

De : CLEMENT Jean-Philippe [mailto:[hidden email]]
Envoyé : mardi 27 septembre 2016 11:12
À : [hidden email]
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 [[hidden email]]
Envoyé : lundi 26 septembre 2016 21:36
À : [hidden email]
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.

 

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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 18:01


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Blueprint issue with generics

Guillaume Nodet-2
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 <[hidden email]>:

Hi Guillaume,

 

Do you think a fallback converter option (or via a fragment) might be added to Aries?

 

JP

 

De : CLEMENT Jean-Philippe [mailto:[hidden email]]
Envoyé : mardi 27 septembre 2016 11:12


À : [hidden email]
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 [[hidden email]]
Envoyé : lundi 26 septembre 2016 21:36
À : [hidden email]
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.

 

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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 18:01


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 




--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration


Reply | Threaded
Open this post in threaded view
|

RE: Blueprint issue with generics

CLEMENT Jean-Philippe

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:[hidden email]]
Envoyé : vendredi 30 septembre 2016 12:07
À : [hidden email]
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 <[hidden email]>:

Hi Guillaume,

 

Do you think a fallback converter option (or via a fragment) might be added to Aries?

 

JP

 

De : CLEMENT Jean-Philippe [mailto:[hidden email]]
Envoyé : mardi 27 septembre 2016 11:12


À : [hidden email]
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 [[hidden email]]
Envoyé : lundi 26 septembre 2016 21:36
À : [hidden email]
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.

 

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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 18:01


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : lundi 26 septembre 2016 15:19


À : [hidden email]
Objet : Re: Blueprint issue with generics

 

Have you been able to try the converter ?

 

2016-09-23 13:07 GMT+02:00 Guillaume Nodet <[hidden email]>:

 

 

2016-09-23 12:22 GMT+02:00 CLEMENT Jean-Philippe <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 23 septembre 2016 11:36


À : [hidden email]
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 <[hidden email]>:

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:[hidden email]]
Envoyé : vendredi 16 septembre 2016 14:29
À : [hidden email]
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 [[hidden email]]
Envoyé : jeudi 11 février 2016 22:39
À : [hidden email]
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 <[hidden email]> 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

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration

 

 



 

--

------------------------
Guillaume Nodet
------------------------

Red Hat, Open Source Integration