yes, we did it with a colleague in my previous job. JSon is not super great to maintain but lists and maps are (we implemented it using XBean).
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-18 10:37 GMT+01:00 Tresch, Anatole <[email protected]>: > 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* >>> > > >>> > >>>
