Shibboleth XML Configuration file Validation

[Brent Putman]

On 9/24/12 9:21 AM, Mark O'Quinn wrote:
> Now, my next step is to look at the SpringConfigurationUtils in order to understand the validation via Spring 

I think the actual validation part isn't really Spring at all, our
document loader impl just uses the standard JAXP mechanism to validate
the files it's told to parse, using the properties set on the
DocumentBuilderFactory, e.g. the schema language being set to XML Schema
and setValidating(true). I don't think Spring itself is really involved
in the validation, that's all the DocumentLoader impl.  If the file
fails validation, that just percolates up to Spring as an exception.


> and specially find the way of reloading some of the configuration files on demand instead of time intervals. 
>


If you're using all local file resources, then just setting the polling
interval to be really short is probably not terribly expensive.  The
ResourceChangeWatcher, which runs on the polling interval, tracks the
resource timestamp of the last reload, and only fires an update event if
the file is newer.  So as long as the system's
java.io.File#lastModified() is not terribly expensive, this shouldn't be
either.

However, if you really want explicit on-demand reloading: the 4 services
in service.xml which are reloadable all implement
edu.internet2.middleware.shibboleth.common.service.ReloadableService, so
in theory you should be able to call reload() on them to effect an
on-demand reload.  That is in essence what the polling impl of the
ReloadableService does
(edu.internet2.middleware.shibboleth.common.config.BaseReloadableService). 
You can obtain those service bean references via their Spring bean id's,
which are in turn exported to and so easily available from the
ServletContext (see the servlet context attribute exporter at the bottom
of service.xml).  A simple JSP or servlet could just iterate over them
and call reload().  I have not tried this, but I can't off-hand think of
any reason why this would not work or be dangerous.... but please test
first. :-)