Yeah we did a lot of work around Groups to actually support them in Shindig. Along the way we found that the Group Id implementation didn't exactly follow the spec.
Doug are you basically extending GroupId with your own custom "@" id? We didn't consider this case, we basically support the @ ids from the spec and then object id, so it makes sense that if you pass another id we throw that exception. I think we might have to come up with a way that we can allow consumers to extend this...would that make sense for your use case? -Ryan From: Henry Saputra <[email protected]> To: [email protected], Date: 06/06/2012 01:48 PM Subject: Re: GroupId The change was part of the commits for SHINDIG-1780. Ryan could probably help with this. - Henry On Wed, Jun 6, 2012 at 9:52 AM, daviesd <[email protected]> wrote: > Some changes were made to GroupId between 2.5-beta1 and 2.5-beta2 that are > affecting me. > > GroupId.Type changed from this > > all, friends, self, deleted, groupId; > > To this > > objectId(0), self(1), friends(2), all(3); > > We had extended AppDataService to support a groupId of @institution > (something that is relevant in our domain) > > osapi.appdata.get({ > userId: '@me', > groupId : '@institution', > appId : '@app'} ) > > However, I have concerns as to how this will work now, because I¹m fighting > through a unit test that does this > > groupId = GroupId.fromJson("@institution") > > And it¹s throwing a IllegalArgumentException. > > Can some one point me in the right direction as to how I¹m suppose to handle > something like this? > > Thanks, > doug >
