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*

Reply via email to