Archive for October, 2008

In one of our current integration projects, where we were using Spring, we had a Spring bean which was constantly running every 20 to 30 seconds pooling the database and fetching new status of records. These statuses would be constantly sent to our client as and when new status came up. This Spring bean is a simple Quartz(From opensymphony) bean of the class MethodInvokingJobDetailFactoryBean.

<bean id="jobBean" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
     <property name="targetObject" ref="queryDatabaseServiceTX" />
     <property name="targetMethod" value="getStatus" />

Here the queryDatabaseServiceTX(Spring bean) is the business service with the method getStatus that actually retrieves the status and performs some updates also.

After this we define two more beans in the Spring context

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
    <property name="triggers">
            <ref bean="simpleTrigger"/>

<bean id="simpleTrigger" class="org.springframework.scheduling.quartz.SimpleTriggerBean">
    <property name="jobDetail" ref=" jobBean " />
    <property name="startDelay" value="10000" />
    <property name="repeatInterval" value="30000" />

Recently we started noticing that multiple threads were instantiated and the business service was called multiple times. This eventually was causing multiple updates to occur. Our design was such that the scheduler should run sequentially, repeating itself every 30 seconds. However sometimes when the database is under too much load the query execution itself takes more than 30 seconds and the next thread is spawned causing dead lock kind of situations.

To overcome this we found a silver bullet. Following was the modification done.

<bean id="jobBean" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean">
   <property name="targetObject" ref="queryDatabaseServiceTX" />
   <property name="targetMethod" value="getStatus" />
   <property name="concurrent" value="false" />

Setting the attribute concurrent to false ensures that no more threads are spawned until the first one is successfully completed.

Read Full Post »

I have been working with wicket for the last one year. It is one of the best web frameworks. In our organization, we are using Oracle Application Sever (OAS) to deploy our applications. We were using OAS and we had no issues with wicket. Recently we upgraded our OAS to and then issues started to appear one after the other.

The first issue that we were facing was with securing the application. We are using Oracle LDAP as our user manager for Authorization and Oracle SSO (Single Sign On) for authentication. The authentication and authorization are working fine if the URL used to access the application is not terminated by a slash “/”. Users are asked to login and only authorized user can access the application. However authentication and authorization are bypassed when the URL used to access the application is terminated with a slash “/”. Users are not even asked to login to the system to access the application.

After debugging and investigating, we noticed that if we use wicket servlet to load our application instead of wicket filter, then the security issue is resolved. However that brought up another issue that is there even in OAS 9.0.4.

The second issue is that, when using wicket servlet, the context which is specified in the servlet mapping in web.xml is omitted by OAS. The same problem was reported in wicket forum [1] and [2]. The context was omitted while sending the response back to the client only and not while sending the request to the server. The reason for this behavior is still ambiguous but we have developed a workaround for the issue. We have implemented a filter that adds the omitted context to the response. Here is our sample filter code

package com.datel.sample.webapplication;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

public class ContextFilter implements Filter{

	private FilterConfig config;

	//Used to store the servlet mapping URL that is defined in the web.xml
	private String servletMappingContext;

	public void destroy() {
		config = null;
		servletMappingContext = null;

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		HttpServletRequest httpRequest = (HttpServletRequest)request;
		HttpServletResponse httpResponse = (HttpServletResponse)response;

		if(servletMappingContext == null || servletMappingContext.length()==0)
			//The getRequestURI returns the full context i.e. /sampleWicket/app/

		myServletResponse newResponse = new myServletResponse(httpResponse);
		chain.doFilter(request, newResponse);

	private void setServletMappingContext(String requestURI) {
		//1. remove last / if it exists
		if (requestURI.endsWith("/"))
			requestURI = requestURI.substring(0, requestURI.length()-1);

		//2. get only the servlet mapping defined in web.xml i.e /app
		requestURI = requestURI.substring(requestURI.lastIndexOf("/"));

		//3. remove the prefixed /
		requestURI = requestURI.substring(1);

		//4. append the / at the end
		servletMappingContext = requestURI+="/";

	public void init(FilterConfig config) throws ServletException {
		this.config = config;

	class myServletResponse extends HttpServletResponseWrapper
		public myServletResponse(HttpServletResponse arg0) {
		public void sendRedirect(String arg0) throws IOException {
			// Add the context to the query string


In the web.xml you need to add the filter:


Please note that this filter will always add the context to the query string and thus it will only work with Application servers that omit the context. It will not work with Tomcat for example. This is because in the response we don’t have handle to the full URL. We have a handle only to the query string.

Due to that we have reported the first issue, Securing Web Applications, to Oracle Support. Oracle was able to reproduce the problem and they agreed to file it as a bug and they suggested to download the latest patchset 5983622 Oracle Fusion Middleware to resolve the problem. We have done so and our application is now secured without the need to go for wicket servlet. We were using Wicket 1.3.4.

[1] http://www.nabble.com/wicket-servlet-mapping-to-subdirectory-td18012945.html#a18012945
[1] http://www.nabble.com/Wicket-cannot-work-on-OC4J-(ias-10g)–td16738242.html#a16744020

Read Full Post »