2.7.x, r71599.

Bumping to 2.6.3. UMich testing verification is not complete.

Yes. I think the group provider need to differentiate between the situations that (1) group doesn't exist or (2) group exist but with no member yet. Maybe return null for the first case and empty list for the second. And the code should only deal with null value and generate the alert about group not found?

Right, if we're not expecting this particular piece of code to throw a generic RunTimeException then there's no reason to catch it here just to print out an error (http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html). I think the problem is that there is no known contract between the external providers (that I know of) what they are expected to return when something goes wrong. Null? Some specific exception? We had problems locally with this lately trying to work around the IdNotFoundException and nulls. I would like this to be consistent.

Another issue we had was does null mean the group wasn't found, or there was another problem with the provider (like the service/database was down/unreachable). Currently it might mean both. This is all a bigger issue.

If the group doesn't have any members then it won't allow you to assign it with the current code.

Really the group provider API should be firmed up to allow for the existance of a group to be tested for. Maybe returning null when a group can't be found?