hi adrian, thx for starting with it! i'll have a look at it tomorrow. fyi: we don't copy parts of other projects without official permission/donation.
regards, gerhard 2012/3/13 Adrian Gonzalez <[email protected]> > Hello, > > I've implemented ConfigProperty feature [1] > Not sure if it's fine, I'm just a CDI newbie. > I just hope this can help. > My notes are here : [2] > > > Best regards, > > [1] https://github.com/gonzalad/incubator-deltaspike/tree/DELTASPIKE-114 > [2] notes : > > 1. ConfigProperty > Implemented both approaches : @ConfigProperty and custom annotation. > Some questions : > * for now I'm throwing an exception if property is missing. > I think this is the right way to go (I don't want to have a > NullPointerException somewhere after). > But perhaps we can add a required attribute in ConfigProperty. > * implemented hack for converter attribute which should be optionnal and > default value should be null. > Needed to create special class for null value (annotation attribute > default value cannot be null). > * not sure about equals impl for ConfigPropertyBean > * is there a simpler approach for ConfigProperty implementation ? > For now I have an extension observing ProcessInjectionTarget > and AfterBeanDiscovery. > * in ProcessInjectionTarget it scans every injectionPoint looking at > @ConfigAttribute or at an annotation annotated with @ConfigAttribute > if found ti stores this injectionPoint in a list. > * in AfterBeanDiscovery, it adds a CDI bean for every item > (configAttribute) in the previous list. > Could a parameterized producer be used instead ? Don't think so, but... > * FYI : I think unit tests for extension can collide (i.e Excludes and > ConfigPropertyExtension). > > 2. Converters > An explicit converter class can be set with converter attribute. > Otherwise, we use default conversion service (should handle any primitive > or wrapper type conversion). > The explicit converter must implement Converter interface (in api). > ConversionService is packaged in impl for now. > I'm not too happy about conversionService. > It's a brutal copy/paste from Spring (I removed without reading all that - > I was really in a hurry) > Not happy about it. > > 3 options then : > * we try a really minimal implementation (basically > hashmap<KeyPair<sourceClass,targetClass>,Converter>). > * we try to implement it well and completely - IMO this will be long. > * we copy / paste all Spring conversion code - soso. > > Some questions : > * some code has been copy/paste from Spring > (i.e. StringToBooleanConverter) : donno how to do. > I've left initial authors (of course !), but changed header file. > Donno if you want to change code impl, or if I need to contact Spring... > > > > > ________________________________ > De : Gerhard Petracek <[email protected]> > À : [email protected] > Cc : Pete Muir <[email protected]> > Envoyé le : Jeudi 8 mars 2012 14h26 > Objet : Re: Re : ConfigResolver : adding @ConfigProperty injection ? > > hi adrian, > > @ #2: > since it's the easiest approach and i would have suggested the same > (independent of other libs): +1 for the interface > right now we just have an use-case for specifying the converter manually -> > we can add e.g. a ConverterFactory later on (as soon as we need it for an > use-case). > > @ #4: > if i remember correctly, someone in an open-source community mentioned such > a plan (for the "near" future). > > regards, > gerhard > > > > 2012/3/7 Adrian Gonzalez <[email protected]> > > > Noticed the JIRA issues for this issue, thanks Gerhard ! > > Sorry for the delay (quite struggling in my day to day work for now ;( ) > > > > > > About conversion API (for converter = StringToIntegerConverter.class), > > just googled a bit : > > 1. there's the javabean specification (soso...) > > 2. Spring has a really nice conversion API : > > > http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/validation.html#core-convert > > built on top of : > > public interface Converter<S, T> { > > T convert(S source); > > } > > the upper layers are ConversionService, GenericConverter - not sure > if > > it's too early to introduce similar functionnality > > 3. of course JSF converters but really tied to JSF (soso...) > > 4. didn't found any info about the official Conversion JSR > > > > > > > > ________________________________ > > De : Jason Porter <[email protected]> > > À : [email protected] > > Cc : Adrian Gonzalez <[email protected]> > > Envoyé le : Mardi 6 mars 2012 22h25 > > Objet : Re: ConfigResolver : adding @ConfigProperty injection ? > > > > +1 to the idea. I also think some more discussion about this is in order. > > > > On Tue, Mar 6, 2012 at 04:09, Pete Muir <[email protected]> wrote: > > > > > +1 > > > > > > On 5 Mar 2012, at 16:17, Adrian Gonzalez wrote: > > > > > > > What about having both options ? > > > > > > > > 1. be able to use directly @ConfigProperty > > > > @Produces > > > > public LoginContext > > > > produceLoginContext(@ConfigProperty("loginConfigFile") String > > > loginConfigFileName, @ConfigProperty("loginModuleName") String > > > loginModuleName) > > > > } > > > > } > > > > Handy when all config values are only used in a centralized class > (e.g. > > > MyAppConfig). > > > > > > > > 2. type safe config annotations > > > > @ConfigProperty( > > > > name = "pool_size", > > > > eager = true, //true is also the default value -> the value gets > > > converted during the bootstrapping process > > > > converter = StringToIntegerConverter.class > > > > ) > > > > public @interface PoolSize { > > > > } > > > > > > > > ----- Mail original ----- > > > > De : Gerhard Petracek <[email protected]> > > > > À : [email protected] > > > > Cc : > > > > Envoyé le : Lundi 5 mars 2012 17h08 > > > > Objet : Re: Re : ConfigResolver : adding @ConfigProperty injection ? > > > > > > > > hi adrian, > > > > > > > > @#1: > > > > it isn't the default value of the property. > > > > eager should be true by default -> the configured value gets > converted > > > > during bootstrapping (if the value has an invalid format the > > > bootstrapping > > > > process fails). > > > > if eager is false, the configured value will be converted directly > > before > > > > the injection (e.g. for values stored in dynamic config-sources). > > > > > > > > @#2: > > > > afaik there is an upcoming jsr about it. > > > > > > > > regards, > > > > gerhard > > > > > > > > > > > > > > > > 2012/3/5 Adrian Gonzalez <[email protected]> > > > > > > > >> Hi Gerhard, > > > >> > > > >> 1. didn't understood the meaning of eager attribute > > > >> If eager = default value, it should have been some integer value in > > your > > > >> sample > > > >> > > > >> > > > >> 2. StringToIntegerConverter converter > > > >> Is there an existing conversion API (standard, in deltaspike, ...) ? > > > >> (otherwise we're gonna need one here - and end up with another > > > conversion > > > >> API ;) ) > > > >> > > > >> Thanks ! > > > >> > > > >> ----- Mail original ----- > > > >> De : Gerhard Petracek <[email protected]> > > > >> À : [email protected] > > > >> Cc : > > > >> Envoyé le : Lundi 5 mars 2012 12h57 > > > >> Objet : Re: ConfigResolver : adding @ConfigProperty injection ? > > > >> > > > >> hi adrian, > > > >> > > > >> if we agree also on adding a bit more to allow e.g.: > > > >> > > > >> //... > > > >> @ConfigProperty( > > > >> name = "pool_size", > > > >> eager = true, //true is also the default value -> the value gets > > > >> converted during the bootstrapping process > > > >> converter = StringToIntegerConverter.class > > > >> ) > > > >> public @interface PoolSize > > > >> { > > > >> } > > > >> > > > >> @Inject > > > >> @PoolSize > > > >> private int configuredPoolSize; > > > >> > > > >> then i would vote +1 > > > >> (for sure the details need further discussions.) > > > >> > > > >> regards, > > > >> gerhard > > > >> > > > >> > > > >> > > > >> 2012/3/5 Adrian Gonzalez <[email protected]> > > > >> > > > >>> Hello, > > > >>> > > > >>> Deltaspike config module is based on ConfigResolver usage : > > > >>> ConfigResolver.getPropertyValue("test") > > > >>> > > > >>> > > > >>> Wouldn't it be interesting to add on top of it some injection > > > >>> capacity ? (i.e. providing @ConfigProperty annotation) > > > >>> > > > >>> Sample usage [1] : > > > >>> @Produces > > > >>> public LoginContext > > > >> produceLoginContext(@ConfigProperty("loginConfigFile") > > > >>> String loginConfigFileName, > > > >>> > > > >> @ConfigProperty("loginModuleName") > > > >>> String loginModuleName) > > > >>> blabla > > > >>> } > > > >>> > > > >>> This approach is based on Antonio's petstore application - config > > code > > > is > > > >>> available in [2] > > > >>> > > > >>> [1] > > > >>> > > > >> > > > > > > https://github.com/agoncal/agoncal-application-petstore-ee6/blob/master/src/main/java/org/agoncal/application/petstore/security/LoginContextProducer.java > > > >>> > > > >>> [2] > > > >>> > > > >> > > > > > > https://github.com/agoncal/agoncal-application-petstore-ee6/blob/master/src/main/java/org/agoncal/application/petstore/util/ConfigProperty.java > > > >>> > > > >>> > > > >> > > > > > > https://github.com/agoncal/agoncal-application-petstore-ee6/blob/master/src/main/java/org/agoncal/application/petstore/util/ConfigPropertyProducer.java > > > >>> > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > Jason Porter > > http://lightguard-jp.blogspot.com > > http://twitter.com/lightguardjp > > > > Software Engineer > > Open Source Advocate > > Author of Seam Catch - Next Generation Java Exception Handling > > > > PGP key id: 926CCFF5 > > PGP key available at: keyserver.net, pgp.mit.edu > > >
