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*
>> > >
>> >
>>
