Category Archives: Java

[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

JAX-WS: Working with .NET Web Services

If you happen to write a JAX-WS Web Services client for a service which is written using .NET Platform, you might come across the below error message when you execute wsimport command.

A class/interface with the same name “?????” is already in use. Use a class customization to resolve this conflict.

This happens because .NET generated WSDL documents may contain multiple elements with same name, which leads to a naming conflict when JAXB attempts to generate bindings. If you ever come across this situation, the solution is very simple. You just have to instruct the JAXB generator to automatically resolve any naming conflicts that might occur during the code generation. This can be done by providing -B-XautoNameResolution argument to wsimport tool. Note that the ‘-B-XautoNameResolution’ has no spaces. -B is used to pass instructions to JAXB Schema Compiler.

An example would be:

wsimport -d gen-src -verbose -B-XautoNameResolution  https://sample.net/service.asmx?WSDL

Note that generated code will refer to duplicate names with a numeric suffix. For example, if there are two elements with name ‘XYZ’, one class will be ‘XYZ’, and the other occurrence will be named as ‘XYZ2’.

Looking for JBoss Maven Repository?

JBoss has decommissioned their Maven 2 repository (about an year ago according to their site) which was available at http://repository.jboss.org/maven2. But many resources out there still refer to this repository, and many people face the following error when they try to use this repository.

Access denied to: http://repository.jboss.org/maven2

This is because JBoss has deactivated this repository and setup a 403 (HTTP Forbidden) error on this URL. After googling for a while, reading through JIRA entries etc., I found this page which pointed to a new repository from JBoss that contains most (if not all) of the artifacts from the previous one. The new repository URL is http://repository.jboss.org/nexus/content/groups/public-jboss/.

It could have been better if JBoss could have given a hint about this in their old repository URL, instead of sending a 403, which gives no clues.

In fact, as the URL indicates, this is a Nexus Maven Repository instance. You can access the Nexus Repository Manager from http://repository.jboss.org/nexus/ which lists all repositories hosted in it.