(Re-resend): About Native-Spring DataConnector definition and the version policy

[Rod Widdowson]

> I think if we were exposing the actual class itself (meaning you'd have
> to instantiate a bean of that type), I'd feel fairly uncomfortable about
> it not being API, but the types thing feels a bit more fuzzy, like
> something that really is more about documentation.

OK.
 
> > Obviously exploiting this would have as a precondition moving the data
> > connectors out to api.
> 
> Does it? 

Well, only in as much as if we said "And here is how you now configure the
LDAP connector if you want to use native Spring" because (as you say) we
would have a line saying class="thing.thing.IMPL.thing"

> I think the same thing applies: use it for custom beans as you
> I don't know that I'm against the idea of supporting the <beans> thing
> inline, but I thought we had explored that originally and concluded it
> didn't work reliably. Were we trying to do something slightly different
> in that case? Maybe embedding Spring inside the <DataConnector> element
> didn't work?

It absolutely didn't work because of the way that, in those days, the
<AttributeResolver> statement was converted into a service.  

When I added the reloading thing and the code which allowed a legacy relying
party file to be arsed either as a relying party or as a MetadataProvider
that had to be rototilled and we ended up with the case that we have now:
Every bean in the resulting ApplicationContext that implements DataConnector
will be used in the resolver.  

This loosens up things massively and allows us to do the embedded <beans>
handling "at the right place" - which is where we are passing the DOM off to
Spring, rather than when Spring gives us the DOM back (by which time it's
too late to do very much)