I dont see the uc for backserialization. For serialization normally only Map<String,String> are serialized/deserislized as internal representation. this the usecase for 'freezing' configs.
What was your isea? Romain Manni-Bucau <[email protected]> schrieb am Do., 18. Dez. 2014 um 08:36: > Great. So we dont propose the opposite yet? T -> String. Idea would be to > be able to serialze back the config somewhere. > Le 18 déc. 2014 04:45, "Anatole Tresch" <[email protected]> a écrit : > > > Its > > > > @FunctionalInterface > > Public interface PropertyAdapter<T>{ > > Public T adapt(String value); > > } > > > > So extremly simple but powerful... > > Romain Manni-Bucau <[email protected]> schrieb am Do., 18. Dez. 2014 > > um > > 01:46: > > > > > 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* > > > > > >
