We will see how it works...
Am 06.01.15 um 11:00 schrieb Reinhard Sandtner:
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*
--
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
