Ok, so you mean generating an or including all names of annotated methods/params? or do you mean to include package and class names? It can not work if you don't. A name maybe used different in different classes.
On Tue, Apr 15, 2014 at 8:25 AM, Mandar Barve <mandar.ba...@sungardas.com> wrote: > Oh all I meant was stuffing the existing search string that cleanString uses > with all identified "sensitive" keywords. And I guess if it starts getting > GIANT it won't make sense. > > > > > On Tue, Apr 15, 2014 at 11:36 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> >> On Tue, Apr 15, 2014 at 6:01 AM, Mandar Barve >> <mandar.ba...@sungardas.com> wrote: >> > 1. The pilot patch I posted already does this of checking the command >> > level >> > flag first and only for "flagged" commands check the list of "sensitive" >> > parameters. I was wondering if that code itself, building list of >> > sensitive >> > parameters as a command can have more than one of these and then >> > stripping >> > them one by one can lead to additional overhead. >> > To reduce that overhead, I was thinking the REGEX that cleanString util >> > function uses can be generated at application load time walking the list >> > of >> > all only "sensitive" (flagged) command classes followed by the >> > "sensitive" >> > param lists for such classes. At run time when commands are executed all >> > you >> > need to do is for the already flagged "sensitive" commands alone use the >> > pre-built REGEX to filter sensitive data. >> >> I am not sure what you mean by this. The REGEX can get quite complex, >> do you envision to create a giant set of or'ed method names? It can be >> done but I doubt that building a REGEX is the best thing at load time. >> At that time more efficient lists or arrays can be build (or a tree >> :P) >> Any way tests will tell us. >> >> -- >> Daan > > -- Daan
