also +1 for URL i think URL is enough at this point
imo the propertySource should know its format or where to get the properties from. we can not provide functionality for each and every case. but we will see what users want to do and what they need so we can provide the functionality later. lg reini > Am 06.01.2015 um 10:29 schrieb Anatole Tresch <[email protected]>: > > Hehe, seems your answers are faster than mine - looks we have an agreement > on URL ;) > > 2015-01-06 10:22 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> hehe >> >> [just cause I found it fun] >> URI -> java.net.URI#toURL >> [/] >> >> I understand you have concerns but I still dont get any of them. If we >> take the Resource abstraction you proposed I see nothing mandatory - >> compared to an URL. I also don't get why it is hard to extend, you >> just pass a handler to a constructor. Last point: which case needs >> this? Pretty sure the cases you mentionned will rely on their own >> property source whatever format it is - I think to a rest service for >> instance. For now - but once again I can miss something, just waiting >> for your exemples - I just see it as a mathematical theory where we >> just need a physical one - one which works for most of usages. >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-06 10:13 GMT+01:00 Anatole Tresch <[email protected]>: >>> No, this is not necessarily true. The decision was to not put it as part >> of >>> core. If other alternatives do not work, we may still discuss how we >> solve >>> our problem. I stated that I have concerns on the extendibility side of >>> URLs, so if we dont't have really good answers to tackle that issues, we >>> will have to look for another solution to solve the resource abstraction >>> problem. There is a reason why Spring has done its abstraction. And it is >>> not about Ant scripting per se, but lets keep away from that fundamental >>> discussion and focus on the problem we want to solve: how to model >>> resources in a unified, effective and extendible way, so we can let >> formats >>> (and probably other logic) consume them savily and with a common API. >>> >>> We could also try to use URIs as abstraction, which do not have the >>> constraints about registered URL handlers, but we then must have some >> logic >>> that is able, e.g. to convert an URI into a input stream... >>> >>> So ideas are welcome! >>> >>> >>> >>> 2015-01-06 8:56 GMT+01:00 Romain Manni-Bucau <[email protected]>: >>> >>>> IIRC we agreed to move format in extensions so it means this is not >>>> the selected solution, no? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2015-01-06 8:55 GMT+01:00 Oliver B. Fischer <[email protected]>: >>>>> I found the discussion from two days ago. But I would like to see this >>>>> discussed in a separate thread. At least I didn't see that we have a >>>> common >>>>> opinion on that. >>>>> >>>>> Oliver >>>>> >>>>> Am 06.01.15 um 08:29 schrieb Oliver B. Fischer: >>>>> >>>>>> Dear all, >>>>>> >>>>>> we have to clarify how do we find a property source at the end of the >>>> day. >>>>>> I have seen now three different apporaches: >>>>>> >>>>>> 1. org.apache.tamaya.format.ConfigurationFormat interface by Anatole >>>>>> 2. Using an URL by Reinhard >>>>>> 3. Custom interface by me for the JSON PropertySource >>>>>> >>>>>> The solution by Anatole and me is very similar and could be unified >>>>>> easily. Independent of the way we go this interface belongs to the >> core >>>>>> module. Or not? >>>>>> >>>>>> Furthermore how does a normal Java SE user will use it? How does the >> top >>>>>> level usage of Tamaya looks like? >>>>>> >>>>>> Oliver >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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*
