Grouper Developers Forum

[Rob Hebron <>]

URL with notes on ESB connector (for call):

https://spaces.internet2.edu/display/~/Grouper+to+ESB
+design

-----Rob Hebron 
<>
 wrote: -----

To: Chris Hyzer 
<>
From: Rob Hebron 
<>
Date: 03/01/2010 04:54PM
cc: Grouper Dev 
<>
Subject: RE: [grouper-dev] ESB connector

-----Chris Hyzer 
<>
 wrote: -----

> We have a way to go from bean to json in GrouperUtil:

   */
  public static String jsonConvertTo(Object object) {

> I originally tried gson, but there was some problem that json-lib solved,
forget what it was.  Can we use that instead of gson?
If I remember correctly the bean one to manies need to be arrays instead of
collections so that reflection can work well.

I'll use a method in GrouperUtil then (I had chosen gson because it did a
better job of converting collections). I'll need to add a new method, as
wrapping the data in a simple class name cases the parser used by my ESB to
throw an exception.


> Are you saying the message is json, then gets converted to XML?  Can we
just send the new simple bean and the converter can convert to json or xml
or something else?  I would think that might be more convenient /
efficient.

> We use xstream to convert javabean to xml, which works well when the
format isn't specified.  I have used xml-beans to map to arbitrary xml
format, and it works fine.  I tried to look for a doc/link to see which is
better castor or xmlbeans, and I cant find one.  Do you have one?  Do you
need to map to an arbitrary format or specify it?

I'm keen to make the XML as simple as possible and leave it up to the user
if it needs to be more complex/be in a certain format etc. (hence Castor,
which gives a a lot of control which can be controlled through
configuration), and the JSON conversion strips everything out nicely. To be
honest, XML isn't top priority so I'll revisit when I get on to testing
this part.

I've got a prototype up and running. It needs a minor change in
GrouperLoaderType and ChangeLogConsumerBase to pass the consumer name
through so that properties can be retrieved easily by the quartz-invoked
job. Also, I'd like to change the use of GrouperUtil.stripStart (line 744,
GrouperLoaderType) as I found that it was easy to use characters at the
start of the consumer name that are in those which are stripped - this
causes an error to be thrown.

Rob