You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <at...@gmail.com> on 2014/12/29 19:41:57 UTC
Renaming PropertyAdapter
Started a new thread ;)
+1 for TypeConverter
Oliver B. Fischer <o....@swe-blog.net> 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 <rmannibucau@gmail.com
> >:
> >
> > 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 <at...@gmail.com>:
> >> 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 <rm...@gmail.com>:
> >>
> >>> 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 <
> gerhard.petracek@gmail.com>:
> >>>> +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 <rmannibucau@gmail.com
> >:
> >>>>
> >>>>> inline as well
> >>>>>
> >>>>> 2014-12-29 17:21 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> >>>>>> Hi Romain/all
> >>>>>>
> >>>>>> see inline
> >>>>>>
> >>>>>> 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <
> rmannibucau@gmail.com
> >>>> :
> >>>>>>
> >>>>>>> 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 <at...@gmail.com>:
> >>>>>>>> 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 <
> >>>>> o.b.fischer@swe-blog.net>:
> >>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>>>>> o.b.fischer@swe-blog.net
> >>>>>>>>>>
> >>>>>>>>>>> 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 o.b.fischer@swe-blog.net
> >>>>>>>>>>> S oliver.b.fischer
> >>>>>>>>>>> J oliver.b.fischer@jabber.org
> >>>>>>>>>>> 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 o.b.fischer@swe-blog.net
> >>>>>>>>> S oliver.b.fischer
> >>>>>>>>> J oliver.b.fischer@jabber.org
> >>>>>>>>> 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*
>
Re: Renaming PropertyAdapter
Posted by Mark Struberg <st...@yahoo.de>.
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 <ge...@gmail.com> 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 <at...@gmail.com>:
>
>> Started a new thread ;)
>>
>> +1 for TypeConverter
>> Oliver B. Fischer <o....@swe-blog.net> 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 <
>> rmannibucau@gmail.com
>> > >:
>> > >
>> > > 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
> <at...@gmail.com>:
>> > >> 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
> <rmannibucau@gmail.com
>> >:
>> > >>
>> > >>> 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 <
>> > gerhard.petracek@gmail.com>:
>> > >>>> +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 <
>> rmannibucau@gmail.com
>> > >:
>> > >>>>
>> > >>>>> inline as well
>> > >>>>>
>> > >>>>> 2014-12-29 17:21 GMT+01:00 Anatole Tresch
> <at...@gmail.com>:
>> > >>>>>> Hi Romain/all
>> > >>>>>>
>> > >>>>>> see inline
>> > >>>>>>
>> > >>>>>> 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau
> <
>> > rmannibucau@gmail.com
>> > >>>> :
>> > >>>>>>
>> > >>>>>>> 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
> <at...@gmail.com>:
>> > >>>>>>>> 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 <
>> > >>>>> o.b.fischer@swe-blog.net>:
>> > >>>>>>>>
>> > >>>>>>>>> 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 <
>> > >>>>>>>>>> o.b.fischer@swe-blog.net
>> > >>>>>>>>>>
>> > >>>>>>>>>>> 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
> o.b.fischer@swe-blog.net
>> > >>>>>>>>>>> S oliver.b.fischer
>> > >>>>>>>>>>> J
> oliver.b.fischer@jabber.org
>> > >>>>>>>>>>> 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 o.b.fischer@swe-blog.net
>> > >>>>>>>>> S oliver.b.fischer
>> > >>>>>>>>> J oliver.b.fischer@jabber.org
>> > >>>>>>>>> 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*
>> >
>>
>
Re: Renaming PropertyAdapter
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <at...@gmail.com>:
> Started a new thread ;)
>
> +1 for TypeConverter
> Oliver B. Fischer <o....@swe-blog.net> 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 <
> rmannibucau@gmail.com
> > >:
> > >
> > > 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 <at...@gmail.com>:
> > >> 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 <rmannibucau@gmail.com
> >:
> > >>
> > >>> 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 <
> > gerhard.petracek@gmail.com>:
> > >>>> +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 <
> rmannibucau@gmail.com
> > >:
> > >>>>
> > >>>>> inline as well
> > >>>>>
> > >>>>> 2014-12-29 17:21 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > >>>>>> Hi Romain/all
> > >>>>>>
> > >>>>>> see inline
> > >>>>>>
> > >>>>>> 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > >>>> :
> > >>>>>>
> > >>>>>>> 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 <at...@gmail.com>:
> > >>>>>>>> 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 <
> > >>>>> o.b.fischer@swe-blog.net>:
> > >>>>>>>>
> > >>>>>>>>> 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 <
> > >>>>>>>>>> o.b.fischer@swe-blog.net
> > >>>>>>>>>>
> > >>>>>>>>>>> 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 o.b.fischer@swe-blog.net
> > >>>>>>>>>>> S oliver.b.fischer
> > >>>>>>>>>>> J oliver.b.fischer@jabber.org
> > >>>>>>>>>>> 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 o.b.fischer@swe-blog.net
> > >>>>>>>>> S oliver.b.fischer
> > >>>>>>>>> J oliver.b.fischer@jabber.org
> > >>>>>>>>> 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*
> >
>