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/28 11:05:45 UTC
[DISCUSS] configuration categories
If we manage configuration container wide for multiple applications and parts of those then we _might_ like to introduce 'categories'.
In DeltaSpike we decided to not needing them because it is easy to just use namespacing and be done. But DeltaSpike config is mostly used inside an application and Tamaya should target container-wide configuration.
So do we need those?
We need to think through a few scenarios e.g. with multiple WARs configured on the same server. And also clustering.
All the configuration along the classpath is 'local' to the current application anyway, but what about java env and properties, or a database configuration?
Do we simply suggest using namespaces or do we like to introduce some application/category context?
As always: adding this adds complexity and we really ONLY must do that if the advantages outpace the complexity.
LieGrue,
strub
Re: [DISCUSS] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
Oh I thought about the SecurityManager stuff again. Romain is right that we don't need categories but instead could leverage namespaces.
A SecurityManager could e.g. use regexp and define that anything with .*passphrase must only be accessed by certain code parts.
LieGrue,
strub
> On Sunday, 28 December 2014, 14:02, Mark Struberg <st...@yahoo.de> wrote:
> > again: if you use namespacing then there is just no conflict.
>
> If we do all that stuff just to avoid conflicts, then we should go back and
> confess it.
> That's just a non problem.
>
> We should NOT do weirdly complex stuff just to work around other peoples stupid
> ideas.
>
> Remember, we agreed to start on a clean sheet. That was the main argument to use
> Java8 as well.
>
> Imo we should not aim to be a 1:1 drop in replacement for every sub-par legacy
> solution but to resolve user problems. That includes that they surely have to
> adopt their way of thinking sometimes.
>
> LieGrue,
> strub
>
>
>
>
>
>
>> On Sunday, 28 December 2014, 12:46, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>> > like Properties?
>>
>> Properties myConf = new Properties();
>> myConf.putAll(System.getProperties());
>> myConf.putAll(myLoadedProps);
>> // etc...
>>
>> I guess you see how it works in spring as well.
>>
>> In CDI you would just @produces it.
>>
>>
>> Drawback: you know "sources"
>> Advanage: you know the sources so you can select the up to date ones
>> and void 80% of conflicts (then 20% are solved by natural overriding)
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>>
>> 2014-12-28 12:39 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>>> Show us an example. When I came along manual config composition it
> always
>> caused a decent amount of pain.
>>>
>>> We really need concrete examples about how this should work.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>
>>>> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau
>> <rm...@gmail.com> wrote:
>>>> > I think it is either not important or so imoortant that it
> should
>> be
>>>> central.
>>>>
>>>> I mean if it is not important we use Configuration.current(). If
> it is
>>>> important then we need to get rid of this contextual config and
> only
>> handle
>>>> a configuration reference. I guess that what any app would do
> without
>> any
>>>> framework.
>>>>
>>>> It also open the door to have multiple configs by app which is
> nice for
>>>> aggregated apps.
>>>>
>>>> Le 28 déc. 2014 12:11, "Mark Struberg"
>> <st...@yahoo.de> a
>>>> écrit :
>>>>
>>>>> To be honest I have no clear idea about it yet.
>>>>>
>>>>> In our application it could have been
>>>>>
>>>>> * 'database' (containing credentials, refetch
> settings,
>> etc) vs
>>>>> * 'documentarchive' vs
>>>>> * 'calculationcore'
>>>>>
>>>>>
>>>>> It could also be split on Application.
>>>>>
>>>>> One of the features could be to have different ConfigSources
> per
>>>>> 'category'.
>>>>> A ConfigSource could have a default category (or none) and
> would
>> then
>>>>> apply to all configuration.
>>>>> Or assigned to a specific category which would then just be
> merged
>> with
>>>>> all the default ones.
>>>>>
>>>>> And yet another point is security. We sooner or later need to
>
>> integrate
>>>>> the SecurityManager. And categories might be used for
> restricting
>> access to
>>>>> certain parts of the configuration.
>>>>>
>>>>> Just brainstorming a bit...
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> wrote:
>>>>>
>>>>>
>>>>> >
>>>>> >
>>>>> >What are categories? Like prefixes? Tenants?
>>>>> >Not sure v1 needs it
>>>>> >Le 28 déc. 2014 11:07, "Mark Struberg"
>>>> <st...@yahoo.de> a écrit :
>>>>> >
>>>>> >If we manage configuration container wide for multiple
>> applications and
>>>>> parts of those then we _might_ like to introduce
>> 'categories'.
>>>>> >>
>>>>> >>
>>>>> >>In DeltaSpike we decided to not needing them because
> it is
>> easy to
>>>> just
>>>>> use namespacing and be done. But DeltaSpike config is mostly
> used
>> inside an
>>>>> application and Tamaya should target container-wide
> configuration.
>>>>> >>
>>>>> >>
>>>>> >>So do we need those?
>>>>> >>
>>>>> >>We need to think through a few scenarios e.g. with
>> multiple WARs
>>>>> configured on the same server. And also clustering.
>>>>> >>
>>>>> >>All the configuration along the classpath is
>> 'local' to the
>>>> current
>>>>> application anyway, but what about java env and properties,
> or a
>> database
>>>>> configuration?
>>>>> >>Do we simply suggest using namespaces or do we like
> to
>> introduce
>>>> some
>>>>> application/category context?
>>>>> >>
>>>>> >>
>>>>> >>As always: adding this adds complexity and we really
> ONLY
>> must do
>>>> that
>>>>> if the advantages outpace the complexity.
>>>>> >>
>>>>> >>
>>>>> >>LieGrue,
>>>>> >>strub
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>
>>
>
Re: [DISCUSS] configuration categories
Posted by Anatole Tresch <an...@apache.org>.
Dear all
I dont know if I get everything along namespaces: thinking of namespaces we
could do the following:
- every Property source (aka PS) has a required name property, String
getName()
- the main configuration hierarchy is build up by a set of top level
property sources, hereby the top level names must be unique, so you can
identify every top level PS by calling:
PropertySource.getInstance("myName");
- every top level PS has a priority and a target configuration name
(provided by the PropertySourceProvider).
Given that we have
- a clear mapping between Configuration -> PropertySource (1..n)
- a clear priority ordering for each Configuration (by priority)
- we can easily add overridings (controlled by some security mechanisms)
to each top level PropertySource
- we can also reference each top level PropertySource by name
- we can also reference each Configuration Property Source (aggregate)
by the config name
Now, when using a builder for setting up the internal PS within a top level
PS:
- Still each PS has a name
- we have a well defined tree structure of PS, child PS etc
- so we can also address each child PS with a path
Example:
PropertyProvider {
name: "system",
target: "default",
priority : 1000
PropertySource {
name: "system"
aggregate {
policy: AggregationPolicy.OVERRIDE,
children{
PropertySource {
name: "defaults",
paths: "META-INF/cfg/defaults/**/*.xml"
},
PropertySource {
policy: AggregationPolicy.OVERRIDE,
name: "config"
children{
PropertySource {
name: "normal",
paths: "META-INF/cfg/system/**/*.xml"
},
PropertySource {
name: "legacy",
paths: "system-cfg/**/*.xml"
}
},
PropertySource {
name: "system.properties",
property-ref: "system.properties" # assumes a
"system.properties" PS/configuration is present
},
}
}
}
}
PropertyProvider {
name: "app",
target: "default",
priority : 5000
PropertySource {
... similar to above
}
}
Given that we can refer to each part (within the whole system):
property-source:system
property-source:system/defaults
property-source:system/config/normal
property-source:system/config/legacy
property-source:system/system.properties
Basically the same would also be possible by querying from the
Configuration side:
configuration:default # Maps to the full current default config
configuration:default/system
configuration:default/system/defaults
For completeness the building code for the system part may look like:
PropertySource ps = PropertySourceBuilder.of("system")
.addPaths("defaults", "META-INF/cfg/defaults/**/*.xml")
.addProviders(
PropertySourceBuilder.of("config")
.addPaths("normal", "META-INF/cfg/system/**/*.xml")
.addPaths("legacy", "system-cfg/**/*.xml")
.build()
)
.build();
WDYT? Would that help?
2014-12-28 14:00 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> again: if you use namespacing then there is just no conflict.
>
> If we do all that stuff just to avoid conflicts, then we should go back
> and confess it.
> That's just a non problem.
>
> We should NOT do weirdly complex stuff just to work around other peoples
> stupid ideas.
>
> Remember, we agreed to start on a clean sheet. That was the main argument
> to use Java8 as well.
>
> Imo we should not aim to be a 1:1 drop in replacement for every sub-par
> legacy solution but to resolve user problems. That includes that they
> surely have to adopt their way of thinking sometimes.
>
> LieGrue,
> strub
>
>
>
>
>
> > On Sunday, 28 December 2014, 12:46, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > > like Properties?
> >
> > Properties myConf = new Properties();
> > myConf.putAll(System.getProperties());
> > myConf.putAll(myLoadedProps);
> > // etc...
> >
> > I guess you see how it works in spring as well.
> >
> > In CDI you would just @produces it.
> >
> >
> > Drawback: you know "sources"
> > Advanage: you know the sources so you can select the up to date ones
> > and void 80% of conflicts (then 20% are solved by natural overriding)
> >
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> >
> > 2014-12-28 12:39 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >> Show us an example. When I came along manual config composition it
> always
> > caused a decent amount of pain.
> >>
> >> We really need concrete examples about how this should work.
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >>> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> >>> > I think it is either not important or so imoortant that it should
> > be
> >>> central.
> >>>
> >>> I mean if it is not important we use Configuration.current(). If it is
> >>> important then we need to get rid of this contextual config and only
> > handle
> >>> a configuration reference. I guess that what any app would do without
> > any
> >>> framework.
> >>>
> >>> It also open the door to have multiple configs by app which is nice
> for
> >>> aggregated apps.
> >>>
> >>> Le 28 déc. 2014 12:11, "Mark Struberg"
> > <st...@yahoo.de> a
> >>> écrit :
> >>>
> >>>> To be honest I have no clear idea about it yet.
> >>>>
> >>>> In our application it could have been
> >>>>
> >>>> * 'database' (containing credentials, refetch settings,
> > etc) vs
> >>>> * 'documentarchive' vs
> >>>> * 'calculationcore'
> >>>>
> >>>>
> >>>> It could also be split on Application.
> >>>>
> >>>> One of the features could be to have different ConfigSources per
> >>>> 'category'.
> >>>> A ConfigSource could have a default category (or none) and would
> > then
> >>>> apply to all configuration.
> >>>> Or assigned to a specific category which would then just be merged
> > with
> >>>> all the default ones.
> >>>>
> >>>> And yet another point is security. We sooner or later need to
> > integrate
> >>>> the SecurityManager. And categories might be used for restricting
> > access to
> >>>> certain parts of the configuration.
> >>>>
> >>>> Just brainstorming a bit...
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
> >>>> rmannibucau@gmail.com> wrote:
> >>>>
> >>>>
> >>>> >
> >>>> >
> >>>> >What are categories? Like prefixes? Tenants?
> >>>> >Not sure v1 needs it
> >>>> >Le 28 déc. 2014 11:07, "Mark Struberg"
> >>> <st...@yahoo.de> a écrit :
> >>>> >
> >>>> >If we manage configuration container wide for multiple
> > applications and
> >>>> parts of those then we _might_ like to introduce
> > 'categories'.
> >>>> >>
> >>>> >>
> >>>> >>In DeltaSpike we decided to not needing them because it is
> > easy to
> >>> just
> >>>> use namespacing and be done. But DeltaSpike config is mostly used
> > inside an
> >>>> application and Tamaya should target container-wide configuration.
> >>>> >>
> >>>> >>
> >>>> >>So do we need those?
> >>>> >>
> >>>> >>We need to think through a few scenarios e.g. with
> > multiple WARs
> >>>> configured on the same server. And also clustering.
> >>>> >>
> >>>> >>All the configuration along the classpath is
> > 'local' to the
> >>> current
> >>>> application anyway, but what about java env and properties, or a
> > database
> >>>> configuration?
> >>>> >>Do we simply suggest using namespaces or do we like to
> > introduce
> >>> some
> >>>> application/category context?
> >>>> >>
> >>>> >>
> >>>> >>As always: adding this adds complexity and we really ONLY
> > must do
> >>> that
> >>>> if the advantages outpace the complexity.
> >>>> >>
> >>>> >>
> >>>> >>LieGrue,
> >>>> >>strub
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>
> >
>
Re: [DISCUSS] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
again: if you use namespacing then there is just no conflict.
If we do all that stuff just to avoid conflicts, then we should go back and confess it.
That's just a non problem.
We should NOT do weirdly complex stuff just to work around other peoples stupid ideas.
Remember, we agreed to start on a clean sheet. That was the main argument to use Java8 as well.
Imo we should not aim to be a 1:1 drop in replacement for every sub-par legacy solution but to resolve user problems. That includes that they surely have to adopt their way of thinking sometimes.
LieGrue,
strub
> On Sunday, 28 December 2014, 12:46, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > like Properties?
>
> Properties myConf = new Properties();
> myConf.putAll(System.getProperties());
> myConf.putAll(myLoadedProps);
> // etc...
>
> I guess you see how it works in spring as well.
>
> In CDI you would just @produces it.
>
>
> Drawback: you know "sources"
> Advanage: you know the sources so you can select the up to date ones
> and void 80% of conflicts (then 20% are solved by natural overriding)
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
>
> 2014-12-28 12:39 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> Show us an example. When I came along manual config composition it always
> caused a decent amount of pain.
>>
>> We really need concrete examples about how this should work.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>>> > I think it is either not important or so imoortant that it should
> be
>>> central.
>>>
>>> I mean if it is not important we use Configuration.current(). If it is
>>> important then we need to get rid of this contextual config and only
> handle
>>> a configuration reference. I guess that what any app would do without
> any
>>> framework.
>>>
>>> It also open the door to have multiple configs by app which is nice for
>>> aggregated apps.
>>>
>>> Le 28 déc. 2014 12:11, "Mark Struberg"
> <st...@yahoo.de> a
>>> écrit :
>>>
>>>> To be honest I have no clear idea about it yet.
>>>>
>>>> In our application it could have been
>>>>
>>>> * 'database' (containing credentials, refetch settings,
> etc) vs
>>>> * 'documentarchive' vs
>>>> * 'calculationcore'
>>>>
>>>>
>>>> It could also be split on Application.
>>>>
>>>> One of the features could be to have different ConfigSources per
>>>> 'category'.
>>>> A ConfigSource could have a default category (or none) and would
> then
>>>> apply to all configuration.
>>>> Or assigned to a specific category which would then just be merged
> with
>>>> all the default ones.
>>>>
>>>> And yet another point is security. We sooner or later need to
> integrate
>>>> the SecurityManager. And categories might be used for restricting
> access to
>>>> certain parts of the configuration.
>>>>
>>>> Just brainstorming a bit...
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>>
>>>>
>>>> >
>>>> >
>>>> >What are categories? Like prefixes? Tenants?
>>>> >Not sure v1 needs it
>>>> >Le 28 déc. 2014 11:07, "Mark Struberg"
>>> <st...@yahoo.de> a écrit :
>>>> >
>>>> >If we manage configuration container wide for multiple
> applications and
>>>> parts of those then we _might_ like to introduce
> 'categories'.
>>>> >>
>>>> >>
>>>> >>In DeltaSpike we decided to not needing them because it is
> easy to
>>> just
>>>> use namespacing and be done. But DeltaSpike config is mostly used
> inside an
>>>> application and Tamaya should target container-wide configuration.
>>>> >>
>>>> >>
>>>> >>So do we need those?
>>>> >>
>>>> >>We need to think through a few scenarios e.g. with
> multiple WARs
>>>> configured on the same server. And also clustering.
>>>> >>
>>>> >>All the configuration along the classpath is
> 'local' to the
>>> current
>>>> application anyway, but what about java env and properties, or a
> database
>>>> configuration?
>>>> >>Do we simply suggest using namespaces or do we like to
> introduce
>>> some
>>>> application/category context?
>>>> >>
>>>> >>
>>>> >>As always: adding this adds complexity and we really ONLY
> must do
>>> that
>>>> if the advantages outpace the complexity.
>>>> >>
>>>> >>
>>>> >>LieGrue,
>>>> >>strub
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>
Re: [DISCUSS] configuration categories
Posted by "John D. Ament" <jo...@apache.org>.
To me, this is just a name associated to one or more config sources.
On Sun Dec 28 2014 at 6:48:35 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> like Properties?
>
> Properties myConf = new Properties();
> myConf.putAll(System.getProperties());
> myConf.putAll(myLoadedProps);
> // etc...
>
> I guess you see how it works in spring as well.
>
> In CDI you would just @produces it.
>
>
> Drawback: you know "sources"
> Advanage: you know the sources so you can select the up to date ones
> and void 80% of conflicts (then 20% are solved by natural overriding)
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-28 12:39 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> > Show us an example. When I came along manual config composition it
> always caused a decent amount of pain.
> >
> > We really need concrete examples about how this should work.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> >> > I think it is either not important or so imoortant that it should be
> >> central.
> >>
> >> I mean if it is not important we use Configuration.current(). If it is
> >> important then we need to get rid of this contextual config and only
> handle
> >> a configuration reference. I guess that what any app would do without
> any
> >> framework.
> >>
> >> It also open the door to have multiple configs by app which is nice for
> >> aggregated apps.
> >>
> >> Le 28 déc. 2014 12:11, "Mark Struberg" <st...@yahoo.de> a
> >> écrit :
> >>
> >>> To be honest I have no clear idea about it yet.
> >>>
> >>> In our application it could have been
> >>>
> >>> * 'database' (containing credentials, refetch settings, etc) vs
> >>> * 'documentarchive' vs
> >>> * 'calculationcore'
> >>>
> >>>
> >>> It could also be split on Application.
> >>>
> >>> One of the features could be to have different ConfigSources per
> >>> 'category'.
> >>> A ConfigSource could have a default category (or none) and would then
> >>> apply to all configuration.
> >>> Or assigned to a specific category which would then just be merged
> with
> >>> all the default ones.
> >>>
> >>> And yet another point is security. We sooner or later need to
> integrate
> >>> the SecurityManager. And categories might be used for restricting
> access to
> >>> certain parts of the configuration.
> >>>
> >>> Just brainstorming a bit...
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>
> >>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com> wrote:
> >>>
> >>>
> >>> >
> >>> >
> >>> >What are categories? Like prefixes? Tenants?
> >>> >Not sure v1 needs it
> >>> >Le 28 déc. 2014 11:07, "Mark Struberg"
> >> <st...@yahoo.de> a écrit :
> >>> >
> >>> >If we manage configuration container wide for multiple applications
> and
> >>> parts of those then we _might_ like to introduce 'categories'.
> >>> >>
> >>> >>
> >>> >>In DeltaSpike we decided to not needing them because it is easy to
> >> just
> >>> use namespacing and be done. But DeltaSpike config is mostly used
> inside an
> >>> application and Tamaya should target container-wide configuration.
> >>> >>
> >>> >>
> >>> >>So do we need those?
> >>> >>
> >>> >>We need to think through a few scenarios e.g. with multiple WARs
> >>> configured on the same server. And also clustering.
> >>> >>
> >>> >>All the configuration along the classpath is 'local' to the
> >> current
> >>> application anyway, but what about java env and properties, or a
> database
> >>> configuration?
> >>> >>Do we simply suggest using namespaces or do we like to introduce
> >> some
> >>> application/category context?
> >>> >>
> >>> >>
> >>> >>As always: adding this adds complexity and we really ONLY must do
> >> that
> >>> if the advantages outpace the complexity.
> >>> >>
> >>> >>
> >>> >>LieGrue,
> >>> >>strub
> >>> >>
> >>> >
> >>> >
> >>>
> >>
>
Re: [DISCUSS] configuration categories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
like Properties?
Properties myConf = new Properties();
myConf.putAll(System.getProperties());
myConf.putAll(myLoadedProps);
// etc...
I guess you see how it works in spring as well.
In CDI you would just @produces it.
Drawback: you know "sources"
Advanage: you know the sources so you can select the up to date ones
and void 80% of conflicts (then 20% are solved by natural overriding)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-28 12:39 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> Show us an example. When I came along manual config composition it always caused a decent amount of pain.
>
> We really need concrete examples about how this should work.
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau <rm...@gmail.com> wrote:
>> > I think it is either not important or so imoortant that it should be
>> central.
>>
>> I mean if it is not important we use Configuration.current(). If it is
>> important then we need to get rid of this contextual config and only handle
>> a configuration reference. I guess that what any app would do without any
>> framework.
>>
>> It also open the door to have multiple configs by app which is nice for
>> aggregated apps.
>>
>> Le 28 déc. 2014 12:11, "Mark Struberg" <st...@yahoo.de> a
>> écrit :
>>
>>> To be honest I have no clear idea about it yet.
>>>
>>> In our application it could have been
>>>
>>> * 'database' (containing credentials, refetch settings, etc) vs
>>> * 'documentarchive' vs
>>> * 'calculationcore'
>>>
>>>
>>> It could also be split on Application.
>>>
>>> One of the features could be to have different ConfigSources per
>>> 'category'.
>>> A ConfigSource could have a default category (or none) and would then
>>> apply to all configuration.
>>> Or assigned to a specific category which would then just be merged with
>>> all the default ones.
>>>
>>> And yet another point is security. We sooner or later need to integrate
>>> the SecurityManager. And categories might be used for restricting access to
>>> certain parts of the configuration.
>>>
>>> Just brainstorming a bit...
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>
>>> >
>>> >
>>> >What are categories? Like prefixes? Tenants?
>>> >Not sure v1 needs it
>>> >Le 28 déc. 2014 11:07, "Mark Struberg"
>> <st...@yahoo.de> a écrit :
>>> >
>>> >If we manage configuration container wide for multiple applications and
>>> parts of those then we _might_ like to introduce 'categories'.
>>> >>
>>> >>
>>> >>In DeltaSpike we decided to not needing them because it is easy to
>> just
>>> use namespacing and be done. But DeltaSpike config is mostly used inside an
>>> application and Tamaya should target container-wide configuration.
>>> >>
>>> >>
>>> >>So do we need those?
>>> >>
>>> >>We need to think through a few scenarios e.g. with multiple WARs
>>> configured on the same server. And also clustering.
>>> >>
>>> >>All the configuration along the classpath is 'local' to the
>> current
>>> application anyway, but what about java env and properties, or a database
>>> configuration?
>>> >>Do we simply suggest using namespaces or do we like to introduce
>> some
>>> application/category context?
>>> >>
>>> >>
>>> >>As always: adding this adds complexity and we really ONLY must do
>> that
>>> if the advantages outpace the complexity.
>>> >>
>>> >>
>>> >>LieGrue,
>>> >>strub
>>> >>
>>> >
>>> >
>>>
>>
Re: [DISCUSS] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
Show us an example. When I came along manual config composition it always caused a decent amount of pain.
We really need concrete examples about how this should work.
LieGrue,
strub
> On Sunday, 28 December 2014, 12:18, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > I think it is either not important or so imoortant that it should be
> central.
>
> I mean if it is not important we use Configuration.current(). If it is
> important then we need to get rid of this contextual config and only handle
> a configuration reference. I guess that what any app would do without any
> framework.
>
> It also open the door to have multiple configs by app which is nice for
> aggregated apps.
>
> Le 28 déc. 2014 12:11, "Mark Struberg" <st...@yahoo.de> a
> écrit :
>
>> To be honest I have no clear idea about it yet.
>>
>> In our application it could have been
>>
>> * 'database' (containing credentials, refetch settings, etc) vs
>> * 'documentarchive' vs
>> * 'calculationcore'
>>
>>
>> It could also be split on Application.
>>
>> One of the features could be to have different ConfigSources per
>> 'category'.
>> A ConfigSource could have a default category (or none) and would then
>> apply to all configuration.
>> Or assigned to a specific category which would then just be merged with
>> all the default ones.
>>
>> And yet another point is security. We sooner or later need to integrate
>> the SecurityManager. And categories might be used for restricting access to
>> certain parts of the configuration.
>>
>> Just brainstorming a bit...
>>
>> LieGrue,
>> strub
>>
>>
>>
>> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>
>> >
>> >
>> >What are categories? Like prefixes? Tenants?
>> >Not sure v1 needs it
>> >Le 28 déc. 2014 11:07, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> >
>> >If we manage configuration container wide for multiple applications and
>> parts of those then we _might_ like to introduce 'categories'.
>> >>
>> >>
>> >>In DeltaSpike we decided to not needing them because it is easy to
> just
>> use namespacing and be done. But DeltaSpike config is mostly used inside an
>> application and Tamaya should target container-wide configuration.
>> >>
>> >>
>> >>So do we need those?
>> >>
>> >>We need to think through a few scenarios e.g. with multiple WARs
>> configured on the same server. And also clustering.
>> >>
>> >>All the configuration along the classpath is 'local' to the
> current
>> application anyway, but what about java env and properties, or a database
>> configuration?
>> >>Do we simply suggest using namespaces or do we like to introduce
> some
>> application/category context?
>> >>
>> >>
>> >>As always: adding this adds complexity and we really ONLY must do
> that
>> if the advantages outpace the complexity.
>> >>
>> >>
>> >>LieGrue,
>> >>strub
>> >>
>> >
>> >
>>
>
Re: [DISCUSS] configuration categories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I think it is either not important or so imoortant that it should be
central.
I mean if it is not important we use Configuration.current(). If it is
important then we need to get rid of this contextual config and only handle
a configuration reference. I guess that what any app would do without any
framework.
It also open the door to have multiple configs by app which is nice for
aggregated apps.
Le 28 déc. 2014 12:11, "Mark Struberg" <st...@yahoo.de> a écrit :
> To be honest I have no clear idea about it yet.
>
> In our application it could have been
>
> * 'database' (containing credentials, refetch settings, etc) vs
> * 'documentarchive' vs
> * 'calculationcore'
>
>
> It could also be split on Application.
>
> One of the features could be to have different ConfigSources per
> 'category'.
> A ConfigSource could have a default category (or none) and would then
> apply to all configuration.
> Or assigned to a specific category which would then just be merged with
> all the default ones.
>
> And yet another point is security. We sooner or later need to integrate
> the SecurityManager. And categories might be used for restricting access to
> certain parts of the configuration.
>
> Just brainstorming a bit...
>
> LieGrue,
> strub
>
>
>
> On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>
> >
> >
> >What are categories? Like prefixes? Tenants?
> >Not sure v1 needs it
> >Le 28 déc. 2014 11:07, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> >If we manage configuration container wide for multiple applications and
> parts of those then we _might_ like to introduce 'categories'.
> >>
> >>
> >>In DeltaSpike we decided to not needing them because it is easy to just
> use namespacing and be done. But DeltaSpike config is mostly used inside an
> application and Tamaya should target container-wide configuration.
> >>
> >>
> >>So do we need those?
> >>
> >>We need to think through a few scenarios e.g. with multiple WARs
> configured on the same server. And also clustering.
> >>
> >>All the configuration along the classpath is 'local' to the current
> application anyway, but what about java env and properties, or a database
> configuration?
> >>Do we simply suggest using namespaces or do we like to introduce some
> application/category context?
> >>
> >>
> >>As always: adding this adds complexity and we really ONLY must do that
> if the advantages outpace the complexity.
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >
> >
>
Re: [DISCUSS] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
To be honest I have no clear idea about it yet.
In our application it could have been
* 'database' (containing credentials, refetch settings, etc) vs
* 'documentarchive' vs
* 'calculationcore'
It could also be split on Application.
One of the features could be to have different ConfigSources per 'category'.
A ConfigSource could have a default category (or none) and would then apply to all configuration.
Or assigned to a specific category which would then just be merged with all the default ones.
And yet another point is security. We sooner or later need to integrate the SecurityManager. And categories might be used for restricting access to certain parts of the configuration.
Just brainstorming a bit...
LieGrue,
strub
On Sunday, 28 December 2014, 11:45, Romain Manni-Bucau <rm...@gmail.com> wrote:
>
>
>What are categories? Like prefixes? Tenants?
>Not sure v1 needs it
>Le 28 déc. 2014 11:07, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>If we manage configuration container wide for multiple applications and parts of those then we _might_ like to introduce 'categories'.
>>
>>
>>In DeltaSpike we decided to not needing them because it is easy to just use namespacing and be done. But DeltaSpike config is mostly used inside an application and Tamaya should target container-wide configuration.
>>
>>
>>So do we need those?
>>
>>We need to think through a few scenarios e.g. with multiple WARs configured on the same server. And also clustering.
>>
>>All the configuration along the classpath is 'local' to the current application anyway, but what about java env and properties, or a database configuration?
>>Do we simply suggest using namespaces or do we like to introduce some application/category context?
>>
>>
>>As always: adding this adds complexity and we really ONLY must do that if the advantages outpace the complexity.
>>
>>
>>LieGrue,
>>strub
>>
>
>
Re: [DISCUSS] configuration categories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What are categories? Like prefixes? Tenants?
Not sure v1 needs it
Le 28 déc. 2014 11:07, "Mark Struberg" <st...@yahoo.de> a écrit :
> If we manage configuration container wide for multiple applications and
> parts of those then we _might_ like to introduce 'categories'.
>
>
> In DeltaSpike we decided to not needing them because it is easy to just
> use namespacing and be done. But DeltaSpike config is mostly used inside an
> application and Tamaya should target container-wide configuration.
>
>
> So do we need those?
>
> We need to think through a few scenarios e.g. with multiple WARs
> configured on the same server. And also clustering.
>
> All the configuration along the classpath is 'local' to the current
> application anyway, but what about java env and properties, or a database
> configuration?
> Do we simply suggest using namespaces or do we like to introduce some
> application/category context?
>
>
> As always: adding this adds complexity and we really ONLY must do that if
> the advantages outpace the complexity.
>
>
> LieGrue,
> strub
>
Re: [DISCUSS] [RESOLVED] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
verdict: it seems we don't need a 'configuration categories'.
If we will hit a blocker then we can always go back thinking about it again.
txs and LieGrue,
strub
> On Sunday, 28 December 2014, 15:53, Anatole Tresch <at...@gmail.com> wrote:
> > Hi Mark
> in Credit Suisse we also had a category feature. To summarize in short:
> - nobody understood it
> . it was bloated (OK, a different story)
> - more or less nobody used it (because of see above)
> - we removed it and nobody complained so far
>
> So I assume, we dont need it. Makes things complicate, and I dont see
> advantages/use cases we cannot solve by environments, resolvers etc., even
> more flexible and more transparent.
>
>
> Mark Struberg <st...@yahoo.de> schrieb am Sun Dec 28 2014 at 15:43:17:
>
>> @Romain: key prefix only. But it is essentially not in the code but only a
>> convention. It is pretty similar to the java package structure. Which also
>> shows that this approach works in practice.
>>
>>
>> @Oliver: as I said, in DeltaSpike we discussed this as well and decided to
>> not need it. But Tamaya has a bit wider approach as it targets not only a
>> single application but a whole ecosystem. I'm still a bit undecided
> myself.
>> But I think we can just start without 'categories' and see how far
> we come
>> with just namespaces. And if we see a blocker with that then we can still
>> go back and add it.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> > On Sunday, 28 December 2014, 14:45, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> > > Question is mainly: is it explicit or key prefixes only. Last
> works
>> for me
>> > to start.
>> > Le 28 déc. 2014 14:40, "Oliver B. Fischer"
>> > <o....@swe-blog.net> a
>> > écrit :
>> >
>> >
>> >> Hi Mark,
>> >>
>> >> category seems for me to be very similar to the concept of a
>> namespace. Is
>> >> there anything we can do with catagories what we cannot do with
>> namespaces?
>> >>
>> >> Best,
>> >>
>> >> Oliver
>> >>
>> >> Am 28.12.14 um 11:05 schrieb Mark Struberg:
>> >>
>> >>> If we manage configuration container wide for multiple
> applications
>> and
>> >>> parts of those then we _might_ like to introduce
> 'categories'.
>> >>>
>> >>>
>> >>> In DeltaSpike we decided to not needing them because it is
> easy to
>> just
>> >>> use namespacing and be done. But DeltaSpike config is mostly
> used
>> > inside an
>> >>> application and Tamaya should target container-wide
> configuration.
>> >>>
>> >>>
>> >>> So do we need those?
>> >>>
>> >>> We need to think through a few scenarios e.g. with multiple
> WARs
>> >>> configured on the same server. And also clustering.
>> >>>
>> >>> All the configuration along the classpath is 'local'
> to the
>> > current
>> >>> application anyway, but what about java env and properties,
> or a
>> > database
>> >>> configuration?
>> >>> Do we simply suggest using namespaces or do we like to
> introduce some
>> >>> application/category context?
>> >>>
>> >>>
>> >>> As always: adding this adds complexity and we really ONLY
> must do that
>> > if
>> >>> the advantages outpace the complexity.
>> >>>
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>
>> >> --
>> >> 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: [DISCUSS] configuration categories
Posted by Anatole Tresch <at...@gmail.com>.
Hi Mark
in Credit Suisse we also had a category feature. To summarize in short:
- nobody understood it
. it was bloated (OK, a different story)
- more or less nobody used it (because of see above)
- we removed it and nobody complained so far
So I assume, we dont need it. Makes things complicate, and I dont see
advantages/use cases we cannot solve by environments, resolvers etc., even
more flexible and more transparent.
Mark Struberg <st...@yahoo.de> schrieb am Sun Dec 28 2014 at 15:43:17:
> @Romain: key prefix only. But it is essentially not in the code but only a
> convention. It is pretty similar to the java package structure. Which also
> shows that this approach works in practice.
>
>
> @Oliver: as I said, in DeltaSpike we discussed this as well and decided to
> not need it. But Tamaya has a bit wider approach as it targets not only a
> single application but a whole ecosystem. I'm still a bit undecided myself.
> But I think we can just start without 'categories' and see how far we come
> with just namespaces. And if we see a blocker with that then we can still
> go back and add it.
>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Sunday, 28 December 2014, 14:45, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > > Question is mainly: is it explicit or key prefixes only. Last works
> for me
> > to start.
> > Le 28 déc. 2014 14:40, "Oliver B. Fischer"
> > <o....@swe-blog.net> a
> > écrit :
> >
> >
> >> Hi Mark,
> >>
> >> category seems for me to be very similar to the concept of a
> namespace. Is
> >> there anything we can do with catagories what we cannot do with
> namespaces?
> >>
> >> Best,
> >>
> >> Oliver
> >>
> >> Am 28.12.14 um 11:05 schrieb Mark Struberg:
> >>
> >>> If we manage configuration container wide for multiple applications
> and
> >>> parts of those then we _might_ like to introduce 'categories'.
> >>>
> >>>
> >>> In DeltaSpike we decided to not needing them because it is easy to
> just
> >>> use namespacing and be done. But DeltaSpike config is mostly used
> > inside an
> >>> application and Tamaya should target container-wide configuration.
> >>>
> >>>
> >>> So do we need those?
> >>>
> >>> We need to think through a few scenarios e.g. with multiple WARs
> >>> configured on the same server. And also clustering.
> >>>
> >>> All the configuration along the classpath is 'local' to the
> > current
> >>> application anyway, but what about java env and properties, or a
> > database
> >>> configuration?
> >>> Do we simply suggest using namespaces or do we like to introduce some
> >>> application/category context?
> >>>
> >>>
> >>> As always: adding this adds complexity and we really ONLY must do that
> > if
> >>> the advantages outpace the complexity.
> >>>
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>
> >> --
> >> 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: [DISCUSS] configuration categories
Posted by Mark Struberg <st...@yahoo.de>.
@Romain: key prefix only. But it is essentially not in the code but only a convention. It is pretty similar to the java package structure. Which also shows that this approach works in practice.
@Oliver: as I said, in DeltaSpike we discussed this as well and decided to not need it. But Tamaya has a bit wider approach as it targets not only a single application but a whole ecosystem. I'm still a bit undecided myself. But I think we can just start without 'categories' and see how far we come with just namespaces. And if we see a blocker with that then we can still go back and add it.
LieGrue,
strub
> On Sunday, 28 December 2014, 14:45, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > Question is mainly: is it explicit or key prefixes only. Last works for me
> to start.
> Le 28 déc. 2014 14:40, "Oliver B. Fischer"
> <o....@swe-blog.net> a
> écrit :
>
>
>> Hi Mark,
>>
>> category seems for me to be very similar to the concept of a namespace. Is
>> there anything we can do with catagories what we cannot do with namespaces?
>>
>> Best,
>>
>> Oliver
>>
>> Am 28.12.14 um 11:05 schrieb Mark Struberg:
>>
>>> If we manage configuration container wide for multiple applications and
>>> parts of those then we _might_ like to introduce 'categories'.
>>>
>>>
>>> In DeltaSpike we decided to not needing them because it is easy to just
>>> use namespacing and be done. But DeltaSpike config is mostly used
> inside an
>>> application and Tamaya should target container-wide configuration.
>>>
>>>
>>> So do we need those?
>>>
>>> We need to think through a few scenarios e.g. with multiple WARs
>>> configured on the same server. And also clustering.
>>>
>>> All the configuration along the classpath is 'local' to the
> current
>>> application anyway, but what about java env and properties, or a
> database
>>> configuration?
>>> Do we simply suggest using namespaces or do we like to introduce some
>>> application/category context?
>>>
>>>
>>> As always: adding this adds complexity and we really ONLY must do that
> if
>>> the advantages outpace the complexity.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>
>> --
>> 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: [DISCUSS] configuration categories
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Question is mainly: is it explicit or key prefixes only. Last works for me
to start.
Le 28 déc. 2014 14:40, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> Hi Mark,
>
> category seems for me to be very similar to the concept of a namespace. Is
> there anything we can do with catagories what we cannot do with namespaces?
>
> Best,
>
> Oliver
>
> Am 28.12.14 um 11:05 schrieb Mark Struberg:
>
>> If we manage configuration container wide for multiple applications and
>> parts of those then we _might_ like to introduce 'categories'.
>>
>>
>> In DeltaSpike we decided to not needing them because it is easy to just
>> use namespacing and be done. But DeltaSpike config is mostly used inside an
>> application and Tamaya should target container-wide configuration.
>>
>>
>> So do we need those?
>>
>> We need to think through a few scenarios e.g. with multiple WARs
>> configured on the same server. And also clustering.
>>
>> All the configuration along the classpath is 'local' to the current
>> application anyway, but what about java env and properties, or a database
>> configuration?
>> Do we simply suggest using namespaces or do we like to introduce some
>> application/category context?
>>
>>
>> As always: adding this adds complexity and we really ONLY must do that if
>> the advantages outpace the complexity.
>>
>>
>> LieGrue,
>> strub
>>
>
> --
> 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: [DISCUSS] configuration categories
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Hi Mark,
category seems for me to be very similar to the concept of a namespace.
Is there anything we can do with catagories what we cannot do with
namespaces?
Best,
Oliver
Am 28.12.14 um 11:05 schrieb Mark Struberg:
> If we manage configuration container wide for multiple applications and parts of those then we _might_ like to introduce 'categories'.
>
>
> In DeltaSpike we decided to not needing them because it is easy to just use namespacing and be done. But DeltaSpike config is mostly used inside an application and Tamaya should target container-wide configuration.
>
>
> So do we need those?
>
> We need to think through a few scenarios e.g. with multiple WARs configured on the same server. And also clustering.
>
> All the configuration along the classpath is 'local' to the current application anyway, but what about java env and properties, or a database configuration?
> Do we simply suggest using namespaces or do we like to introduce some application/category context?
>
>
> As always: adding this adds complexity and we really ONLY must do that if the advantages outpace the complexity.
>
>
> LieGrue,
> strub
--
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