You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2015/01/05 08:36:54 UTC
DefaultConfiguration
Hi guys,
if we keep current impl,
ServiceContext.getInstance().getService(ConfigurationContext.class).get()
should be done in the constructor IMO and not be contextual which
often leads to some issues at runtime - basically it would be possible
to leak configuration.
Also the usage of PropertyFilter doesnt fully work, a single loop is
not enough since a filter can return a filterable value so it should
basically be a:
String old = null;
do {
old = unfilteredValue;
for(PropertyFilter filter:
ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
unfilteredValue = filter.filterProperty(key, unfilteredValue,
(String k) -> key.equals(k)?null:get(k).orElse(null));
}
} while (old != null && unfilteredValue != null &&
!old.equals(unfilteredValue));
or sthg like that.
wdyt?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
Re: DefaultConfiguration
Posted by Anatole Tresch <at...@gmail.com>.
Hi Romain
1) which constructor you mean? IMO it must exactly be that way. The
ConfigurationContext will be contextual, e.g. when Tamaya runs in the
container, installed on the system CP, you will have a context at least for
each application.
2) Filtering is a one pass through. If a filter produces a value that must
be resolved, the resolving filter should come after. Thats it.
More would lead to even more issues. E.g. a filter is able to recognize
that a value was removed by a former filter and then can
decide to readd it, which easily will end up in a endless loop. The
current solution can handle your scenario (just put the resolving filter
later, or add it a second time later). Its similar to the property sources
and the only way to have a clear and decent behaviour here IMO...
Cheers,
Anatole
2015-01-05 8:36 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Hi guys,
>
> if we keep current impl,
> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
> should be done in the constructor IMO and not be contextual which
> often leads to some issues at runtime - basically it would be possible
> to leak configuration.
>
> Also the usage of PropertyFilter doesnt fully work, a single loop is
> not enough since a filter can return a filterable value so it should
> basically be a:
>
> String old = null;
> do {
> old = unfilteredValue;
> for(PropertyFilter filter:
>
> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
> unfilteredValue = filter.filterProperty(key, unfilteredValue,
> (String k) -> key.equals(k)?null:get(k).orElse(null));
> }
>
> } while (old != null && unfilteredValue != null &&
> !old.equals(unfilteredValue));
>
>
> or sthg like that.
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: DefaultConfiguration
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
Configuration can easily store "it's" ConfigurationContext. This is defined as 1:1 and if you remember our discussion then we really only did split this to have a better separation between userland and core.
As far as the @RequestScoped sample goes: each request will get a new instance anyway. Thus the Configuration will always fit to the current Request. No need to internally 'proxy' again.
LieGrue,
strub
> On Monday, 5 January 2015, 16:32, "Tresch, Anatole" <an...@credit-suisse.com> wrote:
> > See inline again...
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Montag, 5. Januar 2015 10:05
> To: dev@tamaya.incubator.apache.org
> Subject: Re: DefaultConfiguration
>
> inline as well
>
> 2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> @Romain inline
>>
>> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> @Anatole:
>>> 1) this is what does few specs but it has some important drawbacks:
>>> - it slows down resolution for nothing IMO
>>>
>> Not an issue, you don't read config a thousand time. It's basically
> only
>> one HashMap access.
>>
>
> It is for sure cause some config will be used in "request scoped"
> beans - or we say it is a bad practise and then we impose some weird
> patterns.
> -> I am fine with that for the current core, we can make a hard dependency to
> ConfigurationContext loaded once. We still can replace the Configuration
> implementation with something different in other contexts, if needed.
>
>>
>>
>>> - it makes configuration no more aggregated, ie depending your context
>>> you get a different configuration which basically lead to using a
>>> config you dont know which is very wrong IMO
>>>
>> Not fully true. You still can have in a EE container a system
>> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
>> can contain a PropertySource that is able to provide the system values as
>> well. So still everything is aggregated. Mixing configs between apps on the
>> same container is a very bad idea (imagine class references that are not
>> visible in the other app for example).
>>
>
> Well this depends your environment and I confirm what I said. Suppose
> you write a "container" - whatever it is EE or not - library,
> you'll
> read config from "container" then you'll surely be executed in the
> app. You don't always want to inherit from the app config at runtime
> (ie after bootstrap) so you clearly need to resolve the config when
> created then just rely on what you have or programmatic API. But you
> should clearly avoid to allow to switch later implicitely - what does
> current impl.
> -> Yes agreed, would be a good way to get Configuration reference that
> is well connected to its context, makes sense!
>
>>> - it breaks the fact ServiceLoader should be called once in
>>> org.apache.tamaya.spi.ServiceContext - or it breaks the
> "standard"
>>> contract since caching if then mandatory - which can be broken in
>>> several environments
>>>
>> ServiceLoader is called once in SE. In EE it is different, since you have
>> different classloaders in place. Nothing bad about that, just reality.
>>
>
> * Once by Configuration instance I meant.
> This is true depending your ServiceContext impl which should itself
> just be a ServiceLoader call and not a cache of ServiceLoader in term
> of design IMO. Caching should be applied in Configuration if needed as
> an aggregator of services.
> -> Agreed. I planned to add the caching functionality to Configuration later
> when we have sorted out how changed are pushed to the system.
> I plan to do a follow up on this topic soon.
>
>
>> 2) it is true the main use case I have to loop are the passwords but
>>> for them it is super nice and almost mandatory if we want to have
>>> reusable filters
>> Sorry, I dont get that (language issue), can you try again...?
>
> If you take my password example. If I want to be sure to make it work
> I'll just dont use the filter chain anymore but rely on a custom impl
> calling filters I *know* I use directly - hardcoded. This means
> filters can't be reused automatically and you can't let the
> "configuration guy" choose chat he does. I don't ask an EL but
> just a
> prefixing/keyword support to be able to relaunch the chain of filters
> if you know you have a not yet resolved value.
>
> -> Sorry, I still don’t get your case. you want to reuse a filter...
> filtering the same? Why it is not reusable? You can directly apply a filter also
> by passing a PropertyConverter ? Perhaps somebody else can help me to
> understand, what Romain means, I still don’t get it, sorry ;)
>
Re: DefaultConfiguration
Posted by Romain Manni-Bucau <rm...@gmail.com>.
was more or less what i suggested so +1.
This is weird - fully agree - but saw it each time a configuration was
becoming legacy (speaking about key/values, not technologies). This
really helps to make it smooth. Often it needs 3 resolutions no more.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-05 16:58 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
> Ok, NOW I GET IT ;)
>
> For me your case looks very weird. I have never seen something like that.
>
> Basically I would say you would have some options with the current architecture:
>
> 1) Register the according filters twice (for N >=2), with different priorities - bad.
> 2) Combine your filtering logic into one filter that internally is able to do the cycle - better, but still a workaround.
>
> But basically we can implement the behavior relatively easily, by counting the entries we have resolved/changed during a filter loop.
> As long as we have values filtered(changed), we will perform the filtering again. Additionally I would add a maximum number of filter loops to be done, after
> which I would abort the filtering and return the final value, just to be sure, we do not run into an endless loop.
>
> WDYT? OK to do so?
>
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Montag, 5. Januar 2015 16:39
> To: dev@tamaya.incubator.apache.org
> Subject: Re: DefaultConfiguration
>
> if my default is "datasource-password:pwd1" then I have a filter
> datasource-password which will return "decrypt:cryptedBar" to reuse
> filter "decrypt". This will only works is both filters are ordered
> correctly. Issue is then decrypt filter can return another
> datasource-password:pwd1 and here it is too late but it is a simple
> need and relatively common when you start to have vN N>1.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-05 16:31 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
>> See inline again...
>>
>> -----Original Message-----
>> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Sent: Montag, 5. Januar 2015 10:05
>> To: dev@tamaya.incubator.apache.org
>> Subject: Re: DefaultConfiguration
>>
>> inline as well
>>
>> 2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>>> @Romain inline
>>>
>>> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>>
>>>> @Anatole:
>>>> 1) this is what does few specs but it has some important drawbacks:
>>>> - it slows down resolution for nothing IMO
>>>>
>>> Not an issue, you don't read config a thousand time. It's basically only
>>> one HashMap access.
>>>
>>
>> It is for sure cause some config will be used in "request scoped"
>> beans - or we say it is a bad practise and then we impose some weird
>> patterns.
>> -> I am fine with that for the current core, we can make a hard dependency to ConfigurationContext loaded once. We still can replace the Configuration implementation with something different in other contexts, if needed.
>>
>>>
>>>
>>>> - it makes configuration no more aggregated, ie depending your context
>>>> you get a different configuration which basically lead to using a
>>>> config you dont know which is very wrong IMO
>>>>
>>> Not fully true. You still can have in a EE container a system
>>> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
>>> can contain a PropertySource that is able to provide the system values as
>>> well. So still everything is aggregated. Mixing configs between apps on the
>>> same container is a very bad idea (imagine class references that are not
>>> visible in the other app for example).
>>>
>>
>> Well this depends your environment and I confirm what I said. Suppose
>> you write a "container" - whatever it is EE or not - library, you'll
>> read config from "container" then you'll surely be executed in the
>> app. You don't always want to inherit from the app config at runtime
>> (ie after bootstrap) so you clearly need to resolve the config when
>> created then just rely on what you have or programmatic API. But you
>> should clearly avoid to allow to switch later implicitely - what does
>> current impl.
>> -> Yes agreed, would be a good way to get Configuration reference that
>> is well connected to its context, makes sense!
>>
>>>> - it breaks the fact ServiceLoader should be called once in
>>>> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
>>>> contract since caching if then mandatory - which can be broken in
>>>> several environments
>>>>
>>> ServiceLoader is called once in SE. In EE it is different, since you have
>>> different classloaders in place. Nothing bad about that, just reality.
>>>
>>
>> * Once by Configuration instance I meant.
>> This is true depending your ServiceContext impl which should itself
>> just be a ServiceLoader call and not a cache of ServiceLoader in term
>> of design IMO. Caching should be applied in Configuration if needed as
>> an aggregator of services.
>> -> Agreed. I planned to add the caching functionality to Configuration later when we have sorted out how changed are pushed to the system.
>> I plan to do a follow up on this topic soon.
>>
>>> 2) it is true the main use case I have to loop are the passwords but
>>>> for them it is super nice and almost mandatory if we want to have
>>>> reusable filters
>>> Sorry, I dont get that (language issue), can you try again...?
>>
>> If you take my password example. If I want to be sure to make it work
>> I'll just dont use the filter chain anymore but rely on a custom impl
>> calling filters I *know* I use directly - hardcoded. This means
>> filters can't be reused automatically and you can't let the
>> "configuration guy" choose chat he does. I don't ask an EL but just a
>> prefixing/keyword support to be able to relaunch the chain of filters
>> if you know you have a not yet resolved value.
>>
>> -> Sorry, I still don’t get your case. you want to reuse a filter... filtering the same? Why it is not reusable? You can directly apply a filter also by passing a PropertyConverter ? Perhaps somebody else can help me to understand, what Romain means, I still don’t get it, sorry ;)
>>
RE: DefaultConfiguration
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
Ok, NOW I GET IT ;)
For me your case looks very weird. I have never seen something like that.
Basically I would say you would have some options with the current architecture:
1) Register the according filters twice (for N >=2), with different priorities - bad.
2) Combine your filtering logic into one filter that internally is able to do the cycle - better, but still a workaround.
But basically we can implement the behavior relatively easily, by counting the entries we have resolved/changed during a filter loop.
As long as we have values filtered(changed), we will perform the filtering again. Additionally I would add a maximum number of filter loops to be done, after
which I would abort the filtering and return the final value, just to be sure, we do not run into an endless loop.
WDYT? OK to do so?
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: Montag, 5. Januar 2015 16:39
To: dev@tamaya.incubator.apache.org
Subject: Re: DefaultConfiguration
if my default is "datasource-password:pwd1" then I have a filter
datasource-password which will return "decrypt:cryptedBar" to reuse
filter "decrypt". This will only works is both filters are ordered
correctly. Issue is then decrypt filter can return another
datasource-password:pwd1 and here it is too late but it is a simple
need and relatively common when you start to have vN N>1.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-05 16:31 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
> See inline again...
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Montag, 5. Januar 2015 10:05
> To: dev@tamaya.incubator.apache.org
> Subject: Re: DefaultConfiguration
>
> inline as well
>
> 2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> @Romain inline
>>
>> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> @Anatole:
>>> 1) this is what does few specs but it has some important drawbacks:
>>> - it slows down resolution for nothing IMO
>>>
>> Not an issue, you don't read config a thousand time. It's basically only
>> one HashMap access.
>>
>
> It is for sure cause some config will be used in "request scoped"
> beans - or we say it is a bad practise and then we impose some weird
> patterns.
> -> I am fine with that for the current core, we can make a hard dependency to ConfigurationContext loaded once. We still can replace the Configuration implementation with something different in other contexts, if needed.
>
>>
>>
>>> - it makes configuration no more aggregated, ie depending your context
>>> you get a different configuration which basically lead to using a
>>> config you dont know which is very wrong IMO
>>>
>> Not fully true. You still can have in a EE container a system
>> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
>> can contain a PropertySource that is able to provide the system values as
>> well. So still everything is aggregated. Mixing configs between apps on the
>> same container is a very bad idea (imagine class references that are not
>> visible in the other app for example).
>>
>
> Well this depends your environment and I confirm what I said. Suppose
> you write a "container" - whatever it is EE or not - library, you'll
> read config from "container" then you'll surely be executed in the
> app. You don't always want to inherit from the app config at runtime
> (ie after bootstrap) so you clearly need to resolve the config when
> created then just rely on what you have or programmatic API. But you
> should clearly avoid to allow to switch later implicitely - what does
> current impl.
> -> Yes agreed, would be a good way to get Configuration reference that
> is well connected to its context, makes sense!
>
>>> - it breaks the fact ServiceLoader should be called once in
>>> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
>>> contract since caching if then mandatory - which can be broken in
>>> several environments
>>>
>> ServiceLoader is called once in SE. In EE it is different, since you have
>> different classloaders in place. Nothing bad about that, just reality.
>>
>
> * Once by Configuration instance I meant.
> This is true depending your ServiceContext impl which should itself
> just be a ServiceLoader call and not a cache of ServiceLoader in term
> of design IMO. Caching should be applied in Configuration if needed as
> an aggregator of services.
> -> Agreed. I planned to add the caching functionality to Configuration later when we have sorted out how changed are pushed to the system.
> I plan to do a follow up on this topic soon.
>
>> 2) it is true the main use case I have to loop are the passwords but
>>> for them it is super nice and almost mandatory if we want to have
>>> reusable filters
>> Sorry, I dont get that (language issue), can you try again...?
>
> If you take my password example. If I want to be sure to make it work
> I'll just dont use the filter chain anymore but rely on a custom impl
> calling filters I *know* I use directly - hardcoded. This means
> filters can't be reused automatically and you can't let the
> "configuration guy" choose chat he does. I don't ask an EL but just a
> prefixing/keyword support to be able to relaunch the chain of filters
> if you know you have a not yet resolved value.
>
> -> Sorry, I still don’t get your case. you want to reuse a filter... filtering the same? Why it is not reusable? You can directly apply a filter also by passing a PropertyConverter ? Perhaps somebody else can help me to understand, what Romain means, I still don’t get it, sorry ;)
>
Re: DefaultConfiguration
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if my default is "datasource-password:pwd1" then I have a filter
datasource-password which will return "decrypt:cryptedBar" to reuse
filter "decrypt". This will only works is both filters are ordered
correctly. Issue is then decrypt filter can return another
datasource-password:pwd1 and here it is too late but it is a simple
need and relatively common when you start to have vN N>1.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-05 16:31 GMT+01:00 Tresch, Anatole <an...@credit-suisse.com>:
> See inline again...
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Sent: Montag, 5. Januar 2015 10:05
> To: dev@tamaya.incubator.apache.org
> Subject: Re: DefaultConfiguration
>
> inline as well
>
> 2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
>> @Romain inline
>>
>> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> @Anatole:
>>> 1) this is what does few specs but it has some important drawbacks:
>>> - it slows down resolution for nothing IMO
>>>
>> Not an issue, you don't read config a thousand time. It's basically only
>> one HashMap access.
>>
>
> It is for sure cause some config will be used in "request scoped"
> beans - or we say it is a bad practise and then we impose some weird
> patterns.
> -> I am fine with that for the current core, we can make a hard dependency to ConfigurationContext loaded once. We still can replace the Configuration implementation with something different in other contexts, if needed.
>
>>
>>
>>> - it makes configuration no more aggregated, ie depending your context
>>> you get a different configuration which basically lead to using a
>>> config you dont know which is very wrong IMO
>>>
>> Not fully true. You still can have in a EE container a system
>> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
>> can contain a PropertySource that is able to provide the system values as
>> well. So still everything is aggregated. Mixing configs between apps on the
>> same container is a very bad idea (imagine class references that are not
>> visible in the other app for example).
>>
>
> Well this depends your environment and I confirm what I said. Suppose
> you write a "container" - whatever it is EE or not - library, you'll
> read config from "container" then you'll surely be executed in the
> app. You don't always want to inherit from the app config at runtime
> (ie after bootstrap) so you clearly need to resolve the config when
> created then just rely on what you have or programmatic API. But you
> should clearly avoid to allow to switch later implicitely - what does
> current impl.
> -> Yes agreed, would be a good way to get Configuration reference that
> is well connected to its context, makes sense!
>
>>> - it breaks the fact ServiceLoader should be called once in
>>> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
>>> contract since caching if then mandatory - which can be broken in
>>> several environments
>>>
>> ServiceLoader is called once in SE. In EE it is different, since you have
>> different classloaders in place. Nothing bad about that, just reality.
>>
>
> * Once by Configuration instance I meant.
> This is true depending your ServiceContext impl which should itself
> just be a ServiceLoader call and not a cache of ServiceLoader in term
> of design IMO. Caching should be applied in Configuration if needed as
> an aggregator of services.
> -> Agreed. I planned to add the caching functionality to Configuration later when we have sorted out how changed are pushed to the system.
> I plan to do a follow up on this topic soon.
>
>> 2) it is true the main use case I have to loop are the passwords but
>>> for them it is super nice and almost mandatory if we want to have
>>> reusable filters
>> Sorry, I dont get that (language issue), can you try again...?
>
> If you take my password example. If I want to be sure to make it work
> I'll just dont use the filter chain anymore but rely on a custom impl
> calling filters I *know* I use directly - hardcoded. This means
> filters can't be reused automatically and you can't let the
> "configuration guy" choose chat he does. I don't ask an EL but just a
> prefixing/keyword support to be able to relaunch the chain of filters
> if you know you have a not yet resolved value.
>
> -> Sorry, I still don’t get your case. you want to reuse a filter... filtering the same? Why it is not reusable? You can directly apply a filter also by passing a PropertyConverter ? Perhaps somebody else can help me to understand, what Romain means, I still don’t get it, sorry ;)
>
RE: DefaultConfiguration
Posted by "Tresch, Anatole " <an...@credit-suisse.com>.
See inline again...
-----Original Message-----
From: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Sent: Montag, 5. Januar 2015 10:05
To: dev@tamaya.incubator.apache.org
Subject: Re: DefaultConfiguration
inline as well
2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> @Romain inline
>
> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> @Anatole:
>> 1) this is what does few specs but it has some important drawbacks:
>> - it slows down resolution for nothing IMO
>>
> Not an issue, you don't read config a thousand time. It's basically only
> one HashMap access.
>
It is for sure cause some config will be used in "request scoped"
beans - or we say it is a bad practise and then we impose some weird
patterns.
-> I am fine with that for the current core, we can make a hard dependency to ConfigurationContext loaded once. We still can replace the Configuration implementation with something different in other contexts, if needed.
>
>
>> - it makes configuration no more aggregated, ie depending your context
>> you get a different configuration which basically lead to using a
>> config you dont know which is very wrong IMO
>>
> Not fully true. You still can have in a EE container a system
> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
> can contain a PropertySource that is able to provide the system values as
> well. So still everything is aggregated. Mixing configs between apps on the
> same container is a very bad idea (imagine class references that are not
> visible in the other app for example).
>
Well this depends your environment and I confirm what I said. Suppose
you write a "container" - whatever it is EE or not - library, you'll
read config from "container" then you'll surely be executed in the
app. You don't always want to inherit from the app config at runtime
(ie after bootstrap) so you clearly need to resolve the config when
created then just rely on what you have or programmatic API. But you
should clearly avoid to allow to switch later implicitely - what does
current impl.
-> Yes agreed, would be a good way to get Configuration reference that
is well connected to its context, makes sense!
>> - it breaks the fact ServiceLoader should be called once in
>> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
>> contract since caching if then mandatory - which can be broken in
>> several environments
>>
> ServiceLoader is called once in SE. In EE it is different, since you have
> different classloaders in place. Nothing bad about that, just reality.
>
* Once by Configuration instance I meant.
This is true depending your ServiceContext impl which should itself
just be a ServiceLoader call and not a cache of ServiceLoader in term
of design IMO. Caching should be applied in Configuration if needed as
an aggregator of services.
-> Agreed. I planned to add the caching functionality to Configuration later when we have sorted out how changed are pushed to the system.
I plan to do a follow up on this topic soon.
> 2) it is true the main use case I have to loop are the passwords but
>> for them it is super nice and almost mandatory if we want to have
>> reusable filters
> Sorry, I dont get that (language issue), can you try again...?
If you take my password example. If I want to be sure to make it work
I'll just dont use the filter chain anymore but rely on a custom impl
calling filters I *know* I use directly - hardcoded. This means
filters can't be reused automatically and you can't let the
"configuration guy" choose chat he does. I don't ask an EL but just a
prefixing/keyword support to be able to relaunch the chain of filters
if you know you have a not yet resolved value.
-> Sorry, I still don’t get your case. you want to reuse a filter... filtering the same? Why it is not reusable? You can directly apply a filter also by passing a PropertyConverter ? Perhaps somebody else can help me to understand, what Romain means, I still don’t get it, sorry ;)
Re: DefaultConfiguration
Posted by Romain Manni-Bucau <rm...@gmail.com>.
inline as well
2015-01-05 9:54 GMT+01:00 Anatole Tresch <at...@gmail.com>:
> @Romain inline
>
> 2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
>> @Anatole:
>> 1) this is what does few specs but it has some important drawbacks:
>> - it slows down resolution for nothing IMO
>>
> Not an issue, you don't read config a thousand time. It's basically only
> one HashMap access.
>
It is for sure cause some config will be used in "request scoped"
beans - or we say it is a bad practise and then we impose some weird
patterns.
>
>
>> - it makes configuration no more aggregated, ie depending your context
>> you get a different configuration which basically lead to using a
>> config you dont know which is very wrong IMO
>>
> Not fully true. You still can have in a EE container a system
> ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
> can contain a PropertySource that is able to provide the system values as
> well. So still everything is aggregated. Mixing configs between apps on the
> same container is a very bad idea (imagine class references that are not
> visible in the other app for example).
>
Well this depends your environment and I confirm what I said. Suppose
you write a "container" - whatever it is EE or not - library, you'll
read config from "container" then you'll surely be executed in the
app. You don't always want to inherit from the app config at runtime
(ie after bootstrap) so you clearly need to resolve the config when
created then just rely on what you have or programmatic API. But you
should clearly avoid to allow to switch later implicitely - what does
current impl.
>
>
>> - it breaks the fact ServiceLoader should be called once in
>> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
>> contract since caching if then mandatory - which can be broken in
>> several environments
>>
> ServiceLoader is called once in SE. In EE it is different, since you have
> different classloaders in place. Nothing bad about that, just reality.
>
* Once by Configuration instance I meant.
This is true depending your ServiceContext impl which should itself
just be a ServiceLoader call and not a cache of ServiceLoader in term
of design IMO. Caching should be applied in Configuration if needed as
an aggregator of services.
> 2) it is true the main use case I have to loop are the passwords but
>> for them it is super nice and almost mandatory if we want to have
>> reusable filters
>>
>
> Sorry, I dont get that (language issue), can you try again...?
>
If you take my password example. If I want to be sure to make it work
I'll just dont use the filter chain anymore but rely on a custom impl
calling filters I *know* I use directly - hardcoded. This means
filters can't be reused automatically and you can't let the
"configuration guy" choose chat he does. I don't ask an EL but just a
prefixing/keyword support to be able to relaunch the chain of filters
if you know you have a not yet resolved value.
>
>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2015-01-05 9:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>> > yes and no, the loop I proposed is easy and allows nice things like
>> > this loop - suppose I implement filters using a prefix:
>> >
>> > super.database.pwd, default = databases:super.pwd --no value-->
>> > database:super.pwd --filter databse--> decrypt:97548739JVD --decrypt
>> > filter--> T@m@ya (the password ;))
>> >
>> > Said otherwise it allows to build values based on other configuration
>> values.
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau
>> > http://www.tomitribe.com
>> > http://rmannibucau.wordpress.com
>> > https://github.com/rmannibucau
>> >
>> >
>> > 2015-01-05 9:32 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> >> the filtering question depends on what we like to do with the Filter.
>> Initially it was only meant to be a straight forward filter. For variable
>> expression evaluation (which is actually not really 'filtering' we would
>> need something like AST to fully work. All other resolutions would not
>> fully work imo. And having a full AST would rather lead us to EL. That's
>> way out of reach imo.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> On Monday, 5 January 2015, 8:37, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>> >>> > Hi guys,
>> >>>
>> >>> if we keep current impl,
>> >>>
>> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
>> >>> should be done in the constructor IMO and not be contextual which
>> >>> often leads to some issues at runtime - basically it would be possible
>> >>> to leak configuration.
>> >>>
>> >>> Also the usage of PropertyFilter doesnt fully work, a single loop is
>> >>> not enough since a filter can return a filterable value so it should
>> >>> basically be a:
>> >>>
>> >>> String old = null;
>> >>> do {
>> >>> old = unfilteredValue;
>> >>> for(PropertyFilter filter:
>> >>>
>> >>>
>> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
>> >>> unfilteredValue = filter.filterProperty(key, unfilteredValue,
>> >>> (String k) -> key.equals(k)?null:get(k).orElse(null));
>> >>> }
>> >>>
>> >>> } while (old != null && unfilteredValue != null &&
>> >>> !old.equals(unfilteredValue));
>> >>>
>> >>>
>> >>> or sthg like that.
>> >>>
>> >>> wdyt?
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau
>> >>> http://www.tomitribe.com
>> >>> http://rmannibucau.wordpress.com
>> >>> https://github.com/rmannibucau
>> >>>
>>
>
>
>
> --
> *Anatole Tresch*
> Java Engineer & Architect, JSR Spec Lead
> Glärnischweg 10
> CH - 8620 Wetzikon
>
> *Switzerland, Europe Zurich, GMT+1*
> *Twitter: @atsticks*
> *Blogs: **http://javaremarkables.blogspot.ch/
> <http://javaremarkables.blogspot.ch/>*
>
> *Google: atsticksMobile +41-76 344 62 79*
Re: DefaultConfiguration
Posted by Anatole Tresch <at...@gmail.com>.
@Romain inline
2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> @Anatole:
> 1) this is what does few specs but it has some important drawbacks:
> - it slows down resolution for nothing IMO
>
Not an issue, you don't read config a thousand time. It's basically only
one HashMap access.
> - it makes configuration no more aggregated, ie depending your context
> you get a different configuration which basically lead to using a
> config you dont know which is very wrong IMO
>
Not fully true. You still can have in a EE container a system
ConfigContext and one ConfigContext for each app/ear. The ear ConfigContext
can contain a PropertySource that is able to provide the system values as
well. So still everything is aggregated. Mixing configs between apps on the
same container is a very bad idea (imagine class references that are not
visible in the other app for example).
> - it breaks the fact ServiceLoader should be called once in
> org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
> contract since caching if then mandatory - which can be broken in
> several environments
>
ServiceLoader is called once in SE. In EE it is different, since you have
different classloaders in place. Nothing bad about that, just reality.
2) it is true the main use case I have to loop are the passwords but
> for them it is super nice and almost mandatory if we want to have
> reusable filters
>
Sorry, I dont get that (language issue), can you try again...?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-05 9:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> > yes and no, the loop I proposed is easy and allows nice things like
> > this loop - suppose I implement filters using a prefix:
> >
> > super.database.pwd, default = databases:super.pwd --no value-->
> > database:super.pwd --filter databse--> decrypt:97548739JVD --decrypt
> > filter--> T@m@ya (the password ;))
> >
> > Said otherwise it allows to build values based on other configuration
> values.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2015-01-05 9:32 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> >> the filtering question depends on what we like to do with the Filter.
> Initially it was only meant to be a straight forward filter. For variable
> expression evaluation (which is actually not really 'filtering' we would
> need something like AST to fully work. All other resolutions would not
> fully work imo. And having a full AST would rather lead us to EL. That's
> way out of reach imo.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Monday, 5 January 2015, 8:37, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> >>> > Hi guys,
> >>>
> >>> if we keep current impl,
> >>>
> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
> >>> should be done in the constructor IMO and not be contextual which
> >>> often leads to some issues at runtime - basically it would be possible
> >>> to leak configuration.
> >>>
> >>> Also the usage of PropertyFilter doesnt fully work, a single loop is
> >>> not enough since a filter can return a filterable value so it should
> >>> basically be a:
> >>>
> >>> String old = null;
> >>> do {
> >>> old = unfilteredValue;
> >>> for(PropertyFilter filter:
> >>>
> >>>
> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
> >>> unfilteredValue = filter.filterProperty(key, unfilteredValue,
> >>> (String k) -> key.equals(k)?null:get(k).orElse(null));
> >>> }
> >>>
> >>> } while (old != null && unfilteredValue != null &&
> >>> !old.equals(unfilteredValue));
> >>>
> >>>
> >>> or sthg like that.
> >>>
> >>> wdyt?
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
Re: DefaultConfiguration
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Anatole:
1) this is what does few specs but it has some important drawbacks:
- it slows down resolution for nothing IMO
- it makes configuration no more aggregated, ie depending your context
you get a different configuration which basically lead to using a
config you dont know which is very wrong IMO
- it breaks the fact ServiceLoader should be called once in
org.apache.tamaya.spi.ServiceContext - or it breaks the "standard"
contract since caching if then mandatory - which can be broken in
several environments
2) it is true the main use case I have to loop are the passwords but
for them it is super nice and almost mandatory if we want to have
reusable filters
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-05 9:38 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> yes and no, the loop I proposed is easy and allows nice things like
> this loop - suppose I implement filters using a prefix:
>
> super.database.pwd, default = databases:super.pwd --no value-->
> database:super.pwd --filter databse--> decrypt:97548739JVD --decrypt
> filter--> T@m@ya (the password ;))
>
> Said otherwise it allows to build values based on other configuration values.
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-05 9:32 GMT+01:00 Mark Struberg <st...@yahoo.de>:
>> the filtering question depends on what we like to do with the Filter. Initially it was only meant to be a straight forward filter. For variable expression evaluation (which is actually not really 'filtering' we would need something like AST to fully work. All other resolutions would not fully work imo. And having a full AST would rather lead us to EL. That's way out of reach imo.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>
>>> On Monday, 5 January 2015, 8:37, Romain Manni-Bucau <rm...@gmail.com> wrote:
>>> > Hi guys,
>>>
>>> if we keep current impl,
>>> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
>>> should be done in the constructor IMO and not be contextual which
>>> often leads to some issues at runtime - basically it would be possible
>>> to leak configuration.
>>>
>>> Also the usage of PropertyFilter doesnt fully work, a single loop is
>>> not enough since a filter can return a filterable value so it should
>>> basically be a:
>>>
>>> String old = null;
>>> do {
>>> old = unfilteredValue;
>>> for(PropertyFilter filter:
>>>
>>> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
>>> unfilteredValue = filter.filterProperty(key, unfilteredValue,
>>> (String k) -> key.equals(k)?null:get(k).orElse(null));
>>> }
>>>
>>> } while (old != null && unfilteredValue != null &&
>>> !old.equals(unfilteredValue));
>>>
>>>
>>> or sthg like that.
>>>
>>> wdyt?
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
Re: DefaultConfiguration
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes and no, the loop I proposed is easy and allows nice things like
this loop - suppose I implement filters using a prefix:
super.database.pwd, default = databases:super.pwd --no value-->
database:super.pwd --filter databse--> decrypt:97548739JVD --decrypt
filter--> T@m@ya (the password ;))
Said otherwise it allows to build values based on other configuration values.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-05 9:32 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> the filtering question depends on what we like to do with the Filter. Initially it was only meant to be a straight forward filter. For variable expression evaluation (which is actually not really 'filtering' we would need something like AST to fully work. All other resolutions would not fully work imo. And having a full AST would rather lead us to EL. That's way out of reach imo.
>
> LieGrue,
> strub
>
>
>
>
>
>
>> On Monday, 5 January 2015, 8:37, Romain Manni-Bucau <rm...@gmail.com> wrote:
>> > Hi guys,
>>
>> if we keep current impl,
>> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
>> should be done in the constructor IMO and not be contextual which
>> often leads to some issues at runtime - basically it would be possible
>> to leak configuration.
>>
>> Also the usage of PropertyFilter doesnt fully work, a single loop is
>> not enough since a filter can return a filterable value so it should
>> basically be a:
>>
>> String old = null;
>> do {
>> old = unfilteredValue;
>> for(PropertyFilter filter:
>>
>> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
>> unfilteredValue = filter.filterProperty(key, unfilteredValue,
>> (String k) -> key.equals(k)?null:get(k).orElse(null));
>> }
>>
>> } while (old != null && unfilteredValue != null &&
>> !old.equals(unfilteredValue));
>>
>>
>> or sthg like that.
>>
>> wdyt?
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
Re: DefaultConfiguration
Posted by Mark Struberg <st...@yahoo.de>.
the filtering question depends on what we like to do with the Filter. Initially it was only meant to be a straight forward filter. For variable expression evaluation (which is actually not really 'filtering' we would need something like AST to fully work. All other resolutions would not fully work imo. And having a full AST would rather lead us to EL. That's way out of reach imo.
LieGrue,
strub
> On Monday, 5 January 2015, 8:37, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > Hi guys,
>
> if we keep current impl,
> ServiceContext.getInstance().getService(ConfigurationContext.class).get()
> should be done in the constructor IMO and not be contextual which
> often leads to some issues at runtime - basically it would be possible
> to leak configuration.
>
> Also the usage of PropertyFilter doesnt fully work, a single loop is
> not enough since a filter can return a filterable value so it should
> basically be a:
>
> String old = null;
> do {
> old = unfilteredValue;
> for(PropertyFilter filter:
>
> ServiceContext.getInstance().getService(ConfigurationContext.class).get().getPropertyFilters()){
> unfilteredValue = filter.filterProperty(key, unfilteredValue,
> (String k) -> key.equals(k)?null:get(k).orElse(null));
> }
>
> } while (old != null && unfilteredValue != null &&
> !old.equals(unfilteredValue));
>
>
> or sthg like that.
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>