Grouper Developers Forum

[Chris Hyzer <>]

I have completed removing the GrouperSession from the business objects, and 
now will tackle removing the DTOs so all we are left with are business 
objects that store data (then I can continue with hooks :) ).

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

Basically for normal Grouper use there are no changes to the API...  the only 
change is if you are not hierarchically using GrouperSessions, e.g.

GrouperSession a =
GrouperSession b=

use a
use b

You can code this way if you want with inverse of control however.

GrouperSession a =
GrouperSession b =

Use a in inverse-of-control
Use b [optionally in inverse-of-control... optionally because it was the last 
created, so it is ready to go without inverse-of-control]

Regards,
Chris

> -----Original Message-----
> From: Chris Hyzer 
> [mailto:]
> Sent: Thursday, June 19, 2008 9:56 AM
> To: GW Brown, Information Systems and Computing; Grouper Dev
> Subject: RE: [grouper-dev] RE: refactor the DAOs
>
> >
> > 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
>