Grouper Developers Forum

[Chris Hyzer <>]

>
> I've suggested to Chris, off list, that we don't need to use callbacks
> for
> the first GrouperSession.start invocation. This should cover common
> coding
> requirements. If you then need to start a new GrouperSession and do
> some
> work you would use the callback - otherwise a second
> GrouperSession.start
> (without a GrouperSession.stop) would throw and IllegalStateException.


I think this is a good idea.  GSH and the unit tests would benefit from 
this...

>
> I'm all for changing the API so that we then no longer need to keep
> passing
> GrouperSession as an argument to lots of methods, however, this is a
> change
> which if introduced without deprecation would break all existing code
> which
> calls the API - so, in order to upgrade, you would have to change all
> custom code and we would need to update the UI, WS, GSH and LDAPPC at
> the
> same time.

The feasibility of changes to the way GrouperSession is unknown, there are 
1000 references to GrouperSessionm in the API.  After analyzing it, it would 
make the API hard to use if the GrouperSession were not passed around at 
least to the top level public methods.  E.g. here is a method call:

GroupFinder.findByName(grouperSession, "someFolder:someGroup");

If the GrouperSession were not passed to it, it wouldn't be clear that a 
GrouperSession needs to be opened...  however, inside that method, it creates 
a Group, sets the GrouperSession to a field, and does some logic.  So I think 
if we can keep the method signature (of public methods that need a session), 
but on the inside, use a callback which would not require setting a field, 
then: the API wouldn't change that much, and the business objects wouldn't 
need GrouperSession as fields.  I will see if this isn't too traumatic... :)

Regards,
Chris