You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Oliver B. Fischer" <o....@swe-blog.net> on 2015/02/12 08:23:14 UTC
Locating a property source for a given format
Dear all,
PropertySource is our abstraction for different property sources and
formats. I think we agree on this. Furthermore we said the origin of a
source must be overhanded as a URL (file://somewhere/).
That is fine and works. But IMHO we miss the connection between them.
How to specify a specific property source and to find the matching
PropertySource?
Therefore I would like to propose a option SPI: PropertySourceLocator (?)
PropertySourceLocator#accepts(URL url):boolean
PropertySourceLocator#get(URL url): PropertySource
WDYT?
Oliver
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Mark: I know but we don't use Java EE at work. Only in some legacy
components but for new components Java EE is prohibited.
Oliver
Am 12.02.15 um 17:11 schrieb Mark Struberg:
> config/*.ext and other wildcard stuff comes down to the issue with non-existing support for it in ClassLoaders. So you will only be able to get this running an a few JVMs and e.g. not on that many JavaEE servers.
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Thursday, 12 February 2015, 16:45, Oliver B. Fischer <o....@swe-blog.net> wrote:
>> like to help our users to write things like
>>
>> builder.addPropertySources("file://.../config/*.ext")
>> .build();
>>
>> I know how to resolve "file:/.../config/*.ext"). But there is no
>> generic
>> way AFAIK to find the PropertySource handling ".ext".
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 12.02.15 um 10:41 schrieb Anatole Tresch:
>> yet
>> MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
>> <o....@swe-blog.net> a
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Mark Struberg <st...@yahoo.de>.
config/*.ext and other wildcard stuff comes down to the issue with non-existing support for it in ClassLoaders. So you will only be able to get this running an a few JVMs and e.g. not on that many JavaEE servers.
LieGrue,
strub
> On Thursday, 12 February 2015, 16:45, Oliver B. Fischer <o....@swe-blog.net> wrote:
> > I felt this feature would be nice for the ConfigurationBuilder. I would
> like to help our users to write things like
>
> builder.addPropertySources("file://.../config/*.ext")
> .build();
>
> I know how to resolve "file:/.../config/*.ext"). But there is no
> generic
> way AFAIK to find the PropertySource handling ".ext".
>
> Bye,
>
> Oliver
>
>
> Am 12.02.15 um 10:41 schrieb Anatole Tresch:
>> +1 for some sample snippets. Perhaps also look at the extensions module
>> called 'formats'. This is still work in progress though (I am not
> yet
>> satisfied with the abstractions), though it might go in a direction you
>> also are thinking, perhaps...?
>>
>> public class MyTestSinglePropertySourceProvider extends
>> BaseSimpleFormatPropertySourceProvider{
>> public MyTestSinglePropertySourceProvider() {
>> super(new JSonFormat(),
>> MyTestSinglePropertySourceProvider.class.getResource(
>> "META-INF/config/myConfig.ini"));
>> }
>>
>> @Override
>> protected PropertySource createPropertySource(String entryTypeName,
>> Map<String, String> entries,
>> ConfigurationFormat
>> formatUsed) {
>> // assuming there is only one entryTypeName = default
>> return new HirarchicalPropertySource(entries);
>> }
>> }
>>
>> and
>>
>> public class MyTestMultiPropertySourceProvider extends
>> BasePathBasedMultiFormatPropertySourceProvider{
>> public
> MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
>> formats, String... paths) {
>> super(Arrays.asList(new ConfigurationFormat[]{}
>> new JsonFormat(),
>> new PropertiesFormat(),
>> new IniConfigurationFormat()}
>> ), "META-INF/config/tamaya-config.*");
>> }
>>
>> @Override
>> protected PropertySource getPropertySource(String entryTypeName,
>> Map<String, String> entries,
>> ConfigurationFormat
>> formatUsed) {
>> // Convert items read into a corresponding PropertySource
>> return null;
>> }
>> }
>>
>> Cheers,
>> Anatole
>>
>>
>>
>> 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> Can you give a sample please? I dont get the point
>>> Le 12 févr. 2015 08:25, "Oliver B. Fischer"
> <o....@swe-blog.net> a
>>> écrit :
>>>
>>
>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I felt this feature would be nice for the ConfigurationBuilder. I would
like to help our users to write things like
builder.addPropertySources("file://.../config/*.ext")
.build();
I know how to resolve "file:/.../config/*.ext"). But there is no generic
way AFAIK to find the PropertySource handling ".ext".
Bye,
Oliver
Am 12.02.15 um 10:41 schrieb Anatole Tresch:
> +1 for some sample snippets. Perhaps also look at the extensions module
> called 'formats'. This is still work in progress though (I am not yet
> satisfied with the abstractions), though it might go in a direction you
> also are thinking, perhaps...?
>
> public class MyTestSinglePropertySourceProvider extends
> BaseSimpleFormatPropertySourceProvider{
> public MyTestSinglePropertySourceProvider() {
> super(new JSonFormat(),
> MyTestSinglePropertySourceProvider.class.getResource(
> "META-INF/config/myConfig.ini"));
> }
>
> @Override
> protected PropertySource createPropertySource(String entryTypeName,
> Map<String, String> entries,
> ConfigurationFormat
> formatUsed) {
> // assuming there is only one entryTypeName = default
> return new HirarchicalPropertySource(entries);
> }
> }
>
> and
>
> public class MyTestMultiPropertySourceProvider extends
> BasePathBasedMultiFormatPropertySourceProvider{
> public MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
> formats, String... paths) {
> super(Arrays.asList(new ConfigurationFormat[]{}
> new JsonFormat(),
> new PropertiesFormat(),
> new IniConfigurationFormat()}
> ), "META-INF/config/tamaya-config.*");
> }
>
> @Override
> protected PropertySource getPropertySource(String entryTypeName,
> Map<String, String> entries,
> ConfigurationFormat
> formatUsed) {
> // Convert items read into a corresponding PropertySource
> return null;
> }
> }
>
> Cheers,
> Anatole
>
>
>
> 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> Can you give a sample please? I dont get the point
>> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <o....@swe-blog.net> a
>> écrit :
>>
>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Romain But my configuration is stored in different files.
My criteria for Tamaya is if it can be used at work with little effort.
Better with less effort as we do currently. Currently I an not do what I
need with Tamaya. ;-(
Oliver
Am 12.02.15 um 17:43 schrieb Romain Manni-Bucau:
> You judt want few custom sources you can call directly for that purpose but
> to be honest this look like the opposite of tamaya design (you dont
> discover files but property sources)
> Le 12 févr. 2015 17:37, "Anatole Tresch" <at...@gmail.com> a écrit :
>
>> Definitivly not, semms for mw you mix up things_
>>
>> PropertySourceProvider = n PropertySources
>> Location(URL) + format + Config/PriorityMapping = n PropertySources
>>
>> Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
>> 16:51:20:
>>
>> entryTypeName,
>> o.b.fischer@swe-blog.net>
>> a
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I don't get it.. ?
Am 12.02.15 um 17:43 schrieb Romain Manni-Bucau:
> You judt want few custom sources you can call directly for that purpose but
> to be honest this look like the opposite of tamaya design (you dont
> discover files but property sources)
> Le 12 févr. 2015 17:37, "Anatole Tresch" <at...@gmail.com> a écrit :
>
>> Definitivly not, semms for mw you mix up things_
>>
>> PropertySourceProvider = n PropertySources
>> Location(URL) + format + Config/PriorityMapping = n PropertySources
>>
>> Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
>> 16:51:20:
>>
>> entryTypeName,
>> o.b.fischer@swe-blog.net>
>> a
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
@Oliver
Matches IMO perfectly a PropertySourceProvider, which
1) reads a system property (or whatever) that defines where your
/super/folder/ is.
2) It can use the resources extension to extract all child files (or only
some with special file endings), or do it itself.
3) You can take each URL and try to create a PropertySource internally
(with whatever logic on mapping the file format in place to
properties/priorities)
4) On success add each PropertySource to the internal list of property
sources.
5) Handover all property sources to the Configuration Context once the
getPropertySources() method is called.
All matches the current API ;) Why we need more?
2015-02-13 9:50 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> @Anatole caricaturally it is:
>
> File[] configs = new File("/super/folder/").listFiles();
> for (final File config : configs) {
> addConfig(config);
> }
>
> (but with URLs)
>
> issue is addConfig.
>
>
> but actually you never do it, you have a provider filtering files it
> can handle so finally all handlable files are read
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-13 9:41 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> > I really dont see the use case, sorry. Can you prrhaps post your current
> builder api, perhaps that helps to get light into the tunnel...
> >
> > -
> > Anatole Tresch
> > Glärnischweg 10
> > 8620 Wetzikon
> > Tel +41 (43) 317 05 30
> > -
> > Send from Mobile
> >
> >> Am 13.02.2015 um 09:18 schrieb Oliver B. Fischer <
> o.b.fischer@swe-blog.net>:
> >>
> >> My problem is only that I am asking for a way to find a PropertySource
> able to handle a given URL. And if a PropertySource is able handle the URL
> it must be also able to parse. At least my PropertyProvider are able to do
> it. But for the ConfigurationBuilder I need a generic ways to find a
> PropertySource able to handle a URL. Ok, I can hardcode it but I think this
> is not what I wan't.
> >>
> >> For now I will add an extension providing a SPI interface. We will see
> how it works out.
> >>
> >> Oliver
> >>
> >>> Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
> >>> The point is API is not done to have auto reading of resources cause it
> >>> makes no sense in most of cases: xml, json, yaml, txt...all these
> formats
> >>> need more than knowing the extension to be able to read it. It means
> >>> PropertySource has to link path and format which is the role of the
> >>> provider you have to write.
> >>>
> >>> Said otherwise each kind of file type you ll discover will need its
> >>> provider otherwise if you do what you described you ll just manage to
> not
> >>> get the expected conf (in the best case)
> >>> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> >>> écrit :
> >>>
> >>>> It helps me to locate resources, right? But if I understand it
> correctly
> >>>> it helps me to get a bunch of URLs. So I am at the same point as
> before.
> >>>>
> >>>> Bye,
> >>>>
> >>>> Oliver
> >>>>
> >>>>
> >>>>
> >>>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
> >>>>
> >>>> --
> >>>> N Oliver B. Fischer
> >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>> P +49 30 44793251
> >>>> M +49 178 7903538
> >>>> E o.b.fischer@swe-blog.net
> >>>> S oliver.b.fischer
> >>>> J oliver.b.fischer@jabber.org
> >>>> 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 o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> 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*
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Anatole caricaturally it is:
File[] configs = new File("/super/folder/").listFiles();
for (final File config : configs) {
addConfig(config);
}
(but with URLs)
issue is addConfig.
but actually you never do it, you have a provider filtering files it
can handle so finally all handlable files are read
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-13 9:41 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> I really dont see the use case, sorry. Can you prrhaps post your current builder api, perhaps that helps to get light into the tunnel...
>
> -
> Anatole Tresch
> Glärnischweg 10
> 8620 Wetzikon
> Tel +41 (43) 317 05 30
> -
> Send from Mobile
>
>> Am 13.02.2015 um 09:18 schrieb Oliver B. Fischer <o....@swe-blog.net>:
>>
>> My problem is only that I am asking for a way to find a PropertySource able to handle a given URL. And if a PropertySource is able handle the URL it must be also able to parse. At least my PropertyProvider are able to do it. But for the ConfigurationBuilder I need a generic ways to find a PropertySource able to handle a URL. Ok, I can hardcode it but I think this is not what I wan't.
>>
>> For now I will add an extension providing a SPI interface. We will see how it works out.
>>
>> Oliver
>>
>>> Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
>>> The point is API is not done to have auto reading of resources cause it
>>> makes no sense in most of cases: xml, json, yaml, txt...all these formats
>>> need more than knowing the extension to be able to read it. It means
>>> PropertySource has to link path and format which is the role of the
>>> provider you have to write.
>>>
>>> Said otherwise each kind of file type you ll discover will need its
>>> provider otherwise if you do what you described you ll just manage to not
>>> get the expected conf (in the best case)
>>> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
>>> écrit :
>>>
>>>> It helps me to locate resources, right? But if I understand it correctly
>>>> it helps me to get a bunch of URLs. So I am at the same point as before.
>>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>>
>>>>
>>>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>>>>
>>>> --
>>>> N Oliver B. Fischer
>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>> P +49 30 44793251
>>>> M +49 178 7903538
>>>> E o.b.fischer@swe-blog.net
>>>> S oliver.b.fischer
>>>> J oliver.b.fischer@jabber.org
>>>> 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
I really dont see the use case, sorry. Can you prrhaps post your current builder api, perhaps that helps to get light into the tunnel...
-
Anatole Tresch
Glärnischweg 10
8620 Wetzikon
Tel +41 (43) 317 05 30
-
Send from Mobile
> Am 13.02.2015 um 09:18 schrieb Oliver B. Fischer <o....@swe-blog.net>:
>
> My problem is only that I am asking for a way to find a PropertySource able to handle a given URL. And if a PropertySource is able handle the URL it must be also able to parse. At least my PropertyProvider are able to do it. But for the ConfigurationBuilder I need a generic ways to find a PropertySource able to handle a URL. Ok, I can hardcode it but I think this is not what I wan't.
>
> For now I will add an extension providing a SPI interface. We will see how it works out.
>
> Oliver
>
>> Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
>> The point is API is not done to have auto reading of resources cause it
>> makes no sense in most of cases: xml, json, yaml, txt...all these formats
>> need more than knowing the extension to be able to read it. It means
>> PropertySource has to link path and format which is the role of the
>> provider you have to write.
>>
>> Said otherwise each kind of file type you ll discover will need its
>> provider otherwise if you do what you described you ll just manage to not
>> get the expected conf (in the best case)
>> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
>> écrit :
>>
>>> It helps me to locate resources, right? But if I understand it correctly
>>> it helps me to get a bunch of URLs. So I am at the same point as before.
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>>
>>>
>>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
isn't the same?
Von meinem iPhone gesendet
> Am 13.02.2015 um 09:41 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> @Olivier: let me rephrase it: you dont find URLs you find
> PropertySources. "find a property source able to handle an URL" doesnt
> make any sense (I get your use case but your code is not designed
> correctly, just change it to handle 1 format and you are done)
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-13 9:18 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> My problem is only that I am asking for a way to find a PropertySource able
>> to handle a given URL. And if a PropertySource is able handle the URL it
>> must be also able to parse. At least my PropertyProvider are able to do it.
>> But for the ConfigurationBuilder I need a generic ways to find a
>> PropertySource able to handle a URL. Ok, I can hardcode it but I think this
>> is not what I wan't.
>>
>> For now I will add an extension providing a SPI interface. We will see how
>> it works out.
>>
>> Oliver
>>
>>> Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
>>>
>>> The point is API is not done to have auto reading of resources cause it
>>> makes no sense in most of cases: xml, json, yaml, txt...all these formats
>>> need more than knowing the extension to be able to read it. It means
>>> PropertySource has to link path and format which is the role of the
>>> provider you have to write.
>>>
>>> Said otherwise each kind of file type you ll discover will need its
>>> provider otherwise if you do what you described you ll just manage to not
>>> get the expected conf (in the best case)
>>> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
>>> écrit :
>>>
>>>> It helps me to locate resources, right? But if I understand it correctly
>>>> it helps me to get a bunch of URLs. So I am at the same point as before.
>>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>>
>>>>
>>>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>>>>
>>>> --
>>>> N Oliver B. Fischer
>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>> P +49 30 44793251
>>>> M +49 178 7903538
>>>> E o.b.fischer@swe-blog.net
>>>> S oliver.b.fischer
>>>> J oliver.b.fischer@jabber.org
>>>> 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Olivier: let me rephrase it: you dont find URLs you find
PropertySources. "find a property source able to handle an URL" doesnt
make any sense (I get your use case but your code is not designed
correctly, just change it to handle 1 format and you are done)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-13 9:18 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> My problem is only that I am asking for a way to find a PropertySource able
> to handle a given URL. And if a PropertySource is able handle the URL it
> must be also able to parse. At least my PropertyProvider are able to do it.
> But for the ConfigurationBuilder I need a generic ways to find a
> PropertySource able to handle a URL. Ok, I can hardcode it but I think this
> is not what I wan't.
>
> For now I will add an extension providing a SPI interface. We will see how
> it works out.
>
> Oliver
>
> Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
>>
>> The point is API is not done to have auto reading of resources cause it
>> makes no sense in most of cases: xml, json, yaml, txt...all these formats
>> need more than knowing the extension to be able to read it. It means
>> PropertySource has to link path and format which is the role of the
>> provider you have to write.
>>
>> Said otherwise each kind of file type you ll discover will need its
>> provider otherwise if you do what you described you ll just manage to not
>> get the expected conf (in the best case)
>> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
>> écrit :
>>
>>> It helps me to locate resources, right? But if I understand it correctly
>>> it helps me to get a bunch of URLs. So I am at the same point as before.
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>>
>>>
>>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
My problem is only that I am asking for a way to find a PropertySource
able to handle a given URL. And if a PropertySource is able handle the
URL it must be also able to parse. At least my PropertyProvider are able
to do it. But for the ConfigurationBuilder I need a generic ways to find
a PropertySource able to handle a URL. Ok, I can hardcode it but I think
this is not what I wan't.
For now I will add an extension providing a SPI interface. We will see
how it works out.
Oliver
Am 13.02.15 um 08:13 schrieb Romain Manni-Bucau:
> The point is API is not done to have auto reading of resources cause it
> makes no sense in most of cases: xml, json, yaml, txt...all these formats
> need more than knowing the extension to be able to read it. It means
> PropertySource has to link path and format which is the role of the
> provider you have to write.
>
> Said otherwise each kind of file type you ll discover will need its
> provider otherwise if you do what you described you ll just manage to not
> get the expected conf (in the best case)
> Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
>> It helps me to locate resources, right? But if I understand it correctly
>> it helps me to get a bunch of URLs. So I am at the same point as before.
>>
>> Bye,
>>
>> Oliver
>>
>>
>>
>> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The point is API is not done to have auto reading of resources cause it
makes no sense in most of cases: xml, json, yaml, txt...all these formats
need more than knowing the extension to be able to read it. It means
PropertySource has to link path and format which is the role of the
provider you have to write.
Said otherwise each kind of file type you ll discover will need its
provider otherwise if you do what you described you ll just manage to not
get the expected conf (in the best case)
Le 13 févr. 2015 00:09, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> It helps me to locate resources, right? But if I understand it correctly
> it helps me to get a bunch of URLs. So I am at the same point as before.
>
> Bye,
>
> Oliver
>
>
>
> Am 12.02.15 um 20:51 schrieb Anatole Tresch:
>
>> Look at the resources extension. It supports Spring styled path resolution
>> to a collection of URLs. Will work in SE, Weblogic, and basically should
>> also in JBoss/Wildfly, but must be tested there since the guys have some
>> interesting classloader design there, which must be handled differently...
>> Basically the extension register another service called ResourceResolver
>> to
>> the ServiceContext.... so we are back to my second original proposal using
>> formats as well ;)
>>
>> 2015-02-12 20:40 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>
>> Hi Antole, my problem is simply that I dont know which PropertySources do
>>> exist. There might be 0 to x possible PropertySources available in the
>>> classpath. So the question is how to I detect them and the method I have
>>> to
>>> call with the given URL.
>>>
>>> Von meinem iPhone gesendet
>>>
>>> this
>>> simple
>>> maps
>>> 2015
>>> PropertySourceLocator
>>> to
>>> one
>>> BTW
>>> not
>>> to
>>> be
>>> to
>>> location,
>>> may
>>>
>>
>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
It helps me to locate resources, right? But if I understand it correctly
it helps me to get a bunch of URLs. So I am at the same point as before.
Bye,
Oliver
Am 12.02.15 um 20:51 schrieb Anatole Tresch:
> Look at the resources extension. It supports Spring styled path resolution
> to a collection of URLs. Will work in SE, Weblogic, and basically should
> also in JBoss/Wildfly, but must be tested there since the guys have some
> interesting classloader design there, which must be handled differently...
> Basically the extension register another service called ResourceResolver to
> the ServiceContext.... so we are back to my second original proposal using
> formats as well ;)
>
> 2015-02-12 20:40 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> Hi Antole, my problem is simply that I dont know which PropertySources do
>> exist. There might be 0 to x possible PropertySources available in the
>> classpath. So the question is how to I detect them and the method I have to
>> call with the given URL.
>>
>> Von meinem iPhone gesendet
>>
>> this
>> simple
>> maps
>> 2015
>> PropertySourceLocator
>> to
>> one
>> BTW
>> not
>> to
>> be
>> to
>> location,
>> may
>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Look at the resources extension. It supports Spring styled path resolution
to a collection of URLs. Will work in SE, Weblogic, and basically should
also in JBoss/Wildfly, but must be tested there since the guys have some
interesting classloader design there, which must be handled differently...
Basically the extension register another service called ResourceResolver to
the ServiceContext.... so we are back to my second original proposal using
formats as well ;)
2015-02-12 20:40 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi Antole, my problem is simply that I dont know which PropertySources do
> exist. There might be 0 to x possible PropertySources available in the
> classpath. So the question is how to I detect them and the method I have to
> call with the given URL.
>
> Von meinem iPhone gesendet
>
> > Am 12.02.2015 um 19:56 schrieb Anatole Tresch <at...@gmail.com>:
> >
> > Hi Oliver
> >
> > How should your spi fit into what we have? You register either
> > propertysources or propertysourceprviders.you can implement a
> > propertysourceprovider that eg reads another config or cli param and
> > creates the corresponding propertysources.they way you do it, you either
> > have hardcoded the priority or read it from the file. Also your mapping
> > from your config file to key/values is clearly defined imo. So for me
> this
> > looks like a fairly trivial use case.
> > Now in huge j2ee environments you have config that has different prios
> > depending it is a file, a system property or a classloader. Even the
> > classloader hierarchy itself has multiple levels/prios. Finally there is
> > not necessarily a unique mapping to key/value pairs. Even when using
> simple
> > ini files different sections may not be part of the key at all, instead
> > they may named "defaults", "system", "app", "ops", "management". Each
> maps
> > to a different prio, so you have 1-n mapping between url and
> > propertysource. This is not reflected by your spi proposal at all (but
> > covered by my current work).
> > Hope that helps... ;-)
> > Oliver B. Fischer <o....@swe-blog.net> schrieb am Do., 12. Feb.
> 2015
> > um 19:04:
> >
> >> Hi Anatole,
> >>
> >> IMHO the suggest SPI is the solution you expected. With this SPI I can
> >> implement a proper URL support without any hardcoded stuff. Ok, the
> >> implementation of the SPI knows how to instantiate it's PropertySource.
> >> But since both are provided by the same module/author/extension this is
> >> ok IMHO.
> >>
> >> But let me cite the JavaDoc of PropertySource
> >>
> >> This interface models a provider that serves configuration properties.
> >> The contained
> >> properties may be read fromMap single or several sources (composite).
> >> PropertySources are the building blocks of the final configuration.
> >>
> >> So from the perspective of PropertySource it is ok if the PropertySource
> >> is responsible for reading and parsing it's source.
> >>
> >> As I said in my initial post: The only think except for array support is
> >> a link between a URL and a PropertySource.
> >>
> >> So please give me a runnable example with the code as it is today how I
> >> can do it in an generic way.
> >>
> >> Bye,
> >>
> >> Oliver
> >>
> >>
> >>
> >>> Am 12.02.15 um 18:13 schrieb Anatole Tresch:
> >>> Ho Oliver
> >>>
> >>> O do noz get your point, see inline...
> >>>
> >>> 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> >>>
> >>>> Why is it so fucking hard to do easy things easily? ;-)
> >>>>
> >>>> Here is an example implementation for th JSONPropertySource
> >>>>
> >>>> public class JSONPropertySourceLocator implements
> PropertySourceLocator
> >> {
> >>>> @Override
> >>>> public PropertySource get(URL source) {
> >>>> if (!accepts(source)) {
> >>>> String mesg = format("%s is not supported",
> >> source.toString());
> >>>> throw new ConfigException(mesg);
> >>>> }
> >>>>
> >>>> return new JSONPropertySource(source);
> >>>> }
> >>>> }
> >>>>
> >>>> 1) who is providing the URLs ?
> >>> 2) Checking for an URL, if it is accepted, most of the time is a format
> >>> issue IMO only. So your code above basically
> >>> dies the same as a format, but unfortunately on top mixes it with a
> >>> PropertySource.
> >>>
> >>>
> >>>> Adding a PropertySourceProviderManager is not helpfull because it has
> to
> >>>> discover existing format (Anatoles approach) or
> >>> This is not true. My example PropertySource can as well use exactly
> one
> >>> single format, but also is fkexible enough to support multiple ones.
> BTW
> >>> also a precondition, when you want to be able to integrate alternate
> >> format
> >>> implementations such as commons-configuration ;)
> >>>
> >>>
> >>>
> >>>> existing PropertySource implementation. Every PropertySource must be
> >>>> scanned for an ctor with URL parameter and so on and so on. This is
> not
> >> an
> >>>> very flexible design..
> >>> As I said, I am also not completely satisfied with everything related
> to
> >>> that, but when doing some criticiscm of things being inflexible, also
> be
> >>> aware that I expect you to provide some ideas how to improve it, Mixing
> >> up
> >>> formats (the act of parsing), with the act of mapping the parsed data
> to
> >> a
> >>> flat key, value structure and assigning (depending on the file
> location,
> >>> the file entries and whatever else) the correct priority for every
> >>> key/value pair, are three aspects that each one must be decided on its
> >> own.
> >>> Hardcoding anything makes no sense from a framework perspective (but
> may
> >> be
> >>> from an enterprise perspective)...
> >>>
> >>>
> >>>> Bye,
> >>>>
> >>>> Oliver
> >>>>
> >>>>
> >>>> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
> >>>>
> >>>> --
> >>>> N Oliver B. Fischer
> >>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>>> P +49 30 44793251
> >>>> M +49 178 7903538
> >>>> E o.b.fischer@swe-blog.net
> >>>> S oliver.b.fischer
> >>>> J oliver.b.fischer@jabber.org
> >>>> 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 o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> 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*
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Antole, my problem is simply that I dont know which PropertySources do exist. There might be 0 to x possible PropertySources available in the classpath. So the question is how to I detect them and the method I have to call with the given URL.
Von meinem iPhone gesendet
> Am 12.02.2015 um 19:56 schrieb Anatole Tresch <at...@gmail.com>:
>
> Hi Oliver
>
> How should your spi fit into what we have? You register either
> propertysources or propertysourceprviders.you can implement a
> propertysourceprovider that eg reads another config or cli param and
> creates the corresponding propertysources.they way you do it, you either
> have hardcoded the priority or read it from the file. Also your mapping
> from your config file to key/values is clearly defined imo. So for me this
> looks like a fairly trivial use case.
> Now in huge j2ee environments you have config that has different prios
> depending it is a file, a system property or a classloader. Even the
> classloader hierarchy itself has multiple levels/prios. Finally there is
> not necessarily a unique mapping to key/value pairs. Even when using simple
> ini files different sections may not be part of the key at all, instead
> they may named "defaults", "system", "app", "ops", "management". Each maps
> to a different prio, so you have 1-n mapping between url and
> propertysource. This is not reflected by your spi proposal at all (but
> covered by my current work).
> Hope that helps... ;-)
> Oliver B. Fischer <o....@swe-blog.net> schrieb am Do., 12. Feb. 2015
> um 19:04:
>
>> Hi Anatole,
>>
>> IMHO the suggest SPI is the solution you expected. With this SPI I can
>> implement a proper URL support without any hardcoded stuff. Ok, the
>> implementation of the SPI knows how to instantiate it's PropertySource.
>> But since both are provided by the same module/author/extension this is
>> ok IMHO.
>>
>> But let me cite the JavaDoc of PropertySource
>>
>> This interface models a provider that serves configuration properties.
>> The contained
>> properties may be read fromMap single or several sources (composite).
>> PropertySources are the building blocks of the final configuration.
>>
>> So from the perspective of PropertySource it is ok if the PropertySource
>> is responsible for reading and parsing it's source.
>>
>> As I said in my initial post: The only think except for array support is
>> a link between a URL and a PropertySource.
>>
>> So please give me a runnable example with the code as it is today how I
>> can do it in an generic way.
>>
>> Bye,
>>
>> Oliver
>>
>>
>>
>>> Am 12.02.15 um 18:13 schrieb Anatole Tresch:
>>> Ho Oliver
>>>
>>> O do noz get your point, see inline...
>>>
>>> 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>>> Why is it so fucking hard to do easy things easily? ;-)
>>>>
>>>> Here is an example implementation for th JSONPropertySource
>>>>
>>>> public class JSONPropertySourceLocator implements PropertySourceLocator
>> {
>>>> @Override
>>>> public PropertySource get(URL source) {
>>>> if (!accepts(source)) {
>>>> String mesg = format("%s is not supported",
>> source.toString());
>>>> throw new ConfigException(mesg);
>>>> }
>>>>
>>>> return new JSONPropertySource(source);
>>>> }
>>>> }
>>>>
>>>> 1) who is providing the URLs ?
>>> 2) Checking for an URL, if it is accepted, most of the time is a format
>>> issue IMO only. So your code above basically
>>> dies the same as a format, but unfortunately on top mixes it with a
>>> PropertySource.
>>>
>>>
>>>> Adding a PropertySourceProviderManager is not helpfull because it has to
>>>> discover existing format (Anatoles approach) or
>>> This is not true. My example PropertySource can as well use exactly one
>>> single format, but also is fkexible enough to support multiple ones. BTW
>>> also a precondition, when you want to be able to integrate alternate
>> format
>>> implementations such as commons-configuration ;)
>>>
>>>
>>>
>>>> existing PropertySource implementation. Every PropertySource must be
>>>> scanned for an ctor with URL parameter and so on and so on. This is not
>> an
>>>> very flexible design..
>>> As I said, I am also not completely satisfied with everything related to
>>> that, but when doing some criticiscm of things being inflexible, also be
>>> aware that I expect you to provide some ideas how to improve it, Mixing
>> up
>>> formats (the act of parsing), with the act of mapping the parsed data to
>> a
>>> flat key, value structure and assigning (depending on the file location,
>>> the file entries and whatever else) the correct priority for every
>>> key/value pair, are three aspects that each one must be decided on its
>> own.
>>> Hardcoding anything makes no sense from a framework perspective (but may
>> be
>>> from an enterprise perspective)...
>>>
>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>>
>>>> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>>>>
>>>> --
>>>> N Oliver B. Fischer
>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>> P +49 30 44793251
>>>> M +49 178 7903538
>>>> E o.b.fischer@swe-blog.net
>>>> S oliver.b.fischer
>>>> J oliver.b.fischer@jabber.org
>>>> 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Hi Oliver
How should your spi fit into what we have? You register either
propertysources or propertysourceprviders.you can implement a
propertysourceprovider that eg reads another config or cli param and
creates the corresponding propertysources.they way you do it, you either
have hardcoded the priority or read it from the file. Also your mapping
from your config file to key/values is clearly defined imo. So for me this
looks like a fairly trivial use case.
Now in huge j2ee environments you have config that has different prios
depending it is a file, a system property or a classloader. Even the
classloader hierarchy itself has multiple levels/prios. Finally there is
not necessarily a unique mapping to key/value pairs. Even when using simple
ini files different sections may not be part of the key at all, instead
they may named "defaults", "system", "app", "ops", "management". Each maps
to a different prio, so you have 1-n mapping between url and
propertysource. This is not reflected by your spi proposal at all (but
covered by my current work).
Hope that helps... ;-)
Oliver B. Fischer <o....@swe-blog.net> schrieb am Do., 12. Feb. 2015
um 19:04:
> Hi Anatole,
>
> IMHO the suggest SPI is the solution you expected. With this SPI I can
> implement a proper URL support without any hardcoded stuff. Ok, the
> implementation of the SPI knows how to instantiate it's PropertySource.
> But since both are provided by the same module/author/extension this is
> ok IMHO.
>
> But let me cite the JavaDoc of PropertySource
>
> This interface models a provider that serves configuration properties.
> The contained
> properties may be read fromMap single or several sources (composite).
> PropertySources are the building blocks of the final configuration.
>
> So from the perspective of PropertySource it is ok if the PropertySource
> is responsible for reading and parsing it's source.
>
> As I said in my initial post: The only think except for array support is
> a link between a URL and a PropertySource.
>
> So please give me a runnable example with the code as it is today how I
> can do it in an generic way.
>
> Bye,
>
> Oliver
>
>
>
> Am 12.02.15 um 18:13 schrieb Anatole Tresch:
> > Ho Oliver
> >
> > O do noz get your point, see inline...
> >
> > 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >
> >> Why is it so fucking hard to do easy things easily? ;-)
> >>
> >> Here is an example implementation for th JSONPropertySource
> >>
> >> public class JSONPropertySourceLocator implements PropertySourceLocator
> {
> >> @Override
> >> public PropertySource get(URL source) {
> >> if (!accepts(source)) {
> >> String mesg = format("%s is not supported",
> source.toString());
> >> throw new ConfigException(mesg);
> >> }
> >>
> >> return new JSONPropertySource(source);
> >> }
> >> }
> >>
> >> 1) who is providing the URLs ?
> > 2) Checking for an URL, if it is accepted, most of the time is a format
> > issue IMO only. So your code above basically
> > dies the same as a format, but unfortunately on top mixes it with a
> > PropertySource.
> >
> >
> >> Adding a PropertySourceProviderManager is not helpfull because it has to
> >> discover existing format (Anatoles approach) or
> > This is not true. My example PropertySource can as well use exactly one
> > single format, but also is fkexible enough to support multiple ones. BTW
> > also a precondition, when you want to be able to integrate alternate
> format
> > implementations such as commons-configuration ;)
> >
> >
> >
> >> existing PropertySource implementation. Every PropertySource must be
> >> scanned for an ctor with URL parameter and so on and so on. This is not
> an
> >> very flexible design..
> >>
> > As I said, I am also not completely satisfied with everything related to
> > that, but when doing some criticiscm of things being inflexible, also be
> > aware that I expect you to provide some ideas how to improve it, Mixing
> up
> > formats (the act of parsing), with the act of mapping the parsed data to
> a
> > flat key, value structure and assigning (depending on the file location,
> > the file entries and whatever else) the correct priority for every
> > key/value pair, are three aspects that each one must be decided on its
> own.
> > Hardcoding anything makes no sense from a framework perspective (but may
> be
> > from an enterprise perspective)...
> >
> >
> >> Bye,
> >>
> >> Oliver
> >>
> >>
> >> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
> >>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Anatole,
IMHO the suggest SPI is the solution you expected. With this SPI I can
implement a proper URL support without any hardcoded stuff. Ok, the
implementation of the SPI knows how to instantiate it's PropertySource.
But since both are provided by the same module/author/extension this is
ok IMHO.
But let me cite the JavaDoc of PropertySource
This interface models a provider that serves configuration properties.
The contained
properties may be read fromMap single or several sources (composite).
PropertySources are the building blocks of the final configuration.
So from the perspective of PropertySource it is ok if the PropertySource
is responsible for reading and parsing it's source.
As I said in my initial post: The only think except for array support is
a link between a URL and a PropertySource.
So please give me a runnable example with the code as it is today how I
can do it in an generic way.
Bye,
Oliver
Am 12.02.15 um 18:13 schrieb Anatole Tresch:
> Ho Oliver
>
> O do noz get your point, see inline...
>
> 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>
>> Why is it so fucking hard to do easy things easily? ;-)
>>
>> Here is an example implementation for th JSONPropertySource
>>
>> public class JSONPropertySourceLocator implements PropertySourceLocator {
>> @Override
>> public PropertySource get(URL source) {
>> if (!accepts(source)) {
>> String mesg = format("%s is not supported", source.toString());
>> throw new ConfigException(mesg);
>> }
>>
>> return new JSONPropertySource(source);
>> }
>> }
>>
>> 1) who is providing the URLs ?
> 2) Checking for an URL, if it is accepted, most of the time is a format
> issue IMO only. So your code above basically
> dies the same as a format, but unfortunately on top mixes it with a
> PropertySource.
>
>
>> Adding a PropertySourceProviderManager is not helpfull because it has to
>> discover existing format (Anatoles approach) or
> This is not true. My example PropertySource can as well use exactly one
> single format, but also is fkexible enough to support multiple ones. BTW
> also a precondition, when you want to be able to integrate alternate format
> implementations such as commons-configuration ;)
>
>
>
>> existing PropertySource implementation. Every PropertySource must be
>> scanned for an ctor with URL parameter and so on and so on. This is not an
>> very flexible design..
>>
> As I said, I am also not completely satisfied with everything related to
> that, but when doing some criticiscm of things being inflexible, also be
> aware that I expect you to provide some ideas how to improve it, Mixing up
> formats (the act of parsing), with the act of mapping the parsed data to a
> flat key, value structure and assigning (depending on the file location,
> the file entries and whatever else) the correct priority for every
> key/value pair, are three aspects that each one must be decided on its own.
> Hardcoding anything makes no sense from a framework perspective (but may be
> from an enterprise perspective)...
>
>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Ho Oliver
O do noz get your point, see inline...
2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Why is it so fucking hard to do easy things easily? ;-)
>
> Here is an example implementation for th JSONPropertySource
>
> public class JSONPropertySourceLocator implements PropertySourceLocator {
> @Override
> public PropertySource get(URL source) {
> if (!accepts(source)) {
> String mesg = format("%s is not supported", source.toString());
> throw new ConfigException(mesg);
> }
>
> return new JSONPropertySource(source);
> }
> }
>
> 1) who is providing the URLs ?
2) Checking for an URL, if it is accepted, most of the time is a format
issue IMO only. So your code above basically
dies the same as a format, but unfortunately on top mixes it with a
PropertySource.
> Adding a PropertySourceProviderManager is not helpfull because it has to
> discover existing format (Anatoles approach) or
This is not true. My example PropertySource can as well use exactly one
single format, but also is fkexible enough to support multiple ones. BTW
also a precondition, when you want to be able to integrate alternate format
implementations such as commons-configuration ;)
> existing PropertySource implementation. Every PropertySource must be
> scanned for an ctor with URL parameter and so on and so on. This is not an
> very flexible design..
>
As I said, I am also not completely satisfied with everything related to
that, but when doing some criticiscm of things being inflexible, also be
aware that I expect you to provide some ideas how to improve it, Mixing up
formats (the act of parsing), with the act of mapping the parsed data to a
flat key, value structure and assigning (depending on the file location,
the file entries and whatever else) the correct priority for every
key/value pair, are three aspects that each one must be decided on its own.
Hardcoding anything makes no sense from a framework perspective (but may be
from an enterprise perspective)...
> Bye,
>
> Oliver
>
>
> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>
>> @Olivier: Anatole is right, make of a custom propertysourceprovider a
>> manager and this one will be responsible to instantiate the right
>> property source depending the logic you need (extension). It is as
>> easy as having a map of factory in the idea.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-12 17:46 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>
>>> Its the PropertySourceProviders that can do file discovery and apply
>>> whatever öpgic on top to determine the different priorities of the
>>> different files fouind...
>>>
>>> Romain Manni-Bucau <rm...@gmail.com> schrieb am Thu Feb 12 2015 at
>>> 17:43:31:
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> 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*
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm not sure, builder aims to end in api IMO, not this factory without
a redesign of the api
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-12 18:05 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> @Romain: I will add this to the builder module. Extension can support it if
> they want.
>
>
> Am 12.02.15 um 18:01 schrieb Romain Manni-Bucau:
>>
>> not exactly since you will handle only the format you can (ie the one you
>> scan)
>>
>> your locator is actually a factory more than a locator (surely why i
>> didnt get your original request). It doesnt makes any sense in tamaya
>> core IMO but can be an extension. but I think Anatole is right saying
>> it is his format abstraction
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>> Why is it so fucking hard to do easy things easily? ;-)
>>>
>>> Here is an example implementation for th JSONPropertySource
>>>
>>> public class JSONPropertySourceLocator implements PropertySourceLocator {
>>> @Override
>>> public PropertySource get(URL source) {
>>> if (!accepts(source)) {
>>> String mesg = format("%s is not supported",
>>> source.toString());
>>> throw new ConfigException(mesg);
>>> }
>>>
>>> return new JSONPropertySource(source);
>>> }
>>> }
>>>
>>> Adding a PropertySourceProviderManager is not helpfull because it has to
>>> discover existing format (Anatoles approach) or existing PropertySource
>>> implementation. Every PropertySource must be scanned for an ctor with URL
>>> parameter and so on and so on. This is not an very flexible design..
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>>
>>> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Romain: I will add this to the builder module. Extension can support it
if they want.
Am 12.02.15 um 18:01 schrieb Romain Manni-Bucau:
> not exactly since you will handle only the format you can (ie the one you scan)
>
> your locator is actually a factory more than a locator (surely why i
> didnt get your original request). It doesnt makes any sense in tamaya
> core IMO but can be an extension. but I think Anatole is right saying
> it is his format abstraction
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Why is it so fucking hard to do easy things easily? ;-)
>>
>> Here is an example implementation for th JSONPropertySource
>>
>> public class JSONPropertySourceLocator implements PropertySourceLocator {
>> @Override
>> public PropertySource get(URL source) {
>> if (!accepts(source)) {
>> String mesg = format("%s is not supported", source.toString());
>> throw new ConfigException(mesg);
>> }
>>
>> return new JSONPropertySource(source);
>> }
>> }
>>
>> Adding a PropertySourceProviderManager is not helpfull because it has to
>> discover existing format (Anatoles approach) or existing PropertySource
>> implementation. Every PropertySource must be scanned for an ctor with URL
>> parameter and so on and so on. This is not an very flexible design..
>>
>> Bye,
>>
>> Oliver
>>
>>
>> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
not exactly since you will handle only the format you can (ie the one you scan)
your locator is actually a factory more than a locator (surely why i
didnt get your original request). It doesnt makes any sense in tamaya
core IMO but can be an extension. but I think Anatole is right saying
it is his format abstraction
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-12 17:56 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Why is it so fucking hard to do easy things easily? ;-)
>
> Here is an example implementation for th JSONPropertySource
>
> public class JSONPropertySourceLocator implements PropertySourceLocator {
> @Override
> public PropertySource get(URL source) {
> if (!accepts(source)) {
> String mesg = format("%s is not supported", source.toString());
> throw new ConfigException(mesg);
> }
>
> return new JSONPropertySource(source);
> }
> }
>
> Adding a PropertySourceProviderManager is not helpfull because it has to
> discover existing format (Anatoles approach) or existing PropertySource
> implementation. Every PropertySource must be scanned for an ctor with URL
> parameter and so on and so on. This is not an very flexible design..
>
> Bye,
>
> Oliver
>
>
> Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
>>
>> @Olivier: Anatole is right, make of a custom propertysourceprovider a
>> manager and this one will be responsible to instantiate the right
>> property source depending the logic you need (extension). It is as
>> easy as having a map of factory in the idea.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-02-12 17:46 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>>
>>> Its the PropertySourceProviders that can do file discovery and apply
>>> whatever öpgic on top to determine the different priorities of the
>>> different files fouind...
>>>
>>> Romain Manni-Bucau <rm...@gmail.com> schrieb am Thu Feb 12 2015 at
>>> 17:43:31:
>>>
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Why is it so fucking hard to do easy things easily? ;-)
Here is an example implementation for th JSONPropertySource
public class JSONPropertySourceLocator implements PropertySourceLocator {
@Override
public PropertySource get(URL source) {
if (!accepts(source)) {
String mesg = format("%s is not supported", source.toString());
throw new ConfigException(mesg);
}
return new JSONPropertySource(source);
}
}
Adding a PropertySourceProviderManager is not helpfull because it has to
discover existing format (Anatoles approach) or existing PropertySource
implementation. Every PropertySource must be scanned for an ctor with
URL parameter and so on and so on. This is not an very flexible design..
Bye,
Oliver
Am 12.02.15 um 17:50 schrieb Romain Manni-Bucau:
> @Olivier: Anatole is right, make of a custom propertysourceprovider a
> manager and this one will be responsible to instantiate the right
> property source depending the logic you need (extension). It is as
> easy as having a map of factory in the idea.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-12 17:46 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> Its the PropertySourceProviders that can do file discovery and apply
>> whatever öpgic on top to determine the different priorities of the
>> different files fouind...
>>
>> Romain Manni-Bucau <rm...@gmail.com> schrieb am Thu Feb 12 2015 at
>> 17:43:31:
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Olivier: Anatole is right, make of a custom propertysourceprovider a
manager and this one will be responsible to instantiate the right
property source depending the logic you need (extension). It is as
easy as having a map of factory in the idea.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-12 17:46 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> Its the PropertySourceProviders that can do file discovery and apply
> whatever öpgic on top to determine the different priorities of the
> different files fouind...
>
> Romain Manni-Bucau <rm...@gmail.com> schrieb am Thu Feb 12 2015 at
> 17:43:31:
>
>> You judt want few custom sources you can call directly for that purpose but
>> to be honest this look like the opposite of tamaya design (you dont
>> discover files but property sources)
>> Le 12 févr. 2015 17:37, "Anatole Tresch" <at...@gmail.com> a écrit :
>>
>> > Definitivly not, semms for mw you mix up things_
>> >
>> > PropertySourceProvider = n PropertySources
>> > Location(URL) + format + Config/PriorityMapping = n PropertySources
>> >
>> > Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015
>> at
>> > 16:51:20:
>> >
>> > > @Anatole: IMHO duplicates the formats module the functionality of the
>> > > PropertySource. IMHO.
>> > >
>> > > Am 12.02.15 um 10:41 schrieb Anatole Tresch:
>> > > > +1 for some sample snippets. Perhaps also look at the extensions
>> module
>> > > > called 'formats'. This is still work in progress though (I am not yet
>> > > > satisfied with the abstractions), though it might go in a direction
>> you
>> > > > also are thinking, perhaps...?
>> > > >
>> > > > public class MyTestSinglePropertySourceProvider extends
>> > > > BaseSimpleFormatPropertySourceProvider{
>> > > > public MyTestSinglePropertySourceProvider() {
>> > > > super(new JSonFormat(),
>> > > > MyTestSinglePropertySourceProvider.class.getResource(
>> > > > "META-INF/config/myConfig.ini"));
>> > > > }
>> > > >
>> > > > @Override
>> > > > protected PropertySource createPropertySource(String
>> > entryTypeName,
>> > > > Map<String, String> entries,
>> > > >
>> ConfigurationFormat
>> > > > formatUsed) {
>> > > > // assuming there is only one entryTypeName = default
>> > > > return new HirarchicalPropertySource(entries);
>> > > > }
>> > > > }
>> > > >
>> > > > and
>> > > >
>> > > > public class MyTestMultiPropertySourceProvider extends
>> > > > BasePathBasedMultiFormatPropertySourceProvider{
>> > > > public MyTestMultiPropertySourceProvi
>> der(List<ConfigurationFormat>
>> > > > formats, String... paths) {
>> > > > super(Arrays.asList(new ConfigurationFormat[]{}
>> > > > new JsonFormat(),
>> > > > new PropertiesFormat(),
>> > > > new IniConfigurationFormat()}
>> > > > ), "META-INF/config/tamaya-config.*");
>> > > > }
>> > > >
>> > > > @Override
>> > > > protected PropertySource getPropertySource(String entryTypeName,
>> > > > Map<String, String> entries,
>> > > > ConfigurationFormat
>> > > > formatUsed) {
>> > > > // Convert items read into a corresponding PropertySource
>> > > > return null;
>> > > > }
>> > > > }
>> > > >
>> > > > Cheers,
>> > > > Anatole
>> > > >
>> > > >
>> > > >
>> > > > 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
>> >:
>> > > >
>> > > >> Can you give a sample please? I dont get the point
>> > > >> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <
>> > o.b.fischer@swe-blog.net>
>> > > a
>> > > >> écrit :
>> > > >>
>> > > >>> Dear all,
>> > > >>>
>> > > >>> PropertySource is our abstraction for different property sources
>> and
>> > > >>> formats. I think we agree on this. Furthermore we said the origin
>> of
>> > a
>> > > >>> source must be overhanded as a URL (file://somewhere/).
>> > > >>>
>> > > >>> That is fine and works. But IMHO we miss the connection between
>> them.
>> > > How
>> > > >>> to specify a specific property source and to find the matching
>> > > >>> PropertySource?
>> > > >>>
>> > > >>> Therefore I would like to propose a option SPI:
>> PropertySourceLocator
>> > > (?)
>> > > >>>
>> > > >>> PropertySourceLocator#accepts(URL url):boolean
>> > > >>> PropertySourceLocator#get(URL url): PropertySource
>> > > >>>
>> > > >>> WDYT?
>> > > >>>
>> > > >>> Oliver
>> > > >>>
>> > > >>> --
>> > > >>> N Oliver B. Fischer
>> > > >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> > > >>> P +49 30 44793251
>> > > >>> M +49 178 7903538
>> > > >>> E o.b.fischer@swe-blog.net
>> > > >>> S oliver.b.fischer
>> > > >>> J oliver.b.fischer@jabber.org
>> > > >>> 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 o.b.fischer@swe-blog.net
>> > > S oliver.b.fischer
>> > > J oliver.b.fischer@jabber.org
>> > > X http://xing.to/obf
>> > >
>> > >
>> >
>>
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Its the PropertySourceProviders that can do file discovery and apply
whatever öpgic on top to determine the different priorities of the
different files fouind...
Romain Manni-Bucau <rm...@gmail.com> schrieb am Thu Feb 12 2015 at
17:43:31:
> You judt want few custom sources you can call directly for that purpose but
> to be honest this look like the opposite of tamaya design (you dont
> discover files but property sources)
> Le 12 févr. 2015 17:37, "Anatole Tresch" <at...@gmail.com> a écrit :
>
> > Definitivly not, semms for mw you mix up things_
> >
> > PropertySourceProvider = n PropertySources
> > Location(URL) + format + Config/PriorityMapping = n PropertySources
> >
> > Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015
> at
> > 16:51:20:
> >
> > > @Anatole: IMHO duplicates the formats module the functionality of the
> > > PropertySource. IMHO.
> > >
> > > Am 12.02.15 um 10:41 schrieb Anatole Tresch:
> > > > +1 for some sample snippets. Perhaps also look at the extensions
> module
> > > > called 'formats'. This is still work in progress though (I am not yet
> > > > satisfied with the abstractions), though it might go in a direction
> you
> > > > also are thinking, perhaps...?
> > > >
> > > > public class MyTestSinglePropertySourceProvider extends
> > > > BaseSimpleFormatPropertySourceProvider{
> > > > public MyTestSinglePropertySourceProvider() {
> > > > super(new JSonFormat(),
> > > > MyTestSinglePropertySourceProvider.class.getResource(
> > > > "META-INF/config/myConfig.ini"));
> > > > }
> > > >
> > > > @Override
> > > > protected PropertySource createPropertySource(String
> > entryTypeName,
> > > > Map<String, String> entries,
> > > >
> ConfigurationFormat
> > > > formatUsed) {
> > > > // assuming there is only one entryTypeName = default
> > > > return new HirarchicalPropertySource(entries);
> > > > }
> > > > }
> > > >
> > > > and
> > > >
> > > > public class MyTestMultiPropertySourceProvider extends
> > > > BasePathBasedMultiFormatPropertySourceProvider{
> > > > public MyTestMultiPropertySourceProvi
> der(List<ConfigurationFormat>
> > > > formats, String... paths) {
> > > > super(Arrays.asList(new ConfigurationFormat[]{}
> > > > new JsonFormat(),
> > > > new PropertiesFormat(),
> > > > new IniConfigurationFormat()}
> > > > ), "META-INF/config/tamaya-config.*");
> > > > }
> > > >
> > > > @Override
> > > > protected PropertySource getPropertySource(String entryTypeName,
> > > > Map<String, String> entries,
> > > > ConfigurationFormat
> > > > formatUsed) {
> > > > // Convert items read into a corresponding PropertySource
> > > > return null;
> > > > }
> > > > }
> > > >
> > > > Cheers,
> > > > Anatole
> > > >
> > > >
> > > >
> > > > 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> > > >
> > > >> Can you give a sample please? I dont get the point
> > > >> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <
> > o.b.fischer@swe-blog.net>
> > > a
> > > >> écrit :
> > > >>
> > > >>> Dear all,
> > > >>>
> > > >>> PropertySource is our abstraction for different property sources
> and
> > > >>> formats. I think we agree on this. Furthermore we said the origin
> of
> > a
> > > >>> source must be overhanded as a URL (file://somewhere/).
> > > >>>
> > > >>> That is fine and works. But IMHO we miss the connection between
> them.
> > > How
> > > >>> to specify a specific property source and to find the matching
> > > >>> PropertySource?
> > > >>>
> > > >>> Therefore I would like to propose a option SPI:
> PropertySourceLocator
> > > (?)
> > > >>>
> > > >>> PropertySourceLocator#accepts(URL url):boolean
> > > >>> PropertySourceLocator#get(URL url): PropertySource
> > > >>>
> > > >>> WDYT?
> > > >>>
> > > >>> Oliver
> > > >>>
> > > >>> --
> > > >>> N Oliver B. Fischer
> > > >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > > >>> P +49 30 44793251
> > > >>> M +49 178 7903538
> > > >>> E o.b.fischer@swe-blog.net
> > > >>> S oliver.b.fischer
> > > >>> J oliver.b.fischer@jabber.org
> > > >>> 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 o.b.fischer@swe-blog.net
> > > S oliver.b.fischer
> > > J oliver.b.fischer@jabber.org
> > > X http://xing.to/obf
> > >
> > >
> >
>
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
You judt want few custom sources you can call directly for that purpose but
to be honest this look like the opposite of tamaya design (you dont
discover files but property sources)
Le 12 févr. 2015 17:37, "Anatole Tresch" <at...@gmail.com> a écrit :
> Definitivly not, semms for mw you mix up things_
>
> PropertySourceProvider = n PropertySources
> Location(URL) + format + Config/PriorityMapping = n PropertySources
>
> Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
> 16:51:20:
>
> > @Anatole: IMHO duplicates the formats module the functionality of the
> > PropertySource. IMHO.
> >
> > Am 12.02.15 um 10:41 schrieb Anatole Tresch:
> > > +1 for some sample snippets. Perhaps also look at the extensions module
> > > called 'formats'. This is still work in progress though (I am not yet
> > > satisfied with the abstractions), though it might go in a direction you
> > > also are thinking, perhaps...?
> > >
> > > public class MyTestSinglePropertySourceProvider extends
> > > BaseSimpleFormatPropertySourceProvider{
> > > public MyTestSinglePropertySourceProvider() {
> > > super(new JSonFormat(),
> > > MyTestSinglePropertySourceProvider.class.getResource(
> > > "META-INF/config/myConfig.ini"));
> > > }
> > >
> > > @Override
> > > protected PropertySource createPropertySource(String
> entryTypeName,
> > > Map<String, String> entries,
> > > ConfigurationFormat
> > > formatUsed) {
> > > // assuming there is only one entryTypeName = default
> > > return new HirarchicalPropertySource(entries);
> > > }
> > > }
> > >
> > > and
> > >
> > > public class MyTestMultiPropertySourceProvider extends
> > > BasePathBasedMultiFormatPropertySourceProvider{
> > > public MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
> > > formats, String... paths) {
> > > super(Arrays.asList(new ConfigurationFormat[]{}
> > > new JsonFormat(),
> > > new PropertiesFormat(),
> > > new IniConfigurationFormat()}
> > > ), "META-INF/config/tamaya-config.*");
> > > }
> > >
> > > @Override
> > > protected PropertySource getPropertySource(String entryTypeName,
> > > Map<String, String> entries,
> > > ConfigurationFormat
> > > formatUsed) {
> > > // Convert items read into a corresponding PropertySource
> > > return null;
> > > }
> > > }
> > >
> > > Cheers,
> > > Anatole
> > >
> > >
> > >
> > > 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> > >
> > >> Can you give a sample please? I dont get the point
> > >> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <
> o.b.fischer@swe-blog.net>
> > a
> > >> écrit :
> > >>
> > >>> Dear all,
> > >>>
> > >>> PropertySource is our abstraction for different property sources and
> > >>> formats. I think we agree on this. Furthermore we said the origin of
> a
> > >>> source must be overhanded as a URL (file://somewhere/).
> > >>>
> > >>> That is fine and works. But IMHO we miss the connection between them.
> > How
> > >>> to specify a specific property source and to find the matching
> > >>> PropertySource?
> > >>>
> > >>> Therefore I would like to propose a option SPI: PropertySourceLocator
> > (?)
> > >>>
> > >>> PropertySourceLocator#accepts(URL url):boolean
> > >>> PropertySourceLocator#get(URL url): PropertySource
> > >>>
> > >>> WDYT?
> > >>>
> > >>> Oliver
> > >>>
> > >>> --
> > >>> N Oliver B. Fischer
> > >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >>> P +49 30 44793251
> > >>> M +49 178 7903538
> > >>> E o.b.fischer@swe-blog.net
> > >>> S oliver.b.fischer
> > >>> J oliver.b.fischer@jabber.org
> > >>> 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 o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Definitivly not, semms for mw you mix up things_
PropertySourceProvider = n PropertySources
Location(URL) + format + Config/PriorityMapping = n PropertySources
Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
16:51:20:
> @Anatole: IMHO duplicates the formats module the functionality of the
> PropertySource. IMHO.
>
> Am 12.02.15 um 10:41 schrieb Anatole Tresch:
> > +1 for some sample snippets. Perhaps also look at the extensions module
> > called 'formats'. This is still work in progress though (I am not yet
> > satisfied with the abstractions), though it might go in a direction you
> > also are thinking, perhaps...?
> >
> > public class MyTestSinglePropertySourceProvider extends
> > BaseSimpleFormatPropertySourceProvider{
> > public MyTestSinglePropertySourceProvider() {
> > super(new JSonFormat(),
> > MyTestSinglePropertySourceProvider.class.getResource(
> > "META-INF/config/myConfig.ini"));
> > }
> >
> > @Override
> > protected PropertySource createPropertySource(String entryTypeName,
> > Map<String, String> entries,
> > ConfigurationFormat
> > formatUsed) {
> > // assuming there is only one entryTypeName = default
> > return new HirarchicalPropertySource(entries);
> > }
> > }
> >
> > and
> >
> > public class MyTestMultiPropertySourceProvider extends
> > BasePathBasedMultiFormatPropertySourceProvider{
> > public MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
> > formats, String... paths) {
> > super(Arrays.asList(new ConfigurationFormat[]{}
> > new JsonFormat(),
> > new PropertiesFormat(),
> > new IniConfigurationFormat()}
> > ), "META-INF/config/tamaya-config.*");
> > }
> >
> > @Override
> > protected PropertySource getPropertySource(String entryTypeName,
> > Map<String, String> entries,
> > ConfigurationFormat
> > formatUsed) {
> > // Convert items read into a corresponding PropertySource
> > return null;
> > }
> > }
> >
> > Cheers,
> > Anatole
> >
> >
> >
> > 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> >
> >> Can you give a sample please? I dont get the point
> >> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <o....@swe-blog.net>
> a
> >> écrit :
> >>
> >>> Dear all,
> >>>
> >>> PropertySource is our abstraction for different property sources and
> >>> formats. I think we agree on this. Furthermore we said the origin of a
> >>> source must be overhanded as a URL (file://somewhere/).
> >>>
> >>> That is fine and works. But IMHO we miss the connection between them.
> How
> >>> to specify a specific property source and to find the matching
> >>> PropertySource?
> >>>
> >>> Therefore I would like to propose a option SPI: PropertySourceLocator
> (?)
> >>>
> >>> PropertySourceLocator#accepts(URL url):boolean
> >>> PropertySourceLocator#get(URL url): PropertySource
> >>>
> >>> WDYT?
> >>>
> >>> Oliver
> >>>
> >>> --
> >>> N Oliver B. Fischer
> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>> P +49 30 44793251
> >>> M +49 178 7903538
> >>> E o.b.fischer@swe-blog.net
> >>> S oliver.b.fischer
> >>> J oliver.b.fischer@jabber.org
> >>> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@Anatole: IMHO duplicates the formats module the functionality of the
PropertySource. IMHO.
Am 12.02.15 um 10:41 schrieb Anatole Tresch:
> +1 for some sample snippets. Perhaps also look at the extensions module
> called 'formats'. This is still work in progress though (I am not yet
> satisfied with the abstractions), though it might go in a direction you
> also are thinking, perhaps...?
>
> public class MyTestSinglePropertySourceProvider extends
> BaseSimpleFormatPropertySourceProvider{
> public MyTestSinglePropertySourceProvider() {
> super(new JSonFormat(),
> MyTestSinglePropertySourceProvider.class.getResource(
> "META-INF/config/myConfig.ini"));
> }
>
> @Override
> protected PropertySource createPropertySource(String entryTypeName,
> Map<String, String> entries,
> ConfigurationFormat
> formatUsed) {
> // assuming there is only one entryTypeName = default
> return new HirarchicalPropertySource(entries);
> }
> }
>
> and
>
> public class MyTestMultiPropertySourceProvider extends
> BasePathBasedMultiFormatPropertySourceProvider{
> public MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
> formats, String... paths) {
> super(Arrays.asList(new ConfigurationFormat[]{}
> new JsonFormat(),
> new PropertiesFormat(),
> new IniConfigurationFormat()}
> ), "META-INF/config/tamaya-config.*");
> }
>
> @Override
> protected PropertySource getPropertySource(String entryTypeName,
> Map<String, String> entries,
> ConfigurationFormat
> formatUsed) {
> // Convert items read into a corresponding PropertySource
> return null;
> }
> }
>
> Cheers,
> Anatole
>
>
>
> 2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> Can you give a sample please? I dont get the point
>> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <o....@swe-blog.net> a
>> écrit :
>>
>>> Dear all,
>>>
>>> PropertySource is our abstraction for different property sources and
>>> formats. I think we agree on this. Furthermore we said the origin of a
>>> source must be overhanded as a URL (file://somewhere/).
>>>
>>> That is fine and works. But IMHO we miss the connection between them. How
>>> to specify a specific property source and to find the matching
>>> PropertySource?
>>>
>>> Therefore I would like to propose a option SPI: PropertySourceLocator (?)
>>>
>>> PropertySourceLocator#accepts(URL url):boolean
>>> PropertySourceLocator#get(URL url): PropertySource
>>>
>>> WDYT?
>>>
>>> Oliver
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
+1 for some sample snippets. Perhaps also look at the extensions module
called 'formats'. This is still work in progress though (I am not yet
satisfied with the abstractions), though it might go in a direction you
also are thinking, perhaps...?
public class MyTestSinglePropertySourceProvider extends
BaseSimpleFormatPropertySourceProvider{
public MyTestSinglePropertySourceProvider() {
super(new JSonFormat(),
MyTestSinglePropertySourceProvider.class.getResource(
"META-INF/config/myConfig.ini"));
}
@Override
protected PropertySource createPropertySource(String entryTypeName,
Map<String, String> entries,
ConfigurationFormat
formatUsed) {
// assuming there is only one entryTypeName = default
return new HirarchicalPropertySource(entries);
}
}
and
public class MyTestMultiPropertySourceProvider extends
BasePathBasedMultiFormatPropertySourceProvider{
public MyTestMultiPropertySourceProvider(List<ConfigurationFormat>
formats, String... paths) {
super(Arrays.asList(new ConfigurationFormat[]{}
new JsonFormat(),
new PropertiesFormat(),
new IniConfigurationFormat()}
), "META-INF/config/tamaya-config.*");
}
@Override
protected PropertySource getPropertySource(String entryTypeName,
Map<String, String> entries,
ConfigurationFormat
formatUsed) {
// Convert items read into a corresponding PropertySource
return null;
}
}
Cheers,
Anatole
2015-02-12 8:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Can you give a sample please? I dont get the point
> Le 12 févr. 2015 08:25, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
> > Dear all,
> >
> > PropertySource is our abstraction for different property sources and
> > formats. I think we agree on this. Furthermore we said the origin of a
> > source must be overhanded as a URL (file://somewhere/).
> >
> > That is fine and works. But IMHO we miss the connection between them. How
> > to specify a specific property source and to find the matching
> > PropertySource?
> >
> > Therefore I would like to propose a option SPI: PropertySourceLocator (?)
> >
> > PropertySourceLocator#accepts(URL url):boolean
> > PropertySourceLocator#get(URL url): PropertySource
> >
> > WDYT?
> >
> > Oliver
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > 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*
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can you give a sample please? I dont get the point
Le 12 févr. 2015 08:25, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> Dear all,
>
> PropertySource is our abstraction for different property sources and
> formats. I think we agree on this. Furthermore we said the origin of a
> source must be overhanded as a URL (file://somewhere/).
>
> That is fine and works. But IMHO we miss the connection between them. How
> to specify a specific property source and to find the matching
> PropertySource?
>
> Therefore I would like to propose a option SPI: PropertySourceLocator (?)
>
> PropertySourceLocator#accepts(URL url):boolean
> PropertySourceLocator#get(URL url): PropertySource
>
> WDYT?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
ext is only an example. I could be also foobar or snafu or 42.
Am 12.02.15 um 17:00 schrieb Romain Manni-Bucau:
> there is no propertysource matching ext actually since you can have a
> jettison and a jackson json readers...which would read different json
> format
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-02-12 16:52 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> To complicated. I miss this feature and discussed it with my colleagues at
>> Deutsche Post. Their and my opinion is that without this functionality
>> Tamaya wouldn't fit to our infrastructure.
>>
>> I knew all of our users could extend one of the existing property providers
>> but I think this shouldn't be needed.
>>
>> Bye,
>>
>> Oliver
>>
>> Am 12.02.15 um 16:09 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 o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
there is no propertysource matching ext actually since you can have a
jettison and a jackson json readers...which would read different json
format
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-02-12 16:52 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> To complicated. I miss this feature and discussed it with my colleagues at
> Deutsche Post. Their and my opinion is that without this functionality
> Tamaya wouldn't fit to our infrastructure.
>
> I knew all of our users could extend one of the existing property providers
> but I think this shouldn't be needed.
>
> Bye,
>
> Oliver
>
> Am 12.02.15 um 16:09 schrieb Mark Struberg:
>
>>> Furthermore we said the origin of a
>>> source must be overhanded as a URL (file://somewhere/).
>>
>> Nope. You pass in a PropertySource programmatically or register it via
>> ServiceLoader pattern.
>>
>>
>>
>>
>>> That is fine and works. But IMHO we miss the connection between them.
>>> How to specify a specific property source and to find the matching
>>> PropertySource?
>>
>>
>> You should not need to do this.
>>
>>
>>
>>> WDYT?
>>
>> Give me the use case and I gonna think about it. Without a really
>> beneficial use case I'm -1
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>> On Thursday, 12 February 2015, 8:25, Oliver B. Fischer
>>> <o....@swe-blog.net> wrote:
>>>>
>>>> Dear all,
>>>
>>> PropertySource is our abstraction for different property sources and
>>> formats. I think we agree on this. Furthermore we said the origin of a
>>> source must be overhanded as a URL (file://somewhere/).
>>>
>>> That is fine and works. But IMHO we miss the connection between them.
>>> How to specify a specific property source and to find the matching
>>> PropertySource?
>>>
>>> Therefore I would like to propose a option SPI: PropertySourceLocator (?)
>>>
>>> PropertySourceLocator#accepts(URL url):boolean
>>> PropertySourceLocator#get(URL url): PropertySource
>>>
>>> WDYT?
>>>
>>> Oliver
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Lets continue this discussion later. As I need it only for the builder
extension I will add this as SPI interface to the extension modules.
WDYT?
Oliver
Am 12.02.15 um 17:45 schrieb Anatole Tresch:
> Basically I was thinking of something similar in my original code, called a
> metamodel. But looking at our model, this is basically nothing else than a
> PropertySourceProvider. You can do whatever is appropriate there. For
> further isolation of you can then implement ConfigurationProvider, so the
> current API is more than flexible enough. Wwe could add such features as
> part of an extension (which I would find useful as well). And since I dont
> want to duplicate resource locating code and the parsing logic, I am
> working on the resources and formats module...
> But the overall point is that the API is still flexible enough IMO.
>
> Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
> 16:57:22:
>
>> To complicated. I miss this feature and discussed it with my colleagues
>> at Deutsche Post. Their and my opinion is that without this
>> functionality Tamaya wouldn't fit to our infrastructure.
>>
>> I knew all of our users could extend one of the existing property
>> providers but I think this shouldn't be needed.
>>
>> Bye,
>>
>> Oliver
>>
>> Am 12.02.15 um 16:09 schrieb Mark Struberg:
>> ServiceLoader pattern.
>> beneficial use case I'm -1
>> o.b.fischer@swe-blog.net> wrote:
>> (?)
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Anatole Tresch <at...@gmail.com>.
Basically I was thinking of something similar in my original code, called a
metamodel. But looking at our model, this is basically nothing else than a
PropertySourceProvider. You can do whatever is appropriate there. For
further isolation of you can then implement ConfigurationProvider, so the
current API is more than flexible enough. Wwe could add such features as
part of an extension (which I would find useful as well). And since I dont
want to duplicate resource locating code and the parsing logic, I am
working on the resources and formats module...
But the overall point is that the API is still flexible enough IMO.
Oliver B. Fischer <o....@swe-blog.net> schrieb am Thu Feb 12 2015 at
16:57:22:
> To complicated. I miss this feature and discussed it with my colleagues
> at Deutsche Post. Their and my opinion is that without this
> functionality Tamaya wouldn't fit to our infrastructure.
>
> I knew all of our users could extend one of the existing property
> providers but I think this shouldn't be needed.
>
> Bye,
>
> Oliver
>
> Am 12.02.15 um 16:09 schrieb Mark Struberg:
> >> Furthermore we said the origin of a
> >> source must be overhanded as a URL (file://somewhere/).
> > Nope. You pass in a PropertySource programmatically or register it via
> ServiceLoader pattern.
> >
> >
> >
> >
> >> That is fine and works. But IMHO we miss the connection between them.
> >> How to specify a specific property source and to find the matching
> >> PropertySource?
> >
> > You should not need to do this.
> >
> >
> >
> >> WDYT?
> > Give me the use case and I gonna think about it. Without a really
> beneficial use case I'm -1
> >
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >> On Thursday, 12 February 2015, 8:25, Oliver B. Fischer <
> o.b.fischer@swe-blog.net> wrote:
> >>> Dear all,
> >> PropertySource is our abstraction for different property sources and
> >> formats. I think we agree on this. Furthermore we said the origin of a
> >> source must be overhanded as a URL (file://somewhere/).
> >>
> >> That is fine and works. But IMHO we miss the connection between them.
> >> How to specify a specific property source and to find the matching
> >> PropertySource?
> >>
> >> Therefore I would like to propose a option SPI: PropertySourceLocator
> (?)
> >>
> >> PropertySourceLocator#accepts(URL url):boolean
> >> PropertySourceLocator#get(URL url): PropertySource
> >>
> >> WDYT?
> >>
> >> Oliver
> >>
> >> --
> >> N Oliver B. Fischer
> >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >> P +49 30 44793251
> >> M +49 178 7903538
> >> E o.b.fischer@swe-blog.net
> >> S oliver.b.fischer
> >> J oliver.b.fischer@jabber.org
> >> 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 o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Locating a property source for a given format
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
To complicated. I miss this feature and discussed it with my colleagues
at Deutsche Post. Their and my opinion is that without this
functionality Tamaya wouldn't fit to our infrastructure.
I knew all of our users could extend one of the existing property
providers but I think this shouldn't be needed.
Bye,
Oliver
Am 12.02.15 um 16:09 schrieb Mark Struberg:
>> Furthermore we said the origin of a
>> source must be overhanded as a URL (file://somewhere/).
> Nope. You pass in a PropertySource programmatically or register it via ServiceLoader pattern.
>
>
>
>
>> That is fine and works. But IMHO we miss the connection between them.
>> How to specify a specific property source and to find the matching
>> PropertySource?
>
> You should not need to do this.
>
>
>
>> WDYT?
> Give me the use case and I gonna think about it. Without a really beneficial use case I'm -1
>
>
>
> LieGrue,
> strub
>
>
>
>> On Thursday, 12 February 2015, 8:25, Oliver B. Fischer <o....@swe-blog.net> wrote:
>>> Dear all,
>> PropertySource is our abstraction for different property sources and
>> formats. I think we agree on this. Furthermore we said the origin of a
>> source must be overhanded as a URL (file://somewhere/).
>>
>> That is fine and works. But IMHO we miss the connection between them.
>> How to specify a specific property source and to find the matching
>> PropertySource?
>>
>> Therefore I would like to propose a option SPI: PropertySourceLocator (?)
>>
>> PropertySourceLocator#accepts(URL url):boolean
>> PropertySourceLocator#get(URL url): PropertySource
>>
>> WDYT?
>>
>> Oliver
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> 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 o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Locating a property source for a given format
Posted by Mark Struberg <st...@yahoo.de>.
> Furthermore we said the origin of a
> source must be overhanded as a URL (file://somewhere/).
Nope. You pass in a PropertySource programmatically or register it via ServiceLoader pattern.
> That is fine and works. But IMHO we miss the connection between them.
> How to specify a specific property source and to find the matching
> PropertySource?
You should not need to do this.
> WDYT?
Give me the use case and I gonna think about it. Without a really beneficial use case I'm -1
LieGrue,
strub
> On Thursday, 12 February 2015, 8:25, Oliver B. Fischer <o....@swe-blog.net> wrote:
> > Dear all,
>
> PropertySource is our abstraction for different property sources and
> formats. I think we agree on this. Furthermore we said the origin of a
> source must be overhanded as a URL (file://somewhere/).
>
> That is fine and works. But IMHO we miss the connection between them.
> How to specify a specific property source and to find the matching
> PropertySource?
>
> Therefore I would like to propose a option SPI: PropertySourceLocator (?)
>
> PropertySourceLocator#accepts(URL url):boolean
> PropertySourceLocator#get(URL url): PropertySource
>
> WDYT?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>