@Romain inline

2015-01-05 9:44 GMT+01:00 Romain Manni-Bucau <[email protected]>:

> @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 <[email protected]>:
> > 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 <[email protected]>:
> >> 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 <
> [email protected]> 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*

Reply via email to