??? MET = Middle Europena Time = GMT +1 2014-12-29 17:25 GMT+01:00 Werner Keil <[email protected]>:
> 1:30pm? Must have been am, at least in Central Europe then. > I may not have been online all the time but was awake;-) > > Ping me for another one, please if you can. > > > > On Mon, Dec 29, 2014 at 5:21 PM, Anatole Tresch <[email protected]> > wrote: > > > Hi Romain/all > > > > see inline > > > > 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > > > Hello Anatole, > > > > > > Tried to put all my thoughts regading current api modules: > > > > > > - Configuration: > > > > > > * looking it I feel like > > > org.apache.tamaya.Configuration#get(java.lang.String) should be the > > > only method of Configuration. I'm not sure about current(), still > > > think it shouldnt be here but in something like in > > > ConfigurationFactory but not in configuration itself - at least to be > > > aligned on common practises > > > > > > -1 for String only, type safe access is one of the most wanted feature > in > > the community. > > -1 for putting it elsewhere: It is JDK 8 style to do so. On top it would > > require adding an additional artifact to the API, which is not necessary. > > Keepo the API as small as possible. If seee further use cases that > require > > additional artifacts, we may reconsider this, but as of now I would let > be > > where it is. > > > > > > * All "adapt-friendly" methods should go elsewhere IMO but not the > > > core API - I guess it could be a mecanism used by all libs we'll add > > > on top of it but I wouldn't bind tamaya-core-api to it since today > > > when you integrate a config with an existing factory you already have > > > it and it just adds noise the core ATM - once again I dont say to drop > > > it but just to move it to another module for now. > > > > > -1 see above (one of the most wanted features). Additionally getXXX for > > JDK wrapper types is a quite common API style in SE. Perhaps Werner can > > correct me, if I am wrong here. Definitively it helps users, since they > > now, that for these types the have guaranteed adapter support and this is > > clearly visible from the API. > > > > > > > - PropertySource: > > > > > > * not sure I get name need, for a future gui? > > > > > Yes and no, Name allows traceability and enables dynamic access of the > > configuration components from outside, e.g. from managment functionality. > > Name could be the file name and additional info. > > > > > > > > > * think it misses something between get(String) and getProperties() - > > > == I agree with the TODO to replace getProperties() by > > > getPropertyKeys(). Wonder if we should get PropertySource and > > > ListablePropertySource instead of isScannable(). Last one would > > > implement Iterable<String> (for getPropertyKeys()). wdyt? > > > > > I would prefer as well adding the keySet() method (it was part of my > > original proposal). > > -1 for Iterable<String>: I can do that easily from the key set, and I > don't > > want to have references on my property source through whatever loops at > > runtime (possible risk of side effects). > > -1 for ListPropertySource. Most of the property sources, even remote > ones, > > will be scannable. Using instanceof to check, if an instance is scannable > > or not, seems for me to much efforts, compared to having the small > boolean > > method. > > > > - PropertySourceProvider: > > > > > > * a detail but shouldn't it be PropertySourcesProvider? > > > > > tbd (other opinions?). In Deltaspike it is called ConfigSourceProvider. > > For me it looks OK, also with the singular... > > > > > > > > > - ServiceContext: > > > > > > * do we need all these default methods? I would do T > > > getTamayaService(Class) and List getUserServices(Class) maybe. This > > > can have an impact on the way it is loaded then - you dont want to > > > load some tamaya services from a lower classloader (SericeContext and > > > Configuratoin[Factory] ones typically). ATM getService() and > > > getServices() doesn't differentiate it and then we could combine both > > > in our usages and have issues later > > > . > > > > > > > We know there are things to improved here. This class was not yet > analyzed > > in more detail last night (it was about 1:30 pm !). We will continue > > today... > > > > Anatole > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Romain Manni-Bucau > > > @rmannibucau > > > http://www.tomitribe.com > > > http://rmannibucau.wordpress.com > > > https://github.com/rmannibucau > > > > > > > > > 2014-12-29 16:11 GMT+01:00 Anatole Tresch <[email protected]>: > > > > Hi Oliver/all > > > > > > > > when you look at the api package you will find the API we have agreed > > on > > > > together last night. Lookt at it and feel free to discuss. We will > meet > > > for > > > > another Hangout session this evening again. > > > > > > > > -Anatole > > > > > > > > 2014-12-28 20:21 GMT+01:00 Oliver B. Fischer < > [email protected] > > >: > > > > > > > >> I hate timezones: 9 PM UTZ at Tuesday... > > > >> > > > >> Am 28.12.14 um 19:55 schrieb Werner Keil: > > > >> > > > >>> UTZ, so does it mean Midnight CET? > > > >>> And did "Thuesday" mean Tuesday or Thursday?;-) > > > >>> > > > >>> I can't say, if I'll be on a tablet then. This is a prepaid, but I > > may > > > top > > > >>> it up although I'm just here till the first week of Jan to use > that. > > > >>> Other places I use there are people long after midnight in most > > cases, > > > but > > > >>> that depends on public transport in Vienna going that long... > > > >>> > > > >>> Everything but Wed night sounds OK, but even Tue and Thu people > will > > > >>> already/still launch a lot of fireworks here;-O > > > >>> > > > >>> Werner > > > >>> > > > >>> On Sun, Dec 28, 2014 at 7:23 PM, Oliver B. Fischer < > > > >>> [email protected] > > > >>> > > > >>>> wrote: > > > >>>> What's about Thuesday around 11pm UTZ? > > > >>>> > > > >>>> Am 28.12.14 um 16:42 schrieb Mark Struberg: > > > >>>> > > > >>>> -- > > > >>>> N Oliver B. Fischer > > > >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > > > >>>> P +49 30 44793251 > > > >>>> M +49 178 7903538 > > > >>>> E [email protected] > > > >>>> S oliver.b.fischer > > > >>>> J [email protected] > > > >>>> X http://xing.to/obf > > > >>>> > > > >>>> > > > >>>> > > > >> -- > > > >> N Oliver B. Fischer > > > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > > > >> P +49 30 44793251 > > > >> M +49 178 7903538 > > > >> E [email protected] > > > >> S oliver.b.fischer > > > >> J [email protected] > > > >> X http://xing.to/obf > > > >> > > > >> > > > > > > > > > > > > -- > > > > *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* > > > -- *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*
