RE: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-04 Thread CLEMENT Jean-Philippe 
Ok crystal clear, thank you for the detailed explanation.

As we need synchronization in order to remove the first launch bug in our apps, 
we will have to use  instead of . Inlining configuration in 
the tag would not be handy; it would be really nice to have a “location” 
option. I raised the KARAF-5082 JIRA for this.

Kind regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : mardi 4 avril 2017 15:44
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Configuration files for ConfigAdmin are supposed to be used with the  
element.
The  element has been designed to support non-configadmin files, 
such as xml, binaries, or whatever.

In both cases, when they come from a feature, they will be installed to the 
file system before the bundles listed in the features are started.
The problem is that if you're using  instead of , the 
configuration won't be pushed to ConfigAdmin by the features service.  They 
will only end up in ConfigAdmin through fileinstall, and that's an asynchronous 
process.

In short, the current design is the following:
 * when using , the configuration is written synchronously to the disk 
and config admin
 * when using , the file is written synchronously to the disk

Your use case about expecting a synchronous write to config admin when using 
 is not supported currently.

The standard way to use  is to inline the configuration, see a very 
simple example here:

https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L876-L879
If you really need the location attribute on the  element, please raise 
a JIRA.


2017-04-04 14:39 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

Sorry, I’m lost :)

At present time I guess we use “regular” .cfg files (key/value pairs in basic 
string format) via configfile tags. The issue is that they are populated in the 
/etc directory at the same time bundles start (during the very first start), so 
bundles may - or may not - find configuration properties. Here is an example of 
how we use configfile tags:

mvn:some.example/whatever/1.0.0/cfg

As far as I understand bundles start and copy of .cfg file to etc being in 
parallel seems to be a nominal case and we should use the config tag instead of 
configfile to get .cfg files in the /etc before bundles start. Ok, so now I 
wonder how to use .cfg files with the config tag. I’m not complaining about 
anything… just trying to find out how it works.


>  When used properly, config files are pushed to ConfigAdmin before bundles 
> are started

Something like mvn:some.example/whatever/1.0.0/cfg?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 19:26
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Btw, I closed the jira because the initial problem is not a problem per se.  
When used properly, config files are pushed to ConfigAdmin before bundles are 
started.  This only happen because of the use of  those typed  properties files 
which aren't really supported yet.

2017-04-03 19:22 GMT+02:00 Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>>:
You can use a properties file.  Afaik, there's no problem with them and they 
are fully supported.
Config files with typed properties will be supported through 
KARAF-5074<https://issues.apache.org/jira/browse/KARAF-5074> which is a new 
feature.

For the location attribute, a new JIRA would be required.  But if you're 
planning to use typed config files and use that attribute as a work around, 
that's a bad idea, as other parts of Karaf will not support it.

Btw, if you want to speed up things a bit, as you seem quite vocal, one way 
would be to provide some patches.

2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as 
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior 
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor



2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
I understand your point and you’re right, it’s better to test things early than 
let the system crash later on. To go further I guess the Blueprint spec would 
have to be enhanced to fully support generics, for instance to be able to 
instantiate an ArrayList bean, to expose and retrieve services with 
generics signature etc.

That's

Re: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-04 Thread Guillaume Nodet 
Configuration files for ConfigAdmin are supposed to be used with the
 element.
The  element has been designed to support non-configadmin
files, such as xml, binaries, or whatever.

In both cases, when they come from a feature, they will be installed to the
file system before the bundles listed in the features are started.
The problem is that if you're using  instead of , the
configuration won't be pushed to ConfigAdmin by the features service.  They
will only end up in ConfigAdmin through fileinstall, and that's an
asynchronous process.

In short, the current design is the following:
 * when using , the configuration is written synchronously to the
disk and config admin
 * when using , the file is written synchronously to the disk

Your use case about expecting a synchronous write to config admin when
using  is not supported currently.

The standard way to use  is to inline the configuration, see a very
simple example here:

https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L876-L879
If you really need the location attribute on the  element, please
raise a JIRA.


2017-04-04 14:39 GMT+02:00 CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com>:

> Hi Guillaume,
>
>
>
> Sorry, I’m lost :)
>
>
>
> At present time I guess we use “regular” .cfg files (key/value pairs in
> basic string format) via configfile tags. The issue is that they are
> populated in the /etc directory at the same time bundles start (during the
> very first start), so bundles may - or may not - find configuration
> properties. Here is an example of how we use configfile tags:
>
>
>
> 
> mvn:some.example/whatever/1.0.0/cfg
>
>
>
> As far as I understand bundles start and copy of .cfg file to etc being in
> parallel seems to be a nominal case and we should use the config tag
> instead of configfile to get .cfg files in the /etc before bundles start.
> Ok, so now I wonder how to use .cfg files with the config tag. I’m not
> complaining about anything… just trying to find out how it works.
>
>
>
> Ø  When used properly, config files are pushed to ConfigAdmin before
> bundles are started
>
>
>
> Something like mvn:some.
> example/whatever/1.0.0/cfg?
>
>
>
> Regards,
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org]
> *Envoyé :* lundi 3 avril 2017 19:26
> *À :* user
> *Objet :* Re: https://issues.apache.org/jira/browse/KARAF-4829
>
>
>
> Btw, I closed the jira because the initial problem is not a problem per
> se.  When used properly, config files are pushed to ConfigAdmin before
> bundles are started.  This only happen because of the use of  those typed
>  properties files which aren't really supported yet.
>
>
>
> 2017-04-03 19:22 GMT+02:00 Guillaume Nodet <gno...@apache.org>:
>
> You can use a properties file.  Afaik, there's no problem with them and
> they are fully supported.
>
> Config files with typed properties will be supported through KARAF-5074
> <https://issues.apache.org/jira/browse/KARAF-5074> which is a new feature.
>
>
>
> For the location attribute, a new JIRA would be required.  But if you're
> planning to use typed config files and use that attribute as a work around,
> that's a bad idea, as other parts of Karaf will not support it.
>
>
>
> Btw, if you want to speed up things a bit, as you seem quite vocal, one
> way would be to provide some patches.
>
>
>
> 2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com>:
>
> Hi,
>
>
>
> The issue KARAF-4829 was closed. I thought I could now use the config tag
> as long with a location attribute, but I’m wrong!
>
>
>
> How to configure a feature in order configuration files to be installed
> prior to bundle startup?
>
>
>
> Thanks!
>
>
>
> Regards,
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org]
> *Envoyé :* lundi 3 avril 2017 18:18
> *À :* user
> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>
>
>
>
>
>
>
> 2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com>:
>
> I understand your point and you’re right, it’s better to test things early
> than let the system crash later on. To go further I guess the Blueprint
> spec would have to be enhanced to fully support generics, for instance to
> be able to instantiate an ArrayList bean, to expose and retrieve
> services with generics signature etc.
>
>
>
> That's what I did to some degree with my ARIES-960 branch:
>
>   https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core
>
>
>
>

RE: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-04 Thread CLEMENT Jean-Philippe 
Hi Guillaume,

Sorry, I’m lost :)

At present time I guess we use “regular” .cfg files (key/value pairs in basic 
string format) via configfile tags. The issue is that they are populated in the 
/etc directory at the same time bundles start (during the very first start), so 
bundles may - or may not - find configuration properties. Here is an example of 
how we use configfile tags:

mvn:some.example/whatever/1.0.0/cfg

As far as I understand bundles start and copy of .cfg file to etc being in 
parallel seems to be a nominal case and we should use the config tag instead of 
configfile to get .cfg files in the /etc before bundles start. Ok, so now I 
wonder how to use .cfg files with the config tag. I’m not complaining about 
anything… just trying to find out how it works.


Ø  When used properly, config files are pushed to ConfigAdmin before bundles 
are started

Something like mvn:some.example/whatever/1.0.0/cfg?

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 19:26
À : user
Objet : Re: https://issues.apache.org/jira/browse/KARAF-4829

Btw, I closed the jira because the initial problem is not a problem per se.  
When used properly, config files are pushed to ConfigAdmin before bundles are 
started.  This only happen because of the use of  those typed  properties files 
which aren't really supported yet.

2017-04-03 19:22 GMT+02:00 Guillaume Nodet 
<gno...@apache.org<mailto:gno...@apache.org>>:
You can use a properties file.  Afaik, there's no problem with them and they 
are fully supported.
Config files with typed properties will be supported through 
KARAF-5074<https://issues.apache.org/jira/browse/KARAF-5074> which is a new 
feature.

For the location attribute, a new JIRA would be required.  But if you're 
planning to use typed config files and use that attribute as a work around, 
that's a bad idea, as other parts of Karaf will not support it.

Btw, if you want to speed up things a bit, as you seem quite vocal, one way 
would be to provide some patches.

2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as 
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior 
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor



2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
I understand your point and you’re right, it’s better to test things early than 
let the system crash later on. To go further I guess the Blueprint spec would 
have to be enhanced to fully support generics, for instance to be able to 
instantiate an ArrayList bean, to expose and retrieve services with 
generics signature etc.

That's what I did to some degree with my ARIES-960 branch:
  https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core

That's why I'd like some people to look at it and see if their actual use case 
works.
From that point:
  * they work, and that's great
  * they don't work and they should, and I'll work on fixing those
  * they don't work because they require ARIES-1633 which I don't have the time 
to implement in the short term
In the third case, I could look at adding a flag...


That said, a fallback strategy could also be welcome in the meantime. And it 
would be more efficient than letting the system try to convert, fail, then 
finally use the custom “erasure converter” defined in the Blueprint.

Would it be possible to get a nice generics defeat flag?

Please provide a test case for my ARIES-960 branch which falls into the third 
category above.


Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org<mailto:gno...@apache.org>]
Envoyé : lundi 3 avril 2017 16:30

À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

I still am not comfortable allowing casting List to List as we 
perfectly know what will happen.
Blueprint is not a compiler, but if you look at CDI, those kind of problems 
have been handled correctly for example, and CDI is not a compiler either, but 
both blueprint and CDI are dependency  injection framework, so there's no 
technical reason to not be able to support the use cases correctly, instead of 
allowing ClassCastException at a later time.

2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe 
<jean-philippe.clem...@fr.thalesgroup.com<mailto:jean-philippe.clem...@fr.thalesgroup.com>>:
Hi Guillaume,

As already discussed, Blueprint is not a compiler but a runtime library. Once 
compiled there is no more generics as Java is

Re: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-03 Thread Guillaume Nodet 
Btw, I closed the jira because the initial problem is not a problem per
se.  When used properly, config files are pushed to ConfigAdmin before
bundles are started.  This only happen because of the use of  those typed
 properties files which aren't really supported yet.

2017-04-03 19:22 GMT+02:00 Guillaume Nodet :

> You can use a properties file.  Afaik, there's no problem with them and
> they are fully supported.
> Config files with typed properties will be supported through KARAF-5074
>  which is a new feature.
>
> For the location attribute, a new JIRA would be required.  But if you're
> planning to use typed config files and use that attribute as a work around,
> that's a bad idea, as other parts of Karaf will not support it.
>
> Btw, if you want to speed up things a bit, as you seem quite vocal, one
> way would be to provide some patches.
>
> 2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com>:
>
>> Hi,
>>
>>
>>
>> The issue KARAF-4829 was closed. I thought I could now use the config tag
>> as long with a location attribute, but I’m wrong!
>>
>>
>>
>> How to configure a feature in order configuration files to be installed
>> prior to bundle startup?
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Regards,
>>
>> JP
>>
>>
>>
>> *De :* Guillaume Nodet [mailto:gno...@apache.org]
>> *Envoyé :* lundi 3 avril 2017 18:18
>> *À :* user
>> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>>
>>
>>
>>
>>
>>
>>
>> 2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe <
>> jean-philippe.clem...@fr.thalesgroup.com>:
>>
>> I understand your point and you’re right, it’s better to test things
>> early than let the system crash later on. To go further I guess the
>> Blueprint spec would have to be enhanced to fully support generics, for
>> instance to be able to instantiate an ArrayList bean, to expose and
>> retrieve services with generics signature etc.
>>
>>
>>
>> That's what I did to some degree with my ARIES-960 branch:
>>
>>   https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core
>>
>>
>>
>> That's why I'd like some people to look at it and see if their actual use
>> case works.
>>
>> From that point:
>>
>>   * they work, and that's great
>>
>>   * they don't work and they should, and I'll work on fixing those
>>
>>   * they don't work because they require ARIES-1633 which I don't have
>> the time to implement in the short term
>>
>> In the third case, I could look at adding a flag...
>>
>>
>>
>>
>>
>> That said, a fallback strategy could also be welcome in the meantime. And
>> it would be more efficient than letting the system try to convert, fail,
>> then finally use the custom “erasure converter” defined in the Blueprint.
>>
>>
>>
>> Would it be possible to get a nice generics defeat flag?
>>
>>
>>
>> Please provide a test case for my ARIES-960 branch which falls into the
>> third category above.
>>
>>
>>
>>
>>
>> Regards,
>>
>> JP
>>
>>
>>
>> *De :* Guillaume Nodet [mailto:gno...@apache.org]
>> *Envoyé :* lundi 3 avril 2017 16:30
>>
>>
>> *À :* user
>> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>>
>>
>>
>> I still am not comfortable allowing casting List to List
>> as we perfectly know what will happen.
>>
>> Blueprint is not a compiler, but if you look at CDI, those kind of
>> problems have been handled correctly for example, and CDI is not a compiler
>> either, but both blueprint and CDI are dependency  injection framework, so
>> there's no technical reason to not be able to support the use cases
>> correctly, instead of allowing ClassCastException at a later time.
>>
>>
>>
>> 2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe <
>> jean-philippe.clem...@fr.thalesgroup.com>:
>>
>> Hi Guillaume,
>>
>>
>>
>> As already discussed, Blueprint is not a compiler but a runtime library.
>> Once compiled there is no more generics as Java is a type erasure language.
>> Moreover, I’m not too sure how Blueprint may handle injection with things
>> like  S getSomething() where in java you can write myinstance.
>> getSomething().
>>
>>
>>
>> I still do have issues with injection and generics, so a global flag to
>> defeat Blueprint checking would be greatly appreciated :)
>>
>>
>>
>> JP
>>
>>
>>
>> *De :* Guillaume Nodet [mailto:gno...@apache.org]
>> *Envoyé :* lundi 3 avril 2017 14:31
>> *À :* user
>> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>>
>>
>>
>>  There are 2 different issues.
>>
>> One is type erasure, i.e. allow the invocation of a method taking a
>> List with a List for example.  That's ARIES-1607, and I
>> really think that's a bad idea, unless someone show me a good example where
>> it makes sense.  At least by default (well, it's against the blueprint spec
>> anyway).  A flag to turn on such a behavior (on a bean or globally) could
>> be an acceptable way, though.
>>
>>
>>
>> Another issue is ARIES-960 where the same

Re: https://issues.apache.org/jira/browse/KARAF-4829

2017-04-03 Thread Guillaume Nodet 
You can use a properties file.  Afaik, there's no problem with them and
they are fully supported.
Config files with typed properties will be supported through KARAF-5074
 which is a new feature.

For the location attribute, a new JIRA would be required.  But if you're
planning to use typed config files and use that attribute as a work around,
that's a bad idea, as other parts of Karaf will not support it.

Btw, if you want to speed up things a bit, as you seem quite vocal, one way
would be to provide some patches.

2017-04-03 18:41 GMT+02:00 CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com>:

> Hi,
>
>
>
> The issue KARAF-4829 was closed. I thought I could now use the config tag
> as long with a location attribute, but I’m wrong!
>
>
>
> How to configure a feature in order configuration files to be installed
> prior to bundle startup?
>
>
>
> Thanks!
>
>
>
> Regards,
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org]
> *Envoyé :* lundi 3 avril 2017 18:18
> *À :* user
> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>
>
>
>
>
>
>
> 2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com>:
>
> I understand your point and you’re right, it’s better to test things early
> than let the system crash later on. To go further I guess the Blueprint
> spec would have to be enhanced to fully support generics, for instance to
> be able to instantiate an ArrayList bean, to expose and retrieve
> services with generics signature etc.
>
>
>
> That's what I did to some degree with my ARIES-960 branch:
>
>   https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core
>
>
>
> That's why I'd like some people to look at it and see if their actual use
> case works.
>
> From that point:
>
>   * they work, and that's great
>
>   * they don't work and they should, and I'll work on fixing those
>
>   * they don't work because they require ARIES-1633 which I don't have the
> time to implement in the short term
>
> In the third case, I could look at adding a flag...
>
>
>
>
>
> That said, a fallback strategy could also be welcome in the meantime. And
> it would be more efficient than letting the system try to convert, fail,
> then finally use the custom “erasure converter” defined in the Blueprint.
>
>
>
> Would it be possible to get a nice generics defeat flag?
>
>
>
> Please provide a test case for my ARIES-960 branch which falls into the
> third category above.
>
>
>
>
>
> Regards,
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org]
> *Envoyé :* lundi 3 avril 2017 16:30
>
>
> *À :* user
> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>
>
>
> I still am not comfortable allowing casting List to List
> as we perfectly know what will happen.
>
> Blueprint is not a compiler, but if you look at CDI, those kind of
> problems have been handled correctly for example, and CDI is not a compiler
> either, but both blueprint and CDI are dependency  injection framework, so
> there's no technical reason to not be able to support the use cases
> correctly, instead of allowing ClassCastException at a later time.
>
>
>
> 2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com>:
>
> Hi Guillaume,
>
>
>
> As already discussed, Blueprint is not a compiler but a runtime library.
> Once compiled there is no more generics as Java is a type erasure language.
> Moreover, I’m not too sure how Blueprint may handle injection with things
> like  S getSomething() where in java you can write myinstance.
> getSomething().
>
>
>
> I still do have issues with injection and generics, so a global flag to
> defeat Blueprint checking would be greatly appreciated :)
>
>
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gno...@apache.org]
> *Envoyé :* lundi 3 avril 2017 14:31
> *À :* user
> *Objet :* Re: Blueprint fails instantiating bean with generic constructor
>
>
>
>  There are 2 different issues.
>
> One is type erasure, i.e. allow the invocation of a method taking a
> List with a List for example.  That's ARIES-1607, and I
> really think that's a bad idea, unless someone show me a good example where
> it makes sense.  At least by default (well, it's against the blueprint spec
> anyway).  A flag to turn on such a behavior (on a bean or globally) could
> be an acceptable way, though.
>
>
>
> Another issue is ARIES-960 where the same thing written in java would
> work.  That's a problem of type assignability verification and I'm willing
> to fix those.  I think that's more your use case.  There's a branch I
> created a while ago with some changes.  Could you check if your use case
> works with the code there ?
>
>
>
> In all cases, a workaround is always to provide a custom blueprint
> converter, as this would allow converting whatever you want to whatever is
> needed.
>
>
>
>
>
>
>
> 2017-04-03 11:23 GMT+02:00 CLEMENT Jean-Philippe <
>

https://issues.apache.org/jira/browse/KARAF-4829

2017-04-03 Thread CLEMENT Jean-Philippe 
Hi,

The issue KARAF-4829 was closed. I thought I could now use the config tag as 
long with a location attribute, but I’m wrong!

How to configure a feature in order configuration files to be installed prior 
to bundle startup?

Thanks!

Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 18:18
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor



2017-04-03 17:03 GMT+02:00 CLEMENT Jean-Philippe 
>:
I understand your point and you’re right, it’s better to test things early than 
let the system crash later on. To go further I guess the Blueprint spec would 
have to be enhanced to fully support generics, for instance to be able to 
instantiate an ArrayList bean, to expose and retrieve services with 
generics signature etc.

That's what I did to some degree with my ARIES-960 branch:
  https://github.com/gnodet/aries/tree/ARIES-960/blueprint/blueprint-core

That's why I'd like some people to look at it and see if their actual use case 
works.
From that point:
  * they work, and that's great
  * they don't work and they should, and I'll work on fixing those
  * they don't work because they require ARIES-1633 which I don't have the time 
to implement in the short term
In the third case, I could look at adding a flag...


That said, a fallback strategy could also be welcome in the meantime. And it 
would be more efficient than letting the system try to convert, fail, then 
finally use the custom “erasure converter” defined in the Blueprint.

Would it be possible to get a nice generics defeat flag?

Please provide a test case for my ARIES-960 branch which falls into the third 
category above.


Regards,
JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 16:30

À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

I still am not comfortable allowing casting List to List as we 
perfectly know what will happen.
Blueprint is not a compiler, but if you look at CDI, those kind of problems 
have been handled correctly for example, and CDI is not a compiler either, but 
both blueprint and CDI are dependency  injection framework, so there's no 
technical reason to not be able to support the use cases correctly, instead of 
allowing ClassCastException at a later time.

2017-04-03 15:46 GMT+02:00 CLEMENT Jean-Philippe 
>:
Hi Guillaume,

As already discussed, Blueprint is not a compiler but a runtime library. Once 
compiled there is no more generics as Java is a type erasure language. 
Moreover, I’m not too sure how Blueprint may handle injection with things like 
 S getSomething() where in java you can write myinstance. 
getSomething().

I still do have issues with injection and generics, so a global flag to defeat 
Blueprint checking would be greatly appreciated :)

JP

De : Guillaume Nodet [mailto:gno...@apache.org]
Envoyé : lundi 3 avril 2017 14:31
À : user
Objet : Re: Blueprint fails instantiating bean with generic constructor

 There are 2 different issues.
One is type erasure, i.e. allow the invocation of a method taking a 
List with a List for example.  That's ARIES-1607, and I really 
think that's a bad idea, unless someone show me a good example where it makes 
sense.  At least by default (well, it's against the blueprint spec anyway).  A 
flag to turn on such a behavior (on a bean or globally) could be an acceptable 
way, though.

Another issue is ARIES-960 where the same thing written in java would work.  
That's a problem of type assignability verification and I'm willing to fix 
those.  I think that's more your use case.  There's a branch I created a while 
ago with some changes.  Could you check if your use case works with the code 
there ?

In all cases, a workaround is always to provide a custom blueprint converter, 
as this would allow converting whatever you want to whatever is needed.



2017-04-03 11:23 GMT+02:00 CLEMENT Jean-Philippe 
>:
Hi Setya,

It might be related to an issue I opened last year: 
https://issues.apache.org/jira/browse/ARIES-1607

At that time I was told to add a custom converter as a workaround. No update on 
the Jira since then; maybe you may vote for it :)

Regards,
JP

-Message d'origine-
De : Setya [mailto:jse...@gmail.com]
Envoyé : vendredi 31 mars 2017 19:09
À : user@karaf.apache.org
Objet : Blueprint fails instantiating bean with generic constructor

Hi all,

Aries Blueprint fails to instantiate bean with the following constructors:

public AggregateAnnotationCommandHandler(Class aggregateType, Repository 
repository) { }

It seems to have problems with the second argument