Filtering and identifiers and logging.

Rod Widdowson rdw at steadingsoftware.com
Thu Jun 20 11:52:55 EDT 2013


Fortified by having got the filters all ported I have start back into the
parsers for filtering (the noise you heard was the disk-heads seeking as I
swapped back Spring information in to main memory).

In the schema, the ids for the matchers is optional and in V2 we do not make
use of the names beyond the ability to pass rules by reference.  

In V3 the plan is (and the code written) to use the filter id much more
extensively in logging.  The wiki talks about generating ids if none are
specified and logging that information to (a) encourage people to add ids
and (2) to provide some sort of hook to help debugging if people do not have
ids set.

So far so good, but reality is slightly different.  The V2 parsing code (and
the aim here as always is to port rather than right), in fact uses something
called a "QualifiedId", which is, I am pretty sure a mechanism to allow
rules to have similar names and be qualified by where they are in the XML
file (so you cannot use a rule reference unless it is names somewhere in
your parent tree).  

Again the plan is to port this unchanged, but it will have a side effect on
the logging because if someone specifies a rule called "MyAndRule" the
message logged might be something more like:

Attribute Filter
'/AttributeFilterPolicyGroup:PolicyExample3/PolicyRequirementRule:
MyAndRule' Some useful message.

On the one hand having the qualified name is useful in really locating the
precise matcher, on the other hand the log line becomes quite long.

Because a lot of logging goes through getLogPrefix() changing this to strip
off everything to the left of the right-hand-most ':' would be quite easy,
but would it add or subtract from the logged message?



More information about the dev mailing list