Hi Romain/all

see inline

2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <[email protected]>:

> Hello Anatole,
>
> Tried to put all my thoughts regading current api modules:
>
> - Configuration:
>
> * looking it I feel like
> org.apache.tamaya.Configuration#get(java.lang.String) should be the
> only method of Configuration. I'm not sure about current(), still
> think it shouldnt be here but in something like in
> ConfigurationFactory but not in configuration itself - at least to be
> aligned on common practises


​-1 for String only, type safe access is one of the most wanted feature in
the community.
-1 for putting it elsewhere: It is JDK 8 style to do so. On top it would
require adding an additional artifact to the API, which is not necessary.
Keepo the API as small as possible. If seee further use cases that require
additional artifacts, we may reconsider this, but as of now I would let be
where it is.
​

* 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 <[email protected]>:
> > Hi Oliver/all
> >
> > when you look at the api package you will find the API we have agreed on
> > together last night. Lookt at it and feel free to discuss. We will meet
> for
> > another Hangout session this evening again.
> >
> > -Anatole
> >
> > 2014-12-28 20:21 GMT+01:00 Oliver B. Fischer <[email protected]>:
> >
> >> I hate timezones: 9 PM UTZ at Tuesday...
> >>
> >> Am 28.12.14 um 19:55 schrieb Werner Keil:
> >>
> >>> UTZ, so does it mean Midnight CET?
> >>> And did "Thuesday" mean Tuesday or Thursday?;-)
> >>>
> >>> I can't say, if I'll be on a tablet then. This is a prepaid, but I may
> top
> >>> it up although I'm just here till the first week of Jan to use that.
> >>> Other places I use there are people long after midnight in most cases,
> but
> >>> that depends on public transport in Vienna going that long...
> >>>
> >>> Everything but Wed night sounds OK, but even Tue and Thu people will
> >>> already/still launch a lot of fireworks here;-O
> >>>
> >>> Werner
> >>>
> >>> On Sun, Dec 28, 2014 at 7:23 PM, Oliver B. Fischer <
> >>> [email protected]
> >>>
> >>>> wrote:
> >>>> What's about Thuesday around 11pm UTZ?
> >>>>
> >>>> Am 28.12.14 um 16:42 schrieb Mark Struberg:
> >>>>
> >>>> --
> >>>> N Oliver B. Fischer
> >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>> P +49 30 44793251
> >>>> M +49 178 7903538
> >>>> E [email protected]
> >>>> S oliver.b.fischer
> >>>> J [email protected]
> >>>> X http://xing.to/obf
> >>>>
> >>>>
> >>>>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E [email protected]
> >> S oliver.b.fischer
> >> J [email protected]
> >> X http://xing.to/obf
> >>
> >>
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter:  @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile  +41-76 344 62 79*
>



-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*

Reply via email to