So your idea is to add more complex configuration structures, e.g. JSON into a value and therefore have the possibility to serialize back changes, done to the config... We will have to add that use case. It would also simplify supporting complex datastructures like collections, etc.
-----Original Message----- From: Romain Manni-Bucau [mailto:[email protected]] Sent: Donnerstag, 18. Dezember 2014 09:21 To: [email protected] Subject: Re: UC: Configuration Injection (SE) using pseudo code to make it shorter: public class MyConfig { @Config(...) @Codec(deserializer = JSonDeserializer.class, serializer = JSonSerializer.class) MySubConfig sub; } config could then be foo = {"a":"b",...} and MySubConfig = { String b;... }. Until now nothing needing all this stuff but now suppose I modify sub during app lifecycle, how do I store modifications? What I would avoid is to 100% rely on impls (ie I cast my Source and use its store method for instance). Would be great to be symmetric :) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 9:15 GMT+01:00 Anatole Tresch <[email protected]>: > 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* >> > > >> > >>
