Grouper Developers Forum

[Thomas BIZOUERNE <>]

Hi Chris,

I wanted to thank you for help. Indeed, I succeed to correct our Hook.

I moved all the business logic in the AttributeHook instead of the GroupHook, because the GroupHook is no more useful for us.

It was necessary to think again about what action to do on each method because the "triggers" are not the same.

Now it's ok, all seems to work.

Thank you again for you time and your patience.

Thomas.

2010/6/30 Chris Hyzer <>

Ok, I think the reason might be a little different, but yes, I think the bottom line is that if you are worried about attributes, you should use the attribute hook methods instead of the group hooks.  I changed my test (attached).  You will now see:

 

        LOGGER.debug("preUpdate attribute: " + attribute.getAttrName()

            + ": '" + attribute.dbVersion().getValue() + "' => '" + attribute.getValue() + "'");

 

 

2010-06-30 12:41:16,564: [main] DEBUG ESCOAttributeHooks.attributePreUpdate(52) - preUpdate attribute: someAttr: 'firstValue' => 'secondValue'

 

So you should probably change your code accordingly.  Ok?

 

Thanks!

Chris

 

 

From: [mailto:] On Behalf Of Thomas BIZOUERNE
Sent: Wednesday, June 30, 2010 11:55 AM

To: Chris Hyzer
Cc:
Subject: Re: [grouper-dev] Problem with our Group Hook since Grouper 1.5.2

 

Hi Chris,

 

Thank you for your time.

 

I looked at the output you sent me, and I think I found what is bothering me : the group attribute "rule" is never returned by dbVersionDifferentFields(), even when we just insert it.

(I mean we never see : different fields: [rule: 'thepreviousrule' => 'mynewrule'])

 

When I read your explanations, I understand that since grouper 1.5, It seems to be the normal behavior, (because "rule" is no more a field ?).

 

So, my question is : In the groupPreUpdate() method, is it possible to be aware of the modification of the "rule" attribute (just like before with dbVersionDifferentField?), or must I have to change the global way of doing ?

 

(Maybe another method can do the job ? Maybe we can get the previous value of the attribute and compare ?...)

 

I'm sorry for my too few skills in Grouper and I thank you again for your patience.

 

Regards,

 

Thomas.

 

 

2010/6/30 Chris Hyzer <>

Ok, bear with me.  I used your hooks classes to make a test case (well, it doesn’t really test yet, it just prints out what is happening).  See the attached classes.  I am doing this in 1.5.2, is that the version you are using, or are you upgrading to 1.6.0?

 

Anyways, here is the code that executes:

 

 

    LOGGER.debug("start, before addGroup");

   

    final Group theGroup = StemHelper.addChildGroup(ESCOGroupHooksTest.this.edu, "testOperation", "testOperation");

 

    LOGGER.debug("after addGroup, before addType");

   

    theGroup.addType(GroupTypeFinder.find("someType", true));

   

    LOGGER.debug("after addType, before addAttribute");

 

    theGroup.setAttribute("someAttr", "firstValue");

    theGroup.store();

 

    LOGGER.debug("after addAttr, before changeAttribute");

 

    theGroup.setAttribute("someAttr", "secondValue");

    theGroup.store();

   

    LOGGER.debug("after changeAttr, before changeField");

 

    theGroup.setDisplayExtension("newDisplayExtension");

    theGroup.store();

 

    LOGGER.debug("after changeField, before groupDelete");

   

    theGroup.delete();

 

 

 

Here is the log output:

 

 

 

2010-06-30 08:23:10,413: [main] DEBUG ESCOGroupHooksTest.testOperations(56) - start, before addGroup

2010-06-30 08:23:10,429: [main] INFO  ESCOGroupHooks.<init>(39) - Creation of an hooks of class: ESCOGroupHooks

2010-06-30 08:23:10,569: [main] DEBUG ESCOGroupHooks.groupPostCommitInsert(57) - postCommitInsert group: edu:testOperation, types: base,

2010-06-30 08:23:10,569: [main] DEBUG ESCOGroupHooksTest.testOperations(60) - after addGroup, before addType

2010-06-30 08:23:10,616: [main] DEBUG ESCOGroupHooksTest.testOperations(64) - after addType, before addAttribute

2010-06-30 08:23:10,616: [main] INFO  ESCOAttributeHooks.<init>(36) - Creation of an hooks of class: ESCOAttributeHooks

2010-06-30 08:23:10,616: [main] DEBUG ESCOAttributeHooks.attributePreInsert(85) - preInsert attribute: someAttr = 'firstValue'

2010-06-30 08:23:10,663: [main] INFO  ESCOGroupHooks.<init>(39) - Creation of an hooks of class: ESCOGroupHooks

2010-06-30 08:23:10,663: [main] DEBUG ESCOGroupHooks.groupPreUpdate(111) - preUpdate group: edu:testOperation, types: base, someType, , different fields: [modifyTime: 'Wed Jun 30 08:23:10 EDT 2010' => 'Wed Jun 30 08:23:10 EDT 2010'],

2010-06-30 08:23:10,710: [main] DEBUG ESCOGroupHooksTest.testOperations(69) - after addAttr, before changeAttribute

2010-06-30 08:23:10,710: [main] INFO  ESCOAttributeHooks.<init>(36) - Creation of an hooks of class: ESCOAttributeHooks

2010-06-30 08:23:10,710: [main] DEBUG ESCOAttributeHooks.attributePreUpdate(52) - preUpdate attribute: someAttr = 'secondValue'

2010-06-30 08:23:10,757: [main] DEBUG ESCOGroupHooks.groupPreUpdate(111) - preUpdate group: edu:testOperation, types: base, someType, , different fields: [modifyTime: 'Wed Jun 30 08:23:10 EDT 2010' => 'Wed Jun 30 08:23:10 EDT 2010'],

2010-06-30 08:23:10,788: [main] DEBUG ESCOGroupHooksTest.testOperations(74) - after changeAttr, before changeField

2010-06-30 08:23:10,804: [main] DEBUG ESCOGroupHooks.groupPreUpdate(111) - preUpdate group: edu:testOperation, types: base, someType, , different fields: [displayExtension: 'testOperation' => 'newDisplayExtension'], [displayName: 'education:testOperation' => 'education:newDisplayExtension'], [modifyTime: 'Wed Jun 30 08:23:10 EDT 2010' => 'Wed Jun 30 08:23:10 EDT 2010'],

2010-06-30 08:23:10,835: [main] DEBUG ESCOGroupHooksTest.testOperations(79) - after changeField, before groupDelete

2010-06-30 08:23:10,929: [main] INFO  ESCOGroupHooks.<init>(39) - Creation of an hooks of class: ESCOGroupHooks

2010-06-30 08:23:10,929: [main] DEBUG ESCOGroupHooks.groupPostDelete(87) - postDelete group: edu:testOperation, types: base, someType,

 

 

 

I think that is correct, though I didn’t get into it in detail.  Is there something that is not correct?  I agree with you that the attribute hook doesn’t have “attribute__rule”, if you are in an attribute update hook, it should just be “rule” and not “attribute__rule”, right?  Anyways, all the test cases work, I think the change is a bunch of things that used to be attributes are now group fields (as of grouper 1.5).   Can you try adjusting your code accordingly?

 

Thanks!

Chris

 

 

From: [mailto:] On Behalf Of Thomas BIZOUERNE
Sent: Tuesday, June 29, 2010 9:39 AM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-dev] Problem with our Group Hook since Grouper 1.5.2

 

First, thank you for your answer,

 

I must tell you that i'm quite lost, that's why my explanations are not as clear as they could be. 

 

I think the better I can do is send you our hook classes, and try to explain what I understand (and what i don't)

You must know that Arnaud developped 2 Hooks : 

ESCOGroupHooks.java

and

ESCOAttributeHooks.java

 

(and a HookInstaller class... but there is no problem with that one i think)

 

You can find the too classes here :

http://svn.giprecia.fr/svn/grouper/ESCO-DynamicGroups/tags/ESCO-DynamicGroups-rel-1.0.0/src/org/esco/dynamicgroups/hooks/ESCOAttributeHooks.java

 

and here :

http://svn.giprecia.fr/svn/grouper/ESCO-DynamicGroups/tags/ESCO-DynamicGroups-rel-1.0.0/src/org/esco/dynamicgroups/hooks/ESCOGroupHooks.java

 

Since my first mail, i succeed to resolve one part of the problem. Indeed, something was wrong in our grouper database, and grouper wasn't able to fill our "rule" attribute when trying to create a "dynamic" group. (I saw in my debugger that the save of the attribute failed with a message like : can't find attribute "rule"... or something like that).

I succeed to delete then create again a "rule" attribute associated with the type "dynamic".

 

So, now, that part is working : I mean when I create a group with the type "dynamic", it seams that all in grouper tables is OK :

here is what i see in grouper_attributes_v :

esco:Etablissements:CLAUDE DE FRANCE_0410017W:groupes_locaux:dg17 | ESCO:Etablissements:CLAUDE DE FRANCE_0410017W:Groupes Locaux:dg17 | rule           | AND(ESCOUAI=0410017W,sn=pol*)  | dynamic         | 9b6cedbbfca34667b2051d71257fe518 | 4028b9b42983256a0129837e09250007 | f49b5c12961c463887049c80accd6fc5 | b42291f2640e4af4bb158a46ae133b13 | 97d1e089a4f9467aaca24cdac447062a |

 

(I see that my group is "dynamic" and has an attribute called rule, filled with "AND(ESCOUAI=0410017W,sn=pol*)", that is what I want)

 

To come back to the hook classes :

I will try to describe you what I see when I create a group using our personnal "grouper UI" (ESCOGrouper), which uses grouper-ws.

 

I can see in my debugger that, when I create a dynamic group, the ESCOGroupHooks is triggered.

The first time In the method groupPreUpdate(), the group isn't detected to be "dynamic"... but I think it's normal because, if i'm not mistaken, a group isn't created in one step.

Then, i see that the method "groupPostCommitInsert()" is called...

Then, the ESCOAttributeHooks is triggered (method attributePreInsert() is called)

Then, we are back in ESCOGroupHooks, in the groupPreUpdate() method :

At this time, the test "isDynamicGroup" is OK, but I can't understand WHY "isDefinitionUpdate()" is always FALSE.

If I understand Arnaud's work, "isDefinitionUpdate()" must return TRUE if the attribute "attribute__rule" has changed. (and we saw that the attribute has really been inserted in grouper...). 

The code behind isDefinitionUpdate(), is, as you can see on the SVN : "group.dbVersionDifferentFields.contains("attribute__rule")", and it always return FALSE.

At this time, if I read in the debugger the value of "group.dbVersionDifferentFields", I only see "[ModifyTime]".

 

I hope you will understand what could be wrong with all that, because I don't know grouper enough to point out what is normal, and what is not :( 

 

Thank you again for you help, i'm really stuck. It's a bit complex.

 

(I'm sorry I didn't send you a test case because i'm not familiar with them)

 

Thomas.

 

2010/6/25 Chris Hyzer <>

Sorry for the delay.  Lets figure this out.

The test case I added for Arnaud in 09 still works in 1.5.3 and 1.6.3.  Is there a way to get a simple hook test case of what you want to do and send it to me and explain what is going on?  I assume if it works with 1.5.3 that it will work with 1.5.2... :)  Want me to try on 1.5.2?

I modified the test case I have and attached it.

As you can see, I add a type to the group, and update the extension, and in the hook it prints out the types, and it prints it out correctly...

2010-06-25 17:47:43,178: [main] DEBUG GroupHookDbVersion.groupPreUpdate(144) - type for group: edu:anotherExt2: base, test1,

Anyways, send me more info and we will get it working.

Thanks,
Chris

-----Original Message-----
From: [mailto:] On Behalf Of Thomas BIZOUERNE
Sent: Wednesday, June 23, 2010 10:10 AM
To:
Subject: [grouper-dev] Problem with our Group Hook since Grouper 1.5.2

Hi everyone,

With grouper 1.4.2, we were using (at GIP RECIA, France) the hook mechanism to
do some custom operations on a particular type of group (a custom group type
called 'dynamic'). It was working pretty well, but since grouper 1.5.2, it
isn't working anymore.

That work was done by Arnaud DEMAN, who already posted on grouper-dev list and
succeed to get the hook working with Chris precious advices.
You can find the discussion here :
https://lists.internet2.edu/sympa/arc/grouper-dev/2009-02/msg00031.html

Today, i'm trying to make the hook work again with grouper 1.5.2 but i'm
pretty "new" to grouper and i don't really understand what is grouper way of
doing when a new group is created.

I will try to explain you my problem :

With grouper 1.4.2, we had a Group hook.
The method groupPreUpdate() was used to make some custom operations if the
group was of a certain type (our custom 'dynamic' type).

The problem is that since grouper 1.5.2, the group retrieved from the
preUpdateBean is no more 'dynamic' (our custom type) ! the "types" list only
contains "base" type.
I also pointed out that the problem is the same in :
  - groupPreInsert()
  - groupPostInsert()
  - groupPreUpdate()
  - groupPostUpdate()

The only moment when i can see two types ("base" and "dynamic") in the list is
in the groupPostCommitInsert() method.

That is one thing...

Seeing that, i tried to move our business code in the groupPostCommitInsert()
method, but then, another problem appeared.
Indeed, the other conditional test failed, (it tests if the custom attribute
related to our custom group type has been updated)
The test consists in a code like :
group.dbVersionDifferentFields().contains(ourCustomAttributeField)
That test is always false by now and I don't know grouper enough to know why.
I tested in other methods :
in groupPreUpdate() : group.dbVersionDifferentFields() = [description,
modifyTime]
in groupPostCommitInsert : group.dbVersionDifferentFields() = []
I don't understand why I never see that my custom attribute is added...

Another thing I can tell you is that, when i create a group of my custom type,
I can see in the database that, before reaching the "groupPostCommitInsert()",
the group isn't really in the DB.
When the groupPostCommitInsert() method is reached, I can see in the database
(grouper_groups_types_v view) that my newly created group is of the right type
: 'dynamic'. (and that the group is present is grouper_groups)

I Hope I am enough clear for you to understand what is wrong, and how I can
correct Arnaud's good work, in order to make it work with grouper 1.5.2.

I saw on the discussion that Chris told Arnaud that some changes were coming
on hooks with grouper 1.5.2. I think this is the reason why it's not working
anymore.

I will continue to investigate while waiting for your answer,

please, fell free to ask me questions if some point is not clear.

Thank you,

Regards,

Thomas, GIP RECIA.