for the sake of completeness: +1 for renaming it (i'm fine with TypeConverter)
regards, gerhard 2014-12-29 19:41 GMT+01:00 Anatole Tresch <[email protected]>: > Started a new thread ;) > > +1 for TypeConverter > Oliver B. Fischer <[email protected]> schrieb am Mo., 29. Dez. 2014 > um 19:38: > > > 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* > > >
