+1 for Converter What's about TypeConverter?
Von meinem iPhone gesendet > Am 29.12.2014 um 18:19 schrieb 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*
