Tag Archives: Spring

[Note To Self] Spring Security Default Target URL

Just a quick note to self on Spring Security Default Target URLs. In one of my recent projects, I noticed that suddenly my Spring Security based login does not use the specified default target url in the configuration. Instead, it was hitting the root of the application always. This application was working perfectly fine until recently, and default target URL has not been changed since.

The Spring Security definition was:

<security:http auto-config="true">
   <security:intercept-url 
      pattern="/!/signin" 
      access="IS_AUTHENTICATED_ANONYMOUSLY" />
   <security:intercept-url 
      pattern="/!/**" 
      access="ROLE_LOGIN" />
   <security:form-login 
      login-page="/!/signin"
      default-target-url="/!/"
      login-processing-url="/!/authenticate" 
      authentication-failure-url="/!/signin#failed"
      authentication-success-handler-ref="authenticationSuccessHandler" />
   <security:logout logout-url="/!/signout" logout-success-url="/!/signin" />
</security:http>

After debugging through Spring Security code, I noticed that the defaultTargetURL of AbstractAuthenticationTargetUrlRequestHandler is not set to my value, but it uses the default ‘/’. Then after some digging up, it turned out that I’ve added a new Authentication Success Handler to my definition for a different purpose, and when an authentication-success-handler-ref is present in the configuration, the ‘default-target-url’ element in XML configuration is not used.

To fix this, the solution was  to specify the default target URL on my authentication success handler bean as follows.

<bean id="authenticationSuccessHandler" 
   class="com.xyz.PlatformAuthenticationSuccessHandler">
   <property name="defaultTargetUrl" value="/!/" />
</bean>

The reason behind this is, the value we provide on the XML configuration goes to the default authentication success handler only. When we define our own, that value goes no where, so we need to specify it manually on the bean itself. This ate up about 15 mins of my time, before luckily noticing that the success handler change was the reason.

 

Integration Testing with MongoDB & Spring Data

Integration Testing is an often overlooked area in enterprise development. This is primarily due to the associated complexities in setting up the necessary infrastructure for an integration test. For applications backed by databases, it’s fairly complicated and time-consuming to setup databases for integration tests, and also to clean those up once test is complete (ex. data files, schemas etc.), to ensure repeatability of tests. While there have been many tools (ex. DBUnit) and mechanisms (ex. rollback after test) to assist in this, the inherent complexity and issues have been there always.

But if you are working with MongoDB, there’s a cool and easy way to do your unit tests, with almost the simplicity of writing a unit test with mocks. With ‘EmbedMongo’, we can easily setup an embedded MongoDB instance for testing, with in-built clean up support once tests are complete. In this article, we will walkthrough an example where EmbedMongo is used with JUnit for integration testing a Repository Implementation.
Continue reading

Eventing with Spring Framework

Spring Framework, since it’s inception, included an eventing mechanism which can be used for application-wide eventing. This eventing mechanism was developed to be used internally by Spring Framework for eventing, such as notification of context being refreshed, etc, but it can be used for application specific custom events as well. This eventing API is based on  an interface named {java}org.springframework.context.ApplicationListener{/java}, which defined one method named {java}onApplicationEvent{/java}. Below code snippet shows a simple events listener which just logs the event information.

package com.yohanliyanage.blog.springevents;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.ApplicationListener;

public class MyEventListener implements ApplicationListener {

	private static final Log LOG = LogFactory.getLog(MyEventListener.class);
	
	public void onApplicationEvent(ApplicationEvent event) {
		LOG.info("Event Occurred : " + event);
	}
}

Continue reading

Wiring up EJBs using Spring

In my recent work, I wanted to wire up my EJB 3 Service Facades using Spring 2.5. I looked for an existing solution to get this done, and it did not turn out to be successful. So I thought of writing my own solution to overcome this using Aspect Oriented Programming (AOP).

Looking into how Spring performs its magical bean wiring, I read through the source code of Spring, and found out that Spring uses the concept of BeanConfigurer and BeanWiringInfoResolver to resolve dependencies for a POJO. Since I was interested on annotations based configuration, I read through the code and found that AnnoationBeanWiringInfoResolver is capable of doing the wiring up for any POJO, by reading through present annotations for that type.

However, since I wanted to make sure that only my EJBs will be wired up using this approach, I decided to extend the AnnotationBeanWiringInfoResolver to provide my own implementation which only does this special treatment.
Continue reading

A Thought about Java EE Applications

Most of the software houses in my country seem to have embraced the concept of EJB3 hardly, for new projects. They develop new projects (and ports) using EJB3 as the middle tier technology, for various reasons.  Majority of the companies also employ Spring Framework as a part of their solutions as well. With the additions of JEE support (XML Bean Definitions) in Spring, the two technologies complements each other, and can be used to promote good programming practices like coding to interfaces, through Spring’s Inversion of Control support. Also, companies are embracing JPA, due to the simple nature of the technology, through “convention over configuration”. Finally, because of the use of EJBs, the solution is deployed into a full blown application server such as JBoss, Websphere, WebLogic etc. 

However, most of these applications are just web applications. And the architecture of these solutions are not distributed. All components of the solution live in a single VM. This raises the question, why do we need EJB? Well, in my perspective, I think it’s basically due to the fact that most developers think EJB is a core part of J2EE stack, and it should be there no matter what. If the final solution is deployed into a clustered environment, if the app is going to be executed in a distributed manner on several VMs, then yes, EJB is the way to go; but why for a webapp which runs in a single VM? Majority of the projects out there are not multi-modular distributed applications. They are single module web applications. IMO, using a technology like EJB is overkill for this type of projects. 

Continue reading