Started a new thread ;)
+1 for TypeConverter
Oliver B. Fischer <[email protected]> schrieb am Mo., 29. Dez. 2014
um 19:38:
> This would mean something like
>
> URIConverter implements StringConverter<URI> {}
>
> IMHO TypeConverter sounds better for the purpose we have...
>
> Wdyt?
>
> Von meinem iPhone gesendet
>
> > Am 29.12.2014 um 18:21 schrieb Romain Manni-Bucau <[email protected]
> >:
> >
> > StringConverter ;). Converters are not always bidirectional but also
> > just Converter<FROM, TO> so StringConverter would work.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-29 18:19 GMT+01:00 Anatole Tresch <[email protected]>:
> >> Is converter appropriate? *Converters are always two way String -> T
> and T
> >> -> String.* We only have one way conversion here...
> >>
> >> 2014-12-29 18:11 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> >>
> >>> converter? sounds stupid but that's what it is and that stays easy.
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2014-12-29 18:07 GMT+01:00 Gerhard Petracek <
> [email protected]>:
> >>>> +1 for the new api and spi as a new starting point.
> >>>> however, imo we should find a better name for PropertyAdapter.
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2014-12-29 17:42 GMT+01:00 Romain Manni-Bucau <[email protected]
> >:
> >>>>
> >>>>> inline as well
> >>>>>
> >>>>> 2014-12-29 17:21 GMT+01:00 Anatole Tresch <[email protected]>:
> >>>>>> Hi Romain/all
> >>>>>>
> >>>>>> see inline
> >>>>>>
> >>>>>> 2014-12-29 16:58 GMT+01:00 Romain Manni-Bucau <
> [email protected]
> >>>> :
> >>>>>>
> >>>>>>> Hello Anatole,
> >>>>>>>
> >>>>>>> Tried to put all my thoughts regading current api modules:
> >>>>>>>
> >>>>>>> - Configuration:
> >>>>>>>
> >>>>>>> * looking it I feel like
> >>>>>>> org.apache.tamaya.Configuration#get(java.lang.String) should be
> the
> >>>>>>> only method of Configuration. I'm not sure about current(), still
> >>>>>>> think it shouldnt be here but in something like in
> >>>>>>> ConfigurationFactory but not in configuration itself - at least to
> be
> >>>>>>> aligned on common practises
> >>>>>>
> >>>>>>
> >>>>>> -1 for String only, type safe access is one of the most wanted
> >>> feature in
> >>>>>> the community.
> >>>>>> -1 for putting it elsewhere: It is JDK 8 style to do so. On top it
> >>> would
> >>>>>> require adding an additional artifact to the API, which is not
> >>> necessary.
> >>>>>> Keepo the API as small as possible. If seee further use cases that
> >>>>> require
> >>>>>> additional artifacts, we may reconsider this, but as of now I would
> >>> let
> >>>>> be
> >>>>>> where it is.
> >>>>>
> >>>>> excepted it is not consistent this way: why providing some specific
> >>>>> method but not "mine". Why allowing to get implicit conversion and to
> >>>>> provide a PropertyAdapter as parameter.
> >>>>>
> >>>>> etc...
> >>>>>
> >>>>> I agree it is an important and nice feature but it is not a core one.
> >>>>>
> >>>>> One thing you forgot is: as a user you want *your* logic which can be
> >>>>> spring, xbean, a custom one.... That's why i strongly think it should
> >>>>> be outside the core to ease integration with other frameworks and not
> >>>>> collide on conversion process.
> >>>>>
> >>>>> About current(): all EE stack does it otherwise ;). The fact JDK 8
> >>>>> allows to mix layers doesnt mean we should do it and that's what does
> >>>>> current for me: mixing service and data layers.
> >>>>>
> >>>>>>
> >>>>>> * All "adapt-friendly" methods should go elsewhere IMO but not the
> >>>>>>> core API - I guess it could be a mecanism used by all libs we'll
> add
> >>>>>>> on top of it but I wouldn't bind tamaya-core-api to it since today
> >>>>>>> when you integrate a config with an existing factory you already
> have
> >>>>>>> it and it just adds noise the core ATM - once again I dont say to
> >>> drop
> >>>>>>> it but just to move it to another module for now.
> >>>>>> -1 see above (one of the most wanted features). Additionally getXXX
> >>> for
> >>>>>> JDK wrapper types is a quite common API style in SE. Perhaps Werner
> >>> can
> >>>>>> correct me, if I am wrong here. Definitively it helps users, since
> >>> they
> >>>>>> now, that for these types the have guaranteed adapter support and
> >>> this is
> >>>>>> clearly visible from the API.
> >>>>>
> >>>>> Maybe where we don't agree is the fact I'm sure nobody excepted
> >>>>> framework writers will use this layer so smaller it is better it is.
> I
> >>>>> would put the easiness effort on next layer and not this one.
> >>>>>
> >>>>>>
> >>>>>>> - PropertySource:
> >>>>>>>
> >>>>>>> * not sure I get name need, for a future gui?
> >>>>>> Yes and no, Name allows traceability and enables dynamic access of
> the
> >>>>>> configuration components from outside, e.g. from managment
> >>> functionality.
> >>>>>> Name could be the file name and additional info.
> >>>>>
> >>>>> using toString can be enough while we don't need this feature (why
> >>>>> introducing an API if the framework does nothing with it?).
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>> * think it misses something between get(String) and
> getProperties() -
> >>>>>>> == I agree with the TODO to replace getProperties() by
> >>>>>>> getPropertyKeys(). Wonder if we should get PropertySource and
> >>>>>>> ListablePropertySource instead of isScannable(). Last one would
> >>>>>>> implement Iterable<String> (for getPropertyKeys()). wdyt?
> >>>>>> I would prefer as well adding the keySet() method (it was part of my
> >>>>>> original proposal).
> >>>>>> -1 for Iterable<String>: I can do that easily from the key set, and
> I
> >>>>> don't
> >>>>>> want to have references on my property source through whatever loops
> >>> at
> >>>>>> runtime (possible risk of side effects).
> >>>>>> -1 for ListPropertySource. Most of the property sources, even remote
> >>>>> ones,
> >>>>>> will be scannable. Using instanceof to check, if an instance is
> >>> scannable
> >>>>>> or not, seems for me to much efforts, compared to having the small
> >>>>> boolean
> >>>>>> method.
> >>>>>
> >>>>> Was not the point. Point was on implementer side API is easier to
> use.
> >>>>> Impl is a detail then.
> >>>>>
> >>>>>> - PropertySourceProvider:
> >>>>>>>
> >>>>>>> * a detail but shouldn't it be PropertySourcesProvider?
> >>>>>> tbd (other opinions?). In Deltaspike it is called
> >>> ConfigSourceProvider.
> >>>>>> For me it looks OK, also with the singular...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - ServiceContext:
> >>>>>>>
> >>>>>>> * do we need all these default methods? I would do T
> >>>>>>> getTamayaService(Class) and List getUserServices(Class) maybe. This
> >>>>>>> can have an impact on the way it is loaded then - you dont want to
> >>>>>>> load some tamaya services from a lower classloader (SericeContext
> and
> >>>>>>> Configuratoin[Factory] ones typically). ATM getService() and
> >>>>>>> getServices() doesn't differentiate it and then we could combine
> both
> >>>>>>> in our usages and have issues later
> >>>>>>> .
> >>>>>>
> >>>>>> We know there are things to improved here. This class was not yet
> >>>>> analyzed
> >>>>>> in more detail last night (it was about 1:30 pm !). We will continue
> >>>>>> today...
> >>>>>>
> >>>>>> Anatole
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Romain Manni-Bucau
> >>>>>>> @rmannibucau
> >>>>>>> http://www.tomitribe.com
> >>>>>>> http://rmannibucau.wordpress.com
> >>>>>>> https://github.com/rmannibucau
> >>>>>>>
> >>>>>>>
> >>>>>>> 2014-12-29 16:11 GMT+01:00 Anatole Tresch <[email protected]>:
> >>>>>>>> Hi Oliver/all
> >>>>>>>>
> >>>>>>>> when you look at the api package you will find the API we have
> >>> agreed
> >>>>> on
> >>>>>>>> together last night. Lookt at it and feel free to discuss. We will
> >>>>> meet
> >>>>>>> for
> >>>>>>>> another Hangout session this evening again.
> >>>>>>>>
> >>>>>>>> -Anatole
> >>>>>>>>
> >>>>>>>> 2014-12-28 20:21 GMT+01:00 Oliver B. Fischer <
> >>>>> [email protected]>:
> >>>>>>>>
> >>>>>>>>> I hate timezones: 9 PM UTZ at Tuesday...
> >>>>>>>>>
> >>>>>>>>>> Am 28.12.14 um 19:55 schrieb Werner Keil:
> >>>>>>>>>>
> >>>>>>>>>> UTZ, so does it mean Midnight CET?
> >>>>>>>>>> And did "Thuesday" mean Tuesday or Thursday?;-)
> >>>>>>>>>>
> >>>>>>>>>> I can't say, if I'll be on a tablet then. This is a prepaid, but
> >>> I
> >>>>> may
> >>>>>>> top
> >>>>>>>>>> it up although I'm just here till the first week of Jan to use
> >>> that.
> >>>>>>>>>> Other places I use there are people long after midnight in most
> >>>>> cases,
> >>>>>>> but
> >>>>>>>>>> that depends on public transport in Vienna going that long...
> >>>>>>>>>>
> >>>>>>>>>> Everything but Wed night sounds OK, but even Tue and Thu people
> >>> will
> >>>>>>>>>> already/still launch a lot of fireworks here;-O
> >>>>>>>>>>
> >>>>>>>>>> Werner
> >>>>>>>>>>
> >>>>>>>>>> On Sun, Dec 28, 2014 at 7:23 PM, Oliver B. Fischer <
> >>>>>>>>>> [email protected]
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>> What's about Thuesday around 11pm UTZ?
> >>>>>>>>>>>
> >>>>>>>>>>> Am 28.12.14 um 16:42 schrieb Mark Struberg:
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> N Oliver B. Fischer
> >>>>>>>>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>>>>>>>>> P +49 30 44793251
> >>>>>>>>>>> M +49 178 7903538
> >>>>>>>>>>> E [email protected]
> >>>>>>>>>>> S oliver.b.fischer
> >>>>>>>>>>> J [email protected]
> >>>>>>>>>>> X http://xing.to/obf
> >>>>>>>>> --
> >>>>>>>>> N Oliver B. Fischer
> >>>>>>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>>>>>>> P +49 30 44793251
> >>>>>>>>> M +49 178 7903538
> >>>>>>>>> E [email protected]
> >>>>>>>>> S oliver.b.fischer
> >>>>>>>>> J [email protected]
> >>>>>>>>> X http://xing.to/obf
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> *Anatole Tresch*
> >>>>>>>> Java Engineer & Architect, JSR Spec Lead
> >>>>>>>> Glärnischweg 10
> >>>>>>>> CH - 8620 Wetzikon
> >>>>>>>>
> >>>>>>>> *Switzerland, Europe Zurich, GMT+1*
> >>>>>>>> *Twitter: @atsticks*
> >>>>>>>> *Blogs: **http://javaremarkables.blogspot.ch/
> >>>>>>>> <http://javaremarkables.blogspot.ch/>*
> >>>>>>>>
> >>>>>>>> *Google: atsticksMobile +41-76 344 62 79*
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> *Anatole Tresch*
> >>>>>> Java Engineer & Architect, JSR Spec Lead
> >>>>>> Glärnischweg 10
> >>>>>> CH - 8620 Wetzikon
> >>>>>>
> >>>>>> *Switzerland, Europe Zurich, GMT+1*
> >>>>>> *Twitter: @atsticks*
> >>>>>> *Blogs: **http://javaremarkables.blogspot.ch/
> >>>>>> <http://javaremarkables.blogspot.ch/>*
> >>>>>>
> >>>>>> *Google: atsticksMobile +41-76 344 62 79*
> >>
> >>
> >>
> >> --
> >> *Anatole Tresch*
> >> Java Engineer & Architect, JSR Spec Lead
> >> Glärnischweg 10
> >> CH - 8620 Wetzikon
> >>
> >> *Switzerland, Europe Zurich, GMT+1*
> >> *Twitter: @atsticks*
> >> *Blogs: **http://javaremarkables.blogspot.ch/
> >> <http://javaremarkables.blogspot.ch/>*
> >>
> >> *Google: atsticksMobile +41-76 344 62 79*
>
