Introduction to iBatis or MyBatis, An alternative to Hibernate and JDBC

For those who does not know iBatis/MyBatis yet, it is a persistence framework – an alternative to JDBC and Hibernate, available for Java and .NET platforms. I’ve been working with it for almost six years, and I am enjoying it!

The first thing you may notice in this and following articles about iBatis/MyBatis is that I am using both iBatis and Mybatis terms. Why? Until June 2010, iBatis was under Apache license and since then, the framework founders decided to move it to Google Code and they renamed it to MyBatis. The framework is still the same though, it just has a different name now.

What is iBatis/MyBatis ?

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the MyBatis data mapper over object relational mapping tools.To use the MyBatis data mapper, you rely on your own objects, XML, and SQL. There is little to learn that you don’t already know. With the MyBatis Data Mapper, you have the full power of both SQL and stored procedures at your fingertips.

iBATIS is based on the idea that there is a value in relational databases and SQL, and that it is a good idea to embrace the industrywide investment in SQL. We have experiences whereby the database and even the SQL itself have outlived the application source code, and even multiple versions of the source code. In some cases we have seen that an application was rewritten in a different language, but the SQL and database remained largely unchanged.

It is for such reasons that iBATIS does not attempt to hide SQL or avoid SQL. It is a persistence layer framework that instead embraces SQL by making it easier to work with and easier to integrate into modern object-oriented software. These days, there are rumors that databases and SQL threaten our object models, but that does not have to be the case. iBATIS can help to ensure that it is not.

What is iBatis ?

• A JDBC Framework
• Developers write SQL, iBATIS executes it using JDBC.
• No more try/catch/finally/try/catch.
• An SQL Mapper
• Automatically maps object properties to prepared statement parameters.
• Automatically maps result sets to objects.
• Support for getting rid of N+1 queries.
• A Transaction Manager
• iBATIS will provide transaction management for database operations if no other transaction manager is available.
• iBATIS will use external transaction management (Spring, EJB CMT, etc.) if available.
• Great integration with Spring, but can also be used without Spring (the Spring folks were early supporters of iBATIS).

What isn’t iBATIS ?

• An ORM
• Does not generate SQL
• Does not have a proprietary query language
• Does not know about object identity
• Does not transparently persist objects
• Does not build an object cache

Essentially, iBatis is a very lightweight persistence solution that gives you most of the semantics of an O/R Mapping toolkit, without all the drama. In other words ,iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database communication (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based upon an object’s state, mapping of complex joins to complex object graphs, etc.).

iBATIS simply maps JavaBeans to SQL statements using a very simple XML descriptor. Simplicity is the key advantage of iBATIS over other frameworks and object relational mapping tools.

Using Spring Context in Oracle SOA 11g

Use case :
Use spring in Bpel to read,write huge files. Since default File Adapter works in Bpel memory this would be good for heavy lifting. I know we have options of java embedd and EJB, but since springs are considered as best java option I would like to explore this option.

Steps:
1. Create a SOA Project , Composite.

2. Create a java interface that has method for reading/writing files : IFileUtils.java method readWriteFile(String filename)

3. Create a java class that implements the IFileUtils interface for reading/writing files : FileUtils.java

4. Now if you dont see spring option in composite , update the Jdeveloper with "Spring & Oracle WebLogic SCA" using help->updates.

5. Create a Bpel process that will invoke the spring.

6. Drop a Spring context in composite :

Name : FileUtilsSpring
Create a new context : FileUtilitySpring.

7. Open FileUtilitySpring.xml and add below lines of code inside the bean tag aftre the below comment


The file should look like :

8. Now you should be able to wire the Bpel and spring component. It will generate the WSDL and load java classes, Composite should look like :

9. Add invoke to Bpel to add the spring context, assign required values

10. Deploy the code and Test in EM

How to avoid Spring Quartz job overlap

Quartz 1.x.x

per javadoc "Stateful jobs are not allowed to execute concurrently, which means new triggers that occur before the completion of the execute(JobExecutionContext jobCtx) method will be delayed."

StatefulJob extends Job and it does not add any new methods, to achieve this behavior make the following changes:
From:
public class MySchedulerJob implements org.quartz.Job {
void execute(JobExecutionContext context) {/* method implementation */}
}
To this:
public class MySchedulerJob implements org.quartz.StatefulJob {
void execute(JobExecutionContext context) {/*method implementation*/}
}

Quartz 2.x
Annotations are used in Quartz 2.x, StatefulJob is deprecated.

@DisallowConcurrentExecution
public class MySchedulerJob implements org.quartz.Job {
void execute(JobExecutionContext context) {/*method implementation*/}
}

Spring Security

Getting Started

I would suggest getting started with the applicationContext-security.xml that is found in the tutorial sample, and trimming it down a bit. Here’s what I got when I trimmed it down:

<?xml version="1.0" encoding="UTF-8"?> 
 
<!-- 
  - Sample namespace-based configuration 
  - 
  - $Id: applicationContext-security.xml 3019 2008-05-01 17:51:48Z luke_t $ 
  --> 
 
<beans:beans xmlns="http://www.springframework.org/schema/security" 
    xmlns:beans="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
                         http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
                        http://www.springframework.org/schema/security 
                         http://www.springframework.org/schema/security/spring-security-2.0.1.xsd"> 
 
 <global-method-security secured-annotations="enabled"> 
 </global-method-security> 
 
    <http auto-config="true"> 
        <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" /> 
    </http> 
 
    <!-- 
    Usernames/Passwords are 
        rod/koala 
        dianne/emu 
        scott/wombat 
        peter/opal 
    --> 
    <authentication-provider> 
        <password-encoder hash="md5"/> 
        <user-service> 
            <user name="rod" password="a564de63c2d0da68cf47586ee05984d7" authorities="ROLE_SUPERVISOR, ROLE_USER, ROLE_TELLER" /> 
            <user name="dianne" password="65d15fe9156f9c4bbffd98085992a44e" authorities="ROLE_USER,ROLE_TELLER" /> 
            <user name="scott" password="2b58af6dddbd072ed27ffc86725d7d3a" authorities="ROLE_USER" /> 
            <user name="peter" password="22b5c9accc6e1ba628cedc63a72d57f8" authorities="ROLE_USER" /> 
     </user-service> 
 </authentication-provider> 
</beans:beans>

This makes a good baseline for the modifications we’re going to make. But first…

Mapping XML Elements to Java Code

I found it very helpful at this point, before messing with the XML, to know where the Java code was that corresponded to the available XML elements. The basic class that Spring Security uses for mapping XML elements to beans is SecurityNamespaceHandler. The code in this class simply delegates XML elements to bean definition parsers. It’s easy to follow along and map XML elements to Java code in this way. Unfortunately, don’t expect extensive commenting in the Java code to help you

web.xml Changes

I agree with the Spring Security documentation and found it easier to extract the security-related stuff into its own XML configuration file. This allows you to play XML tricks and not require namespace-tagging for the security elements. First off, you have to include a reference to applicationContext-security.xml in your [Spring] initialization parameters in your web.xml file:

 <context-param> 
  <param-name>contextConfigLocation</param-name> 
  <param-value> 
   /WEB-INF/spring-app-servlet.xml
   /WEB-INF/applicationContext-security.xml
  </param-value> 
 </context-param>

Next, as instructed by the Spring Security getting started guide, you need to add the filter mapping. In my case, this went right after the <context-param> end tag, since I didn’t have any other filters:

    <filter> 
        <filter-name>springSecurityFilterChain</filter-name> 
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> 
    </filter> 
 
    <filter-mapping> 
      <filter-name>springSecurityFilterChain</filter-name> 
      <url-pattern>/*</url-pattern> 
    </filter-mapping>

This default mapping will run all requests to your application through Spring Security. Now we’re done with web.xml, and we move on to…

Database-Backed Authentication

In my case, my application was already configured to use a JDBC DataSource, so pointing Spring Security at my JDBC data source was as easy as modifying the authentication-provider element to reference my already configured Spring bean:

    <authentication-provider> 
     <jdbc-user-service data-source-ref="dataSource"/> 
    </authentication-provider>

Now, the immediate question I asked is – OK, what does the convention over configuration assume my database tables look like? If you look at the documentation of the JDBC authentication provider, you would expect to see that information there, but you’d be wrong.

Instead, you have to look at the SQL queries that are hard-coded in the JdbcDaoImpl class and infer the schema structure for yourself. This article has a graphical depiction of the basic schema down in section 5.4.

If you want to configure the queries that are used, simply match the available attributes on the jdbc-user-service element to the SQL queries in the Java class I referenced above. In my example, I wanted to simplify my schema by adding the user’s role directly to the user table. So I modified the XML configuration slightly as follows:

  <jdbc-user-service data-source-ref="dataSource"  
    authorities-by-username-query="select username,authority from users where username=?"/>

This allowed me to put values in the ‘authority’ column like ‘ROLE_ADMIN’ or ‘ROLE_USER’, which translate directly into Spring Security roles!

Configuring URL authorization

Mapping URLs to roles is really easy. In your http element, simply put successive elements like this:

        <intercept-url pattern="/admin/*.do" access="ROLE_ADMIN"  /> 
        <intercept-url pattern="/**.do" access="ROLE_USER,ROLE_ADMIN"  />

Note here that the ‘access’ attribute values directly correspond to the values returned by the second column of the authorities-by-username-query. The ‘.do’ mapping is what I arbitrarily chose for my application – you may have to adjust depending on what your application’s Spring-managed URLs look like.

Configuring and Branding Spring Security-managed Pages

Finally, I wanted to figure out where the pages related to Spring Security should be configured, so that I could modify them if I needed to. Somewhat oddly, Spring Security ships with a default login page whose HTML markup is located in a class file – DefaultLoginPageGeneratingFilter. We would (obviously) like to replace this with our own custom page. Since we are authenticating everything passing through the Spring servlet, we must use a JSP for this.

Add the following to the http tag in the security configuration file:

<form-login login-page="/login.jsp" />

Now you need to put the login.jsp page in your web application (generally in the WEB-INF directory). The basic structure of the page you’re creating will look like this:

<%@ page import="org.springframework.security.ui.webapp.AuthenticationProcessingFilter" %> 
<%@ page import="org.springframework.security.ui.AbstractProcessingFilter" %> 
<%@ page import="org.springframework.security.AuthenticationException" %> 
 
...
<form action="j_spring_security_check"> 
 <label for="j_username">Username</label> 
 <input type="text" name="j_username" id="j_username" <c:if test="${not empty param.login_error}">value='<%= session.getAttribute(AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY) %>'</c:if>/>
 <br/>
<label for="j_password">Password</label> 
 <input type="password" name="j_password" id="j_password"/> 
 <br/> 
 <input type='checkbox' name='_spring_security_remember_me'/> Remember me on this computer.
 <br/> 
 <input type="submit" value="Login"/> 
</form>

The names of the form elements and form action must match what is shown here otherwise your login form will not work!

Note also that this is a plain ol’ JSP page, and not under Spring control. It is likely that you could play with the servlet filter patterns in web.xml to bring these pages under Spring control, but that is a topic outside the scope of this brief tutorial.

There are a couple other pages you will want to configure.

Access Denied: This is the page the user will see if they are denied access to the site due to lack of authorization (i.e. tried to hit a page that they didn’t have access to hit, even though they were authenticated properly). This is configured as follows:

    <http ... access-denied-page="/accessDenied.jsp"> 
     ...
    </http>

Default Target URL: This is where the user will be redirected upon successful login. This can (and probably should) be a page located under Spring control. Configured as follows:

    <http ... > 
    ...
        <form-login ... default-target-url="/home.do"/> 
    ...
    </http>

Logout URL: The page where the user is redirected upon a successful logout. This can be a page located under Spring control too (provided that it allows anonymous access):

    <http ... > 
    ...
     <logout logout-success-url="/home.do"/> 
    ...
    </http>

Login Failure URL: Where the user will be sent if there was an authentication failure. Typically this is back to the login form, with a URL parameter, such as:

    <http ... > 
    ...
        <form-login ... authentication-failure-url="/login.jsp?login_error=1"/> 
    ...
    </http>

Putting it Together

Here’s what my whole sample Spring security configuration looked like when I was done:

<beans:beans xmlns="http://www.springframework.org/schema/security" 
    xmlns:beans="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd 
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.1.xsd"> 
 
 <global-method-security secured-annotations="enabled">
<!-- AspectJ pointcut expression that locates our "post" method and applies security that way 
  <protect-pointcut expression="execution(* bigbank.*Service.post*(..))" access="ROLE_TELLER"/> 
  --> 
 </global-method-security> 
 
    <http auto-config="true" access-denied-page="/accessDenied.jsp"> 
        <intercept-url pattern="/login.jsp*" filters="none"/>  
        <intercept-url pattern="/admin/editUser.do" access="ROLE_ADMIN"  /> 
        <intercept-url pattern="/admin/searchUsers.do" access="ROLE_ADMIN"  /> 
        <intercept-url pattern="/**.do" access="ROLE_USER,ROLE_ADMIN"  /> 
     <form-login authentication-failure-url="/login.jsp?login_error=1" default-target-url="/home.do"/> 
     <logout logout-success-url="/home.do"/> 
    </http> 
 
<authentication-provider> 
        <jdbc-user-service data-source-ref="dataSource" authorities-by-username-query="select username,authority from users where username=?"/> 
    </authentication-provider> 
 
</beans:beans>

Wrap-Up

Ironically, just as I was drafting this article, a smart colleague of mine happened to come to me telling me about all the problems he was having getting started with Spring Security. He complained about the lack of detailed documentation on the XML, and the fact that the getting started documentation really wasn’t comprehensive (both complains that I had as well). Note that this colleague also happened to be responsible for implementing Acegi Security with Spring in a prior project that we worked on together – so he was intimately familiar with the underlying technology. He ended up going back to the Java-based configuration mechanism in frustration!

Hope this helps you out and I always appreciate hearing your comments and questions.