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:
<configfile
finalname=”/etc/whatever.cfg”>mvn:some.example/whatever/1.0.0/cfg</configfile>
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 <config
name=”whatever”>mvn:some.example/whatever/1.0.0/cfg</config>?
Regards,
JP
De : Guillaume Nodet [mailto:[email protected]]
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
<[email protected]<mailto:[email protected]>>:
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
<[email protected]<mailto:[email protected]>>:
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:[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>>:
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<String> 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:[email protected]<mailto:[email protected]>]
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<String> to List<Integer> 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
<[email protected]<mailto:[email protected]>>:
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> S getSomething() where in java you can write myinstance.<Boolean>
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:[email protected]<mailto:[email protected]>]
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<String> with a List<Integer> 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
<[email protected]<mailto:[email protected]>>:
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:[email protected]<mailto:[email protected]>]
Envoyé : vendredi 31 mars 2017 19:09
À : [email protected]<mailto:[email protected]>
Objet : Blueprint fails instantiating bean with generic constructor
Hi all,
Aries Blueprint fails to instantiate bean with the following constructors:
public AggregateAnnotationCommandHandler(Class<T> aggregateType, Repository<T>
repository) { }
It seems to have problems with the second argument since it contains generic
parameter.
While it successfully instantiates the following bean:
public EventSourcingRepository(AggregateFactory<T> aggregateFactory, EventStore
eventStore) { }
I'm using Apache Karaf 4.0.8.
Any insight would be greatly appreciated.
Thanks & Regards,
Setya
--
View this message in context:
http://karaf.922171.n3.nabble.com/Blueprint-fails-instantiating-bean-with-generic-constructor-tp4049986.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
