Just catching up on the thread here.. When I first started really working
on Fulcrum Security, I was looking to improve a couple things from the
original which was basically Turbine security with a new name.
I wanted to be able to move away from Torque and not just to another
persistence framework like Hibernate. Instead, I wanted to abstract all the
underlying persistence aspects from the API. I love Hibernate, but I know
that in 2 years I'll be using something else to access the database, but
I'll still be working with Fulcrum Security! I have been kicking around a
prevayler based provider for non database situations, and this works nicely
with Fulcrum security. The price of this was losing some of the goodies
that you can get by using the underlying objects directly.. However, where
ever possible, you should be able to get to the underlying objects to do
whatever you need to.
The other part was to break up the security entities so you can use just
what you need, and glue them together using your own model.. Again, this
does lead a bit to the managers only working on indidual enties, and leaving
it up to the ModelManager where you need to glue things together.
The last bit is that I inherited some things like the
RoleSets/GroupSets/PermissionSets.. I liked them because you didn't have a
ton of casting and could be sure that what was in a set was really what you
expected it to be. However, having said that, I found them a challenge as
well because they don't implement the Set interface to the letter of the
law..
And unfortunantly, if you use the use case that Michael Jones submitted:
SecuritySet ss;
...
if (shouldAdd) {
if (ss instanceof GroupSet)
((GroupSet) ss).add((Group) e1);
if (ss instanceof RoleSet)
((RoleSet) ss).add((Role) e1);
if (ss instanceof PermissionSet)
((PermissionSet) ss).add((Permission) e1);
}
You end up doing lots of icky casting anyway!
Now.. If Lester's approach here would work properly:
/* The RoleSet.add method */
public boolean add(Object obj)
{
if (obj instanceof RoleSet)
{
add((Role)obj);
}
else
{
super.add(obj);
}
}
Then I'd be very happy to commit those changes.. It would be nice if
Michael's usecase boiled down to:
ss.add(e1);
However, my only stipulation would be that we have some good unit tests
verifing this logic.. It feels like the kind of tricky thing that can bite
a developer.. They get an error doing ss.add(e1) and dont' realize the
somewhere buried down in the guts of the RoleSet.java interaction with the
Hibernate Set class is a bug!
Eric Pugh
> -----Original Message-----
> From: Mike Manner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 27, 2004 9:10 PM
> To: Turbine Users List
> Subject: Re: Fulcrum SecuritySet error
>
>
>
> Hi Lester,
>
>
> giving your example :
>
> >> Set roles = a_Group.getRoles();
> >>
> >> // All groups given the user role.
> >> Role role = (Role)m_RolesByName.get(k_RoleWhatever);
> >> assert(role != null);
> >> roles.add(role);
> >> a_Session.save(group);
>
> >>Whether this succeeds or not depends on the state of a_Group. If I just
> >>created the group myself, I would have had to call this code at
> some point:
>
> >> Set groupRoles = new HashSet();
> >> a_Group.setRolesAsSet(groupRoles);
>
>
> I don't think you have to do that, because the getRoles() method always
> return a RoleSet (empty if you have created the Group yourself).
>
> The methods getRolesAsSet() and setRolesAsSet() should never be used
> because their purpose is only hibernate mapping,
> use getRoles() and setRoles(Set) instead to play with RoleSet objects.
>
>
>
> There is another way to attach a group to a role, so that you don't need
> to care about all this :
>
> get a ModelManager object (an hibernate implementation) and use the
> "grant(group,role)" method...
>
> this method is doing the job for you (it adds the role in the group's
> RoleSet and the group in the role's GroupSet).
>
> hope this helps
>
>
>
> Lester Ward wrote:
>
> >>I am not sure exactly what you are trying to achieve and I am
> >>sorry if I have got the wrong end of the stick, but when you
> >>are adding the security elements you should use the managers.
> >>These encapsulate all the hibernate code for getting them into
> >>the database.
> >>
> >>
> >
> >The managers seem to involve manipulating single objects.
> Doesn't this sort
> >of defeat the purpose of using Hibernate, given it's incredibly useful
> >cascade abilities?
> >
> >Here is what I am doing:
> >
> >I have a pre-loaded map of roles (which in this system never
> really change).
> >I have a group and am trying to change it's roles. Based on the API, I'm
> >doing this:
> >
> > Set roles = a_Group.getRoles();
> >
> > // All groups given the user role.
> > Role role = (Role)m_RolesByName.get(k_RoleWhatever);
> > assert(role != null);
> > roles.add(role);
> > a_Session.save(group);
> >
> >Whether this succeeds or not depends on the state of a_Group. If I just
> >created the group myself, I would have had to call this code at
> some point:
> >
> > Set groupRoles = new HashSet();
> > a_Group.setRolesAsSet(groupRoles);
> >
> >
> >
> >In that case, I get this HashSet back when I call getRolesAsSet and
> >everything works great. If, however, a_Group is an existing group loaded
> >from the database, when I call getRolesAsSet, I get back a Hibernate set
> >that does the proxy thing mentioned in my first mail. Then the
> >roles.add(role) call fails.
> >
> >The saving of the group automatically saves the relation records with no
> >additional coding, one of the points of using Hibernate. I don't
> see how the
> >managers help in this case, because I don't see any methods for
> attaching...
> >
> >Ah! D'oh! There is my problem! I shouldn't be assigning to an
> interface! The
> >code should be:
> >
> > RoleSet roles = a_Group.getRoles();
> >
> >Interestingly, I got screwed here be a good habit: declaring variables as
> >interfaces, not objects. In other words, I always code like this:
> >
> > Set mySet = new HashSet();
> > List myList = new ArrayList();
> > Collection myCollection = new ArrayList();
> >
> >...not...
> >
> > HashSet mySet = new HashSet(); // Bad
> > ArrayList myList = new ArrayList(); // Bad
> >
> >This habit makes your code much more flexible in the long run,
> particularly
> >if you need to change performance characteristics. It screws me
> here because
> >the RoleSet isn't a complete implementation of the Set interface (which
> >makes me stand behind my previous e-mail on how to change it even more).
> >
> >Wordman
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
