Services and reloadable bean definitions

[Rod Widdowson]

My understanding of the problem statement is

- There are some subsystems/bean hierarchies that we want to refresh
independent of the container’s lifetime.
- If the reload of a subsystem fails, we should continue with the “last
known good” setup.
- There are some subsystems which have to be destroyed as soon as possible
because they consume external resource (database connections) and we cannot
wait for gc.
- Because of the external resource consumption, the destruction of these
subsystems cannot happen without synchronization with the callers of
subsystem

I’ll add for completeness:

- That there is an interesting twist brought in by the attribute mapper,
resolver and encoder.  These three subsystems are all driven from the same
configuration file - indeed the attribute resolver resource source is the
parameter to the constructor of the attribute mapper and probably will be
for the (yet to be written) SAML attribute encoding subsystem.  Therefore we
need to make sure that the mapping, resolution and encoding for a particular
request are all driver from *the same* version of the configuration.

- That we do need to bear in mind the fail fast/fail slow issues which
caused some problems during V2.

Having looked hard at it and then spoken to some people and then looked hard
again I just do not see that Spring provides an in built mechanism to do
everything that we need above.  It seems to provide support to allow one to
build a system which fulfils all the requirements, but there are no silver
bullets here.

What Spring does have is support for initialization of beans (via the
InitializingBean interface) and destruction (via the DisposableBean
interface).    We currently (inside the hand parsed beans) do not take
currently take advantage of this and I suggest that we so in V3.

For the rest I do not see but that we can do better than something like the
V2 Service interface.  Whilst I do not want to reimplement anything which
Spring already supports I have spent a lot of time looking at Spring's
capabilities to no avail.

So what is a Service ? – well pretty much what one would expect. I can
provide details of the V2 Implementation, but basically a service will/does

•	Offer thread safe access to the function(s) provided by the
subsidiary beans.
•	Control the lifecycle of these subsidiary beans as per the above
constraints
•	Exploit the Spring context hierarchy (just as V2 does) so that the
subsidiary beans can get access to beans defined in the parent contexts.
•	Work not just for our custom parsed definitions, but also for any
(all?) user changeable files, this to probably include the property files.

At this stage I am not exactly certain how to wire all these things
together, the overall way in which the V2 system works is Ok – but I am
unsure (just because I have not spent time thinking it through) how to
extend this easily (definition of each service is pretty cumbersome in V2 )
and I am slightly unhappy with the way V2 handles the “multiple functions
from the same config” issue (it doesn’t - AFAICS).

For now I’m just looking for buy in to using the concept of a service to
handle reload in V3.  We (Tom and I) can then play with the basic ideas as
we lay out the bean definitions in the idp-test harness.

Rod