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. >
Can't we forbids not scannable sources for now? > > 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. > was my idea as well. brings me to one the most important topic: what's the lifecycle of a config? depending the answer it can work or not. > 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* >>
