Skip to Content.
Sympa Menu

grouper-dev - xmpp merge with esb

Subject: Grouper Developers Forum

List archive

xmpp merge with esb


Chronological Thread 
  • From: Chris Hyzer <>
  • To: Grouper Dev <>
  • Subject: xmpp merge with esb
  • Date: Tue, 1 Jun 2010 07:29:14 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

Hey,

 

I had coded an xmpp change log consumer, but Rob’s ESB connector is a superset of it, so I emailed what I wanted to do (well, most of it, found a few more things as I did the work) to Rob last week, and performed this work:

 

- added a unit test with some filter tests

- move event types into EsbEvent enum (so that it is easy to know the choices)

- fixed this misspelling: esb.lisenters.http.enable = false

- I think most XMPP connections will go through the same server, so if you dont specify details, they will inherit from defaults (in grouper-loader.properties):

 

###################################

## XMPP notifications defaults

###################################

 

## general xmpp configuration

xmpp.server.host = jabber.school.edu

xmpp.server.port = 5222

xmpp.user = grouperjabber

# note, pass can be in an external file with morphstring

xmpp.pass = **********

xmpp.resource = grouperServer

 

- note you can also inherit everything but the resource (or any other combination)

- XMPP change log consumers can specify the resource to connect with

- XMPP change log consumers can specify multiple jabber ids to send to, comma separated

- extracted the XMPP connection code to a common Grouper class: XmppConnectionBean, so that we can maintain XMPP code in one place.  This also reuses connections so we  need fewer connections to the xmpp server

- note: also we do not disconnect anymore at the end of each change log batch, this will be more efficient

- use the source when looking up subject (more efficient)

- cache the subject in the EsbEvent (more efficient if subject used in filter)

- removed my old XMPP change log consumer code, configured to work with ESB connector, recoded client to use json

 

https://spaces.internet2.edu/display/GrouperWG/Grouper+XMPP+notifications+v1.6.0

 

- ensured that the EL used by the ESB connector could filter by subject source, group name regex, and if a subject has an attribute, and flattened memberships only..  e.g.

 

changeLog.consumer.xmpp.elfilter = (event.eventType eq 'MEMBERSHIP_DELETE' || event.eventType eq 'MEMBERSHIP_ADD') && event.membershipType == 'flattened' && event.subjectHasAttribute('loginid') && event.sourceId == 'jdbc' && event.groupName =~ '^test\\:xmppGroups\\:.*$'

 

- if there was an exception sending to XMPP server, try to reconnect and resend

- change the xmpp authentication method default to SASL-PLAIN instead of default of GSSAPI

- added some javadoc comments to reduce eclipse warnings

- added sequence number to esb event so that the receiver can tie each message back to something easily (e.g. if problem), also added sequence numbre to more log messages

- added grouperUtil to the EL context

- if name or description is an attribute to send, will do subject.getName() or subject.getDescription()

- NOTE: should we have multivalued subject attributes in the object model, or just comma separated (currently is just comma separated)

- removed the require attribute or require source in client config, put in the same elfilter as on server

 

Rob, sorry to ask, but do you mind running your tests again to make sure everything is ok?  :)

 

Note: when we change the EsbEvent in the future, we do need a versioning strategy so old recipients don’t break?

 

Thanks!

Chris

 

 



  • xmpp merge with esb, Chris Hyzer, 06/01/2010

Archive powered by MHonArc 2.6.16.

Top of Page