StringConverter ;). Converters are not always bidirectional but also just Converter<FROM, TO> so StringConverter would work.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-29 18:19 GMT+01:00 Anatole Tresch <[email protected]>: > Is converter appropriate? *Converters are always two way String -> T and T > -> String.* We only have one way conversion here... > > 2014-12-29 18:11 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> converter? sounds stupid but that's what it is and that stays easy. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2014-12-29 18:07 GMT+01:00 Gerhard Petracek <[email protected]>: >> > +1 for the new api and spi as a new starting point. >> > however, imo we should find a better name for PropertyAdapter. >> > >> > regards, >> > gerhard >> > >> > >> > >> > 2014-12-29 17:42 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> > >> >> inline as well >> >> >> >> 2014-12-29 17:21 GMT+01:00 Anatole Tresch <[email protected]>: >> >> > 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. >> >> > >> >> >> >> excepted it is not consistent this way: why providing some specific >> >> method but not "mine". Why allowing to get implicit conversion and to >> >> provide a PropertyAdapter as parameter. >> >> >> >> etc... >> >> >> >> I agree it is an important and nice feature but it is not a core one. >> >> >> >> One thing you forgot is: as a user you want *your* logic which can be >> >> spring, xbean, a custom one.... That's why i strongly think it should >> >> be outside the core to ease integration with other frameworks and not >> >> collide on conversion process. >> >> >> >> About current(): all EE stack does it otherwise ;). The fact JDK 8 >> >> allows to mix layers doesnt mean we should do it and that's what does >> >> current for me: mixing service and data layers. >> >> >> >> > >> >> > * 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. >> >> > >> >> >> >> Maybe where we don't agree is the fact I'm sure nobody excepted >> >> framework writers will use this layer so smaller it is better it is. I >> >> would put the easiness effort on next layer and not this one. >> >> >> >> > >> >> >> - 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. >> >> > >> >> >> >> using toString can be enough while we don't need this feature (why >> >> introducing an API if the framework does nothing with it?). >> >> >> >> > >> >> > >> >> >> * 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. >> >> > >> >> >> >> Was not the point. Point was on implementer side API is easier to use. >> >> Impl is a detail then. >> >> >> >> > - 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*
