Re: GAP Keys

[Eric Dalquist]

I did the same exercise Peter did and can't find any reason the Class
used for the entity type has to implement IBasicEntity or any other GaP
class.

Mike / Dan,
Can you answer why uP3 classes need to implement IBasicEntity or any
other GaP interface?



Note, I'm sending this to everyone and to the uP3 mailing list that
Andrew was nice enough to create. It would be good if each of you could
subscribe to this list to make tracking uP3 email discussions easier.
The subscribe link is below.

http://groups.google.com/group/jasig-uportal3-dev/subscribe

-Eric



Peter Kharchenko wrote:

> Eric, Michael, others,
> Just browsing through the GAP code, I can't figure out why one
> couldn't use IPortletDefinitionId.class for type argument. There
> doesn't seem to be any direct instantiation or type checking ... but
> that's pretty easy to miss.
> So what breaks if we use the interface class there ? That would be an
> optimal solution, because that's what we're really trying to do -
> group all IPortletId entities.
>
> -peter.
>
> Eric Dalquist wrote:
>
>> While finishing up the GaP integration with the portlet manager I was
>> talking with Mike and realized that I had to rely on the
>> PortletDefinitionIdImpl class for the entity identifier type. This is
>> a big concern for me as it completely negates the effort of coding to
>> interfaces.
>>
>> Talking with Mike I understand that for an object to be used as a
>> group key it must implement the IBasicEntity interface from GAP. For
>> uP3 interfaces that we want to use for group keys we don't want to
>> tie them directly to the GAP framework so only the impl of the
>> IPortletDefinitionId implements this interface, tieing us to the use
>> of that implementation.
>>
>> An alternative which we talked about and will move to is to create
>> wrapper classes. Having a PortletDefinitionIdBaiscEntityImpl class
>> which implements IPortletDefinitionId, IBasicEntity and wraps another
>> IPortletDefinitionId will solve the problem of depending on objects
>> returning an interface of a specific implementation.
>>
>> We should try to follow this wrapper pattern in the future as well,
>> blindly casting interfaces (which is really what was happening here)
>> is dangerous and, as I said before, negates the whole point of coding
>> to interfaces.
>>
>>
>>
>>
>>
>> PS: While writing this I think it is about time to either move these
>> talks to the jasig-dev list or ask for a jasig-up3 mailing list.
>>
>>
>> -Eric
>
>

[Dan Ellentuck]

Eric is right. I think there may be a couple of misunderstandings
about keys in GAP. Maybe this will clarify:

1. In GAP, in order to be "grouped" an entity must be able to answer a
String key. It need not implement any interface.

2. This is because the groups service does not directly reference the
underlying entities to which it refers, like portlet definitions or
persons, but operates on stub objects: IGroupMembers, IEntities and
IEntityGroups. It is these stub objects that must implement
IBasicEntity, which allows them to be grouped, cached and locked.

3. The groups service "registers" known "entity types", but these need
not implement IBasicEntity either, and in fact, you can register any
class or interface as an entity type, including Object and Thread.
This registration declares the allowable object types of entities
referred to by group members (the stub objects). A group with a given
"entity type" can contain stub objects whose underlying entity type is,
descends from or implements, the registered type. Perhaps "entity
type" is a misleading name. Maybe group type or leaf type would have
been better.

I'm going to cross-post this today, but will use only the list starting
tomorrow.

Dan

[Dan Ellentuck]

[Dan Ellentuck]

After re-reading item 3 in my last post and doing some checking, I
realized it was incorrect to say, "A group with a given 'entity type'

can contain stub objects whose underlying entity type is, descends from

or implements, the registered type...." In fact, a group's entity type
must equal, and not simply be assignable from, the entity type of its
members. I was confusing group entity type rules with those of the
entity caching system.

[Eric Dalquist]

Dan,
The checks are just string equality checks at the core aren't they?

-Eric

[Dan Ellentuck]

Hi Eric,

I was talking about validating the entity type of a
prospective group member; it must equal the entity type of
its containing group. In this narrow context, equals is
being applied to objects of type Class. However, I think
you may be asking how are group members and IBasicEntities
in general checked for equality, and here, String equality
checks ARE at the core.

Dan