Selective Parsing?

[Rod Widdowson]

> That at least doesn't misuse a Spring feature.

I'm relatively relaxed by this. To my mind we are using the feature in
exactly the manner expected - we are setting the environment when we parse
and consulting it at the point of parsing.  Their specific implementation
may be heavy handed, but we (again to my mind) are just using the
capabilities. 

> I don't know if that's preferable to having a faux parent context with an
> explicit bean name or not. 

I'm not sure that I completely understand this, probably because "context"
is a term which is overloaded everywhere, but specifically in this case.

When we set up to parse we create an ApplicationContext and we can give this
a unique DisplayName (or we could have our own class implementing
ApplicationContext if we wanted).

When we are called at the point of parse we are given a ParserContext.
Again for the record, it is possible to get to the ApplicationContext (if
there was one) by navigating first to the readerContext and from there to
the BeanDefinitionRegistry. The  BeanDefinitionRegistry will implement
ApplicationContext if that’s what we set reader to, and this can have its
DisplayName queried and that could drive parsing decisions.  But that also
feels like an abuse of Spring.

However this is probably all irrelevant.  

On Friday someone mentioned Lazy Initialization and a quick test does appear
to indicate that setLazyInit() does exactly what we need, and so we can
avoid the cost of initializing MetadataProviders except where we need them.
We do still have the issue of the potential cost of parsing crypto material
but this seems less important.

Again, nothing needs to be decided at this immediately, but my favoured
approach is to use lazy initialization, particularly on the metadata
providers.

Rod