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>*
