> *In the existing code there was an "internal" interface called > PropertySource
That one is ok. I don't get the DEFAULT (not needed imo) and I don't like the tight coupling to the typing (toConfiguration). I would completely detach the configuration aspect (String/String) from the conversion aspect. Actually having some sane String representation for converting values is a feature which is desperately needed in many other places as well. In the implementation I also don't like that for each and every operation this currently does PropertyAdapterProviderSpi as = ServiceContext.getInstance().getSingleton(PropertyAdapterProviderSpi.class); over and over again. This really slows down the operation. Imo it should be more like BeanManager. To have a getInstance() method but it's perfectly fine to store this reference once and after that just use it without having to go through the expensive parts over and over again. > Aggregation gets as simple as a simple > BiFunction<String,String,String> If you have a hammer... I don't see why we need the aggregation to be a function at all? There is one single fixed algorithm: Take the ordinal value of each PropertySource (oh, this is missing btw! Please read up on that trick, this is actually the CORE of the whole mechanism.) and apply all of them on top of each other. Effectively merging them - with the more important values 'winning'. > *- one convenient accessor for each basic wrapper type like short, int, > boolean etc.* That's fine, but it must not be bound to the configuration. See my arguments above. > *- one generic accessor where no adapter was passed. In this case > PropertyAdapter itself provides a service interface, where you can access > one by calling PropertyAdapter.getInstance(Class<T> type).* I like the idea of having an extensible converter system. I've not looked at this in detail but from doing a few unit tests with it it feels a slight bit clumsy yet (too many method calls involved). I bet together we can find a solution which is as flexible but more elegant. But have not wrapped around my head about this topic. LieGrue, strub > On Saturday, 27 December 2014, 0:49, Anatole Tresch <[email protected]> > wrote: > > *Hi Mark* > > 2014-12-26 23:58 GMT+01:00 Mark Struberg <[email protected]>: > >> Hi! >> >> Trying to get a discussion stated WITHOUT doing tons of code which we >> probably might throw away later anyway. >> >> It seems we are all pretty d'accord that that primary configuration is >> done in a String/String key-value style. Native Object style as in JNDI is >> out of scope and adds too many restrictions. >> >> *+1 * > > Of course there is another layer of 'Types' on top of those Strings. > E.g. >> if a user likes to configure a Date then we should define a default format >> (or rather, various ones) + eventually a 'transformer'. >> But that doesn't change the fact that _internally_ it only gets stored > as >> String. >> > *In the existing code there was an "internal" interface called > PropertySource, which is quite similar to Deltaspike and also is dealing > strictly with Strings only.Similar all subsequent operations like > combining/aggregating/overriding property sources etc was strictly done on > this internal String representation. Aggregation gets as simple as a simple > BiFunction<String,String,String> then.* > *The Configuration interface extended PropertySource (we may also just > duplicate the methods to make it completely independent), hereby adding* > *- one convenient accessor for each basic wrapper type like short, int, > boolean etc.* > *- one generic accessor where the adapter to be used could be passed > explicitly* > *- one generic accessor where no adapter was passed. In this case > PropertyAdapter itself provides a service interface, where you can access > one by calling PropertyAdapter.getInstance(Class<T> type).* > > ** > *That way users have* > *- full API comfort for the most common types.* > *- a generic typed access, where they dont have to care on the adapter > (respectively Tamaya can provide default adapters as useful; and companies > can add their own adapters for their internal types as well). Users then > don't have to care about adapters, because they are transparently provided.* > *- the power users, or like in the use case you sent (with the password > decryption) an adapter can also be passed explicitly.* > > I'd suggest that we keep the core API as String only and then add >> formatters on top of that (if any). >> > *As long as type support ends up as first class citizen in the API part, I > agree. Basically the existing code already does this implicitly: there is > a method Configuration toConfiguration() defined on each PropertySource, to > get an extended instance, where typed access is offered,* > > > >> There are various flavours to define the various formats >> 1.) don't define it at all. Means we let the application deal with >> formatting > > 2.) Only have String/String in our API but suggest default formats in our >> documentation. > > 3.) Only have String/String in our API and just define standard format >> Strings for DateFormatter, NumberFormatter, etc in interfaces or helper >> classes. > > 4.) Have the fully typed API. Means we don't only have a getValue(keyName) >> but also a getDate(keyName), etc >> 5.) Stay String/String in our API (same like 2) but add additional >> Formatter helpers on top of it. >> > > *As I said I think clearly 5 is the way to go. Simple "type free" low > level handling, but comfort for users when config is accessed. Something > like:* > > *PropertySource lowLevelConfig = PropertySource.current();* > *Configuration cfg = Configuration.of(lowLevelConfig);* > > *These things can easily be backed up by service implemented in the core > module.* > > > >> I personally like 3 and 5. The main reason is that we are most probably >> not able to define all formats here. Thus any typed API we do define would >> be limited by nature. >> >> There is one major bullet which we should address/take care of: take care >> of timezones and locales. We should really think about those if we define >> the formats. >> > *+1 * > > There is also a bit of brain to put into array representations. But lets do >> that later in a separate discussion. >> > *+1 arrays and all kind of collections, or at least list/array; map* > > > > >> >> >> LieGrue, >> strub >> > > > > -- > *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* >
