Grouper Developers Forum

[Chris Hyzer <>]

I have completed the removal of the DTO layer.  So now we have business 
objects (e.g. Group), and a data access layer which can be replaced (DAO's), 
but the access layer is essentially singletons, and the business objects are 
the beans which are mapped to the DB.

The goal here was that now when you get an object in a hook call, it will be 
a business object, and you can call business methods on it [e.g. 
group.getMembers() ].  There are other advantages also, like that we don't 
have to copy data back and forth all over the place, we can send a business 
object to the DB directly (since hibernated), there are fewer classes to deal 
with in the API...

The only public change is that now the DTO javabean property methods are 
available in the business object (most were already) [e.g. setCreateTime()].

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

All unit tests on the API pass.

The next step is to continue on the path of removing DB side effects from 
business object setters (to make the API easier to use, and to make the hooks 
more powerful since they can intercept multiple changes at once), also to 
work on hook features like computing diffs compared with DB [I think I might 
be done here], asynchronous hooks [underway], and to implement hooks on all 
the business objects and find more high level opportunities.

Btw, I think we *will* need to lists of hooks for each type since if we have 
an auditing suite that will be available (or a couple to choose from), it 
should self-install, and not rely on someone registering at each method...

Kind regards,
Chris

> -----Original Message-----
> From: Chris Hyzer
> Sent: Tuesday, June 24, 2008 2:23 AM
> To: Grouper Dev
> Subject: RE: [grouper-dev] RE: refactor the DAOs
>
> 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
> >