Configuration reloading via Tomcat 7 parallel deployment ?

[Rod Widdowson]

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Cantor, Scott

> I really am hard pressed to believe Spring is sophisticated enough to do
> this for us.


I discovered another wrinkle yesterday which I should have spotted earlier.
There is at least one “service” which does not use Spring, and that is the
LogbackLoggingService (we use Spring to configure it, it of itself uses
JoranConfigurator).

So, armed with this fresh knowledge and the discussions to date it feels
that since we have one and are trying to tie ourselves in loops to not
implement the other, we should just go ahead and implement the simple code
that we have discussed.  

The output will be two concrete classes, LogbackService and SpringService.
The later will be the class Tom suggested some time ago:

class SpringService<T extends ServicableComponent>  extents BaseService {
	T getServiceableComponent();
}

ServiceableComponent will have the expected methods (lock(), release() and
unload()).  If we implement this as a base class to exploit Spring and make
all the requisite plugins (filters, resolvers, …) implement Closeable we can
be done in about 40 lines.

For the reload, we can borrow a lot of the existing infrastructure, but I
also propose to jettison all the code around multiple states and performance
tracking.  None of this has any homologs in V2 and, I feel, represents “work
in progress” towards a design which was not completed.  We have cases to
track the needs that this addresses and we can leave the base classes
(net.shibboleth.idp.log.EventLogger and
net.shibboleth.idp.log.PerformanceEvent) in place.

We can probably replace net.shibboleth.idp.service.Service with
org.springframework.context.Lifecycle as well, even if we do not expect to
leverage this right now.

/Rod