Skip to Content.
Sympa Menu

grouper-dev - hooks and notifications summary

Subject: Grouper Developers Forum

List archive

hooks and notifications summary

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Grouper Dev <>, "" <>
  • Subject: hooks and notifications summary
  • Date: Thu, 29 May 2008 11:24:06 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

This is to summarize the discussion we had yesterday about hooks and

I will do a proof of concept in two weeks. This will be about groups (and
maybe memberships if there is time).

We decided:

1. No multiple event registration, implementers can call multiple methods
from one hook point, and API hooks will just be in the API
2. The hook will be transactional or not in Grouper (not transactional
currently in Signet)
3. The hook will receive the object which is currently being operated on
4. The hook implementation class will extend one of several hook classes, and
one or many methods can be overridden

We didn't decide these, but we have discussed them in previous meetings

1. Vetos are communicated with a subclass of RuntimeException (since Grouper
API is heavily nested, and don't want to add a bunch of boolean returns)
2. Hooks are synchronous. The hook API will make it easy to do part of the
hook implementation logic asynchronously (3 lines). (Since not multiple
hooks, and people will generally want synchronous for non-notification hooks,
I think all should just be synchronous.


We talked about changes to the Grouper API.

The problem is that the DB layer is now transparent, and there are long
running transactions. So:


Generates: update grouper_groups set description = "whatever" where uuid =

(granted this is actually a grouper_attribute, but this isn't an exact
example :) ).

So what we need is either:

a. high level method which does multiple things at once:

group.assignFields(name, description, nameFriendly, attributes)

-or- b. we need to change the existing methods to not generate sql:

group.setAttribute("a", "b");;

We think that (a) will have the least impact on the existing code and unit
tests, but (b) is really the right thing to do. I will take a look.

Also, we discussed long running transactions again. The issue is that there
are three levels to the DB layer.

- the transaction: from when the tx starts to where the commit happens. This
is out of the control of the Grouper API, and this is the way we want to keep
- where we want the hook point: this is some operation on the object
model. E.g. change the description and attributes of a group
- the sql (hopefully we can move this up to where the hook
point is)

I didn't really take notes of the discussion, if I left anything out, let me


Archive powered by MHonArc 2.6.16.

Top of Page