On the classpath

I guess I’d rather be on the classpath than the warpath…

Anyway, Bitronix’s bitronix.tm.Configuration class currently only supports specifying the resource loader .properties file’s location relative to the JVM’s current directory (think “argument to the constructor of a File object”), but for unit testing we would like to be able to plop the .properties file in our classpath and not have to hardcode a path to it.  Basically we wish we could give BTM a classpath-relative properties path-n-filename.  For the moment, we’ll use this hack:

    public static void beforeAllTests() {

        final String configurationFilePath = getAbsoluteFilePath("/bitronix-resource-loader.properties");


    private static String getAbsoluteFilePath(String classPathBasedFilePath) {
        URL path = ThisClass.class.getResource(classPathBasedFilePath);
        if (path == null) {
            throw new RuntimeException("Can't find resource " + classPathBasedFilePath);
        return path.getFile();

In our case, path.getFile() returns something along the lines of:


The leading slash is kind of funky, but it works.


2 thoughts on “On the classpath

  1. I wonder why you’re trying to use the resource loader within your tests.

    This facility was built to facilitate integration in containers where you cannot easily extend the configuration file’s format, the best example being Tomcat.

    Spring allows you to create pools directly using the BTM API so there’s no need for an extra configuration file here. The same goes for your unit tests: you can just create PoolingDataSource or PoolingConnectionFactory objects directly in the setUp() method, store them in member variables and close them in the tearDown() method.

    If you have design questions, I’d happily answer them in the mailing list.

  2. Ludovic,
    What we’re doing is in our integration test, we’re programmatically starting the bitronix.tm.Configuration and TransactionManager classes, and then we kick off our (production) application context starter, which loads various bean files. (The logic for this beanfile loading is nontrivial — it’s more than a simple call to ClassPathXmlApplicationContext().) By having the Configuration class load resources from an external .properties file, we don’t have to add a special “test mode” flag to our application context loader service to tell it to bring additional (JDBC datasource or JMS connection factory) beans into our application context if we’re in test mode. That way we’ll be able to use our production context starter without modification for integration testing too. Does that make sense?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.