[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Tom Zeller]

> On Nov 10, 2013, at 7:05 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
> 
> Scott said:
> 
>> Not hung up on details, but yes, I would expect something like that.
> 
> That’s where my mind is  going, but sadly getting into the details flushes
> an architectural call we need to make (although I suspect it is made for
> us).  So here goes...
> 
> Tom's suggestion
> 
>> interface ReloadableService<T extends ServiceableComponent>
>> start()
>> stop()
>> reload()
>> ...
>> T getServiceableComponent()
> 
> Is pretty close to where I was going, but it needs more work in the in the
> case of destroyable, reloadable components - otherwise once you have called
> getServiceableComponent() you lose track of it and there is no
> synchronization between you and the destroy.  
> 
> There are two ways around this, what V2 does is:
> 
> class FooService implements Foo, ReloadableService
> 
> And wrap the calls to the methods in (just) enough logic to handle the
> synchronization.  The actual implementation is not something I'd port
> through to V3 though - it makes dangerous use of locks.  This also has the
> disadvantage that we need a class for everything (FilterService,
> ResolverService and so on).
> 
> The other solution is to add a:
> 
> doneWithServiceableComponent()
> 
> to the ServiceableComponent interface and to wrap the call to
> getServiceableComponent in a try{}  and the doneWithServiceableComponent()
> in the finally{}.
> 
> Neither of these deals with the case in which the same configuration file
> supports two different operations.  We already have this in V2 (Attribute
> resolution and Attribute encoding coming from attribute-resolver.xml) and in
> V3 I am proposing that there be three (Attribute mapping, resolution and
> encoding).  There is definite timing window during a reload during which an
> inflight operation can see two version of the configuration.
> 
> If we care about this (and I do since I spend most of my life dealing with
> the outcomes of this sort of thing) then the second solution (the
> get/doneWith() pairing) offers an out.  We can grab the component at the
> start of the flow and call doneWith () it at the end. Meantime we can cast
> the ServiceableComponent to whatever we want it to be and then use as
> appropriate.  It's always the same component and it is proof against
> reloading.
> 
> Against this I have two concerns, one technical and the other vaguely
> visceral.
> 
> My technical concern lies in the fact that we absolutely *must* always call
> doneWithServiceableComponent(), otherwise destruction will not take place.
> It's easy to do this within the confines of a try/finally, but given the
> complexity of a webflow can we easily guarantee this?
> 
> I use reference counted subsystems (which is what this is) all the time to
> deal with exactly this sort of situation, but I'll admit that debugging
> reference count leaking can be a bear, and by their very nature bugs in
> these systems are not something you can easily test for.  Maybe Spring's
> lifecycle can help use here?  If the SWF is a bean which implements
> DisposableBean - does it suffice to call doneWithServiceableComponent() in
> the destroy() method?  
> 
> The absolutely guarantee is to use finalize()as a final defence, but I have
> read enough to be leery of that (and we would certainly want to use it only
> as the final fail-safe).
> 
> The other concern is really no more than an observation:  if you do have a
> service which can implement a number of different Operations the obvious
> thing to do is to add a
> 
> <S extends ServiceableComponent> queryInterface(Class<S>) 
> 
> method to allow you to turn one sort of component (say an attribute
> resolver) into another (say attribute encoder).  And hey presto you have
> invented IUnknown!!  I have enough COM wounds (some of them as recent as
> last Thursday) for this to provoke the aforementioned visceral reaction.  Of
> course you don't need to do it that way - it's just that that solution leapt
> out at me. 
> 
> My overall instinct is that if we are to implement safe reload then we need
> to go for the refcounted model.  But I am very leery of the pitfalls of
> adopting it.
> 
> Thoughts?
> 
> 
> 
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net