Grouper Developers Forum

[Chris Hyzer <>]

Hey,

 

We discussed hooks at the signet call today, and from a high level the signet and grouper hooks vision is aligned, but on the details we need to agree on a common approach.  We can continue the discussion on Wednesday at the grouper call.  Let us know any feedback.

 

Thanks,

Chris

 

Here is Dave’s document:

https://wiki.internet2.edu/confluence/pages/viewpage.action?pageId=23183

 

Here is my document:

https://wiki.internet2.edu/confluence/display/GrouperWG/Hooks+simple

 

Here are some of the gaps (from my perspective on Dave’s document):

 

1.       We should not have asynchronous events.  It is an extra configuration step that doesn’t really save someone that much custom code.  If you need asynchronous make a new Runnable and put the login in the run() method… easy.

2.       We should not have runtime registration.  Eventually we could add that, but I think it should be a config file and a class implementation, no need to write code to register.  Keep things easy to use (especially at first)

3.       The only multiple registrations are for the implementer, for an extension, and for the  api itself (signet or grouper).  So, three hook implementations, max three listeners on queue.  We can then have a determinate order (for custom, then extension, then api (signet/grouper).  The more things in system that are determinate, the better (who wants intermittent problems???)

4.       I like the idea of a context object, this can be a different object for each hook (might be same for pre/post, might not).  This way as more fields are added, the hook implementations don’t need to be recompiled…

5.       The real objects should be passed  to hook code, as much info as possible, NOT the  xml object stuff…  we want to reduce queries, give the power to change the objects (in intelligent ways), and give access to the API (might be methods that don’t need to be duplicated).  Also, things like current user session should definitely be passed (and db resources which in Grouper’s case are threadlocal anyways, so doesn’t matter)

6.       I don’t think setting a reason  in the event object  and returning a Boolean is going to cut it, I think vetoing needs to be runtime exception based.  We need to not be passing objects around the  API, we need to cut through the red tape and just throw an exception with all the information in it.