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*
