Source Allies Blog » Spring

Spring Injection with @Resource, @Autowired and @Inject

David Kessler — Mon, 01 Aug 2011 12:00:09 +0000

Overview

I’ve been asked several times to explain the difference between injecting Spring beans with ‘@Resource’, ‘@Autowired’, and ‘@Inject’. While I received a few opinions from colleagues and read a couple of posts on this topic I didn’t feel like I had a complete picture.

Annotations

Annotation	Package	Source
@Resource	javax.annotation	Java
@Inject	javax.inject	Java
@Qualifier	javax.inject	Java
@Autowired	org.springframework.bean.factory	Spring

In order to explore the behavior of each annotation I fired up Spring Tool Suite and started debugging the code. I used Spring 3.0.5.RELEASE in my research. The following is a summary of my findings.

The Code

I wanted to know how ‘@Resource’, ‘@Autowired’, and ‘@Inject’ resolved dependencies. I created an interface called ‘Party’ and created two implementations classes. This allowed me to inject beans without using the concrete type. This provided the flexibility I needed to determine how Spring resolves beans when there are multiple type matches.

public interface Party {
 
}

‘Person’ is a component and it implements ‘Party’.

package com.sourceallies.person;
...
@Component
public class Person implements Party {
 
}

‘Organization’ is a component and it implements ‘Party’.

package com.sourceallies.organization;
...
@Component
public class Organization implements Party {
 
}

I setup a Spring context that scans both of these packages for beans marked with ‘@Component’.

 base-package="com.sourceallies.organization"/>
 base-package="com.sourceallies.person"/>

Tests

Test 1: Ambiguous Beans

In this test I injected a ‘Party’ bean that has multiple implementations in the Spring context.

@Resource
private Party party;

@Autowired
private Party party;

@Inject
private Party party;

In all three cases a ‘NoSuchBeanDefinitionException’ is thrown. While this exception’s name implies that no beans were found, the message explains that two beans were found. All of these annotations result in the same exception.

org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No unique bean of type [com.sourceallies.Party] is defined: 
expected single matching bean but found 2: [organization, person]

Test 2: Field Name

In this test I named the Party field person. By default beans marked with ‘@Component’ will have the same name as the class. Therefore the name of the class ‘Person’ is person.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

‘@Resource’ can also take an optional ‘name’ attribute. This is equivalent to the ‘@Resource’ code above. In this case the field variable name remains ‘party’. There is no equivalent syntax for ‘@Autowired’ or ‘@Inject’. Instead you would have to use a ‘@Qualifier’. This syntax will be covered later.

@Resource(name="person")
private Party party;

All four of these styles inject the ‘Person’ bean.

Test 3: Field Type

In this test I changed the type to be a ‘Person’.

@Resource
private Person party;

@Autowired
private Person party;

@Inject
private Person party;

All of these annotations inject the ‘Person’ bean.

Test 4: Default Name Qualifier

In this test I use a ‘@Qualifier’ annotation to point to the default name of the ‘Person’ component.

@Resource
@Qualifier("person")
private Party party;

@Autowired
@Qualifier("person")
private Party party;

@Inject
@Qualifier("person")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 5: Qualified Name

I added a ‘@Qualifier’ annotation to the ‘Person’ class

package com.sourceallies.person;
...
@Component
@Qualifier("personBean")
public class Person implements Party {
 
}

In this test I use a ‘@Qualifier’ annotation to point to the qualified name of the ‘Person’ component.

@Resource
@Qualifier("personBean")
private Party party;

@Autowired
@Qualifier("personBean")
private Party party;

@Inject
@Qualifier("personBean")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 6: List of Beans

In this test I inject a list of beans.

@Resource
private List<Party> parties;

@Autowired
private List<Party> parties;

@Inject
private List<Party> parties;

All of these annotations inject 2 beans into the list. This can also be accomplished with a ‘@Qualifier’. Each bean marked with a specific qualifier will be added to the list.

Test 7: Conflicting messages

In this test I add a bad ‘@Qualifier’ and a matching field name.

@Resource
@Qualifier("bad")
private Party person;

@Autowired
@Qualifier("bad")
private Party person;

@Inject
@Qualifier("bad")
private Party person;

In this case the field marked with ‘@Resource’ uses the field name and ignores the ‘@Qualifier’. As a result the ‘Person’ bean is injected.

However the ‘@Autowired’ and ‘@Inject’ field throw a ‘NoSuchBeanDefinitionException’ error because it can not find a bean that matches the ‘@Qualifier’.

 org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No matching bean of type [com.sourceallies.Party] found for dependency: 
expected at least 1 bean which qualifies as autowire candidate for this dependency. 
Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true),
@org.springframework.beans.factory.annotation.Qualifier(value=bad)}

Conclusions

With the exception of test 2 & 7 the configuration and outcomes were identical. When I looked under the hood I determined that the ‘@Autowired’ and ‘@Inject’ annotation behave identically. Both of these annotations use the ‘AutowiredAnnotationBeanPostProcessor’ to inject dependencies. ‘@Autowired’ and ‘@Inject’ can be used interchangeable to inject Spring beans. However the ‘@Resource’ annotation uses the ‘CommonAnnotationBeanPostProcessor’ to inject dependencies. Even though they use different post processor classes they all behave nearly identically. Below is a summary of their execution paths.

@Autowired and @Inject

Matches by Type
Restricts by Qualifiers
Matches by Name

@Resource

Matches by Name
Matches by Type
Restricts by Qualifiers (ignored if match is found by name)

While it could be argued that ‘@Resource’ will perform faster by name than ‘@Autowired’ and ‘@Inject’ it would be negligible. This isn’t a sufficient reason to favor one syntax over the others. I do however favor the ‘@Resource’ annotation for it’s concise notation style.

@Resource(name="person")

@Autowired
@Qualifier("person")

@Inject
@Qualifier("person")

You may argue that they can be equal concise if you use the field name to identify the bean name.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

True enough, but what happens if you want to refactor your code? By simply renaming the field name you’re no longer referring to the same bean. I recommend the following practices when wiring beans with annotations.

Spring Annotation Style Best Practices

Explicitly name your component [@Component("beanName")]
Use ‘@Resource’ with the ‘name’ attribute [@Resource(name="beanName")]
Avoid ‘@Qualifier’ annotations unless you want to create a list of similar beans. For example you may want to mark a set of rules with a specific ‘@Qualifier’ annotation. This approach makes it simple to inject a group of rule classes into a list that can be used for processing data.
Scan specific packages for components [context:component-scan base-package="com.sourceallies.person"]. While this will result in more component-scan configurations it reduces the chance that you’ll add unnecessary components to your Spring context.

Following these guidelines will increase the readability and stability of your Spring annotation configurations.

Testing Spring Wiring

David Kessler — Wed, 01 Jun 2011 17:00:20 +0000

Overview

Spring is an essential part of my technology stack. I cann’t image providing quality software that doesn’t leverage an IoC container. However, decoupling components requires some amount of configuration. Whether this is accomplished through annotations or XML, it’s fairly easy to mess up. Fixing these missing or incorrect configurations doesn’t take very long. The real question is how quickly can you identify these errors?

This question of how long, is a feedback loop question. Unfortunately many teams wait until they fire up the application server to see if their Spring context is wired correctly. This is too late.

One of our clients suffered from this very issue. Due to environmental constraints they could not run automated, in-container tests that would have identified misconfigured beans. After repeatedly committing stupid configuration mistakes, I decided that I would write a Spring wiring test. As I began to write this I encountered five problems.

Problem 1: Scope

The first problem that I encountered was that not all of my beans were being created when I loaded my context.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class SpringWiringTest{
 
     @Test
     public void testSomething(){
...

I quickly remembered that only beans with the default ’singleton’ scope will be loaded immediately. The rest of the bean scopes (’prototype’, ‘request’, and ’session’) will not be created until they are requested. In order to solve this I looped through all of the bean names and retrieved each bean from the context.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     context.getBean(name);
}

However, when I ran this I got the following error

java.lang.IllegalStateException: No Scope registered for scope 'request'

In order to correct this issue I added the following setup method.

@Before
public void testCaseSetUp(){
     context.getBeanFactory().registerScope("session", new SessionScope());
     context.getBeanFactory().registerScope("request", new RequestScope());
     MockHttpServletRequest request = new MockHttpServletRequest();
     ServletRequestAttributes attributes =
          new ServletRequestAttributes(request);
     RequestContextHolder.setRequestAttributes(attributes);
}

I threw in the session scope too just to be safe.

Problem 2: Abstract Bean Definitions

The second problem that I had to solve was requesting abstract beans.

org.springframework.beans.factory.BeanIsAbstractException: Error creating bean
with name 'testBean': Bean definition is abstract

In order to solve this issue I added a check to verify if a bean definition was abstract.

String[] names = context.getBeanDefinitionNames();
for(String name : names){
     BeanDefinition beanDefinition = context.getBeanDefinition(name);
     if(!beanDefinition.isAbstract()){
          context.getBean(name);
     }
}

Problem 3: Mock Beans

The third issue I found was environment specific beans. JNDI references are one type of environment specific bean.

In order to solve this issue, I decided to create a test bootstrap context that imported all of the production contexts. This provided a place for me to override beans that I wanted to create for the test. I used Mockito to create mock beans in most situations.

While this worked for most beans, I received errors when I wired up mock DataSources. Instead I used embedded databases to replace real DataSources.

class="org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseFactoryBean" p:databaseType="H2" abstract="true"/>

Problem 4: Components

This fourth issue was harder to identify but equally problematic. I frequently wired up beans with the @Component annotation and failed to configure an ‘component-scan’ for those packages.

In other words I needed to reconcile the classes marked with the @Component annotation with the beans that were available in the Spring context.

ClassPathScanningCandidateComponentProvider scanner =
     new ClassPathScanningCandidateComponentProvider(true);
scanner.addIncludeFilter(new AnnotationTypeFilter(Component.class));
for (BeanDefinition bean : scanner.findCandidateComponents("com.something")){
      components.add(bean.getBeanClassName());
}

This will create a list of components found on the classpath under the specified base package. Reconciling this list with the beans loaded in the Spring context will identify any components that are not configured in Spring. This list came in handy for two reasons. First it identified any components that I needed to configure in Spring. Second it listed components that were provided in dependent jars. This list helped us become proactive instead of reactive.

Problem 5: Duplicate Bean Definitions

The fifth issue is duplicate bean definitions. This can occur when more than one bean has the same bean definition name. This can also occur when the same context is loaded multiple times. By default Spring allows the new bean definition to overwrite the previous one. This sounds annoying but harmless. On the contrary, Spring does not guarantee the loading order. Furthermore, each deployment environment’s classloader can load context files in a different order. The bottom line is that duplicate bean definitions can result in subtle and painful bugs.

While this issue was clear to me the solution was a bit more illusive. At first I tried to set the allowBeanDefinitionOverriding flag on org.springframework.beans.factory.support.DefaultListableBeanFactory. This throws an exception if the same bean definition is loaded multiple times. Case closed, right?

Unfortunately the solution was not this simple. Problem 3, Mock Beans, requires the creation of a test bootstrap context that overrides bean definitions. So the allowBeanDefinitionOverriding flag is out. After crying a little, I started exploring Spring. Long story short, I overrode the ‘protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)’ method on org.springframework.context.support.ClassPathXmlApplicationContext and injected a delegating proxy.

@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
		throws BeansException, IOException {
	Enhancer enhancer = new Enhancer();
	enhancer.setSuperclass(DefaultListableBeanFactory.class);
	BeanohBeanFactoryMethodInterceptor callback = new BeanohBeanFactoryMethodInterceptor(
			beanFactory);
	callbacks.add(callback);
	enhancer.setCallback(callback);
	DefaultListableBeanFactory proxy = (DefaultListableBeanFactory) enhancer
			.create();
 
	super.loadBeanDefinitions(proxy);
}

I used ‘net.sf.cglib.proxy.Enhancer’ and ‘net.sf.cglib.proxy.MethodInterceptor’ to create a proxy. The trick was to delegate to the real ‘org.springframework.beans.factory.support.DefaultListableBeanFactory’ instance.

@Override
public Object intercept(Object object, Method method, Object[] args,
		MethodProxy methodProxy) throws Throwable {
	Method delegateMethod = delegateClass.getMethod(method.getName(),
			method.getParameterTypes());
	if ("registerBeanDefinition".equals(method.getName())) {
		if (beanDefinitionMap.containsKey(args[0])) {
			List definitions = beanDefinitionMap
					.get(args[0]);
			definitions.add((BeanDefinition) args[1]);
		} else {
			List beanDefinitions = new ArrayList();
			beanDefinitions.add((BeanDefinition) args[1]);
			beanDefinitionMap.put((String) args[0], beanDefinitions);
		}
	}
	return delegateMethod.invoke(delegate, args);
}

This passively collects bean definitions that are registered with the registerBeanDefinition method. This method takes two arguments: a String bean name (arg[0]) and a ‘org.springframework.beans.factory.config.BeanDefinition’ (arg[1]). This map of bean definitions can be inspected later to determine if beans were loaded multiple times.

Conclusions

This experience has lead our team to develop a complete, open source solution called Beanoh (pronounced \’beanˌō\). Simply download the jar or build the project with maven and start using it.

public class SomeTest extends BeanohTestCase {
 
	@Test
	public void testSomething() {
		assertContextLoading();
	}
}

For more information visit http://beanoh.org/overview.html.

In just a few short weeks this testing approach prevented our team from committing broken Spring configurations. Furthermore, we took time to evaluate the inherited components that we received through our project dependencies. This provided valuable insights into our dependency structure and our packaging strategy.

These wiring tests even gave us feedback as we refactored our spring contexts. We were able to simplify our context files without worrying that we would break something. We also identified unused and duplicate bean definitions. Without the quick feedback of this wiring test we would have committed broken changes that effected the whole team.

Automated tests help you manage code behavior rather than allowing code to drive your behavior. Download Beanoh today and take control of your Spring configuration.

For more information checkout our YouTube video tutorials.

Aggregate MyBatis.NET SqlMaps from Multiple C# Projects

Matt Vincent — Wed, 06 Oct 2010 15:20:28 +0000

Summary

This blog post describes an approach for integrating Spring.NET and MyBatis.NET in a way that lets iBATIS aggregate SqlMap config files from multiple assemblies (a.k.a. assembly scanning) prior to handing out ISqlMapper instances. Teams setting up new MyBatis.NET/Spring.NET tech stacks might find this useful.

The Problem

Your typical enterprise C# ASP.NET web application will have dependencies on multiple C# projects. Just as best practices with OOAD and Spring support placing our Spring XML configuration files (Spring.NET doesn’t have attribute based configuration … yet) alongside our business components (by namespace or project) rather than keeping all Spring config in a giant single file (thereby limiting reusability of specific business components) we can also follow this process with MyBatis configuration files. This is not out of the box funcationality with MyBatis.NET. Furthermore, how do you prevent those consuming your C# Project (containing multiple SqlMap config files) from having to know the exact locations of your SqlMap.config files within your assembly?

A typical enterprise Spring.NET/MyBATIS.NET web app

Wouldn’t it be nice to have your ASP.NET web application simply discover any new MyBATIS config files when the application starts up?

If you’re on the bleeding edge with iBATIS 3 beta code, then this is a fairly simple task with psuedo code like:

            string[] sqlMaps = Inspector.GetSqlMapsFromAssembly(
                       “MyCompany.Domain1”, “*.SqlMaps.*.xml);
            CodeConfigurationInterpreter codeConfig =
                        new CodeConfigurationInterpreter();
            codeConfig.AddDatabase(new OracleProvider(), “….”);
            foreach (string map in sqlMaps)
            codeConfig.AddSqlMap(map, true);

However, for those of us using MyBatis 1.6.x releases in our Spring.NET apps, below is another solution that allows your app to grab all MyBatis.NET config files in a set of dependent C# project.

The Solution

Step 1. – Let Spring know about your dependent projects:

Define a class to hold your config locations like this (yes, Spring.Core.IO.Resource would make much more sense then SearchLocation here…).

    public class SqlMapsHolder : ISqlMapsHolder
    {
        private List embeddedSqlMapSearchLocations;
 
        ///
        /// Two part string: the first representing the NAnt style search pattern, the second is the name of the assembly in which to search.
        ///
        public List EmbeddedSqlMapSearchLocations
        {
            get { return embeddedSqlMapSearchLocations; }
            set { embeddedSqlMapSearchLocations = value; }
        }
 
        /// Take a string of the form "*.Sqlmaps.*.xml, MyCompany.Example" and return it's two parts.
        /// a string like "*.Sqlmaps.*.xml, MyCompany.Example"
       public SearchLocation GetSearchLocation(string searchLocationString)
        {
            char[] delimiter = new char[] { ',' };
            string[] parts = searchLocationString.Split(delimiter, 2);
            return new SearchLocation(parts[0], parts[1]);
        }
    }
 
    /// Holds the distinct NAnt search pattern and assembly name parts.
    public struct SearchLocation
    {
        /// NAnt search pattern and Assembly name
        public string Pattern, Assembly;
 
        /// Constructor
        /// NAnt/Ant search pattern (like *.Sqlmaps.*.xml)
        /// Assembly name (like MyCompany.Example)
        public SearchLocation(string pattern, string assembly)
        {
            Pattern = pattern;
            Assembly = assembly;
        }
    }

Step 2. – Specify your dependent assemblies in your Spring config XML

The configuration below will tell your application to look in the Party, Account and Policy dependent assemblies for any XML files (which are of course marked as “Embedded Resources”) in a folder called SqlMaps (or any other NAnt style syntax you specify) and will pull all of these SqlMaps together before starting up MyBatis. (The SqlMaps you refer to should start with the tag)

This is what you should place in your Spring Config files to tell your app in which assemblies to look for SqlMap config files.

 id="SqlMapsHolder" type="MyCompany.Util.SqlMapsHolder, MyCompany.Util" >  
     name="EmbeddedSqlMapSearchLocations">  
         element-type="string">
            >*.Sqlmaps.*.xml, MyCompany.Party>
            >*.Sqlmaps.*.xml, MyCompany.Account>
            >*.Sqlmaps.*.xml, MyCompany.Policy>
        >
    >
>

Where these Sqlmap.xml files look like this:

 version="1.0" encoding="utf-8" ?>
 namespace="MyCompany.Party.Sqlmaps" 
xmlns="http://ibatis.apache.org/mapping" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    >... >
    >...>
    >...>
>

Step 3. – Create your own SqlMapperFactory.

Let’s call it ConfiguredMapperFactory. Here’s the pseudo-code:

    ///
using System.Configuration;
using IBatisNet.DataMapper;
using Spring.Context;
    /// Used by Spring to initialize a custom MyBATIS.NET singleton Mapper
    ///
    public class ConfiguredMapperFactory : IConfiguredMapperFactory, IApplicationContextAware
    {
        ///
        /// An assembly location in the format:  MyASPNETWebApp.SqlMap.Config.Production.SqlMap.config,MyASPNETWebApp.SqlMap
        ///
        public string ConfigResourceLocation { get; set; }
 
        ///
        /// Container responsible for holding the various SqlMap.xml files that will be merged into one XML document before initializing MyBATIS
        ///
        public ISqlMapsHolder SqlMapsHolder { get; set; }
 
        ///
        /// Singleton instance of our custom MyBatis.NET Mapper
        ///
        public ISqlMapper ConfiguredMapperInstance
        {
            get
            {
                // if the MyBatis.NET config files were not specified via Spring
                if (ConfigResourceLocation == null)
                {
                    // then fall back on getting the config location from web.config
                    lock (typeof(ConfiguredMapper))
                    {
                        string configResourceLocationFromWebConfig =
                            ConfigurationSettings.AppSettings["ibatis.net.config.resource.location"];
                        ConfigResourceLocation = configResourceLocationFromWebConfig;
                        _configuredMapperInstance = ConfiguredMapper.Instance(ConfigResourceLocation, SqlMapsHolder, _applicationContext);
                    }
                }
 
                if (_configuredMapperInstance == null) // braces left out for brevity
                    lock (typeof(ConfiguredMapper))
                        _configuredMapperInstance = ConfiguredMapper.Instance(ConfigResourceLocation, SqlMapsHolder, _applicationContext);
 
                return _configuredMapperInstance;
            }
        }
 
        ///
        /// Getter for the iBATIS.NET ISqlMapper configured based on custom locations of sqlmap.config and providers.config
        ///
        public ISqlMapper GetConfiguredMapperInstance() { return ConfiguredMapperInstance; }
        private ISqlMapper _configuredMapperInstance;

Step 4. – Make a SqlMap Aggregator

We’ll also need a class that knows how to package up all of the iBATIS SqlMaps it finds into a single XML doc that’s fed to MyBATIS:

/// 
/// Merges specified assembly's XML sqlmaps into a SqlMap.config file 
/// 
  
public class SqlMapMerger { 
    public static string DATAMAPPER_NAMESPACE_PREFIX = "mapper"; 
    public static string PROVIDERS_NAMESPACE_PREFIX = "provider"; 
    public static string MAPPING_NAMESPACE_PREFIX = "mapping"; 
    public static string DATAMAPPER_XML_NAMESPACE = "http://ibatis.apache.org/dataMapper"; 
    public static string PROVIDER_XML_NAMESPACE = "http://ibatis.apache.org/providers"; 
    public static string MAPPING_XML_NAMESPACE = "http://ibatis.apache.org/mapping"; 
    public static string XML_DATAMAPPER_CONFIG_ROOT = "sqlMapConfig"; 
    public static string XML_SQLMAPS = "sqlMapConfig/sqlMaps";
 
    /// 
    /// Token for xml path to sqlMap elements.
    /// 
  
    public static string XML_SQLMAP = "sqlMapConfig/sqlMaps/sqlMap";
 
    ///
    /// Merge the additional SqlMaps into the Primary SqlMap.config with which we'll initialize iBATIS.NET 
    ///
    ///The application specific SqlMap.config file
    ///A container of additional locations in which we'll search for SqlMap XML files
    public XmlDocument Merge(XmlDocument primarySqlMapConfig, ISqlMapsHolder additionalSqlMapXmlFiles) { 
 
        XmlNamespaceManager nsManager = new XmlNamespaceManager(primarySqlMapConfig.NameTable); 
        nsManager.AddNamespace(DATAMAPPER_NAMESPACE_PREFIX, DATAMAPPER_XML_NAMESPACE);
        nsManager.AddNamespace(PROVIDERS_NAMESPACE_PREFIX, PROVIDER_XML_NAMESPACE);
        nsManager.AddNamespace(MAPPING_NAMESPACE_PREFIX, MAPPING_XML_NAMESPACE); 
 
        String mappingPrefix = ApplyDataMapperNamespacePrefix(XML_SQLMAPS); 
        XmlNode sqlMapsNode = primarySqlMapConfig.SelectSingleNode(mappingPrefix, nsManager);
 
        // look at each search location (*.Sqlmaps.*.xml, MyCompany.Project)
        foreach (String searchLocation in additionalSqlMapXmlFiles.EmbeddedSqlMapSearchLocations) { 
            // split it up between the comma 
            SearchLocation location = additionalSqlMapXmlFiles.GetSearchLocation(searchLocation); 
 
            // look for matching files in the assembly 
            IList matchingSqlMaps = AssemblyResourceUtil.GetMatchingResources(location.Assembly, location.Pattern);
 
            // add each of these locations to the primary SqlMap.config's  section like this: 
            //   
            //     
            //   
            foreach (String fullSqlMapXmlFileName in matchingSqlMaps) { 
                // the "extra" SqlMap that we want to integrate into the main one. 
                XmlNode newSqlMap = primarySqlMapConfig.CreateNode(XmlNodeType.Element, "sqlMap", DATAMAPPER_XML_NAMESPACE); 
                XmlAttribute embeddedLocation = primarySqlMapConfig.CreateAttribute("embedded");
                embeddedLocation.Value = string.Format("{0},{1}", fullSqlMapXmlFileName, location.Assembly);
                newSqlMap.Attributes.Append(embeddedLocation); 
                sqlMapsNode.AppendChild(newSqlMap);
            }
        }
        return primarySqlMapConfig; 
    } 
 
    ///   
    /// Apply the dataMapper namespace prefix 
    /// 
    public static string ApplyDataMapperNamespacePrefix(string elementName) { 
        return DATAMAPPER_NAMESPACE_PREFIX + ":" + elementName. Replace("/", "/" + DATAMAPPER_NAMESPACE_PREFIX + ":");
    }
}

Step 5. – Create a Class to Configure MyBatis using multiple SqlMap config files

Next, create the ConfiguredMapper that application will use to get instances of the MyBatis ISqlMapper:

using System.Xml;
using IBatisNet.Common.Utilities;
using IBatisNet.DataMapper;
using IBatisNet.DataMapper.Configuration;
using Spring.Context;
 
    /// 
    /// A singleton class to access the SqlMapper defined by the SqlMap.Config
    /// 
    public class ConfiguredMapper
    {
        #region Fields
        private static volatile ISqlMapper _mapper = null;
        #endregion
 
        /// 
        /// static Configure constructor that can be
        /// used for callback
        /// 
        ///
 
        protected static void Configure(object obj)
        {
            _mapper = null;
        }
 
        /// 
        /// Init the 'default' SqlMapper defined by the SqlMap.Config file.
        /// 
        protected static void InitMapper(string configResourceLocation, ISqlMapsHolder additionalSqlMapXmlFiles, IApplicationContext applicationContext)
        {
            DomSqlMapBuilder builder = new DomSqlMapBuilder();
            XmlDocument sqlMapConfig = Resources.GetEmbeddedResourceAsXmlDocument(configResourceLocation); // example "MyCompany.SqlMap.Config.Production.SqlMap.config,MyCompany"
            SqlMapMerger merger = new SqlMapMerger();
            XmlDocument mergedSqlMapConfig = merger.Merge(sqlMapConfig, additionalSqlMapXmlFiles);
            _mapper = builder.Configure(mergedSqlMapConfig);
            // the commented out code below will be the subject of a subsequent blog article:
            // ManagedConnectionStringDataSource managedConnectionStringDataSource = new ManagedConnectionStringDataSource(_mapper.DataSource);
            // managedConnectionStringDataSource.ApplicationContext = applicationContext;
            // inject our own IDataSource so that we can control what is returned when iBATIS calls IDataSource.ConnectionString
            // _mapper.DataSource = managedConnectionStringDataSource;
        }
 
        /// 
        /// Get the instance of the SqlMapper defined by the SqlMap.Config file.
        /// 
        /// A SqlMapper initalized via the SqlMap.Config file.
        public static ISqlMapper Instance(string configResourceLocation, ISqlMapsHolder additionalSqlMapXmlFiles, IApplicationContext applicationContext)
        {
            if (_mapper == null)
            {
                lock (typeof(SqlMapper))
                {
                    if (_mapper == null) // double-check
                    {
                        InitMapper(configResourceLocation, additionalSqlMapXmlFiles, applicationContext);
                    }
                }
            }
            return _mapper;
        }
    }

Step 6. – Wire up your custom Mapper Factory in Spring

 id="ConfiguredMapperFactory" type="MyCompany.Util.Ibatis.ConfiguredMapperFactory,MyCompany.Util" >
     name="ConfigResourceLocation" value="MyASPNETWebApp.Config.SqlMap.config,MyASPNETWebApp"/>
     name="SqlMapsHolder" ref="SqlMapsHolder"/>
>
 
 id="IbatisSqlMapper" factory-method="GetConfiguredMapperInstance" factory-object="ConfiguredMapperFactory"/>

Where the SqlMap.config file you refer to is nothing more than:

 version="1.0" encoding="UTF-8" ?> 
 xmlns="http://ibatis.apache.org/dataMapper" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
    >
         key="proxy_userid" value="************"/>
         key="proxy_password" value="************"/>
         key="userid" value="************"/>
    >
 
     embedded="MyCompany.Util.Config.providers.config,MyCompany.Util"/>
 
      
    >  
         name="Oracle Data Provider for .NET"/>  
         name="mycompanydatasource" connectionString="Proxy User Id=${proxy_userid};Proxy Password=${proxy_password};User Id=${userid}"/>  
    >
 
    >
        
    >
>

Step 7. – Inject the IbatisSqlMapper into your Data Access Objects

 id="MyPartyDAO" type="MyCompany...." >  
     name="SqlMapper" value="IbatisSqlMapper"/>  
>

Where SqlMapper is an IBatisNet.DataMapper.ISqlMapper field or property in your Data Access Object.

Environment Specific Properties in Spring

Travis Klotz — Mon, 01 Mar 2010 19:10:16 +0000

On many occasions I want to be able to inject environment specific property values into my Spring managed beans. These may be things like web service endpoints, database URLs, etc. Values I know for each environment at build time, but I want to use the same WAR/EAR file in each environment. I would like to keep the actual values separate from the Spring config files themselves. And I would really like to manage a set of default values for each property, so that I do not need to specify a value for every property in every environment (ex. my credit card processing URL for dev, test, uat is the same, but for production it is different.)

Spring already has 90% of this solution already worked out. The PropertyPlaceholderConfigurer can be used to externalize property values into Java properties files. These properties can then be referenced “ant style” in your configuration files ex. ${myPropertyValues}. It can even handle multiple files, checking them in order for each property, so one file can override one or move values that are stored in another. However the PropertyPlaceholderConfigurer doesn’t have any concept of an environment specific file.

Thats where we come in:

package com.sourceallies.config;
 
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;
 
public class EnvironmentPropertyPlaceholderConfigurer extends
		PropertyPlaceholderConfigurer {
 
   @Override
   public void setLocation(Resource location) {
      if (!(location instanceof ClassPathResource)) {
         throw new RuntimeException(
               "EnvironmentPropertyPlaceholderConfigurer " + 
               "locations must be on the classpath");
      }
 
      ClassPathResource cl = (ClassPathResource) location;
      String filename = cl.getFilename();
 
      //switch  "env.properties" to "env.dev.properties"
      String envFilename = filename.replaceAll(
            "(.*)\\.properties", 
            "$1." + getEnvironment().toLowerCase() + ".properties");
 
      Resource envLocation = cl.createRelative(envFilename);
      if (envLocation.exists()) {
         setLocations(new Resource[] { location, envLocation });
      } else {
         setLocations(new Resource[] { location });
      }
   }
 
   public String getEnvironment() {
      /*
       * Magic goes here. This method must be able to determine which
       * environment it is running in without any help from injected
       * properties.
       */
 
      return System.getProperty("sai.env", "DEV");
   }
}

This version of the configurer expects a single resource to be passed in via the location property. In this case I restrict it only to ClassPathResource instances, but really it can be any version that can generate a new resource with a relative path. The resource we configure here should be the “default” file, the configurer will then build an environment specific file based on the default name and check its existence. If the environment specific file is found the are ordered up so that any properties in the environment file will override the values in the default file. If no environment file is found, only the default file is used.

The only real magic here is how the configurer determines the environment that its running in. In this simple case, the configurer relies on a system property to tell it what environment its running in. In larger organizations I have found that getting system properties set reliably across environments to be extremely difficult (most shops still tack on application server administration to the jobs of the DBA’s or the Unix/Windows admins who are already overworked.) In these cases, more extreme methods may be needed to determine the environment name. JNDI lookups, Database queries, reading files from the file system may all be good solutions. The important thing is that you can’t inject the environment name, if it were that easy, we wouldn’t actually need this configurer!

Spring’s refreshable beans

Octavian Covalschi — Fri, 08 Jan 2010 14:00:19 +0000

A couple of days ago I found out about a really nice feature in Spring, called ‘refreshable bean’.

Spring’s vision a refreshable bean is a dynamic-language-backed bean that monitors changes to its source code and then reloads itself when changes occur. And it is all this is done without restarting/re-deploying entire app. Sweet!

Currently Spring supports only 3 dynamic languages: JRuby, Groovy, BeanShell.

A simple example taken from springsource’s website looks like:

>
    ...
     id="messenger"

Source Allies Blog » Spring

Spring Injection with @Resource, @Autowired and @Inject

Overview

Annotations

The Code

Tests

Test 1: Ambiguous Beans

Test 2: Field Name

Test 3: Field Type

Test 4: Default Name Qualifier

Test 5: Qualified Name

Test 6: List of Beans

Test 7: Conflicting messages

Conclusions

Related Links

Testing Spring Wiring

Overview

Problem 1: Scope

Problem 2: Abstract Bean Definitions

Problem 3: Mock Beans

Problem 4: Components

Problem 5: Duplicate Bean Definitions

Conclusions

Aggregate MyBatis.NET SqlMaps from Multiple C# Projects

Summary

The Problem

The Solution

Step 1. – Let Spring know about your dependent projects:

Step 2. – Specify your dependent assemblies in your Spring config XML

Step 3. – Create your own SqlMapperFactory.

Step 4. – Make a SqlMap Aggregator

Step 5. – Create a Class to Configure MyBatis using multiple SqlMap config files

Step 6. – Wire up your custom Mapper Factory in Spring

Step 7. – Inject the IbatisSqlMapper into your Data Access Objects

Environment Specific Properties in Spring

Spring’s refreshable beans