"Native" spring configuration for attribute filters

[Rod Widdowson]

About a month ago I lost the rag with the custom syntax and decided to work
out how hard it would be to write native beans to configure something which
is currently configured with customer spring.

After some consultation I decided to look at attribute filtering and today
this got to the top of my list.

The results are in SVN [1] if you want to peruse.  They can certainly be
tightened up.  Each native file has the custom syntax it is replacing as a
comment (and for completeness there is an equivalent file in customer syntax
in the directory above)

My take-aways are:

- This was not hard and once I got going it became quite mechanical.

- The results are no more impenetrable than the custom syntax

- That weird things like plumbing natural Matchers into Policy roles shows
itself up by having more complex plumbing whereas in the custom syntax the
inherent complexity is masked.  See policy5.xml.

- That before we went live with this we would need to define a bunch of
abstract beans to hide the impl nature of most of the actual matchers and
policy rules.

- And that this in turn would require some not inconsiderable expansion of
the documentation.

Nonetheless this might be worthwhile, particularly for people writing their
own filters.  The quid pro-quo of the extra work would be that we wouldn't
need to make any of the spring modules -api (as opposed to -impl) if we
required that people writing their own filters deployed them using spring.

[1]
http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-attribute-fi
lter-spring/src/test/resources/net/shibboleth/idp/attribute/filter/spring/na
tive/

/Rod