2.3.2 -> 2.4M1

2.4.M1 -> 4.0M1

Major changes

4.0M1 -> 4.0M2

Major changes

4.0M2 -> 4.0

Discussions and Howtos

Turbine 4 Entity User Data Model, Facts and Discussion, Fulcrum Security

Updated content from Turbine developer mailing list discussion (Fri, 08 Jul 2016 11:11:50 GMT).


Security/Authentication is now separated and moved into Fulcrum Security. To get a better understanding...

... I started with a user model as an example and sketching the situations with some (pseudo) code. User instantiation is the first place, where a new user model comes into place - may be a good starting point.

To get a new user instance in

  1. Turbine-4-M1
  2. Turbine-4-M2, Turbine-4

consider this (pseudocode) examples in

  1.   org.apache.turbine.services.security.TurbineSecurity.getUserInstance()  {
        return getService().getUserInstance()

    where service could be e.g. org.apache.turbine.services.security.BaseSecurityService and the userInstance looks like

     return (org.apache.turbine.om.security.User) getUserClass().newInstance(); 

    The userClass / userInstance is configured in Turbine configuration e.g. setting

     services.SecurityService.user.class= org.apache.turbine.om.security.TurbineUser 
    which is the default user class.

    The contract interface is  org.apache.turbine.om.security.User.

  2. As configured by default
     services.SecurityService.user.manager = org.apache.turbine.services.security.DefaultUserManager 

    the method getUserInstance has a wrapped user instance:

       TurbineUser u = umDelegate.getUserInstance(); (1)
       return wrap(u); (2)
    • (1) umDelegate object implements
      • org.apache.fulcrum.security.model.turbine.TurbineUserManager (e.g. org.apache.fulcrum.security.torque.turbine.TorqueTurbineUserManagerImpl. Configuration is in Fulcrum roleConfiguration.xml. <role name="org.apache.fulcrum.security.UserManager" default-class="<umDelegate>">.

      The userInstance delegates further e.g. in

      org.apache.fulcrum.security.spi.AbstractUserManager.getUserInstance() and may look like this

        return T user = (T) Class.forName(getClassName()).newInstance(); 

      where the className is configured in Fulcrum XML configuration (componentConfiguration.xml.)

       <userManager><className>, which becomes the userDelegate in DefaultUserImpl (2) Since Turbine 4.0 wrap code looks like

        return (U) getUserWrapper(user); 
      It just wraps the user object to keep the contract, by default

      org.apache.turbine.om.security.DefaultUserImpl is an implementation of org.apache.turbine.om.security.User and wraps the userDelegate org.apache.fulcrum.security.model.turbine.entity.TurbineUser as configured in Fulcrum componentConfiguration.xml.

      The contract interface is <T extends org.apache.turbine.om.security.User>.


This is may be the most interesting part to understand, as the same User interface has been broken up and the semantics changed a little bit.

  1. - ( org.apache.turbine.om.security.TurbineUser is a class).

    org.apache.turbine.om.security.User (properties: password,  email, firstName, lastName, confirmed, createDate, loggedin, accessCounter, perm, temp, updateLastLogin, tempStorage,permStorage)

    • -> org.apache.turbine.om.security.SecurityEntity (properties: name, id, idAsObject)

      • -> ..

  2. org.apache.turbine.om.security.User (properties: confirmed, createDate, loggedin, accessCounter, perm, temp, updateLastLogin, tempStorage,permStorage)

    • -> org.apache.fulcrum.security.model.turbine.entity.TurbineUser (-)

      • -> org.apache.fulcrum.security.entity.ExtendedUser (properties: email, firstName, lastName, objectData)..

        • -> org.apache.fulcrum.security.entity.User (property: password)

          • -> org.apache.fulcrum.security.entity.SecurityEntity (properties: name,id)

        -> org.apache.fulcrum.security.model.turbine.entity.TurbineUserGroupRoleEntity (properties: userGroupRoleSet, add-/removeUserGroupRoleSet)

      -> ..

As a result there is now NO TurbineUser class any more (except occasionally a ORM generated class), but instead a new interface (in a different package) with some additional methods (cft. TurbineUserGroupRoleEntity) is present. This makes sense as the TurbineUser is now a special case in Fulcrum Security.

Default classes

  1. org.apache.turbine.om.security.TurbineUser implements org.apache.turbine.om.security.User 

  2. org.apache.turbine.om.security.DefaultUserImpl implements org.apache.turbine.om.security.User 

More Delegates

  1. -
  2. org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl (properties: email, firstName, lastName, password, objectData) Interfaces

    -> org.apache.fulcrum.security.model.turbine.entity.TurbineUser

    • Extended classes
      • -> org.apache.fulcrum.security.model.turbine.entity.impl.AbstractTurbineSecurityEntityImpl

        • -> org.apache.fulcrum.security.entity.impl.SecurityEntityImpl (properties: equals, hashCode, toString) Interfaces

          • -> org.apache.fulcrum.security.entity.SecurityEntity (properties: id, name)


Moved properties

The getter/setter for email, firstName, lastName, password moved from org.apache.turbine.om.security.User to the new interface org.apache.fulcrum.security.model.turbine.entity.TurbineUser.

Password is now in an interface org.apache.fulcrum.security.entity.User of its own, the other setter/getter methods are in org.apache.fulcrum.security.entity.ExtendedUser.

The new model properties entityId and entityName correspond probably to id and name in some way..

Old and New



Building Torque ORM with

<table name="turbine_user" idMethod="native" baseClass="<baseClass>" interface="org.apache.fulcrum.security.model.turbine.entity.TurbineUser">

could be done using as base class, but it´s NOT required. Example options for baseClass e.g.:

In this example the generated class in this case is just named TurbineUser by default.

SecurityService, UserManager

Both could be found in Turbine and Fulcrum. As said in [http://turbine.apache.org/turbine/turbine-4.0-M2/services/security-service.html] Fulcrum Managers are just delegates and should/could only be used from Turbine services in Turbine context.

More Examples

org.apache.turbine.services.security.SecurityService (userInstance, getUser..)

org.apache.turbine.services.security.UserManager (userInstance, authenticate

org.apache.fulcrum.security.SecurityService (userManager, ..)

org.apache.fulcrum.security.UserManager (userInstance, authenticate

How to handle extra columns in Turbine user table with Fulcrum Security


If you have to map colums other than firstName, lastName, email, password to a table you have to implement your own wrapper and set in TR.properties. PermStorage is by default considered in Fulcrum just "as is", i.e. it is saved only in objectData.


Fulcrum user: Turbine userDelegate: Fulcrum <userManager><className> componentConfiguration.xml

Turbine wrapper optional if you have additional columns:

Turbine wrapper:


in TR.properties.


Fulcrum security package just saves the permStorage in objectData by default.

(Pseudo) Code example


DefaultUserManager store(User user) 

calls Fulcrum e.g. TorqueAbstractUserManager

 saveUser(User user) 

 TorqueAbstractSecurityEntity u = (TorqueAbstractSecurityEntity)user;

u is the Fulcrum user class, which the user can set (the userDelegate).

If this user has additional properties they are not set, as permStorage is saved only in objectData by default.

Turbine4/Turbine4.0M1/Diff (last edited 2017-11-22 10:56:03 by GeorgKallidis)