You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tamaya.apache.org by Mark Struberg <st...@yahoo.de> on 2014/12/28 16:42:16 UTC

do a hangout hacking session?

Hi!

I think we start getting closer to a common view. What about doing some hacking session via google hangout and try to move certain parts back to proper?

I'm located in Vienna means UTC +1

I'm available on irc.freenode.net channels #openwebbeans, #deltaspike and #apache-tamaya



LieGrue,
strub

Re: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.

Hi all,

there is litte chance that I will be able to join this evening because 
of some private issues I have to deal with. ;-(

Bye,

Oliver

Am 29.12.14 um 16:11 schrieb Anatole Tresch:
> 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....@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
>>
>>
>

-- 
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

Re: do a hangout hacking session?

Posted by Mark Struberg <st...@yahoo.de>.

Sorry werner, missed you. 

I've invited those who were available on #apache-tamaya + anatole.
Do you like to attend today?


LieGrue,
strub





> On Monday, 29 December 2014, 16:50, Werner Keil <we...@gmail.com> wrote:
> > So there was a Hangout? Didn't see any invitation in my timeline;-O
> 
> 
> On Mon, Dec 29, 2014 at 4:11 PM, Anatole Tresch <at...@gmail.com> 
> wrote:
> 
>>  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....@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*
>> 
>

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

So there was a Hangout? Didn't see any invitation in my timeline;-O

On Mon, Dec 29, 2014 at 4:11 PM, Anatole Tresch <at...@gmail.com> wrote:

> 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....@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*
>

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

OK, as long as my tablet and prepaid sim hold out I'm happy to join.

On Mon, Dec 29, 2014 at 5:22 PM, Anatole Tresch <at...@gmail.com> wrote:

> Tonight. Same time 22:30 MET, same "place". Mark should invite you.
>
> 2014-12-29 17:12 GMT+01:00 Werner Keil <we...@gmail.com>:
>
> > So what about the next hangout some time this week?
> >
> > On Mon, Dec 29, 2014 at 4:58 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > 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.
> > >
> > > * 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.
> > >
> > > - PropertySource:
> > >
> > > * not sure I get name need, for a future gui?
> > > * 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?
> > >
> > > - PropertySourceProvider:
> > >
> > > * a detail but shouldn't it be PropertySourcesProvider?
> > >
> > > - 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.
> > >
> > >
> > >
> > >
> > >
> > > 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*
>

Re: do a hangout hacking session?

Posted by Anatole Tresch <at...@gmail.com>.

Tonight. Same time 22:30 MET, same "place". Mark should invite you.

2014-12-29 17:12 GMT+01:00 Werner Keil <we...@gmail.com>:

> So what about the next hangout some time this week?
>
> On Mon, Dec 29, 2014 at 4:58 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > 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.
> >
> > * 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.
> >
> > - PropertySource:
> >
> > * not sure I get name need, for a future gui?
> > * 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?
> >
> > - PropertySourceProvider:
> >
> > * a detail but shouldn't it be PropertySourcesProvider?
> >
> > - 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.
> >
> >
> >
> >
> >
> > 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*

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

So what about the next hangout some time this week?

On Mon, Dec 29, 2014 at 4:58 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

> 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.
>
> * 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.
>
> - PropertySource:
>
> * not sure I get name need, for a future gui?
> * 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?
>
> - PropertySourceProvider:
>
> * a detail but shouldn't it be PropertySourcesProvider?
>
> - 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.
>
>
>
>
>
> 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....@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*
>

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*
> >
>

Renaming PropertyAdapter

Posted by 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 <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: do a hangout hacking session?

Posted by Romain Manni-Bucau <rm...@gmail.com>.

+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 <o....@swe-blog.net>:
> 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 <rm...@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 <ge...@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 <rm...@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: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.

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 <rm...@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 <ge...@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 <rm...@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: do a hangout hacking session?

Posted by Romain Manni-Bucau <rm...@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 <ge...@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 <rm...@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: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.

+1 for Converter

What's about TypeConverter?

Von meinem iPhone gesendet

> Am 29.12.2014 um 18:19 schrieb 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 <ge...@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 <rm...@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: do a hangout hacking session?

Posted by 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 <ge...@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 <rm...@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: do a hangout hacking session?

Posted by 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 <ge...@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 <rm...@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 <rm...@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*
>>

Re: do a hangout hacking session?

Posted by Gerhard Petracek <ge...@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 <rm...@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 <rm...@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*
>

Re: do a hangout hacking session?

Posted by Anatole Tresch <at...@gmail.com>.

See inline

2014-12-29 17:42 GMT+01:00 Romain Manni-Bucau <rm...@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 <rm...@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.
>

There is a clear rule set:
1) Convenience and guaranteed support (can be tested by a TCK easily) is
added for the JDK wrapper types. Nothing else.
2) Normally you use the implicit type support.
3) There might be cases, where you want to support it explicitly:
    a) you want to provide your adapter yourself, e.g. you provide your
secret PKI decryption engine, to decrypt a encrpyted password. You don't
want this to register as a global adapter!
    b) similarly the same applies to specific application types, e.g.
legacy types you don't want to be supported OOTB.
    c) you want to override the defaults, because you e.g. once more legacy
entries. And you dont want to add the additional parser, so it is available
to all other users of your system.
 


> etc...
>
> I agree it is an important and nice feature but it is not a core one.
>
There is a separation: the internals is strictly based on String, String
maps (see PropertySource). Configuration provides typed access (its more
some kind of service), really all users I have talked with, want. So IMO it
is one of the real core features. Removing it IMO would be a big mistake,
nobody would understand that.


> 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.
>

They still can do that, simply use the String methods. But the other that
do not work with such fancy frameworks, will not want to do the conversion
themselves. We are building a complete API here, not only an implementtion
of eg Spring's PropertySource...


>
> 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.
>

This will change. EE is still on Java 7, so obviously this is not possible
at all. Given minizing your API fottprint, especially the internals it
makes more than sense. Image
how java.text would look, if you build it today. Cou could simply say
NumberFormat.getInstance(). You would probably even not require to expose
DecimalFormat...



> >
> > * 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.
>
> I do not agree at all. In Credit Suisse for example more or less every
developer is dealing with configuration somehow. It is by far not only the
framework developer!



> >
> >> - 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?).
>

getName() has another contract than toString(). Perhaps we should clarify
that. And toString() always is implemented, so people can "forget" to do
so.
GetName() is part of the contract they have to provide...


> >
> >> * 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.
>

Maybe. I see ot otherwise, it requires you to implement Iterable on every
config source...


Let's see if other opinions are there...



-- 
*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: do a hangout hacking session?

Posted by Romain Manni-Bucau <rm...@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 <rm...@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....@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*

Re: do a hangout hacking session?

Posted by Anatole Tresch <at...@gmail.com>.

??? MET = Middle Europena Time = GMT +1

2014-12-29 17:25 GMT+01:00 Werner Keil <we...@gmail.com>:

> 1:30pm? Must have been am, at least in Central  Europe then.
> I may not have been online all the time but was awake;-)
>
> Ping me for another one, please if you can.
>
>
>
> On Mon, Dec 29, 2014 at 5:21 PM, Anatole Tresch <at...@gmail.com>
> wrote:
>
> > Hi Romain/all
> >
> > see inline
> >
> > 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <rm...@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.
> > 
> >
> > * 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.
> >
> >
> > > - 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.
> >
> >
> >
> > > * 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.
> >
> > - 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: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

1:30pm? Must have been am, at least in Central  Europe then.
I may not have been online all the time but was awake;-)

Ping me for another one, please if you can.



On Mon, Dec 29, 2014 at 5:21 PM, Anatole Tresch <at...@gmail.com> wrote:

> Hi Romain/all
>
> see inline
>
> 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <rm...@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.
> 
>
> * 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.
>
>
> > - 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.
>
>
>
> > * 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.
>
> - 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*
>

Re: do a hangout hacking session?

Posted by Anatole Tresch <at...@gmail.com>.

Hi Romain/all

see inline

2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <rm...@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.


* 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.


> - 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.



> * 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.

- 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....@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*

Re: do a hangout hacking session?

Posted by Romain Manni-Bucau <rm...@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.

* 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.

- PropertySource:

* not sure I get name need, for a future gui?
* 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?

- PropertySourceProvider:

* a detail but shouldn't it be PropertySourcesProvider?

- 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.

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....@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*

Re: do a hangout hacking session?

Posted by 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....@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*

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

Yep, Timezones in Java are always a problem, especially 5 different
competing Date/Time APIs;-D



On Sun, Dec 28, 2014 at 8:21 PM, Oliver B. Fischer <o.b.fischer@swe-blog.net
> wrote:

> 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
>
>

Re: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@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

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

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:
>
>> Hi!
>>
>>
>> I think we start getting closer to a common view. What about doing some
>> hacking session via google hangout and try to move certain parts back to
>> proper?
>>
>> I'm located in Vienna means UTC +1
>>
>> I'm available on irc.freenode.net channels #openwebbeans, #deltaspike
>> and #apache-tamaya
>>
>>
>>
>> LieGrue,
>> strub
>>
>
> --
> 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
>
>

Re: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.

What's about Thuesday around 11pm UTZ?

Am 28.12.14 um 16:42 schrieb Mark Struberg:
> Hi!
>
> I think we start getting closer to a common view. What about doing some hacking session via google hangout and try to move certain parts back to proper?
>
> I'm located in Vienna means UTC +1
>
> I'm available on irc.freenode.net channels #openwebbeans, #deltaspike and #apache-tamaya
>
>
>
> LieGrue,
> strub

-- 
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

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

It requites slightly more bandwidth, but without video my tablet/tethering
(on the laptop but slow;-) might handle it.

Werner

On Sun, Dec 28, 2014 at 6:14 PM, Mark Struberg <st...@yahoo.de> wrote:

> I suggest google hangout.
>
>
> LieGrue,
> strub
>
>
>
>
> > On Sunday, 28 December 2014, 17:54, Werner Keil <we...@gmail.com>
> wrote:
> > > I'm only on Tablet here over holidays, but if that works (via Web
> interface
> > like for CDI) I could try.
> >
> > Werner
> >
> >
> > On Sun, Dec 28, 2014 at 5:30 PM, John D. Ament <jo...@apache.org>
> > wrote:
> >
> >>  Probably not that early for me (I think that's 21:30 UTC right?)
> > I'll stop
> >>  in though to see if you guys are around though.
> >>
> >>  On Sun Dec 28 2014 at 11:00:25 AM Mark Struberg <st...@yahoo.de>
> > wrote:
> >>
> >>  > 10:30 sounds good to me. That way even some US colleagues might be
> > able
> >>  to
> >>  > join.
> >>  >
> >>  >
> >>  > LieGrue,
> >>  > strub
> >>  >
> >>  >
> >>  >
> >>  >
> >>  > On Sunday, 28 December 2014, 16:56, Anatole Tresch
> > <at...@gmail.com>
> >>  > wrote:
> >>  > >
> >>  > >Sounds good. Do you have time prefs? I will not have time before
> > 10.30pm
> >>  > (gmt+1as well) today...
> >>  > >
> >>  > >Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez.
> > 2014 um
> >>  16:49:
> >>  > >
> >>  > >Hi!
> >>  > >>
> >>  > >>I think we start getting closer to a common view. What about
> > doing some
> >>  > hacking session via google hangout and try to move certain parts back
> > to
> >>  > proper?
> >>  > >>
> >>  > >>I'm located in Vienna means UTC +1
> >>  > >>
> >>  > >>I'm available on irc.freenode.net channels #openwebbeans,
> > #deltaspike
> >>  > and #apache-tamaya
> >>  > >>
> >>  > >>
> >>  > >>
> >>  > >>LieGrue,
> >>  > >>strub
> >>  > >>
> >>  > >
> >>  > >
> >>  >
> >>
> >
>

Re: do a hangout hacking session?

Posted by Mark Struberg <st...@yahoo.de>.

I suggest google hangout.


LieGrue,
strub




> On Sunday, 28 December 2014, 17:54, Werner Keil <we...@gmail.com> wrote:
> > I'm only on Tablet here over holidays, but if that works (via Web interface
> like for CDI) I could try.
> 
> Werner
> 
> 
> On Sun, Dec 28, 2014 at 5:30 PM, John D. Ament <jo...@apache.org>
> wrote:
> 
>>  Probably not that early for me (I think that's 21:30 UTC right?)  
> I'll stop
>>  in though to see if you guys are around though.
>> 
>>  On Sun Dec 28 2014 at 11:00:25 AM Mark Struberg <st...@yahoo.de> 
> wrote:
>> 
>>  > 10:30 sounds good to me. That way even some US colleagues might be 
> able
>>  to
>>  > join.
>>  >
>>  >
>>  > LieGrue,
>>  > strub
>>  >
>>  >
>>  >
>>  >
>>  > On Sunday, 28 December 2014, 16:56, Anatole Tresch 
> <at...@gmail.com>
>>  > wrote:
>>  > >
>>  > >Sounds good. Do you have time prefs? I will not have time before 
> 10.30pm
>>  > (gmt+1as well) today...
>>  > >
>>  > >Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez. 
> 2014 um
>>  16:49:
>>  > >
>>  > >Hi!
>>  > >>
>>  > >>I think we start getting closer to a common view. What about 
> doing some
>>  > hacking session via google hangout and try to move certain parts back 
> to
>>  > proper?
>>  > >>
>>  > >>I'm located in Vienna means UTC +1
>>  > >>
>>  > >>I'm available on irc.freenode.net channels #openwebbeans, 
> #deltaspike
>>  > and #apache-tamaya
>>  > >>
>>  > >>
>>  > >>
>>  > >>LieGrue,
>>  > >>strub
>>  > >>
>>  > >
>>  > >
>>  >
>> 
>

Re: do a hangout hacking session?

Posted by Werner Keil <we...@gmail.com>.

I'm only on Tablet here over holidays, but if that works (via Web interface
like for CDI) I could try.

Werner

On Sun, Dec 28, 2014 at 5:30 PM, John D. Ament <jo...@apache.org>
wrote:

> Probably not that early for me (I think that's 21:30 UTC right?)  I'll stop
> in though to see if you guys are around though.
>
> On Sun Dec 28 2014 at 11:00:25 AM Mark Struberg <st...@yahoo.de> wrote:
>
> > 10:30 sounds good to me. That way even some US colleagues might be able
> to
> > join.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > On Sunday, 28 December 2014, 16:56, Anatole Tresch <at...@gmail.com>
> > wrote:
> > >
> > >Sounds good. Do you have time prefs? I will not have time before 10.30pm
> > (gmt+1as well) today...
> > >
> > >Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez. 2014 um
> 16:49:
> > >
> > >Hi!
> > >>
> > >>I think we start getting closer to a common view. What about doing some
> > hacking session via google hangout and try to move certain parts back to
> > proper?
> > >>
> > >>I'm located in Vienna means UTC +1
> > >>
> > >>I'm available on irc.freenode.net channels #openwebbeans, #deltaspike
> > and #apache-tamaya
> > >>
> > >>
> > >>
> > >>LieGrue,
> > >>strub
> > >>
> > >
> > >
> >
>

Re: do a hangout hacking session?

Posted by "John D. Ament" <jo...@apache.org>.

Probably not that early for me (I think that's 21:30 UTC right?)  I'll stop
in though to see if you guys are around though.

On Sun Dec 28 2014 at 11:00:25 AM Mark Struberg <st...@yahoo.de> wrote:

> 10:30 sounds good to me. That way even some US colleagues might be able to
> join.
>
>
> LieGrue,
> strub
>
>
>
>
> On Sunday, 28 December 2014, 16:56, Anatole Tresch <at...@gmail.com>
> wrote:
> >
> >Sounds good. Do you have time prefs? I will not have time before 10.30pm
> (gmt+1as well) today...
> >
> >Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez. 2014 um 16:49:
> >
> >Hi!
> >>
> >>I think we start getting closer to a common view. What about doing some
> hacking session via google hangout and try to move certain parts back to
> proper?
> >>
> >>I'm located in Vienna means UTC +1
> >>
> >>I'm available on irc.freenode.net channels #openwebbeans, #deltaspike
> and #apache-tamaya
> >>
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >
> >
>

Re: do a hangout hacking session?

Posted by Mark Struberg <st...@yahoo.de>.

10:30 sounds good to me. That way even some US colleagues might be able to join. 


LieGrue,
strub




On Sunday, 28 December 2014, 16:56, Anatole Tresch <at...@gmail.com> wrote:
>
>Sounds good. Do you have time prefs? I will not have time before 10.30pm (gmt+1as well) today...
>
>Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez. 2014 um 16:49:
>
>Hi!
>>
>>I think we start getting closer to a common view. What about doing some hacking session via google hangout and try to move certain parts back to proper?
>>
>>I'm located in Vienna means UTC +1
>>
>>I'm available on irc.freenode.net channels #openwebbeans, #deltaspike and #apache-tamaya
>>
>>
>>
>>LieGrue,
>>strub
>>
>
>

Re: do a hangout hacking session?

Posted by Anatole Tresch <at...@gmail.com>.

Sounds good. Do you have time prefs? I will not have time before 10.30pm
(gmt+1as well) today...
Mark Struberg <st...@yahoo.de> schrieb am So., 28. Dez. 2014 um 16:49:

> Hi!
>
> I think we start getting closer to a common view. What about doing some
> hacking session via google hangout and try to move certain parts back to
> proper?
>
> I'm located in Vienna means UTC +1
>
> I'm available on irc.freenode.net channels #openwebbeans, #deltaspike and
> #apache-tamaya
>
>
>
> LieGrue,
> strub
>

Re: do a hangout hacking session?

Posted by "Oliver B. Fischer" <o....@swe-blog.net>.

Good idea, but I must know this some days before the actual date (work, 
family,...)

Bye,

Oliver

<http://dict.leo.org/#/search=short-term&searchLoc=0&resultOrder=basic&multiwordShowSingle=on> 

Am 28.12.14 um 16:42 schrieb Mark Struberg:
> Hi!
>
> I think we start getting closer to a common view. What about doing some hacking session via google hangout and try to move certain parts back to proper?
>
> I'm located in Vienna means UTC +1
>
> I'm available on irc.freenode.net channels #openwebbeans, #deltaspike and #apache-tamaya
>
>
>
> LieGrue,
> strub

-- 
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