Grouper Developers Forum

[Tom Zeller <>]

Would anyone be interested in providing an Attribute class, in lieu of returning Set<String> or Map<String, Set<String>> ?

At Memphis, we started using JNDI Attribute and Attributes, but found them ungainly, so we wrote our own multi-valued Attribute class which essentially wraps a Map<String, Set<String>>, but which returns values in the order they were entered, and which doesn't allow null or empty "" strings.

So, a Source returns Subjects, and Subjects consist of an Identifier with many Attributes. Because attributes are fundamental to provisioning, it seems (to me to be) reasonable for them to have their own class.

Perhaps we might denote an Attribute as either multi- or single-valued for provisioning as well.

TomZ  

On Mon, Mar 23, 2009 at 9:14 AM, Chris Hyzer <> wrote:

Web Services / grouperClient currently assumes only single valued attributes... whoops.

I opened a bug to track this:

https://bugs.internet2.edu/jira/browse/GRP-257

Regards,
Chris

> -----Original Message-----
> From: GW Brown, Information Systems and Computing
> [mailto:]
> Sent: Monday, March 23, 2009 5:30 AM
> To: Chris Hyzer; Tom Zeller
> Cc:

> Subject: RE: [grouper-dev] exception handling and finders
>
> We definitely support multi-valued subject attributes. So long as
> getAttributeValue returns the first value of any multi-value, and
> getAttributeValues can still return a Set of a single String I think
> the
> changes are OK. Returning unmodifiable Sets sounds right - there may be
> quite a few other places where we should return unmodifiable
> collections.
>
> Gary
>
> --On 21 March 2009 23:39 -0400 Chris Hyzer <>
> wrote:
>
> >
> >
> > I made these changes to the Subject API, though I uncovered a
> dilemma.
> >
> >
> >
> > While taking the liberty of formatting the code, and removing eclipse
> > warnings of the subject API per the discussion below, I added generic
> > declarations to all of the collection types.  It turns out I believe
> that
> > Subject.getAttributes() should return a map of string keys and a
> > multivalued string value (currently it is only the vague Map return
> > type).  It should be: Map<String, Set<String>>.  The JDBC and JNDI
> > builtin implementations do this ok.  However, the handful of Grouper
> > implementations only return a Map<String, String> assuming that there
> are
> > no multivalued subject attributes, and RegistrySubject does not
> really
> > implement another method correctly either.
> >
> >
> >
> > So, first of all if this is not the correct return type, or if we
> don't
> > support multivalued subject attributes, let me know and maybe this is
> off
> > base.
> >
> >
> >
> > If so, then I propose an easy solution though it might require people
> to
> > change their code if they have a custom subject implementations…
> >
> >
> >
> > 1.       I suggest we make a BaseSubject just like we have a
> > BaseSourceAdapter (and use it for our built-ins as examples).  If
> > everyone who implements they source adapter has subclassed the
> > BaseSourceAdapter, then they have no work to do to upgrade to the new
> > finders, since I made methods in the abstract class (though they are
> > deprecated, so at some point you need to change your code).  Also, I
> > think there is shared logic so implementers don't have to do that
> > much…  but we can still code to the interface Subject.
> >
> > 2.       I think instead of having all Subjects return a map of
> String to
> > Set<String> (since that would mean the subject object would probably
> keep
> > its representation like that internally, which means a LOT of Set
> objects
> > which are not needed), we should get rid of that method
> > (getAttributes()).  I think it isn't really used anyways, and if so,
> > only to get a list of attribute names.
> >
> > 3.       We should add two methods: Set<String> getAttributeNames(),
> and
> > boolean isAttributeMultiValued(attributeName)
> >
> > 4.       We can document that we assume
> getAttributeValue(attributeName)
> > and getAttributeValues(attributeName) are only called when the
> attribute
> > is known to be single or multivalued (should check if so)…  this way
> > everything is as expected without extraneous Set's.
> >
> >
> >
> > In general, returning a set for an attribute value is dangerous
> anyway,
> > because if it is not Unmodifiable, then the caller can use it to edit
> the
> > subject's attributes.  And if it is unmodifiable, then it is another
> > layer to extraneous objects (though I guess
> > getAttributeValues(attributeName) should return Unmodifiable sets)
> >
> >
> >
> > Btw. I think the API and UI and WS (the main consumers
> > ofSubject.getAttributes() would not even be affected by this change…
> > see, I said it wasn't heavily used… J
> >
> >
> >
> > Thoughts?
> >
> >
> >
> > Thanks,
> >
> > Chris
> >
> >
> >
> > Ps. At some point I would like to continue a conversation we had last
> > year with the core committers about the value of lack of eclipse
> > warnings, since some of the warnings are useful, and if there are too
> > many, the useful ones are diluted and not seen…
> >
> >
> >
> >
> >
> >
> >
> > From: [mailto:] On Behalf Of Tom
> > Zeller
> > Sent: Tuesday, March 17, 2009 12:47 PM
> > To: Chris Hyzer
> > Cc:
> > Subject: Re: [grouper-dev] exception handling and finders
> >
> >
> >
> >
> >
> >
> > One open issue is should we do the same thing to the subject API
> (make
> > exceptions unchecked, and finders which return 1 result should take a
> > param as to whether or not null is an exception)?  I would have
> already
> > except I believe it would change the interface of custom sources, so
> > people would need to tweak them and recompile before upgrading to
> 1.5…
> > is this ok?
> >
> >
> >
> > The subject API seems simple enough that we should opt for
> consistency,
> > i.e. make the subject API like grouper.
> >
> >
> >
> > Should we roll the subject API into grouper as we did ldappc ?
> >
> >
> >
> > TomZ
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing
>