What about PropertyConverter? Type is even more generic.
Still not very happy. But none of the names so far really pinned down the meaning. Of course I don't know a better name neither ;) LieGrue, strub > On Monday, 29 December 2014, 22:13, Gerhard Petracek > <[email protected]> wrote: > > 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* >> > >> >
