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*
