Configuration reloading via Tomcat 7 parallel deployment ?

Tom Zeller tzeller at dragonacea.biz
Sun Nov 24 11:28:08 EST 2013



On Nov 24, 2013, at 9:50 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>> -----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).

Ha.

> 
> 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.

This last part is what I think I want to do, but I can be wrong, haven't tried to type it yet. So, maybe keep that in mind if it helps.

Minimum time at the moment, thx for understanding.



More information about the dev mailing list