Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] RE: refactor the DAOs

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] RE: refactor the DAOs

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Grouper Dev <>
  • Subject: RE: [grouper-dev] RE: refactor the DAOs
  • Date: Tue, 24 Jun 2008 02:22:42 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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 :) ).

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]


> -----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

Archive powered by MHonArc 2.6.16.

Top of Page