Subject: Grouper Developers Forum
- From: Chris Hyzer <>
- To: "" <>, Grouper Dev <>
- Subject: FW: hooks and notifications summary
- Date: Fri, 6 Jun 2008 11:57:07 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
Here is the email that was requested to be re-sent out for community response.
The two items that we didn't discuss in the previous grouper call were
discussed today in the signet call without dissent.
> -----Original Message-----
> From: Chris Hyzer
> Sent: Thursday, May 29, 2008 11:24 AM
> To: Grouper Dev;
> Subject: hooks and notifications summary
> 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
> 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
> 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 = "sdffdskjljdfg"
> (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
> 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 it
> - 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 know.
- FW: hooks and notifications summary, Chris Hyzer, 06/06/2008
Archive powered by MHonArc 2.6.16.