Load Multiple Contexts into Spring

Written by MikeNereson

July 26th, 2009 at 9:32 am

Posted in java

Tagged with ,

With one comment

I have  already argued that many application contexts are better than a single application context. But how do you load more than one context?

There are a couple of ways to do this.

web.xml contextConfigLocation

Your first option is to load them all into your Web application context via the ContextConfigLocation element. You’re already going to have your primary applicationContext here, assuming you’re writing a web application. All you need to do is put some white space between the declaration of the next context.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml
        applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

The above uses carriage returns. Alternatively, yo could just put in a space.

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>
    <param-value>
        applicationContext1.xml applicationContext2.xml
    </param-value>
</context-param>

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

applicationContext.xm import resourcel

Your other option is to just add your primary applicationContext.xml to the web.xml and then use import statements in that primary context.

In applicationContext.xml you might have…

<!-- hibernate configuration and mappings -->
<import resource="applicationContext-hibernate.xml"/>

<!-- ldap -->
<import resource="applicationContext-ldap.xml"/>

<!-- aspects -->
<import resource="applicationContext-aspects.xml"/>

Which strategy should you use?

I always prefer to load up via web.xml This allows me to keep all contexts isolated from each other. With tests, we can load just the contexts that we need to run those tests. This makes development more modular too as components stay loosely coupled, so that in the future I can extract a package or vertical layer and move it to its own module.

If you are loading contexts into a non-web application, I would use the import resource.

Any benefits to going with the application context import method over the web.xml contextConfigLocation?

  • Share/Bookmark
July 26, 2009 | Filed Under java | 1 Comment 

Choose many Spring contexts over a single context

Written by MikeNereson

July 26th, 2009 at 9:29 am

Posted in java

Tagged with , ,

With 2 comments

This is a short introduction to splitting up your bean definitions from one single Spring application context, to many application contexts. That is, from one XML file to many XML files. The general idea is to have one single primary application context, usually titled applicationContext.xml, and then many other application contexts with are named what they contain.

Example

For example, a single web project might contain the following contexts.

Breakdown

In this example, your DAO definitions, transaction managers, and DAO or integration interceptors are defined in applicationContext-dao.xml. We have further broken the DAO application context to a dao-datasource which contains our data sources. LDAP configuration, beans, and DAOs are in their own applicationContext-ldap.xml.

Benefits

Why so many? There have been a few benefits so far.

Responsibility

The Single Responsibility Principal is widely accepted and states that

… every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.

The same holds true for XML contexts.  The general ides is to make our contexts more robust and to be able to isolate a context’s tasks and capabilities. And clearly, working with a smaller XML file is easier than working with one enormous file. It is easier to maintain and easier to read.

Testing

When I wrote my tests for LDAP, I had my LDAP configuration in applicationContext.xml, but then every time I ran an LDAP test, I would get the WebApplicationContext, which would import applicationContext-hibernate, which would connect to the database. Tests took forever and needless resources were used. Now I just get applicationContext-ldap.xml which only contains LDAP configurations, so no needless resources are loaded and tests remain quick.

Inclusion and Exclusion

Finally, its really easy to comment out a line like

<import resource="applicationContext-aspects.xml"/>

and quickly have all my aspects, which for me only write logs, disabled. Or easy to add a line like

<import resource="applicationContext-dao-mock.xml"/>

which overrides all of your DAO implementations with mock DAOs. This would be for testing.

Does anyone else use multiple application context files? See any other benefits? Or problems?

  • Share/Bookmark
July 26, 2009 | Filed Under java | 2 Comments 

List of Version Control Web Sites

Written by Welzie

July 24th, 2009 at 10:07 am

Posted in Software Tools

Tagged with , , , , ,

With 10 comments

I recently needed to find a web site that offered version control services. I was having server issues and needed to find a reliable place to keep my code. Below is a list of sites that I found and some info about each one. Please add comments if you like or dislike any of these.

Note: The “cost” list below only shows the basic packages. Visit the sites for other plan details.

FREE – Version Control Hosts/Hosting

Cost
Per
Month		 Disk
Space		 Number
of
Repos		 Number
of
users		 Version
Control
Options		 SSL
beanstalkapp.com free 100mb 1 3 SVN no
unfuddle.com free 200mb unlimited 2 git, SVN
projectlocker.com free 500mb unlimited 5 git, SVN no
bitbucket.org free 500mb 1 ? mercurial yes
xp-dev.com free 500mb unlimited unlimited SVN no

Cost – Version Control Hosts/Hosting (Basic Packages)

Cost
Per
Month		 Disk
Space		 Number
of
Repos		 Number
of
users		 Version
Control
Options		 Other
Tools
Available
assembla.com $3 per project
+ $3 per gig		 pay per gb 1 pay per user SVN, git, mercurial ?
svnrepository.com $3.95 500mb 1 unlimited SVN, git, mercurial trac, redmine
hosted-projects.com $7 100mb unlimited unlimited SVN trac, WebDAV
wush.net $6.5 1gb 1 unlimited SVN Trac, Bugzilla, FogBugz, WebDAV, WebSVN
cvsdude.com $6 250mb 2 5 SVN ?
beanstalkapp.com $15 3gb 10 5 SVN basecmap, campfire, fogbuz
svnsite.com $5 400mb 1 4 SVN
unfuddle.com $9 512mb unlimited 10 git, SVN
codespaces.com $3 500mb unlimited 2 SVN ?
projectlocker.com $2.08 2.5gb unlimited 2 git, SVN Trac
GitHub.com $7 600mb 5 1 git ?
bitbucket.org $5 500mb 5 1 mercurial ?
xp-dev.com $3.3 ($40 a year) 2000mb unlimited unlimited SVN ?


Version Control with Git (Amazon)


Pro Git (Amazon)

Practical Subversion, 2nd Edition (Amazon)



Mercurial: The Definitive Guide (Animal Guide)
  • Share/Bookmark
July 24, 2009 | Filed Under Software Tools | 10 Comments