grouper-users - RE: Help with accessing web services
Subject: Grouper Users - Open Discussion List
List archive
- From: Chris Hyzer <>
- To: Paul Gazda <>, "" <>
- Subject: RE: Help with accessing web services
- Date: Fri, 27 Feb 2009 16:05:56 -0500
- Accept-language: en-US
- Acceptlanguage: en-US
> I was only
thinking of inserts, not updates for the errors. So it would be scenario 2. I think on an
insert, the displayName should be blank… since if you changed any display
extensions of parent stems, it wouldn’t do anything, so why be allowed to
put anything in there? However, we are already live, so its hard to
mandate that. Maybe a warning if you enter anything in displayName on
insert? > > But your
response does show that I don’t understand the interrelationship of the
methods. I assumed that in an update situation, if you had > this: > displayName = stemDisplayName:displayExtension > and you did
this: > wsGroup.setDisplayExtension(“newDisplayExtension”); > the
displayName would be updated to “stemDisplayName:newDisplayExtension”. > > From your
explanation in 3, I get the impression that you would have to do this: > wsGroup.setDisplayExtension(“newDisplayExtension”); > wsGroup.setDisplayName(“stemDisplayName:newDisplayExtension”); > > I’m not
understanding why the methods setDisplayExtension and setExtension exist at all
if the values ultimately have to be also set by > setName and
setExtension. Those beans are
used for multiple purposes. They are marshaled from XML, in which case
all getters and setters need to exist and be simple (not affect each
other). Also, you can use those beans for the API, in which case you need
to know what you are doing. I think warnings are the best way…
We could have a second set of objects for people to use, and then I could
convert those to beans for communication, or we could use interfaces somehow with
multiple implementations, but I was hoping not to have to do either of those.
We could also put the beans in “user-mode” where it would do that
logic for you, but in default mode they are simple. That is something I
am more open to if server side warnings arent enough. The advantage to
limiting it to server side warnings is that WS users who arent using the client
API would also benefit… Thoughts? Chris From: Paul Gazda
[mailto:] I was only
thinking of inserts, not updates for the errors. So it would be scenario 2. But your response
does show that I don’t understand the interrelationship of the methods. I
assumed that in an update situation, if you had this: displayName = stemDisplayName:displayExtension and you did this: wsGroup.setDisplayExtension(“newDisplayExtension”); the displayName
would be updated to “stemDisplayName:newDisplayExtension”. From your
explanation in 3, I get the impression that you would have to do this: wsGroup.setDisplayExtension(“newDisplayExtension”); wsGroup.setDisplayName(“stemDisplayName:newDisplayExtension”); I’m not
understanding why the methods setDisplayExtension and setExtension exist at all
if the values ultimately have to be also set by setName and setExtension. Paul Gazda From: Chris Hyzer
[mailto:] Yeah… we have some options here, I would prefer to do only
#1, but I am open to 2 and 3 if people want them: 1.
If there is a mismatch, I could not throw an error, and instead
just put some text in the warning field in the response to the web service
(there is a warning field where free-form text can go). *This is my
preference* a. The
use case where errors wouldn’t work is: retrieve a group, set the
displayExtension to something different, don’t bother syncing up the
displayName, and saving it. 2.
If it is an insert, and things don’t match, and its not
because they are blank, then I could throw an error (not sure why someone would
do that). 3.
If it is an update, and the displayName is different than it
used to be, but not in sync with the displayExtension, I could throw an
error. Im not sure about this one, its probably ok, but might affect some
legitimate uses Regards, Chris From: Paul Gazda
[mailto:] Thanks. It makes
sense the way you explain it. Just an opinion, but it might be better if an
explanatory error is thrown if a user tries to set a conflicting extension or
displayExtension for a groupSave operation. Paul Gazda From: Chris Hyzer
[mailto:] Yes! Finally a request which doesn’t look like a
bug. Though I admit it is weird. One of the requirements for web services was to have the same
object retrieved from web services, be sent on a save. However, the 4
fields of a group have some redundancy: name = stemName:extension displayName = stemDisplayName:displayExtension so… if you send a name which is not in sync with the
extension, then it will disregard the extension. If you send a displayName which is not in sync with the
displayExtension, it will disregard the displayName. Might seem a little weird, but it makes sense if you think about
it. Well, at least it does for me… J I updated the groupSave documentation to mention this: https://wiki.internet2.edu/confluence/display/GrouperWG/Group+Save OK? You should be able to pull the group up in the UI or GSH and see
consistent results. Thanks, Chris From: Paul Gazda
[mailto:] Chris, Thanks very much
for your quick response and feature enhancement. It works great! I did discover
what looks like a bug in the grouperClient display from the line command. Some
of the data is mixed up. The displayName field shows data for display
extension, and the extension field shows the last node of the group name, even
though I intentionally set the extension to a different value as a test. Program code:
wsGroup.setName("NAU:group name");
wsGroup.setDisplayName("NAU:group display name");
wsGroup.setExtension("group extension");
wsGroup.setDisplayExtension("group display extension");
wsGroup.setDescription("group description");
wsGroupToSave.setSaveMode("INSERT");
wsGroupSaveResults = gcGroupSave.execute(); grouper.client.properties: webService.findGroups.output
= Index ${index}: name: ${wsGroup.name}, displayName: ${wsGroup.display Name}, extension:
${wsGroup.extension}, displayExtension: ${wsGroup.displayExtension},
description: ${wsGroup.description}$newline$ java -jar
grouperClient.jar --operation=findGroupsWs --queryFilterType=FIND_BY_STEM_NAME
--stemName=NAU Index 0: name:
NAU:group name, displayName: NAU:group display extension, extension: group
name, displayExtension: group display extension, description: group description Paul Gazda From: Chris Hyzer
[mailto:] I made some improvements to the 1.4 branch to address your
issues: https://bugs.internet2.edu/jira/browse/GRP-230 1. If there is no lookup object on an insert, it should be ok 2. If there is a lookup, with a name, on an insert, and the name
is the same as the group name (nonlookup), then thats ok 3. If an insert, and the group already exists, then give the
error GROUP_ALREADY_EXISTS Get 1.4 branch with: cvs
-d:pserver::/home/cvs/i2mi login cvs -d:pserver::/home/cvs/i2mi
export -r GROUPER_1_4_BRANCH grouper cvs
-d:pserver::/home/cvs/i2mi export -r
GROUPER_1_4_BRANCH grouper-ws Regards, Chris From: Paul Gazda
[mailto:] Chris, A special response
code would be ideal, since the INSERT saveMode implies that you are counting on
the group not existing yet. However, I can analyze the error message for a
phrase if necessary, but the problem I am having is that I do not get
“group already exists with name:” anywhere in my error message. You
show this: Bad response from web service: resultCode:
PROBLEM_SAVING_GROUPS, There were 0 successes and 1 failures of saving
groups. java.lang.RuntimeException: edu.internet2.middleware.grouper.exception.GroupAddException: group already exists with name:
'aStem:aGroup4', What I get is
this: "Bad response
from web service: resultCode: PROBLEM_SAVING_GROUPS, There were 0 successes and
1 failures of saving groups. java.lang.RuntimeException:
java.lang.RuntimeException: Must
not pass in a name for an insert, Problem in
HibernateSession: HibernateSession: isNew: false, isReadonly: false,
grouperTransactionType: READ_WRITE_NEW, Problem in
HibernateSession: HibernateSession: isNew: true, isReadonly: false,
grouperTransactionType: READ_WRITE_NEW
at edu.internet2.middleware.grouper.ws.soap.WsGroupToSave.save(WsGroupToSave.java:365) . . . Paul Gazda From: Chris Hyzer
[mailto:] Sorry, this email slipped by me. I run this from grouper
client API public static void main(String[]
args) { WsGroupToSave
wsGroupToSave = new WsGroupToSave(); wsGroupToSave.setSaveMode("INSERT");
wsGroupToSave.setWsGroupLookup(new WsGroupLookup(null, null)); WsGroup wsGroup = new WsGroup();
wsGroup.setDisplayExtension("a group4"); wsGroup.setExtension("aGroup4"); wsGroup.setName("aStem:aGroup4"); wsGroupToSave.setWsGroup(wsGroup); try { WsGroupSaveResults
wsGroupSaveResults = new GcGroupSave().addGroupToSave(wsGroupToSave).execute(); //prints
SUCCESS_INSERTED when it works System.out.println(wsGroupSaveResults.getResults()[0].getResultMetadata().getResultCode()); } catch
(GcWebServiceError gwse) {
WsGroupSaveResults wsGroupSaveResults =
(WsGroupSaveResults)gwse.getContainerResponseObject(); System.out.println(wsGroupSaveResults.getResults()[0].getResultMetadata().getResultCode());
gwse.printStackTrace(); } } When it is not there, it prints: SUCCESS_INSERTED When it is there, it prints: edu.internet2.middleware.grouperClient.ws.GcWebServiceError:
Bad response from web service: resultCode: PROBLEM_SAVING_GROUPS, There were 0
successes and 1 failures of saving groups. java.lang.RuntimeException: edu.internet2.middleware.grouper.exception.GroupAddException: group already
exists with name: 'aStem:aGroup4', Here are the possible response codes to a group save: http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-ws/doc/api/edu/internet2/middleware/grouper/ws/soap/WsGroupSaveResult.WsGroupSaveResultCode.html?root=I2MI&view=co Do you want a special response code for an insert that indicates
the group was already there, or is EXCEPTION good enough? Thanks, Chris From: Paul Gazda
[mailto:] Hi Chris. Thanks for the
great help on how to access web services from within a java program. Your
example worked great. I am now venturing out and trying to do a GroupSave using
the GrouperClient.java code as a guide. The save operation works, but if I try
to save a group name that already exists and get an error message, I want to be
able to determine that the error was due to the group already existing rather
than some other reason. I have been unable to determine this from the error
message that is returned. I set saveMode =
"INSERT" because I do not want to modify an existing group if it
exists. If the group already exists, I get this error message: Grouper error
attempting to save group.
edu.internet2.middleware.grouperClient.ws.GcWebServiceError: Bad response from
web service: resultCode: PROBLEM_SAVING_GROUPS, There were 0 successes and 1
failures of saving groups. java.lang.RuntimeException:
java.lang.RuntimeException: Must not pass in a name for an insert, Problem in
HibernateSession: HibernateSession: isNew: false, isReadonly: false,
grouperTransactionType: READ_WRITE_NEW, Problem in
HibernateSession: HibernateSession: isNew: true, isReadonly: false,
grouperTransactionType: READ_WRITE_NEW I do not see
anything in the error message that tells me the group already exists.
e.getMessage() does not give me any different information. Is there a way I
can tell if the GroupSave failure is due to the group already existing? Thanks. Paul Gazda From: Chris Hyzer
[mailto:] I think the easiest and best way to use grouper web services by
code is to use the grouper client API. Here is an example below that I
tested and it works. All the configuration is in the
grouper.client.properties file, and you only need the grouperClient.jar.
Here are the classes you should be using: Here are all the underlying beans: Full javadoc: http://middleware.internet2.edu/dir/groups/grouper/grouper/1.4.1/gc/api/index.html Here are example grouper client calls: That said, I need to put more examples on the grouper client
website, if you need help doing something, let me know and I can beef up the
docs. Your other code either needs all the dependent jars, or to use
the classes in the classpath of the grouperClient.jar. I took in a
minimal number of 3rd party jars into the grouper client jar, and
changed their classpath so nothing conflicts. I wanted this to be very
easy for non java people to use, so it is one jar and one config file, and an
easy command line. Java is not as easy to kick off with multiple jars,
and less easy to upgrade etc… there are disadvantages here (like
your confusion), but I think the pros outweigh the cons. Regards, Chris /* * @author mchyzer * $Id$ */ package
edu.internet2.middleware.grouperClient.poc; import
edu.internet2.middleware.grouperClient.api.GcFindStems; import
edu.internet2.middleware.grouperClient.ws.beans.WsFindStemsResults; import
edu.internet2.middleware.grouperClient.ws.beans.WsResultMeta; import
edu.internet2.middleware.grouperClient.ws.beans.WsStem; import
edu.internet2.middleware.grouperClient.ws.beans.WsStemQueryFilter; /** * */ public class FindStem { /** * @param args */ public static void main(String[]
args) { GcFindStems
gcFindStems = new GcFindStems(); WsStemQueryFilter
wsStemQueryFilter = new WsStemQueryFilter();
wsStemQueryFilter.setStemName("penn");
wsStemQueryFilter.setStemQueryFilterType("FIND_BY_STEM_NAME_APPROXIMATE");
gcFindStems.assignStemQueryFilter(wsStemQueryFilter); WsFindStemsResults
wsFindStemsResults = gcFindStems.execute(); WsResultMeta
resultMetadata = wsFindStemsResults.getResultMetadata(); if (!"T".equals(resultMetadata.getSuccess()))
{ throw new
RuntimeException("Error finding stems: " + resultMetadata.getSuccess()
+ ",
" + resultMetadata.getResultCode()
+ ",
" + resultMetadata.getResultMessage()); } WsStem[] wsStems =
wsFindStemsResults.getStemResults(); if (wsStems != null) { for (WsStem wsStem
: wsStems) {
System.out.println(wsStem.getName()); } } } } |
- RE: Help with accessing web services, (continued)
- RE: Help with accessing web services, Paul Gazda, 02/13/2009
- RE: Help with accessing web services, Chris Hyzer, 02/18/2009
- RE: Help with accessing web services, Paul Gazda, 02/18/2009
- RE: Help with accessing web services, Chris Hyzer, 02/18/2009
- RE: Help with accessing web services, Chris Hyzer, 02/20/2009
- RE: Help with accessing web services, Paul Gazda, 02/25/2009
- RE: Help with accessing web services, Chris Hyzer, 02/25/2009
- RE: Help with accessing web services, Paul Gazda, 02/27/2009
- RE: Help with accessing web services, Chris Hyzer, 02/27/2009
- RE: Help with accessing web services, Paul Gazda, 02/27/2009
- RE: Help with accessing web services, Chris Hyzer, 02/27/2009
- RE: Help with accessing web services, Paul Gazda, 02/27/2009
- RE: Help with accessing web services, Chris Hyzer, 02/27/2009
- RE: Help with accessing web services, Paul Gazda, 02/25/2009
- RE: Help with accessing web services, Paul Gazda, 02/18/2009
- RE: Help with accessing web services, Chris Hyzer, 02/18/2009
- RE: Help with accessing web services, Paul Gazda, 02/13/2009
Archive powered by MHonArc 2.6.16.