Yes, the other point is that it is also much more expensive.
Consider that a user calls Configuration.get("mykey");
In that case we just call getKey starting with the highest PropertySource until
we find. This value will then get handed over to the filter chain. Most filters
will not need any additional info.
If we would require to have the full Map prepared then we would need to merge
ALL keys and not only the one which you are interested in. Depending on how the
ConfigSource is implemented this could be pretty expensive.
LieGrue,
strub
> On Tuesday, 6 January 2015, 17:25, Romain Manni-Bucau <[email protected]>
> wrote:
> >T he design you used is quite common if you completely build the
> configuration underlying map at startup and dont have yet the
> configuration instance which is not exactly our case. That said when I
> asked about lifecycle it was exactly for it, it is quite common to
> throw IllegalStateException when that's the case - but since we
> evaluate lazily values with filters it should be fine.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-06 17:20 GMT+01:00 Anatole Tresch <[email protected]>:
>> So finally, removing the function/map worked OOTB. I don't know why I
>> originally struggled with it. Perhaps it was simply too late in the night
>> and my brown was not working as fine as earlier... I will checkin the
>> changes. We now only have one simple method:
>>
>> String filterProperty(String key, String valueToBeFiltered);
>>
>> 2015-01-06 17:11 GMT+01:00 Anatole Tresch <[email protected]>:
>>
>>> Hi Mark
>>>
>>> For me it is completely OK, thath keys of non scannable resources are
> not
>>> included, Basically that is the nature of non scannable ones...
>>> For removing the map mathematically your proposal is running. But is it
>>> really simpler? On API side yes, but on implementation side as well?
>>> Nevertheless I will give it a try and come back to you, if I see any
> issues
>>> not considered so far...
>>>
>>> Cheers,
>>> Anatole
>>>
>>>
>>> 2015-01-06 16:23 GMT+01:00 Mark Struberg <[email protected]>:
>>>
>>>> The Map<String,String> is only available for scannable
> PropertySources.
>>>> E.g. you cannot portably enlist the values of a JNDI location for
> example.
>>>>
>>>>
>>>> What I mean is the following. If you do a Configuration.current()
> in your
>>>> PropertyFilter then you can get those metadata entries very easily
> with
>>>> Configuration.get(currentConfigKey + ".metadata.cipher")
> for example. Of
>>>> course you only have your filter doing something if the key
> doesn't yet
>>>> contain ".metadata." to prevent ending up with an endless
> loop.
>>>>
>>>> Got me?
>>>>
>>>> The point is there is a.) an easy and more powerful workaround and
> b.)
>>>> not all Filters will need this.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > On Tuesday, 6 January 2015, 16:08, Anatole Tresch
> <[email protected]>
>>>> wrote:
>>>> > > BTW you always have "functions" to access a
> datastructure. With a Map
>>>> > you
>>>> > have severals, whereas with Function<String,String> you
> only have one...
>>>> > but I dont want to start a discussions on the mathematical
> fundations...
>>>> >
>>>> > 2015-01-06 15:37 GMT+01:00 Romain Manni-Bucau
> <[email protected]>:
>>>> >
>>>> >> I got your case and I have the same but your solution is
> not user
>>>> >> friendly and you only need to access currently built
> configuration
>>>> >> (Map), why abstracting a Map by a function? I mean your
> contract is
>>>> >> just a data structure access and not a behavior as you
> explained it so
>>>> >> Function is wrong.
>>>> >>
>>>> >>
>>>> >> Romain Manni-Bucau
>>>> >> @rmannibucau
>>>> >> http://www.tomitribe.com
>>>> >> http://rmannibucau.wordpress.com
>>>> >> https://github.com/rmannibucau
>>>> >>
>>>> >>
>>>> >> 2015-01-06 15:29 GMT+01:00 Anatole Tresch
> <[email protected]>:
>>>> >> > Hi Romain
>>>> >> >
>>>> >> > please reread my last mail. Accessing Configuration
> reentrantly will
>>>> > not
>>>> >> > work, since you will have to apply the filters
> before returning asny
>>>> >> > result. Also you will not want to look at the
> filtered but at the
>>>> >> original
>>>> >> > values...
>>>> >> > Using a function is nothing else than applying the
> recommendations
>>>> > from
>>>> >> > Oracle to use prebuilt function before defining your
> own.
>>>> >> >
>>>> >> > According metadata: I did not mention it explicitly,
> but
>>>> >> >
>>>> >> > - it is a absolutely required core feature for
> all companies in
>>>> the
>>>> >> > finance industry, especially banks.
>>>> >> > - it is quite for sure important also for others.
>>>> >> > - it is not built in in the core (we have
> explicitly removed it),
>>>> > but
>>>> >> is
>>>> >> > modellabe by additional properties:
>>>> >> >
>>>> >> > E.g. a value
>>>> >> >
>>>> >> > a.b.dbPassword=hd8z874h8efh8rth48rheih
>>>> >> >
>>>> >> > could have additional metadata:
>>>> >> >
>>>> >> >
> a.b.dbPassword[metadata]=sensitive:true,cypher:DES3,issuer=a122334
>>>> >> >
>>>> >> > If you now want to filter these passwords for users,
> that are not in
>>>> > the
>>>> >> > admin role you must have access to the seconds
> property.
>>>> >> > This is an elegant and easy way to provide metadata:
>>>> >> >
>>>> >> >
>>>> >> > - it can be added by a module easily
>>>> >> > - it fits in the current solution
>>>> >> > - it is extendible
>>>> >> > - it can be used for filtering
>>>> >> > - it can be added on top (additionally) by
> additional property
>>>> >> providers
>>>> >> > - it can be overridden as needed by overriding
> property sources
>>>> >> similar
>>>> >> > to normal properties
>>>> >> > - it can be filtered out easily
>>>> >> > - ...
>>>> >> >
>>>> >> > Got the point? There is a couple of use case behind
> these
>>>> concepts...
>>>> >> >
>>>> >> > Anatole
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > 2015-01-06 14:41 GMT+01:00 Romain Manni-Bucau
>>>> > <[email protected]>:
>>>> >> >
>>>> >> >> you dont want to make it explicit it is the
> metadata - this term
>>>> >> >> doesnt mean much btw, is it the 'in
> progress'
>>>> > configuration of the
>>>> >> >> property source key-values?
>>>> >> >>
>>>> >> >> this can make sense but shouldn't rely on a
> function which
>>>> > really
>>>> >> >> makes no sense in term of API.
>>>> >> >>
>>>> >> >> if you want to "evaluate further
> properties" you need
>>>> > the
>>>> >> >> Configuration otherwise you just get raw
> properties which shouldnt
>>>> > be
>>>> >> >> readable with our current contracts IMO.
>>>> >> >>
>>>> >> >> About supports: as said +0.
>>>> >> >>
>>>> >> >>
>>>> >> >> Romain Manni-Bucau
>>>> >> >> @rmannibucau
>>>> >> >> http://www.tomitribe.com
>>>> >> >> http://rmannibucau.wordpress.com
>>>> >> >> https://github.com/rmannibucau
>>>> >> >>
>>>> >> >>
>>>> >> >> 2015-01-06 14:35 GMT+01:00 Anatole Tresch
>>>> > <[email protected]>:
>>>> >> >> > Hi Romain
>>>> >> >> > /Mark
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > around your proposal my feedback:
>>>> >> >> >
>>>> >> >> > Filter {
>>>> >> >> > boolean supports(key, value);
>>>> >> >> > String filter(key, value);
>>>> >> >> > }
>>>> >> >> >
>>>> >> >> > - 2 methods for something easy like value
> filtering, IMO too
>>>> > much! The
>>>> >> >> > supports method does not add any additional
> functionality I
>>>> > cannot do
>>>> >> >> > within filter itself
>>>> >> >> > - There is a very good reason, why there is
> also a Function
>>>> > coming in
>>>> >> the
>>>> >> >> > API: it gives the filter
>>>> >> >> > access to the original unfiltered set of
> properties for
>>>> >> >> > - accessing metadata about the property
> to filter
>>>> >> >> > - to see if in case of a null value read
> out the original
>>>> > value and
>>>> >> >> maybe
>>>> >> >> > readding a filtered version of it
>>>> >> >> > - evaluate further properties
>>>> >> >> >
>>>> >> >> > Since the time of filtering is a special
> runtime state within
>>>> >> evaluating
>>>> >> >> > configuration it is not possible to route
> the call simply to
>>>> > the
>>>> >> normal
>>>> >> >> > configuration methods (it would loop).
> Additionally original
>>>> >> unfiltered
>>>> >> >> > values are not present.
>>>> >> >> >
>>>> >> >> > So -100 to remove it. Summairzing IMO the
> filter looks exact
>>>> > how it
>>>> >> >> should,
>>>> >> >> > no more no less.
>>>> >> >> >
>>>> >> >> > Cheers
>>>> >> >> > Anatole
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > 2015-01-06 12:16 GMT+01:00 Romain
> Manni-Bucau
>>>> > <[email protected]
>>>> >> >:
>>>> >> >> >
>>>> >> >> >> Hi guys,
>>>> >> >> >>
>>>> >> >> >> just notice filter API was:
>>>> >> >> >>
>>>> >> >> >> String filterProperty(String key,
> String
>>>> > valueToBeFiltered,
>>>> >> >> >> Function<String,String>
> propertyValueProvider);
>>>> >> >> >>
>>>> >> >> >> I dont get it at all:
>>>> >> >> >> 1) if forces a returned value ->
> I'd add a
>>>> > supports(key,
>>>> >> currentValue)
>>>> >> >> >> to make filter composition easier
>>>> >> >> >> 2) why a function? a filter needs key
> and value not only
>>>> > one of both
>>>> >> +
>>>> >> >> >> why doing a function (filterProperty)
> of function since
>>>> > we dont need
>>>> >> >> >> it for something as trivial as
> filtering. If you want to
>>>> > play with
>>>> >> >> >> java 8 then
>>>> > org.apache.tamaya.core.internal.DefaultConfiguration#
>>>> >> >> >> get(String)
>>>> >> >> >> should get a list of fnuction to apply
> but it would be a
>>>> > very weird
>>>> >> >> >> API.
>>>> >> >> >>
>>>> >> >> >> My Proposal would be simply:
>>>> >> >> >>
>>>> >> >> >> Filter {
>>>> >> >> >> boolean supports(key, value);
>>>> >> >> >> String filter(key, value);
>>>> >> >> >> }
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> 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
>>>> > <%2B41-76%20344%2062%2079>*
>>>> >
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > *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*
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > *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*
>
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> *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
> <%2B41-76%20344%2062%2079>*
>>>
>>
>>
>>
>> --
>> *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*
>
