Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

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

Gary

--On 18 June 2008 05:38 -0400 Chris Hyzer 
<>
 wrote:

> Ok, that wasn't too big of a deal, I refactored per my previous email and
> all unit tests pass.
>
> The next step is change the data layer a little more.
>
> Right now if the hook gets GroupDTO, it would be nice to get back to the
> Group object so that all the group members can be listed.
>
> The Group object has two fields, the GrouperSession (who to run queries
> as for security), and the GroupDTO.  So if the GroupDTO knows the
> GrouperSession, then we can get to a Group object.  Since the GroupDTO
> can be cached (and since in OO it doesn't belong anyway), we don't want
> the DTO to have a reference to GrouperSession.  So...
>
> The proposal is to do a ThreadLocal and inverse of control (IOC) on
> GrouperSession similar to the way the HibernateSession works with long
> running transactions, and not have the Group object keep a reference to
> GrouperSession.  We need IOC since in ThreadLocals we need to remove it
> when it is done.
>
> Existing code would need to be modified
>
> FROM:
>
> GrouperSession grouperSession = GrouperSession.start(subject);
> ...do work...
> grouperSession.stop();
>
> TO:
>
> GrouperSession.callbackGrouperSession(subject, new
> GrouperSessionHandler() {   public Object callback(GrouperSession
> grouperSession) {
>     ...do work...
>   }});
>
> Then at that point, the business object only has a 1 to 1 reference to
> DTO, so we could just get rid of DTO so the hooks would be very easy to
> use (you only have to worry about business object, you can list members
> with the object you receive, etc).
>
> We could deprecate the existing session strategy, but the problem is if
> you don't close your session in the current way you are still good to go.
> If you don't close your session with threadlocals (new way), bad things
> can happen...  so I suggest doing what we did with hibernate long running
> transactions and make the switch...  but if we want to deprecate and
> people will still compile but might or might not work, that fine too.  :)
>
> Im not sure this is feasible, so the first thing to do is try it and see
> if there are problems...
>
> Anyone have existing code that this would break or anyone have other
> objections?  Let me know thoughts asap.
>
> Thanks!
> Chris
>
>
> > -----Original Message-----
> > From: Chris Hyzer
> > Sent: Monday, June 16, 2008 10:07 PM
> > To: Grouper Dev
> > Subject: refactor the DAOs
> >
> > Hey,
> >
> > Gary and I were discussing how the Grouper data layer works.
> >
> > Currently it is a business object (e.g. Group) which talks to (and
> > delegates to) a DTO bean (e.g. GroupDTO), which talks to and lazily
> > delegates to a DAO bean (e.g. GroupDAO interface which is implemented
> > by Hib3GroupDAO).
> >
> > In doing hooks, there are some complications with this approach:
> >
> > 1. different hooks have access to different object layers, and not all
> > object layers have references to each other
> > 2. when doing things like getting diffs of what has changed, the DB
> > state of the object needs to be stored, but this is in the DAO at the
> > time of Hibernate, and that particular DAO is not kept around, another
> > is created when needed again, so the DB state needs to be propagated:
> > DAO -> DTO -> Business object -> DTO -> DAO
> >
> > Needless to say I am trying to simplify a little bit.
> >
> > My idea was to cut out a layer or two.  This would be a decent amount
> > of (re)work.  Gary's idea is to take the bean part out of the DAO, and
> > make it a singleton which is only responsible for data access queries
> > (which return DTO's).  The DTO's would hold the state of the object.
> >
> > I checked it out briefly, and Gary's idea would not require a lot of
> > code changes, and would simplify things, so I agree this is how we
> > should proceed.
> >
> > I will do this and see how it goes.  Let me know asap if anyone
> > disagrees or would like to discuss.  These objects weren't public
> > before and they are an implementation detail, else I would wait for a
> > call, but thought I would mention it on the list.  :)
> >
> > Thanks,
> > Chris



----------------------
GW Brown, Information Systems and Computing