+0 looks good as well even if used for really more in some other frameworks
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-12-29 19:37 GMT+01:00 Oliver B. Fischer <[email protected]>: > This would mean something like > > URIConverter implements StringConverter<URI> {} > > IMHO TypeConverter sounds better for the purpose we have... > > Wdyt? > > Von meinem iPhone gesendet > >> Am 29.12.2014 um 18:21 schrieb Romain Manni-Bucau <[email protected]>: >> >> 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*
