Lately I was refactoring a application that acceses DB. Due it was using plain JDBC I decided to reimplement it using iBatis instead of Hibernate as I would do if starting from scratch.

I have used iBatis 1.x before, and now I decided to use the latest 2.0, and the Spring support.
I was keen to see that it was like using Hibernate support, very easy. In fact is easier to understand how things work than using Hibernate.

While reading the Spring reference guide I saw that the iBatis section didn’t cover most changes in
version 2, so I decided to complete it. You can read the full section here until Spring people update
it.

public class Account {
	private String name;
	private String email;

	public String getName() {
		return this.name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getEmail() {
		return this.email;
	}

	public void setEmail(String email) {
		this.email = email;
	}
}

<sql-map name="Account">
	<result-map name="result" class="examples.Account">
		<property name="name" column="NAME" columnIndex="1"/>
		<property name="email" column="EMAIL" columnIndex="2"/>
	</result-map>


	<mapped-statement name="getAccountByEmail" result-map="result">
		select
			  ACCOUNT.NAME,
			  ACCOUNT.EMAIL
		from ACCOUNT
		where ACCOUNT.EMAIL = #value#
	</mapped-statement>

	<mapped-statement name="insertAccount">
		insert into ACCOUNT (NAME, EMAIL) values (#name#, #email#)
	</mapped-statement>
</sql-map>

<sql-map-config>

	<sql-map resource="example/Account.xml"/>

</sql-map-config>

<bean id="sqlMap" class="org.springframework.orm.ibatis.SqlMapFactoryBean">
	<property name="configLocation"><value>WEB-INF/sqlmap-config.xml</value></property>

</bean>

public class SqlMapAccountDao extends SqlMapDaoSupport implements AccountDao {

	public Account getAccount(String email) throws DataAccessException {
		return (Account) getSqlMapTemplate().executeQueryForObject("getAccountByEmail", email);
	}

	public void insertAccount(Account account) throws DataAccessException {
		getSqlMapTemplate().executeUpdate("insertAccount", account);
	}
}

<!-- for more information about using datasource, have a look at the JDBC chapter -->

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	<property name="driverClassName"><value>${jdbc.driverClassName}</value></property>
	<property name="url"><value>${jdbc.url}</value></property>
	<property name="username"><value>${jdbc.username}</value></property>

	<property name="password"><value>${jdbc.password}</value></property>
</bean>

<bean id="accountDao" class="example.SqlMapAccountDao">
	<property name="dataSource"><ref local="dataSource"/></property>

	<property name="sqlMap"><ref local="sqlMap"/></property>
</bean>

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE sqlMap PUBLIC
  "-//iBATIS.com//DTD SQL Map 2.0//EN"
  "http://www.ibatis.com/dtd/sql-map-2.dtd">

<sqlMap namespace="Account">

	<resultMap id="result" class="examples.Account">
		<result property="name" column="NAME" columnIndex="1"/>
		<result property="email" column="EMAIL" columnIndex="2"/>
	</resultMap>

	<select id="getAccountByEmail" resultMap="result">
		select
			  ACCOUNT.NAME,
			  ACCOUNT.EMAIL
		from ACCOUNT
		where ACCOUNT.EMAIL = #value#
	</select>

	<insert id="insertAccount">
		insert into ACCOUNT (NAME, EMAIL) values (#name#, #email#)
	</insert>

</sqlMap>

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMapConfig PUBLIC
  "-//iBATIS.com//DTD SQL Map Config 2.0//EN"
  "http://www.ibatis.com/dtd/sql-map-config-2.dtd">

<sqlMapConfig>

	<sqlMap resource="example/Account.xml"/>

</sqlMapConfig>

<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
	<property name="configLocation"><value>WEB-INF/sqlmap-config.xml</value></property>
</bean>

public class SqlMapAccountDao extends SqlMapClientDaoSupport implements AccountDao {

	public Account getAccount(String email) throws DataAccessException {
		Account acc = new Account();
		acc.setEmail();
		return (Account)getSqlMapClientTemplate().queryForObject("getAccountByEmail", email);
	}

	public void insertAccount(Account account) throws DataAccessException {
		getSqlMapClientTemplate().update("insertAccount", account);
	}
}

<!-- for more information about using datasource, have a look at the JDBC chapter -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	<property name="driverClassName"><value>${jdbc.driverClassName}</value></property>

	<property name="url"><value>${jdbc.url}</value></property>
	<property name="username"><value>${jdbc.username}</value></property>
	<property name="password"><value>${jdbc.password}</value></property>

</bean>

<bean id="accountDao" class="example.SqlMapAccountDao">
	<property name="dataSource"><ref local="dataSource"/></property>
	<property name="sqlMapClient"><ref local="sqlMapClient"/></property>
</bean>

The Spring Framework has released the 1.1.5 version, the last one before 1.2 release candidate comes out with major improvements as Hibernate 3 and JMX support. As with previous versions I have uploaded it to the maven repository at ibiblio, so maven users can download automatically.

Until now, to use Acegi Security System for Spring in your web application you needed to add at least three filters and filtermappings to your web.xml, eg. to secure an application using form based authentication these lines had to be present in every web.xml:

<filter>
  <filter-name>Acegi Authentication Processing Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value>
  </init-param>
</filter>
<filter>
  <filter-name>Acegi Security System for Spring Http Session Integration Filter</filter-name>
  <filter-class>net.sf.acegisecurity.ui.webapp.HttpSessionIntegrationFilter</filter-class>
</filter>
<filter>
  <filter-name>Acegi HTTP Request Security Filter</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>Acegi Authentication Processing Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
  <filter-name>Acegi Security System for Spring Http Session Integration Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
filter-mapping>
  <filter-name>Acegi HTTP Request Security Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

With the latest changes in CVS (thanks Ben) you only need to add one filter and filter mapping to web.xml:

<filter>
  <filter-name>Acegi Filter Chain Proxy</filter-name>
  <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
  <init-param>
    <param-name>targetClass</param-name>
    <param-value>net.sf.acegisecurity.util.FilterChainProxy</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name>Acegi Filter Chain Proxy</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

And a bean definition to the Spring application context, specifying the actual filters and the urls to map.

<bean id="filterChainProxy"
  class="net.sf.acegisecurity.util.FilterChainProxy">
  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      PATTERN_TYPE_APACHE_ANT
      /**=authenticationProcessingFilter,httpSessionIntegrationFilter,securityEnforcementFilter
    </value>
  </property>
</bean> 

This approach allow you to reuse the bean across all your applications, as it won’t change if you’re using the same authentication schema (eg. form based). As a sideeffect also allows using ant patterns or regular expresions in the url mappings.

Juergen Hoeller has announced the release of Spring Framework 1.1.4

I’ve recently used Acegi for a simple application and as I wanted to know how
much it loads the webapp I used JMeter to benchmark it. I’ve just spent less
than 30 min. to setup everything, so yake it as is, just a small idea of what
involves adding the Acegi filters to process the requests.

What I have used:

• Tomcat 4.0.6
• Acegi 0.7.0
• JMeter 2.0.2

Acegi filters defined in web.xml:

• A ProcessingFilter made by myself
• HttpSessionIntegrationFilter
• SecurityEnforcementFilter

Here there are the results of three tries, each one with the number of threads,
the ramp-up (delay between threads in seconds), and the loops (number of times
the test was executed). The url tested was not secured.

You can see that the overhead of using Acegi is about 14% increase of access
time in every page when the load is high. When it’s low, the overhead is
higher, but not relevant.

The long awaited 0.7.0 relase of Acegi Security System for Spring is out. I’m happy to have contributed (just a bit) to this great project. And it is built with maven!!

Dear Spring Community

I’m pleased to announce the Acegi Security System for Spring release 0.7.0 is now available from http://acegisecurity.sourceforge.net. The project provides comprehensive security services for The Spring Framework. You can read about the features in detail at http://acegisecurity.sourceforge.net.

There are many changes, improvements and fixes in release 0.7.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). The major new feature areas are:

* Significant improvements to ACL security services

* AspectJ support (useful for instance-level security)

* Refactoring of ObjectDefinitionSources (especially useful for web URI security)

* Automatic propagation of security identity via RMI and HttpInvoker

* Integration with Servlet Spec’s getRemoteUser()

* Refactoring of Contacts sample to use the new ACL security services

* Additional event publishing (now includes authorisation, not just authentication)

* CVS restructure to use Maven as the build system

* A new project web site with FAQs, links to external articles etc

The new ACL security services deserve special mention, as they make it possible to develop applications that require complex instance-based security without any custom code. The entire configuration of such applications can be declared in the IoC container using standard Acegi Security services, so this should help significantly improve architecture and development time.

As per the Apache APR project versioning guidelines, this is a major release. We expect the next major release will be 1.0.0, although release 0.7.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page.

For Maven users, Acegi Security’s latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. We will also be adding release 0.7.0 and above to iBiblio.

We hope you find this new release useful in your projects.

Best regards

Ben