grouper-dev - xmpp merge with esb
Subject: Grouper Developers Forum
List archive
- 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.