You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Mark Struberg <st...@yahoo.de> on 2014/12/30 11:52:02 UTC
Which API parts feel pretty solid already?
Hi!
As we again made a lot of progress in the API/SPI Discussion, I think we could start working no the impl again. Of course only on parts which we feel are pretty solid in the API part already.
Here is my list of candidates:
* ServiceContext: This is the 'singleton factory' so to say. It's sole intention is to return exactly one instance per given class. It must take care about ClassLoader structures etc.
It gets picked up by the ServiceContextManager via the java.util.ServiceLoader mechanism. If there are multiple implementations then the one with the highest ordinal() will be taken.
The default implementation should have an ordinal of -100? (we could also make the default ordinal() return 1000 if you like that better) That way a user - but also some container vendors - could easily exchange this implementation.
* ConfigurationContext: This is the core part framework programmers interact with. There is exactly one instance per e.g. a WAR (let's forget about EAR for now, this is a bit more difficult). It knows all the PropertySources which got configured or programmatically added, etc. This is kind of the core part of all the configuration mechanism! It kind of defines the 'scenario' which defines the whole behaviour of the configuration platform.
This class is the one which picks up all the PropertySources which get registered via ServiceLoader.
We will surely add a few more methods in the future, but this should be easy to enhance later.
It might also register and initialize the Configuration instance?
Because if someone adds a PropertySource programmatically then we need a way to tell the Configuration instance that it needs to drop it's caches (if there are any in a later phase).
* Configuration: This is the core part for USERS. Where 'user' means the programmers who just like to know some configured values.
* Standard PropertySources: We need to discuss which ones every implementation of the spec needs to add by default. I'd say it's pretty much a no-brainer to add 1 for environment and another one for java props for now.
Do you see any blocker for one of those areas right now?
If not, who wants to work on which area?
LieGrue,
strub
Re: Which API parts feel pretty solid already?
Posted by "John D. Ament" <jo...@apache.org>.
On Tue Dec 30 2014 at 5:56:05 AM Mark Struberg <st...@yahoo.de> wrote:
> Hi!
>
> As we again made a lot of progress in the API/SPI Discussion, I think we
> could start working no the impl again. Of course only on parts which we
> feel are pretty solid in the API part already.
>
> Here is my list of candidates:
>
> * ServiceContext: This is the 'singleton factory' so to say. It's sole
> intention is to return exactly one instance per given class. It must take
> care about ClassLoader structures etc.
>
Have we actually described how classloaders interact with configuration?
Remember, we're doing all of this in SE right now, we don't have EE's
classloader problems. Later in this same email you talk about skipping EAR
for now. So what's the issue we need to handle w/ classloaders?
Remember that EARs are just a wrapper for multiple applications, leveraging
common libraries and possibly some shared EJBs.
> It gets picked up by the ServiceContextManager via the
> java.util.ServiceLoader mechanism. If there are multiple implementations
> then the one with the highest ordinal() will be taken.
>
> The default implementation should have an ordinal of -100? (we could also
> make the default ordinal() return 1000 if you like that better) That way a
> user - but also some container vendors - could easily exchange this
> implementation.
>
Last I saw on the mail thread was people leaning towards priority. If we
switched to ordinal, fine, but we should probably summarize the results of
these off list meetings for those who didn't receive invites.
>
> * ConfigurationContext: This is the core part framework programmers
> interact with. There is exactly one instance per e.g. a WAR (let's forget
> about EAR for now, this is a bit more difficult). It knows all the
> PropertySources which got configured or programmatically added, etc. This
> is kind of the core part of all the configuration mechanism! It kind of
> defines the 'scenario' which defines the whole behaviour of the
> configuration platform.
> This class is the one which picks up all the PropertySources which get
> registered via ServiceLoader.
>
> We will surely add a few more methods in the future, but this should be
> easy to enhance later.
>
> It might also register and initialize the Configuration instance?
>
> Because if someone adds a PropertySource programmatically then we need a
> way to tell the Configuration instance that it needs to drop it's caches
> (if there are any in a later phase).
>
>
> * Configuration: This is the core part for USERS. Where 'user' means the
> programmers who just like to know some configured values.
>
>
> * Standard PropertySources: We need to discuss which ones every
> implementation of the spec needs to add by default. I'd say it's pretty
> much a no-brainer to add 1 for environment and another one for java props
> for now.
>
>
>
> Do you see any blocker for one of those areas right now?
>
>
> If not, who wants to work on which area?
>
>
>
> LieGrue,
> strub
>
Re: Which API parts feel pretty solid already?
Posted by Daniel Cunha <da...@gmail.com>.
johnzon +1 :)
On Tue, Dec 30, 2014 at 6:12 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> we can use any library matching Apache licensing
> (http://www.apache.org/legal/resolved.html).
>
> About json we could enrich johnzon pretty easily to have what we need
> instead of relying on an external one.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 19:04 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> > I agree that XML is so yesterday but it is also widely used and
> supported.
> >
> >
> > Am 30.12.14 um 18:55 schrieb Mark Struberg:
> >
> >> xml imo it so yesterday. The problem with xml is that you would also
> >> define a XSD and Schema. That would be add 30 pages to the spec without
> much
> >> benefit.
> >>
> >> Remember that every user can very simply register his own
> PropertySources
> >> where he reads his own XML.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >>> On Tuesday, 30 December 2014, 18:40, Romain Manni-Bucau
> >>> <rm...@gmail.com> wrote:
> >>>>
> >>>> I think we need to support properties cause it is 1-1 with the API and
> >>>
> >>> then we should maybe release and see what users do.
> >>>
> >>> JSON is a pretty bad solution for config since you can't comment
> >>> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
> >>> is...XML but I wonder how more advanced property sources would
> >>> completely replace file based ones (ie we should only provide a single
> >>> one based on file mainly for tests or do we really need to tackle
> >>> these formats). In all cases I would expect to find them in
> >>> "tamaya-extra" to start and no in the main delivery. So it can really
> >>> wait the first release which would at least provide the API and
> >>> default "wiring".
> >>>
> >>> wdyt?
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>>
> >>> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> >>>>
> >>>> Hi,
> >>>>
> >>>> on Thursday I would like to discuss with you which kind of property
> >>>> sources
> >>>> we required.
> >>>>
> >>>> Even if I don't like it very much, we should support XML. But I
> would
> >>>
> >>> like
> >>>>
> >>>> to see also JSON, YAML and HOCON support.
> >>>>
> >>>> Bye,
> >>>>
> >>>> 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
> >
>
--
Daniel Cunha (soro)
Re: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
+1 :-)
Von meinem iPhone gesendet
> Am 31.12.2014 um 00:05 schrieb Mark Struberg <st...@yahoo.de>:
>
> folks, I really suggest we add none of those in our core.
>
> It might easily get added later as an extension anyway.
>
> Think about it that way: our core api + impl will end up somewhere around > 100 kByte. So why should we add a library which is close to 1MB just for having a JSON configuration possibility?
>
> If a user needs it then he can easily add it himself.
>
>
> LieGrue,
> strub
>
>
>
>
>>> On Tuesday, 30 December 2014, 23:25, Oliver B. Fischer <o....@swe-blog.net> wrote:
>>> I think you are right. Jackson offers more than we need since only need
>> strings.
>>
>>
>>> Am 30.12.14 um 22:27 schrieb Romain Manni-Bucau:
>>> jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
>>> Main issue with jackson will surely be the size I think
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-12-30 21:39 GMT+01:00 Oliver B. Fischer
>> <o....@swe-blog.net>:
>>>> Already found it. Since I really wish to have YAML support I would
>> prefer
>>>> Jackson since it supports both.
>>>>
>>>> Am 30.12.14 um 21:11 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I agree. It is totally reasonable to support only some formats in core and to put all additional formats in different jars.
Von meinem iPhone gesendet
> Am 31.12.2014 um 08:43 schrieb Anatole Tresch <at...@gmail.com>:
>
> +1 keep things minimalistic. Json or whatever support will be as easy as
> adding an additional jar/dep to your project. Thats the reason I voted for
> standard properties/xml-properties: the parser is already there ootb in the
> java platform. Even support for ini files in core might be arguable!
> Mark Struberg <st...@yahoo.de> schrieb am Mi., 31. Dez. 2014 um 00:06:
>
>> folks, I really suggest we add none of those in our core.
>>
>> It might easily get added later as an extension anyway.
>>
>> Think about it that way: our core api + impl will end up somewhere around
>>> 100 kByte. So why should we add a library which is close to 1MB just for
>> having a JSON configuration possibility?
>>
>> If a user needs it then he can easily add it himself.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>> On Tuesday, 30 December 2014, 23:25, Oliver B. Fischer <
>> o.b.fischer@swe-blog.net> wrote:
>>>> I think you are right. Jackson offers more than we need since only need
>>> strings.
>>>
>>>
>>>> Am 30.12.14 um 22:27 schrieb Romain Manni-Bucau:
>>>> jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
>>>> Main issue with jackson will surely be the size I think
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2014-12-30 21:39 GMT+01:00 Oliver B. Fischer
>>> <o....@swe-blog.net>:
>>>>> Already found it. Since I really wish to have YAML support I would
>>> prefer
>>>>> Jackson since it supports both.
>>>>>
>>>>> Am 30.12.14 um 21:11 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: Which API parts feel pretty solid already?
Posted by Anatole Tresch <at...@gmail.com>.
+1 keep things minimalistic. Json or whatever support will be as easy as
adding an additional jar/dep to your project. Thats the reason I voted for
standard properties/xml-properties: the parser is already there ootb in the
java platform. Even support for ini files in core might be arguable!
Mark Struberg <st...@yahoo.de> schrieb am Mi., 31. Dez. 2014 um 00:06:
> folks, I really suggest we add none of those in our core.
>
> It might easily get added later as an extension anyway.
>
> Think about it that way: our core api + impl will end up somewhere around
> > 100 kByte. So why should we add a library which is close to 1MB just for
> having a JSON configuration possibility?
>
> If a user needs it then he can easily add it himself.
>
>
> LieGrue,
> strub
>
>
>
>
> > On Tuesday, 30 December 2014, 23:25, Oliver B. Fischer <
> o.b.fischer@swe-blog.net> wrote:
> > > I think you are right. Jackson offers more than we need since only need
> > strings.
> >
> >
> > Am 30.12.14 um 22:27 schrieb Romain Manni-Bucau:
> >> jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
> >> Main issue with jackson will surely be the size I think
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-30 21:39 GMT+01:00 Oliver B. Fischer
> > <o....@swe-blog.net>:
> >>> Already found it. Since I really wish to have YAML support I would
> > prefer
> >>> Jackson since it supports both.
> >>>
> >>> Am 30.12.14 um 21:11 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: Which API parts feel pretty solid already?
Posted by Mark Struberg <st...@yahoo.de>.
folks, I really suggest we add none of those in our core.
It might easily get added later as an extension anyway.
Think about it that way: our core api + impl will end up somewhere around > 100 kByte. So why should we add a library which is close to 1MB just for having a JSON configuration possibility?
If a user needs it then he can easily add it himself.
LieGrue,
strub
> On Tuesday, 30 December 2014, 23:25, Oliver B. Fischer <o....@swe-blog.net> wrote:
> > I think you are right. Jackson offers more than we need since only need
> strings.
>
>
> Am 30.12.14 um 22:27 schrieb Romain Manni-Bucau:
>> jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
>> Main issue with jackson will surely be the size I think
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-30 21:39 GMT+01:00 Oliver B. Fischer
> <o....@swe-blog.net>:
>>> Already found it. Since I really wish to have YAML support I would
> prefer
>>> Jackson since it supports both.
>>>
>>> Am 30.12.14 um 21:11 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I think you are right. Jackson offers more than we need since only need
strings.
Am 30.12.14 um 22:27 schrieb Romain Manni-Bucau:
> jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
> Main issue with jackson will surely be the size I think
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 21:39 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Already found it. Since I really wish to have YAML support I would prefer
>> Jackson since it supports both.
>>
>> Am 30.12.14 um 21:11 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: Which API parts feel pretty solid already?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
jackson and snakeyaml are ASF v2 and jyaml is BSD so all are allowed.
Main issue with jackson will surely be the size I think
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-30 21:39 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Already found it. Since I really wish to have YAML support I would prefer
> Jackson since it supports both.
>
> Am 30.12.14 um 21:11 schrieb Romain Manni-Bucau:
>>
>> johnzon is an impl of the JSON-P API provided by Apache which has a
>> mapper and few jaxrs provider. Project is still young but we
>> completely own the code so easy to get what we need if not yet here.
>> Comments are under the radar since some months but not yet done.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-30 21:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>> What is johnzon?
>>>
>>> Am 30.12.14 um 19:12 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Already found it. Since I really wish to have YAML support I would
prefer Jackson since it supports both.
Am 30.12.14 um 21:11 schrieb Romain Manni-Bucau:
> johnzon is an impl of the JSON-P API provided by Apache which has a
> mapper and few jaxrs provider. Project is still young but we
> completely own the code so easy to get what we need if not yet here.
> Comments are under the radar since some months but not yet done.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 21:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> What is johnzon?
>>
>> Am 30.12.14 um 19:12 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: Which API parts feel pretty solid already?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
johnzon is an impl of the JSON-P API provided by Apache which has a
mapper and few jaxrs provider. Project is still young but we
completely own the code so easy to get what we need if not yet here.
Comments are under the radar since some months but not yet done.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-30 21:01 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> What is johnzon?
>
> Am 30.12.14 um 19:12 schrieb Romain Manni-Bucau:
>>
>> we can use any library matching Apache licensing
>> (http://www.apache.org/legal/resolved.html).
>>
>> About json we could enrich johnzon pretty easily to have what we need
>> instead of relying on an external one.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-30 19:04 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>> I agree that XML is so yesterday but it is also widely used and
>>> supported.
>>>
>>>
>>> Am 30.12.14 um 18:55 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
What is johnzon?
Am 30.12.14 um 19:12 schrieb Romain Manni-Bucau:
> we can use any library matching Apache licensing
> (http://www.apache.org/legal/resolved.html).
>
> About json we could enrich johnzon pretty easily to have what we need
> instead of relying on an external one.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 19:04 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> I agree that XML is so yesterday but it is also widely used and supported.
>>
>>
>> Am 30.12.14 um 18:55 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: Which API parts feel pretty solid already?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
we can use any library matching Apache licensing
(http://www.apache.org/legal/resolved.html).
About json we could enrich johnzon pretty easily to have what we need
instead of relying on an external one.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-30 19:04 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> I agree that XML is so yesterday but it is also widely used and supported.
>
>
> Am 30.12.14 um 18:55 schrieb Mark Struberg:
>
>> xml imo it so yesterday. The problem with xml is that you would also
>> define a XSD and Schema. That would be add 30 pages to the spec without much
>> benefit.
>>
>> Remember that every user can very simply register his own PropertySources
>> where he reads his own XML.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Tuesday, 30 December 2014, 18:40, Romain Manni-Bucau
>>> <rm...@gmail.com> wrote:
>>>>
>>>> I think we need to support properties cause it is 1-1 with the API and
>>>
>>> then we should maybe release and see what users do.
>>>
>>> JSON is a pretty bad solution for config since you can't comment
>>> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
>>> is...XML but I wonder how more advanced property sources would
>>> completely replace file based ones (ie we should only provide a single
>>> one based on file mainly for tests or do we really need to tackle
>>> these formats). In all cases I would expect to find them in
>>> "tamaya-extra" to start and no in the main delivery. So it can really
>>> wait the first release which would at least provide the API and
>>> default "wiring".
>>>
>>> wdyt?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>>
>>>> Hi,
>>>>
>>>> on Thursday I would like to discuss with you which kind of property
>>>> sources
>>>> we required.
>>>>
>>>> Even if I don't like it very much, we should support XML. But I would
>>>
>>> like
>>>>
>>>> to see also JSON, YAML and HOCON support.
>>>>
>>>> Bye,
>>>>
>>>> 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
I agree that XML is so yesterday but it is also widely used and supported.
Am 30.12.14 um 18:55 schrieb Mark Struberg:
> xml imo it so yesterday. The problem with xml is that you would also define a XSD and Schema. That would be add 30 pages to the spec without much benefit.
>
> Remember that every user can very simply register his own PropertySources where he reads his own XML.
>
> LieGrue,
> strub
>
>
>
>
>
>> On Tuesday, 30 December 2014, 18:40, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>> I think we need to support properties cause it is 1-1 with the API and
>> then we should maybe release and see what users do.
>>
>> JSON is a pretty bad solution for config since you can't comment
>> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
>> is...XML but I wonder how more advanced property sources would
>> completely replace file based ones (ie we should only provide a single
>> one based on file mainly for tests or do we really need to tackle
>> these formats). In all cases I would expect to find them in
>> "tamaya-extra" to start and no in the main delivery. So it can really
>> wait the first release which would at least provide the API and
>> default "wiring".
>>
>> wdyt?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>>
>> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>> Hi,
>>>
>>> on Thursday I would like to discuss with you which kind of property sources
>>> we required.
>>>
>>> Even if I don't like it very much, we should support XML. But I would
>> like
>>> to see also JSON, YAML and HOCON support.
>>>
>>> Bye,
>>>
>>> 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: Which API parts feel pretty solid already?
Posted by Mark Struberg <st...@yahoo.de>.
xml imo it so yesterday. The problem with xml is that you would also define a XSD and Schema. That would be add 30 pages to the spec without much benefit.
Remember that every user can very simply register his own PropertySources where he reads his own XML.
LieGrue,
strub
> On Tuesday, 30 December 2014, 18:40, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > I think we need to support properties cause it is 1-1 with the API and
> then we should maybe release and see what users do.
>
> JSON is a pretty bad solution for config since you can't comment
> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
> is...XML but I wonder how more advanced property sources would
> completely replace file based ones (ie we should only provide a single
> one based on file mainly for tests or do we really need to tackle
> these formats). In all cases I would expect to find them in
> "tamaya-extra" to start and no in the main delivery. So it can really
> wait the first release which would at least provide the API and
> default "wiring".
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
>
> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Hi,
>>
>> on Thursday I would like to discuss with you which kind of property sources
>> we required.
>>
>> Even if I don't like it very much, we should support XML. But I would
> like
>> to see also JSON, YAML and HOCON support.
>>
>> Bye,
>>
>> 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Another important question is if we can rely on third party libraries or
which parts we have to write our-self???
So, supporting JSON and YAML is easy if we can use Jackson (ASF license)?
Bye,
Oliver
Am 30.12.14 um 18:38 schrieb Romain Manni-Bucau:
> I think we need to support properties cause it is 1-1 with the API and
> then we should maybe release and see what users do.
>
> JSON is a pretty bad solution for config since you can't comment
> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
> is...XML but I wonder how more advanced property sources would
> completely replace file based ones (ie we should only provide a single
> one based on file mainly for tests or do we really need to tackle
> these formats). In all cases I would expect to find them in
> "tamaya-extra" to start and no in the main delivery. So it can really
> wait the first release which would at least provide the API and
> default "wiring".
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Hi,
>>
>> on Thursday I would like to discuss with you which kind of property sources
>> we required.
>>
>> Even if I don't like it very much, we should support XML. But I would like
>> to see also JSON, YAML and HOCON support.
>>
>> Bye,
>>
>> 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: Which API parts feel pretty solid already?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yep globally agree, just not sure about json for the mentionned reason
but nothing strong against it.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-30 18:54 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Concering the "tamaya-extras": This addresses the issue of modularization of
> Tamaya. For all non-standard features I think we need multiple modules/jars
> since we rely on SPIs.
>
> I think JSON is simply a must today since it is very common in many systems
> and people are used to it. If we write our own parser (good/bad idea?) we
> can add support for C style commends as Jackson it does.
>
> YAML is widely used in the Devops movement and I know many systems who
> support YAML config files (e.g. Dropwizard, ElasticSearch).
>
> Bye,
>
> Oliver
>
> Am 30.12.14 um 18:38 schrieb Romain Manni-Bucau:
>
>> I think we need to support properties cause it is 1-1 with the API and
>> then we should maybe release and see what users do.
>>
>> JSON is a pretty bad solution for config since you can't comment
>> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
>> is...XML but I wonder how more advanced property sources would
>> completely replace file based ones (ie we should only provide a single
>> one based on file mainly for tests or do we really need to tackle
>> these formats). In all cases I would expect to find them in
>> "tamaya-extra" to start and no in the main delivery. So it can really
>> wait the first release which would at least provide the API and
>> default "wiring".
>>
>> wdyt?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>> Hi,
>>>
>>> on Thursday I would like to discuss with you which kind of property
>>> sources
>>> we required.
>>>
>>> Even if I don't like it very much, we should support XML. But I would
>>> like
>>> to see also JSON, YAML and HOCON support.
>>>
>>> Bye,
>>>
>>> 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Concering the "tamaya-extras": This addresses the issue of
modularization of Tamaya. For all non-standard features I think we need
multiple modules/jars since we rely on SPIs.
I think JSON is simply a must today since it is very common in many
systems and people are used to it. If we write our own parser (good/bad
idea?) we can add support for C style commends as Jackson it does.
YAML is widely used in the Devops movement and I know many systems who
support YAML config files (e.g. Dropwizard, ElasticSearch).
Bye,
Oliver
Am 30.12.14 um 18:38 schrieb Romain Manni-Bucau:
> I think we need to support properties cause it is 1-1 with the API and
> then we should maybe release and see what users do.
>
> JSON is a pretty bad solution for config since you can't comment
> anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
> is...XML but I wonder how more advanced property sources would
> completely replace file based ones (ie we should only provide a single
> one based on file mainly for tests or do we really need to tackle
> these formats). In all cases I would expect to find them in
> "tamaya-extra" to start and no in the main delivery. So it can really
> wait the first release which would at least provide the API and
> default "wiring".
>
> wdyt?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>> Hi,
>>
>> on Thursday I would like to discuss with you which kind of property sources
>> we required.
>>
>> Even if I don't like it very much, we should support XML. But I would like
>> to see also JSON, YAML and HOCON support.
>>
>> Bye,
>>
>> 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: Which API parts feel pretty solid already?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I think we need to support properties cause it is 1-1 with the API and
then we should maybe release and see what users do.
JSON is a pretty bad solution for config since you can't comment
anything IMO - , YAML is not bad but not yet very well know AFAIK, XML
is...XML but I wonder how more advanced property sources would
completely replace file based ones (ie we should only provide a single
one based on file mainly for tests or do we really need to tackle
these formats). In all cases I would expect to find them in
"tamaya-extra" to start and no in the main delivery. So it can really
wait the first release which would at least provide the API and
default "wiring".
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-30 18:32 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Hi,
>
> on Thursday I would like to discuss with you which kind of property sources
> we required.
>
> Even if I don't like it very much, we should support XML. But I would like
> to see also JSON, YAML and HOCON support.
>
> Bye,
>
> 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: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi,
on Thursday I would like to discuss with you which kind of property
sources we required.
Even if I don't like it very much, we should support XML. But I would
like to see also JSON, YAML and HOCON support.
Bye,
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: Which API parts feel pretty solid already?
Posted by Mark Struberg <st...@yahoo.de>.
Go for it :)
LieGrue,
strub
> On Tuesday, 30 December 2014, 16:26, Reinhard Sandtner <re...@gmail.com> wrote:
> > Hey,
>
> i would go for the implementation of the standard PropertySources
> SystemPropertySource and EnvironmentPropertySource if it’s ok.
>
> should i create a JIRA and submit the patch when i’m done or do you prefer a
> pull request?
> which one is easier to review for you?
>
> btw: shouldn’t we create a JIRA for every task?
>
> lg
> reini
>
>
>
>> Am 30.12.2014 um 14:06 schrieb Anatole Tresch <at...@gmail.com>:
>>
>> Hi,
>>
>> i would take the ConfigurationContext.
>>
>> Cheers
>> Anatole
>> Mark Struberg <st...@yahoo.de> schrieb am Di., 30. Dez. 2014 um
> 11:56:
>>
>>> Hi!
>>>
>>> As we again made a lot of progress in the API/SPI Discussion, I think
> we
>>> could start working no the impl again. Of course only on parts which we
>>> feel are pretty solid in the API part already.
>>>
>>> Here is my list of candidates:
>>>
>>> * ServiceContext: This is the 'singleton factory' so to say.
> It's sole
>>> intention is to return exactly one instance per given class. It must
> take
>>> care about ClassLoader structures etc.
>>> It gets picked up by the ServiceContextManager via the
>>> java.util.ServiceLoader mechanism. If there are multiple
> implementations
>>> then the one with the highest ordinal() will be taken.
>>>
>>> The default implementation should have an ordinal of -100? (we could
> also
>>> make the default ordinal() return 1000 if you like that better) That
> way a
>>> user - but also some container vendors - could easily exchange this
>>> implementation.
>>>
>>> * ConfigurationContext: This is the core part framework programmers
>>> interact with. There is exactly one instance per e.g. a WAR (let's
> forget
>>> about EAR for now, this is a bit more difficult). It knows all the
>>> PropertySources which got configured or programmatically added, etc.
> This
>>> is kind of the core part of all the configuration mechanism! It kind of
>>> defines the 'scenario' which defines the whole behaviour of the
>>> configuration platform.
>>> This class is the one which picks up all the PropertySources which get
>>> registered via ServiceLoader.
>>>
>>> We will surely add a few more methods in the future, but this should be
>>> easy to enhance later.
>>>
>>> It might also register and initialize the Configuration instance?
>>>
>>> Because if someone adds a PropertySource programmatically then we need
> a
>>> way to tell the Configuration instance that it needs to drop it's
> caches
>>> (if there are any in a later phase).
>>>
>>>
>>> * Configuration: This is the core part for USERS. Where 'user'
> means the
>>> programmers who just like to know some configured values.
>>>
>>>
>>> * Standard PropertySources: We need to discuss which ones every
>>> implementation of the spec needs to add by default. I'd say
> it's pretty
>>> much a no-brainer to add 1 for environment and another one for java
> props
>>> for now.
>>>
>>>
>>>
>>> Do you see any blocker for one of those areas right now?
>>>
>>>
>>> If not, who wants to work on which area?
>>>
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>
Re: Which API parts feel pretty solid already?
Posted by Anatole Tresch <at...@gmail.com>.
Hi John
Se does not mean you only one classloader. It dependes on the architecture
of your runtime... So you must think on classloader hierarchies .
Nevertheless this area is not new...
Anatole
Reinhard Sandtner <re...@gmail.com> schrieb am Di., 30. Dez.
2014 um 16:26:
> Hey,
>
> i would go for the implementation of the standard PropertySources
> SystemPropertySource and EnvironmentPropertySource if it’s ok.
>
> should i create a JIRA and submit the patch when i’m done or do you prefer
> a pull request?
> which one is easier to review for you?
>
> btw: shouldn’t we create a JIRA for every task?
>
> lg
> reini
>
>
> > Am 30.12.2014 um 14:06 schrieb Anatole Tresch <at...@gmail.com>:
> >
> > Hi,
> >
> > i would take the ConfigurationContext.
> >
> > Cheers
> > Anatole
> > Mark Struberg <st...@yahoo.de> schrieb am Di., 30. Dez. 2014 um
> 11:56:
> >
> >> Hi!
> >>
> >> As we again made a lot of progress in the API/SPI Discussion, I think we
> >> could start working no the impl again. Of course only on parts which we
> >> feel are pretty solid in the API part already.
> >>
> >> Here is my list of candidates:
> >>
> >> * ServiceContext: This is the 'singleton factory' so to say. It's sole
> >> intention is to return exactly one instance per given class. It must
> take
> >> care about ClassLoader structures etc.
> >> It gets picked up by the ServiceContextManager via the
> >> java.util.ServiceLoader mechanism. If there are multiple implementations
> >> then the one with the highest ordinal() will be taken.
> >>
> >> The default implementation should have an ordinal of -100? (we could
> also
> >> make the default ordinal() return 1000 if you like that better) That
> way a
> >> user - but also some container vendors - could easily exchange this
> >> implementation.
> >>
> >> * ConfigurationContext: This is the core part framework programmers
> >> interact with. There is exactly one instance per e.g. a WAR (let's
> forget
> >> about EAR for now, this is a bit more difficult). It knows all the
> >> PropertySources which got configured or programmatically added, etc.
> This
> >> is kind of the core part of all the configuration mechanism! It kind of
> >> defines the 'scenario' which defines the whole behaviour of the
> >> configuration platform.
> >> This class is the one which picks up all the PropertySources which get
> >> registered via ServiceLoader.
> >>
> >> We will surely add a few more methods in the future, but this should be
> >> easy to enhance later.
> >>
> >> It might also register and initialize the Configuration instance?
> >>
> >> Because if someone adds a PropertySource programmatically then we need a
> >> way to tell the Configuration instance that it needs to drop it's caches
> >> (if there are any in a later phase).
> >>
> >>
> >> * Configuration: This is the core part for USERS. Where 'user' means the
> >> programmers who just like to know some configured values.
> >>
> >>
> >> * Standard PropertySources: We need to discuss which ones every
> >> implementation of the spec needs to add by default. I'd say it's pretty
> >> much a no-brainer to add 1 for environment and another one for java
> props
> >> for now.
> >>
> >>
> >>
> >> Do you see any blocker for one of those areas right now?
> >>
> >>
> >> If not, who wants to work on which area?
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
>
>
Re: Which API parts feel pretty solid already?
Posted by Reinhard Sandtner <re...@gmail.com>.
Hey,
i would go for the implementation of the standard PropertySources SystemPropertySource and EnvironmentPropertySource if it’s ok.
should i create a JIRA and submit the patch when i’m done or do you prefer a pull request?
which one is easier to review for you?
btw: shouldn’t we create a JIRA for every task?
lg
reini
> Am 30.12.2014 um 14:06 schrieb Anatole Tresch <at...@gmail.com>:
>
> Hi,
>
> i would take the ConfigurationContext.
>
> Cheers
> Anatole
> Mark Struberg <st...@yahoo.de> schrieb am Di., 30. Dez. 2014 um 11:56:
>
>> Hi!
>>
>> As we again made a lot of progress in the API/SPI Discussion, I think we
>> could start working no the impl again. Of course only on parts which we
>> feel are pretty solid in the API part already.
>>
>> Here is my list of candidates:
>>
>> * ServiceContext: This is the 'singleton factory' so to say. It's sole
>> intention is to return exactly one instance per given class. It must take
>> care about ClassLoader structures etc.
>> It gets picked up by the ServiceContextManager via the
>> java.util.ServiceLoader mechanism. If there are multiple implementations
>> then the one with the highest ordinal() will be taken.
>>
>> The default implementation should have an ordinal of -100? (we could also
>> make the default ordinal() return 1000 if you like that better) That way a
>> user - but also some container vendors - could easily exchange this
>> implementation.
>>
>> * ConfigurationContext: This is the core part framework programmers
>> interact with. There is exactly one instance per e.g. a WAR (let's forget
>> about EAR for now, this is a bit more difficult). It knows all the
>> PropertySources which got configured or programmatically added, etc. This
>> is kind of the core part of all the configuration mechanism! It kind of
>> defines the 'scenario' which defines the whole behaviour of the
>> configuration platform.
>> This class is the one which picks up all the PropertySources which get
>> registered via ServiceLoader.
>>
>> We will surely add a few more methods in the future, but this should be
>> easy to enhance later.
>>
>> It might also register and initialize the Configuration instance?
>>
>> Because if someone adds a PropertySource programmatically then we need a
>> way to tell the Configuration instance that it needs to drop it's caches
>> (if there are any in a later phase).
>>
>>
>> * Configuration: This is the core part for USERS. Where 'user' means the
>> programmers who just like to know some configured values.
>>
>>
>> * Standard PropertySources: We need to discuss which ones every
>> implementation of the spec needs to add by default. I'd say it's pretty
>> much a no-brainer to add 1 for environment and another one for java props
>> for now.
>>
>>
>>
>> Do you see any blocker for one of those areas right now?
>>
>>
>> If not, who wants to work on which area?
>>
>>
>>
>> LieGrue,
>> strub
>>
Re: Which API parts feel pretty solid already?
Posted by Anatole Tresch <at...@gmail.com>.
Hi,
i would take the ConfigurationContext.
Cheers
Anatole
Mark Struberg <st...@yahoo.de> schrieb am Di., 30. Dez. 2014 um 11:56:
> Hi!
>
> As we again made a lot of progress in the API/SPI Discussion, I think we
> could start working no the impl again. Of course only on parts which we
> feel are pretty solid in the API part already.
>
> Here is my list of candidates:
>
> * ServiceContext: This is the 'singleton factory' so to say. It's sole
> intention is to return exactly one instance per given class. It must take
> care about ClassLoader structures etc.
> It gets picked up by the ServiceContextManager via the
> java.util.ServiceLoader mechanism. If there are multiple implementations
> then the one with the highest ordinal() will be taken.
>
> The default implementation should have an ordinal of -100? (we could also
> make the default ordinal() return 1000 if you like that better) That way a
> user - but also some container vendors - could easily exchange this
> implementation.
>
> * ConfigurationContext: This is the core part framework programmers
> interact with. There is exactly one instance per e.g. a WAR (let's forget
> about EAR for now, this is a bit more difficult). It knows all the
> PropertySources which got configured or programmatically added, etc. This
> is kind of the core part of all the configuration mechanism! It kind of
> defines the 'scenario' which defines the whole behaviour of the
> configuration platform.
> This class is the one which picks up all the PropertySources which get
> registered via ServiceLoader.
>
> We will surely add a few more methods in the future, but this should be
> easy to enhance later.
>
> It might also register and initialize the Configuration instance?
>
> Because if someone adds a PropertySource programmatically then we need a
> way to tell the Configuration instance that it needs to drop it's caches
> (if there are any in a later phase).
>
>
> * Configuration: This is the core part for USERS. Where 'user' means the
> programmers who just like to know some configured values.
>
>
> * Standard PropertySources: We need to discuss which ones every
> implementation of the spec needs to add by default. I'd say it's pretty
> much a no-brainer to add 1 for environment and another one for java props
> for now.
>
>
>
> Do you see any blocker for one of those areas right now?
>
>
> If not, who wants to work on which area?
>
>
>
> LieGrue,
> strub
>
Re: Which API parts feel pretty solid already?
Posted by Mark Struberg <st...@yahoo.de>.
Yes, currently he can only retrieve a single String value.
Of course we might think about adding String lists. It should be pretty easy to add it on top of our current ideas.
Please open a new [DISCUSS] thread and start collecting ideas on IF and HOW we could implement this.
LieGrue,
strub
> On Wednesday, 31 December 2014, 11:08, Oliver B. Fischer <o....@swe-blog.net> wrote:
> > Hi, I just realized that users cannot retrieve a list of values but only single
> values. Or did I miss something?
>
> Oliver
>
> Von meinem iPhone gesendet
>
>
>> Am 30.12.2014 um 11:52 schrieb Mark Struberg <st...@yahoo.de>:
>>
>> Hi!
>>
>> As we again made a lot of progress in the API/SPI Discussion, I think we
> could start working no the impl again. Of course only on parts which we feel are
> pretty solid in the API part already.
>>
>> Here is my list of candidates:
>>
>> * ServiceContext: This is the 'singleton factory' so to say.
> It's sole intention is to return exactly one instance per given class. It
> must take care about ClassLoader structures etc.
>> It gets picked up by the ServiceContextManager via the
> java.util.ServiceLoader mechanism. If there are multiple implementations then
> the one with the highest ordinal() will be taken.
>>
>> The default implementation should have an ordinal of -100? (we could also
> make the default ordinal() return 1000 if you like that better) That way a user
> - but also some container vendors - could easily exchange this implementation.
>>
>> * ConfigurationContext: This is the core part framework programmers
> interact with. There is exactly one instance per e.g. a WAR (let's forget
> about EAR for now, this is a bit more difficult). It knows all the
> PropertySources which got configured or programmatically added, etc. This is
> kind of the core part of all the configuration mechanism! It kind of defines the
> 'scenario' which defines the whole behaviour of the configuration
> platform.
>> This class is the one which picks up all the PropertySources which get
> registered via ServiceLoader.
>>
>> We will surely add a few more methods in the future, but this should be
> easy to enhance later.
>>
>> It might also register and initialize the Configuration instance?
>>
>> Because if someone adds a PropertySource programmatically then we need a
> way to tell the Configuration instance that it needs to drop it's caches (if
> there are any in a later phase).
>>
>>
>> * Configuration: This is the core part for USERS. Where 'user'
> means the programmers who just like to know some configured values.
>>
>>
>> * Standard PropertySources: We need to discuss which ones every
> implementation of the spec needs to add by default. I'd say it's pretty
> much a no-brainer to add 1 for environment and another one for java props for
> now.
>>
>>
>>
>> Do you see any blocker for one of those areas right now?
>>
>>
>> If not, who wants to work on which area?
>>
>>
>>
>> LieGrue,
>> strub
>
Re: Which API parts feel pretty solid already?
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi, I just realized that users cannot retrieve a list of values but only single values. Or did I miss something?
Oliver
Von meinem iPhone gesendet
> Am 30.12.2014 um 11:52 schrieb Mark Struberg <st...@yahoo.de>:
>
> Hi!
>
> As we again made a lot of progress in the API/SPI Discussion, I think we could start working no the impl again. Of course only on parts which we feel are pretty solid in the API part already.
>
> Here is my list of candidates:
>
> * ServiceContext: This is the 'singleton factory' so to say. It's sole intention is to return exactly one instance per given class. It must take care about ClassLoader structures etc.
> It gets picked up by the ServiceContextManager via the java.util.ServiceLoader mechanism. If there are multiple implementations then the one with the highest ordinal() will be taken.
>
> The default implementation should have an ordinal of -100? (we could also make the default ordinal() return 1000 if you like that better) That way a user - but also some container vendors - could easily exchange this implementation.
>
> * ConfigurationContext: This is the core part framework programmers interact with. There is exactly one instance per e.g. a WAR (let's forget about EAR for now, this is a bit more difficult). It knows all the PropertySources which got configured or programmatically added, etc. This is kind of the core part of all the configuration mechanism! It kind of defines the 'scenario' which defines the whole behaviour of the configuration platform.
> This class is the one which picks up all the PropertySources which get registered via ServiceLoader.
>
> We will surely add a few more methods in the future, but this should be easy to enhance later.
>
> It might also register and initialize the Configuration instance?
>
> Because if someone adds a PropertySource programmatically then we need a way to tell the Configuration instance that it needs to drop it's caches (if there are any in a later phase).
>
>
> * Configuration: This is the core part for USERS. Where 'user' means the programmers who just like to know some configured values.
>
>
> * Standard PropertySources: We need to discuss which ones every implementation of the spec needs to add by default. I'd say it's pretty much a no-brainer to add 1 for environment and another one for java props for now.
>
>
>
> Do you see any blocker for one of those areas right now?
>
>
> If not, who wants to work on which area?
>
>
>
> LieGrue,
> strub