Scott Eade <[EMAIL PROTECTED]> writes:
>Henning,
>I've been trying to catch you for days to ask you a couple of questions
>about your SecurityService proposal in fulcrum cvs HEAD.
Hi,
I've been busy with a project in the last days. Send me Mail, I usually
respond quite quickly.
>1. Can you please summarise the changes that your code introduces? I am
>particularly interested in knowing how this affects the ability to extend
>the TurbineUser table.
the most important change is the decoupling of the Torque table
description and the resulting Peers and Objects from the Security
Object implementations. You still get the Peers and Torque Objects,
but the service itself works with the DBGroup, DBUser, DBRole and
DBPermission objects (which are the only ones visible to the
application) and maps their fields to the Torque objects with the Peer
Managers (UserPeerManager, GroupPeerManager..., you get the idea). All
this mapping is done by Introspection and completely transparent to
the Turbine / Fulcrum application.
You can configure all the column names, the tables and the objects in
the Fulcrum.properties. We e.g. use it all the time of an application
which extends the Security System to the notion of "Accounts in
Groups" which map onto Turbine Users. We need additional fields in the
tables and simply add them, change the class definitions of the Torque
objects in Fulcrum and then "extend" the Security Objects as described
in the db-security-service.xml howto in the proposal.
>2. What is the status of your proposal? It looks to me like the code would
>have been moved from a proposal to the actual implementation by now, except
>that there may have been some concern with regards to other suggested work
>on the security service (which doesn't seem to have materialized).
Well, that's a tough question. The code itself works fine for us. I
think that many other projects (like Jetspeed or Scarab, which use the
Turbine security service, too) could benefit greatly from it. I do
have some more changes (mainly feature additions) and a few bug fixes
added which aren't in the jakarta repository yet. If you want them, I can
send it to you. Contact me directly via mail.
I do have another massive change to the security service, though,
which was absolutely necessary for the scaling of our application. I
ripped out the current SecuritySet (GroupSet, RoleSet, PermissionSet)
implementation which sucks rocks when it comes to
groupSet.getGroup(groupName) and replaced it with a Map-based
implementation which allows very fast lookup of name and
id. Unfortunately this change would affect the SecurityService
interface. No problem for our inhouse solution; big problem for the
Fulcrum code itself (but then again, we don't have a release yet :-) )
If you don't want to read about my opinion on apache project politics,
skip down now. You will find an example of how to expand the user
object. :-)
<mode="rant">
So now, you ask me: "If this is all so great, why isn't it in the CVS
repository, yet". Basically, the reason for this, is the fact that
many of my co-developers consider Turbine a "playground" for other
things. I consider Turbine the base of many of our applications and
I'm absolutely furious that things like the building process got
crushed for no reason and that for people that can't upgrade to the
lastest and greatest development tools every other morning, Turbine
and Fulcrum got broken again and again. When pointing this out, I got
told from one developer that "he's absolutely ready to take the fire
and does not care about it. He considers himself on the right way and
is ready to take some heat to show everybody that he's right. And the
book isn't ready yet (whatever this means)".
I'm unhappy about the decision making process in the projects, some
seem to be considered the personal "property" of some developers
("Fulcrum? Ah, let's screw Fulcrum, there is something else around the
bend. User base? We have no user base, because we have no
releases. Making a release? Ah no, let's not make a release, there are
some things, that will be eterenally changed and if we make a release,
we might get a user base and then we can't screw around with the stuff
like we used to do all the time").
I voted down the change to Maven B5 with a long explanation just as
required in http://jakarta.apache.org/site/decisions.html. This -1 got
ignored by some people with a "this is my stuff, I don't care about
other developers, votes suck if they don't go my way" attitude.
According to the apache guidelines, -1 votes with a reason are
considered a "veto" which must be resolved. Some developers seem to
have decided that "this would be a waste of time" and simply ignored
it. One considered "Fuck Henning" on IRC to be a reasonable reaction
to the veto. And that was it.
So at the moment, I don't waste my time with people who treat
community projects like it is their personal ~/scratch directory. I
wait till Turbine and/or Fulcrum will stabilize and maybe one day we
might even get releases of 'irrelevant things like the central build
tool'. But then again, maybe not.
We at INTERMETA have our internal CVS development tree and thanks to
the Apache License I'm neither required nor forced to put our changes
back into the main tree. I'd like to, but at the moment it would be a
waste of time which I don't have.
At the moment, our internal Fulcrum build tree differs from the jakarta one
by about 16.800 lines of code:
% cvs export -r HEAD -kk fulcrum > & /dev/null
% cvs -d :ext:[EMAIL PROTECTED]:/home/cvspublic export -r HEAD -kk
jakarta-turbine-fulcrum >& /dev/null
% diff -Nurb jakarta-turbine-fulcrum/src/java fulcrum/src/java | wc -l
16817
which splits down to
Security Service 12946 lines
Intake 1830 lines
other stuff 2041 lines
it would be moot to merge it to get told "I blow this away next
week. No, I don't care about your concerns. Did you test BTW
fooDevelop 0.0.2-snap-19700802.0824 from <some obscure server outside
apache.org>? There are no docs about it, but you surely have lots of
free time at hand to rework your 250 KLOC to work with it. Ah yes, and
we will move the whole building process over to this tool in about 15
minutes".
We're at the moment running a stripped down Turbine-2 with fully
integrated Fulcrum; remaining Turbine-2 services ported to Fulcrum and
running under the Fulcrum Service broker.
Everything uses commons.logging for its logging purposes and logging
is integrated and centralized into Log4J (No more fscking LogService,
which was a bad idea from the beginning anyway).
We use an intake service which is able to use multiple XML files
(Which is very important to us, because we use a module system where
every module of our application registers itself as a Turbine service
and contains its own intake files).
I do intend to put all of this stuff back into Turbine-2, once 2.2
_is_ released and we have a definite idea where to move with Fulcrum
besides "let's blow it away and maybe we can use an Avalon container
for it at some point". At the moment, I'm more concerned with getting our
application to ship.
</rant>
>Of concern to me is the difficulty in extending TurbineUser. I need to be
>able to do this before I can migrate to turbine 2.2. Judging by the list
>activity this is of critical importance to many others also. I am happy to
>contribute to this effort in terms of documentation or whatever else is
>necessary (time permitting).
Docs should be included in the proposal. You basically do it like this:
--- your-torque-schema.xml ---
<table name="MY_USER" idMethod="idbroker">
<!-- Standard Turbine Columns. Definitions just like the original Turbine for the sake
of readability -->
<column name="USER_ID" type="INTEGER" required="true" primaryKey="true" />
<column name="LOGIN_NAME" type="VARCHAR" required="true" size="64"
javaName="UserName"/>
<column name="PASSWORD_VALUE" type="VARCHAR" required="true" size="16"
javaName="Password"/>
<column name="MODIFIED" type="TIMESTAMP"/>
<column name="CREATED" type="TIMESTAMP"
javaName="CreateDate"/>
<column name="LAST_LOGIN" type="TIMESTAMP"/>
<!-- (Putting these into the basic table was a fscking bad idea but we have to live
with it, now) -->
<column name="FIRST_NAME" type="VARCHAR" required="true" size="64" />
<column name="LAST_NAME" type="VARCHAR" required="true" size="64" />
<column name="EMAIL" type="VARCHAR" size="64" />
<column name="CONFIRM_VALUE" type="VARCHAR" size="16"
javaName="Confirmed"/>
<column name="OBJECTDATA" type="VARBINARY"/>
<!-- ****** Your Custom columns ***** -->
<column name="MY_DATA type="VARCHAR" size="32" javaName="Data" />
<column name="MY_INTEGER type="INTEGER" javaName="Value" />
<unique>
<unique-column name="LOGIN_NAME"/>
</unique>
</table>
--- your-torque-schema.xml ---
Now you build a torque object with your schema. You should get MyUser
and MyUserPeer (names may vary according to the class creation policy
that you configured for torque but you get the idea).
Configure this to be your User class in the _DB_ Service (please not the DB!):
--- Fulcrum.properties ---
services.SecurityService.db.userPeer.class = com.mycompany.om.MyUserPeer
--- Fulcrum.properties ---
You don't _need_ any more properties, because everything else will be
retrieved either with Introspection from the peer object or the
defaults will be used, which is fine, because we copied the
definition of the stock Turbine table.
If you explicitly want to configure everything, you can use the
following properties:
--- Fulcrum.properties ---
#
# These are the defaults for the colum names in the Peer Object
#
services.SecurityService.db.userPeer.column.name = LOGIN_NAME
services.SecurityService.db.userPeer.column.id = USER_ID
services.SecurityService.db.userPeer.column.password = PASSWORD_VALUE
services.SecurityService.db.userPeer.column.firstname = FIRST_NAME
services.SecurityService.db.userPeer.column.lastname = LAST_NAME
services.SecurityService.db.userPeer.column.email = EMAIL
services.SecurityService.db.userPeer.column.confirm = CONFIRM_VALUE
services.SecurityService.db.userPeer.column.createdate = CREATED
services.SecurityService.db.userPeer.column.lastlogin = LAST_LOGIN
services.SecurityService.db.userPeer.column.objectdata = OBJECTDATA
#
# This is the class of the Torque objects returned by the Peer. If
# it is omitted, the class name is queried from the configured Peer.
#
services.SecurityService.db.user.class = com.mycompany.om.MyUser
#
# These are the bean properties for the required fields from the
# Torque objects. If omitted, these defaults are used:
#
services.SecurityService.db.user.property.name = UserName
services.SecurityService.db.user.property.id = UserId
services.SecurityService.db.user.property.password = Password
services.SecurityService.db.user.property.firstname = FirstName
services.SecurityService.db.user.property.lastname = LastName
services.SecurityService.db.user.property.email = Email
services.SecurityService.db.user.property.confirm = Confirmed
services.SecurityService.db.user.property.createdate = CreateDate
services.SecurityService.db.user.property.lastlogin = LastLogin
services.SecurityService.db.user.property.objectdata = Objectdata
--- Fulcrum.properties ---
Ok, now you ask yourself: "How can I access "MY_DATA" and
"MY_INTEGER"?. You simply write yourself a new class which extends the
implementation object from the database service:
--- cut ---
package com.mycompany.security;
import org.apache.fulcrum.security.impl.db.DBUser;
import org.apache.fulcrum.security.entity.User;
import com.mycompany.om.MyUser;
public class MyDbUser
extends DBUser
implements User
{
public MyDbUser()
{
super();
}
public String getData()
{
return ((MyUser) getPersistentObj()).getData();
}
public int getValue()
{
return ((MyUser) getPersistentObj()).getValue();
}
public void setData(String data)
{
((MyUser) getPersistentObj()).setData(data);
}
public void setValue(int value)
{
((MyUser) getPersistentObj()).setValue(value);
}
}
--- cut ---
and now (here comes the trick!), you tell the SecurityService (note
the absence of DB! This is the main security service and this trick is
not dependent on the DB Security Service!) no longer to return its
default User-implementation objects but your very own MyDbUser
objects:
--- Fulcrum.properties ---
#
# Tell the security service to return objects of this type as objects
# implementing the User interface.
#
services.SecurityService.user.class = com.mycompany.security.MyDbUser
--- Fulcrum.properties ---
and in your code you write
MyDbUser myDbUser = (MyDbUser) TurbineSecurity.getUser("test");
String data = myDbUser.getData();
That's it. If you need to change your Peer objects, no more
recompiling of Fulcrum or Turbine. Change them, extend your Custom
MyDbUser class, deploy. Works. You should've seen some of the loops we
went through before we got this... :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
