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*
