Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: Scott Koranda <>
  • Cc: Michael Hodges <>, "" <>
  • Subject: Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014
  • Date: Thu, 14 Aug 2014 19:35:08 +0000
  • Accept-language: en-US

It should be quite feasible to distribute AMQ within the Grouper install and
have it come up just as grouper does.
Lots of products come with embedded components. A small org could run
grouper and not even care there is AMQ.


On Aug 14, 2014, at 2:53 PM, Scott Koranda

> On Thu, Aug 14, 2014 at 1:35 PM, Michael R. Gettes
> <>
> wrote:
>> We share the same vision Michael. Our changelog consumer makes use of the
>> AMQ library calls. It shouldn’t be hard to substitute XYZ broker API to
>> make it compatible with Rabbit and so on.
> +1
> I understand the value proposition for making AMQ the preferred
> message broker, and a tight
> integration with Grouper makes sense to me, but I would like to see
> the changelog consumer
> flexible enough so that one could "easily" use a different message system.
> I would also appreciate an effort to standardize on the message format(s).
> I disagree with Michael about a change log consumer that provisions
> directly to LDAP. For smaller
> campuses and virtual organizations a change log consumer that directly
> provisions to LDAP (including
> a bulk synchronization mode or cycle) is preferred even if a messaging
> system like AMQ ends up being
> well integrated with Grouper. Having the additional message broker
> piece adds extra complexity
> that smaller organizations simply do not want to deal with. The
> Grouper team always has to make
> tradeoffs and decisions about where to invest limited effort and IMHO
> it is worth the effort to have
> a simple LDAP provisioner not bound to a messaging system that is
> known to support the major
> LDAP implementations (OpenLDAP, 389, Sun/Oracle, MS AD).
> Thanks,
> Scott K

Archive powered by MHonArc 2.6.16.

Top of Page