PropertyAdapter from the JVM? If so clearly -1, it is slow and not usable @runtime (only valuable during bootstrap IMO).
In Johnzon I wanted to do it as well, found it super sexy, then I benched...totally not usable if the config can be used "often" like it will for sure with CDI and potentially for each request (typical @RequestScoped). Only solution would be to cache computed values which can then be wrong if computation depends on the context which is totally valuable (depending the logged user for some cases for instance). In term of API having Serializer, Deserilizer, Codec (= Serializer + Deserializer) interfaces can make sense since in some cases you'll just want to deserilize, no? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 1:30 GMT+01:00 Anatole Tresch <[email protected]>: > *Hi Romain* > > *short inline (before I take some sleep..)...* > > *Anatole* > > > 2014-12-18 0:13 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> >> 2014-12-18 0:05 GMT+01:00 Anatole Tresch <[email protected]>: >> > Hi all >> > I would like to present another use case: injection of configuration in >> SE >> > (EE should be almost similar): >> > >> > Automatic Configuration (Configuration Injection) >> > >> > Tamaya must provide a feature for automatic configuration, where >> properties >> > of a class or methods can be annotated: >> > >> > - >> > >> > Hereby the lifecycle of the instances configured should not be managed >> > by Tamaya. >> > - >> > >> > String as well as other types should be supported. >> > - >> > >> >> We should limit to types we can handle to start I think (until we >> finished other IoC integration to keep it aligned to start) >> >> So file, string, primitive wrappers, uri, inetaddress... > > > *Disagree. The mechanism is already in place and working well. > PropertyAdapter is a generic functional interface.* > *I would not want to throw it away. The only thing, I see is really worth > discussing are other aspects, like meta-information, and > multi-values/collection support. * > > >> > It must be possible to define default values to be used, if no valid >> > value is present. >> > - >> > >> > It must be possible to define dynamic expressions, at least for >> default >> > values. >> > - >> > >> > The values configured can be reinjected, if the underlying >> configuration >> > changes. This should also be the case fir final classes, such as >> Strings. >> > - >> > >> >> -1, I would introduce DynamicValue<String> (or any generic) for it >> > > *Other opinions? * > >> >> > Reinjection should be controllable by an loading policy. >> > - >> > >> > It should be possible to evaluate multiple keys, e.g. current keys, >> and >> > as a backup deprecated keys from former application releases. >> > - >> > >> > It should be possible to evaluate multiple configurations. >> > - >> > >> > The type conversion of the properties injected should be configurable. >> > - >> > >> > The value evaluated for a property (before type conversion) may be >> > adaptable as well. >> > - >> > >> > It should be possible to observe configuration changes. >> > >> > To illustrate the points above imagine the following POJO: >> > Configured POJO Example >> > >> > *public* *class* *MyPojo* { >> > @ConfigProperty("myCurrency") >> > @DefaultValue("CHF") // use as default >> > @WithLoadingPolicy(LoadingPolicy.INITIAL) // load the value only >> > once (no reinjection) >> > *private* *String* currency; >> > >> > @ConfigProperty("myCurrencyRate") >> > *private* *Long* currencyRate; >> > >> > @ConfigProperty // evaluates to >> > key=<fieldName>="fullRate" >> > @ConfigProperty("fallback.property") >> > @WithConfig("default") >> > @WithConfig("moduleConfig"); >> > *private* *BigDecimal* fullRate; >> > >> > // Configuration method >> > *void* setStartup(@ConfigProperty *boolean* startup, >> > @ConfigProperty("componentName") @WithConfig("module1") >> > @DefaultValue("N/A") *String* compName){ >> > ... >> > } >> > >> >> I would put default value in @ConfigProperty to avoid >> TooMuchAnnotationsException >> @WithConfig({}) for the same reason or even in @ConfigProperty(configs = >> {})? >> > > *For configs, we can add them to the property annotation. Adding the > default values IMO makes less sense, because you want to define the default > value only once, whereas you can lookup multiple properties...* > > > >> > // Configuration method >> > @ConfigProperty("componentName") >> > @WithConfig("module1") >> > @DefaultValue("N/A") >> > *private* *void* setComponentName(*String* compName){ >> > ... >> > } >> > >> > // Configuration listener method, defining which properties to listen >> for >> > @ConfigChanges >> > @ConfigProperty("componentName") >> > *private* *void* setComponentName(ConfigChange change){ >> > ... >> > } >> > >> > } >> > >> > The instance then can be passed for being configured: >> > Configuring a POJO >> > >> > MyPojo instance = *new* MyPojo();*Configuration*.configure(instance); >> > >> >> I'd use "bind" keyword since you don't configure the instance, just >> you map the config on it no? >> > > *IMO users get more confused with bind. Lets see, what others think... ;)* > > > >> > This will configure all values according to the load policies (by >> default >> > LoadPolicy.INITIAL). Depending on the listeners present and the >> properties >> > injected Tamaya will keep weak references to the bean and the current >> > environment, so it can be determined, when configuration changes must be >> > published into the bean. >> >> Would hide it behind DynamicValue cause in some case you'll not be >> able to do it very well, would also allow to add some useful methods >> like hasChanged(). >> > > *Hmm, I start to feel some sympathies for the DynamicValue ... * > >> >> > Feel free to comment or ask questions ;) >> > >> > Best, >> > Anatole >> > >> > -- >> > *Anatole Tresch* >> > Java Engineer & Architect, JSR Spec Lead >> > Glärnischweg 10 >> > CH - 8620 Wetzikon >> > >> > *Switzerland, Europe Zurich, GMT+1* >> > *Twitter: @atsticks* >> > *Blogs: **http://javaremarkables.blogspot.ch/ >> > <http://javaremarkables.blogspot.ch/>* >> > >> > *Google: atsticksMobile +41-76 344 62 79* >> > > > -- > *Anatole Tresch* > Java Engineer & Architect, JSR Spec Lead > Glärnischweg 10 > CH - 8620 Wetzikon > > *Switzerland, Europe Zurich, GMT+1* > *Twitter: @atsticks* > *Blogs: **http://javaremarkables.blogspot.ch/ > <http://javaremarkables.blogspot.ch/>* > > *Google: atsticksMobile +41-76 344 62 79*
