New and Unknown Java Libraries

I like finding new useful java libraries. I usually find them from posts like this one. Other times I find them because I have a problem needing a solution. Here are some of my favorite unknown java libraries that I have found over the past year. Today I use every one of these in my projects. Interestingly, 4 of 6 are hosted on http://code.google.com.

Google-API-Translate-Java

Provides a simple, unofficial, Java client API for using Google Translate. I use this to translate caption files for videos into several other languages. It has lots of options and has never failed me.

XmlTool

XMLTool is a very simple Java library to be able to do all sorts of common operations with an XML document with a very easy to use class using the Fluent Interface pattern to facilitate XML manipulations.

XStream

XStream is a simple library to serialize objects to XML and back again. Also useful for creating JSON responses.

Architecture Rules

Architecture Rules leverages an xml configuration file and optional programmatic configuration to assert your code’s architecture via unit tests or ant tasks. This test is able to assert that specific packages do not depend on others and is able to check for and report on cyclic dependencies among your project’s packages and classes. Get cyclic dependency detection with the Maven 2 plugin and zero configuration.

CyberNeko HTML Parser

NekoHTML is a simple HTML scanner and tag balancer that enables application programmers to parse HTML documents and access the information using standard XML interfaces. This can be used to extract the textual content from an HTML fragment.

Charts4j

charts4j is a free, lightweight charts & graphs Java API. It enables developers to programmatically create the charts available in the Google Chart API through a straightforward and intuitive Java API.

What do you use?

Do you have any new and unknown java tools that you use that you would recommend we checkout?

July 30, 2009 | Filed Under Software Tools | 1 Comment

Load Multiple Contexts into Spring

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?

July 26, 2009 | Filed Under java | 1 Comment

Choose many Spring contexts over a single context

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.

applicationContext.xml
applicationContext-dao.xml
applicationContext-dao-datasource.xml
applicationContext-ldap.xml
applicationContext-aspects.xml
applicationContext-web.xml

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?

July 26, 2009 | Filed Under java | 2 Comments