This is primarily a bug-fix release. We believe most important bugs
have been identified and been resolved, which justifies a new major
release.
Below are the highlights of this release.
- many bug-fixes and improvements [ more
]
- additional constraints [ more ]
- easy way to retrieve a
RoleUsersManager [ more ]
Repository support for application-wide properties [ more ]
- merged dedicated XML selectors [ more
]
- added
XmlSelectorProperty [ more
]
Many bugfixes and
improvements
The following sections received a number of bugfixes
and were improved:
- continuations,
- web application engine,
- logout element,
- user identification,
- generic query manager,
- in-template OGNL statements,
- element implementations in Groovy,
- repository.
[ top ]
Additional constraints
Two new
constraints were added to ConstrainedProperty:
persistent and
saved.
Persistent allows you to indicate
that a bean property shouldn't be stored in a back-end data storage. It
will thus not be automatically persisted through, for example, a database.
This makes it possible to still use a bean as a central data entity and
have informational properties that should only be used to retrieve
information from the user.
Saved allows you to indicate
that a property shouldn't automatically save its value to a data store,
but it will still participate in the definition of the structure of the
data entity. For example, this makes it possible to continue to use one
place to define the table structure and use database triggers to fill in
the values instead.
[ top ]
Easy way to retrieve a
RoleUsersManager
The RoleUsersManager
class provides the functionalities to retrieve a
RoleUsersManagers from a particular
Authenticated element in a site.
Since you can have many authentication schemes and backends being
active in a single web application. it's quite verbose to retrieve a
RoleUsersManager when you want to perform some operations on
its stored credentials. This class provides the functionalities to quickly
perform this retrieval through the static getRoleUsersManager(Site
site, String authElementId) method.
You can thus very easily update a user's attributes, for
example:
public class BanUser extends Element
{
public void processElement()
{
String login = getInput("login");
RoleUsersManager credentials =
RoleUsersManagerRetriever.getRoleUsersManager(getSite(), ".AUTH_USER");
try
{
RoleUserAttributes attrs = credentials.getAttributes(login);
attrs.getRoles().add("banneduser");
credentials.updateUser(login, attrs);
}
catch (CredentialsManagerException e)
{
// handle the exception
}
}
}[ top ]
Repository support for
application-wide properties
Since Java allows the configuration of
an application through the use of properties, many other sub-system have
adopted a similar approach (for example servlet init parameters). Most of
the time an application runs through several barriers of configuration
that often function independently. Properties support in the
Repository makes it possible for each sub-system to add their
properties to the same pool. This makes it much more convenient to
retrieve a property value afterwards since they're all available from a
single source. In a RIFE web application these are for example, the system
properties and the servlet init parameters.
[ top
]
Merged dedicated XML
selectors
The dedicated XML selectors for Config and
Datasources have been merged in the a single
selector package since they provide the same functionalities.
This also made it possible to easily add dynamic XML file selection to the
MemoryScheduler.
So what was before
ConfigSelectorHostname, ConfigSelectorOs,
ConfigSelectorUser, DatasourceSelectorHostname,
DatasourceSelectorOs, DatasourceSelectorUser is
now available as XmlSelectorHostname,
XmlSelectorOs and XmlSelectorUser.
[ top ]
Added XmlSelectorProperty
A new XML selector has been added to automatically select an XML
file according to the rife.application property that is
looked up from the Repository properties. You can use this
selector for Config, Datasources and
MemoryScheduler. It's typically used to easily store all the
configuration for application variants in the same source repository and
set this property during the installation to indicate which variant to
use.
For example in tomcat's server.xml file by setting a context
parameter:
<Host name="test.myhost.com" appBase="/home/tomcat/test_myhost_com">
<Context path="" docBase="ROOT">
<Parameter name="rife.application"
value="test"
override="false"/>
</Context>
</Host>
<Host name="prod.myhost.com" appBase="/home/tomcat/prod_myhost_com">
<Context path="" docBase="ROOT">
<Parameter name="rife.application"
value="production"
override="false"/>
</Context>
</Host>[ top ]