Add a service layer for exposing FlowDescriptor beans to the various flows

It’s not documented because it isn’t viable, though I didn’t pull the service yet. I probably will deprecate it at some point.

It was too fragile to be viable because it was too situational due to all the singletons, and would lead to more confusion than help. Spring does not support or want to have this notion of reloading things.

Making it work basically depends on having special service APIs that are wrapped in a lot of other code we built to handle all the synchronization required, which is what the other dedicated services do. It can’t just wrap any general object to make it reloadable, so it’s for a somewhat different use case. But that’s the only way to do it in practice without so much Spring knowledge that it wouldn’t be generally helpful.

Usually when somebody needs something to be reloiadable, the best answer is to put it somewhere that is, typically the attribute resolver. Many, though not all, use cases can be handled that way by indirecting things via an attribute.

I was looking for a way to create a generic reloadable bean (since my custom stuff in global.xml is not reloadable) and in my searching, I came across this.

It would help a bit if this feature was documented.

There are limitations on exposing all the existing beans related to this problem area through a proxied interface because of circular bean references caused by beans used via conditional expressions that may not actually exist in the configuration.

Rather than introduce all the risk that completely reworking the configuration in place would create, I just added a dedicated service that loads a conditional resource to hold "managed" beans that are meant to be reloadable. I'll write documentation later to illustrate how to move specific user-modifiable beans into the reloadable "zone". Practical use cases will likely be limited to specific beans anyway rather than making dozens of beans reloadable.

Dumped original functional design in favor of reusing the work I did on reloadable Spring beans.

I now have a managed Spring ApplicationContext out of which I can proxy beans through factories into the global namespace. Prototypes are therefore reloadable automatically if they're injected into other prototypes.

We can use this generically to make any bean reloadable if its used in a way that allows for that, including specific configuration objects in flows.

The problem of supporting beans is pretty widespread and not easily fixable in some cases, we have a lot of cross-contamination between the files and flow definitions relying on the common Spring context to access different beans.

As a proof of concept I have code working for subject c14n but it doesn't accomodate all the miscellany. I think the only way to handle a lot of that is going to be exposing more general bean lookup through this service interface, possibly just the ApplicationContext outright for internal use. Most of the consumers are prototype beans that either have to be modified to change how they would acquire their injected beans or rely on FactoryBean proxies that reach in and get the now-isolated beans and expose them under the same name that used to be visible.

I already used the factory bean trick to avoid breaking login flows in case there are third party flows that copied our design/code and that seems to work pretty well.