I've tried enough downstream stuff to know that this is basically complete.

Migration assistance is now over in https://shibboleth.atlassian.net/browse/MDA-277.

I took a look at the RelocatedBeanFactoryPostProcessor and it does look plausibly like something that would make sense to provide.

I already provide one classpath resource (net/shibboleth/metadata/beans.xml) that provides some abstract parent beans to make defining user configuration simpler. I think I could either extend that to include an instance of RelocatedBeanFactoryPostProcessor) or provide another file to <include> that just had the migration bean in it.

I think I’m right in saying that I already have a hard dependency on the old spring-extensions artifact (now shib-spring) so it wouldn’t actually cause any bloat, either, just overhead in any context it was used in.

It’s an interesting thought; thanks for the suggestion.

Could it be added programattically, loading its ruleset from a config file? Just a thought.

Thanks. I think we talked about that before at some point, because I already have a note to look into it.

Because someone would have to add a bean explicitly to their configuration it doesn’t improve things much for a one-off. I have no way of injecting such a bean into an existing configuration in the way that we can with the IdP. So for a one-off migration, people need to edit their configurations one way or another and maybe it’s not super helpful. On the other hand, if I did invent such a thing and suggest that people include it in all configurations as a hedge against future migrations then that might make more sense.