Re: Config rework, take 2

Pushed eveything I had and created the related jira for 1.8.0. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: Config rework, take 2

@ConfigProperty(converter) method was added and ConfigSource and ConfigFilter decoarated with @Source and @Filter are added to the config using cdi bean lookup after extension startup (= usable after CDI startup but without any META-INF/services and with all CDI features like injections and

Re: Config rework, take 2

On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau wrote: > 2016-11-07 17:56 GMT+01:00 Mark Struberg : > > > yes the EAR case is a bit harder. Also OSGi is a bit tricky. > > > > In my javaconfig proposal I have moved this out into a SPI which is

Re: Config rework, take 2

yes the EAR case is a bit harder. Also OSGi is a bit tricky. In my javaconfig proposal I have moved this out into a SPI which is pluggable. The only requirement is that you can get the config for 'your application' via ConfigProvider#getConfig(). If this is internally done via a

Re: Config rework, take 2

added @Source and @Filter as markers (was breaking applications otherwise), pushed the basic plain proxying too. Only tested with OWB for now but seems not bad. The storage change is more impacting cause of ear case which is not protable at all so wonder if we can do anything about it without

Config rework, take 2

Hi guys sent it some times ago - ok, a long time ago now ;) - but will retry with few more details now. Goal: I'd like to rework a bit our configuration Proposals (no particular order but numbered to let it be referenced): 1. Add converter to @ConfigProperty (cdi lookup or fallback on