Recently, l encountered a very interesting fact about using Hibernate and EJB. Our design was simple, Container Managed Transactions and a remote interface provided by EJB, Spring wired business objects, and Hibernate as our data access layer. Simple and neat. Well, sort of.

It had been smooth sailing, we delivered a large number of application functionality and time came to integrate a third party application. We provided a specific integration API (through EJB) to abstract the complexity of our business processes. Our API was clean and simple to use. We spent a while “hooking up” the third party application and just as we we thought we were going to pull it off; Unmarshalling Exeptions. What the?

We looked for the usual candidates; had we packaged the incorrect version of our domain objects that we delivered to the vendor? Nope. Did we have an incorrect version of the domain objects? Nope. Well, what could it be? Looking a little closer at the exception stack trace revealed the truth; incompatible hibernate proxy objects! Oh no, hibernate is in my POJO.

A quick check of the vendor libraries revealed a truth we were hoping would not be true; the vendor was using hibernate as well, and no prizes for who can guess what the problem was; The vendor had a different version of hibernate.

This made me reflect on the “discussions” we’d had with Architecture about the use of Data Transfer Objects (DTO’s). An Object Oriented purist would strongly argue that DTO’s are, in fact, not objects as they have no behavior, and that DTO’s increase maintenance costs due to the impact they have on change. But, if your architecture has mandated isolated classloaders (EJB’s facades), one must pass “pure” objects from one classloader to the next. What does that mean? Its simple, the binary dependency should only be on the objects that are defined in the API and nothing more.

So, my next question was; where the hell is hibernate hiding in my domain objects? Collections. To be more specific; hibernate Collections. Due to the many pitfalls of ORM, hibernate has “solved” the problem by creating proxies for Collections of objects. This is the hibernate teams solution to the N+1 selects problem. Only for me, this particular aspect relating to ORM had leaked into our architecture and exposed a hole that was not covered. Now we have a submarine with a leaky hull.

After my blog on Aspects of Spring on a monolithic codebase, lve been searching about the topic and, to my surprise, have not been able to find any posting relating to this or similar issues. Nor have l been able to locate any documentation or papers regarding this aspect of spring usage. Well… l think its time to lay claim to a pattern.

After some thought, lve decided to call it Single Bean Factory per Classloader. And the description of the pattern is:

When constructing a Spring Bean Factory, ensure that you have a single instance of the bean factory per-classloader and you load the spring application context files from a standard location in the classpath.

What does this equate to? Well, lets me describe the pattern by giving an example from the trenches: A J2EE application (EAR) that contains an EJB and Web Module.

In the complex innards of an J2EE Application Server, there are a few truths that we can rely on. One of these truths is that an EAR will have a classloader all to itself. Therefore, all JAR’s packaged at the EAR level will be on the EAR’s classpath *automagically*. The EJB module will always share the EAR’s classloader, in fact, they are deployed as a single JAR in the root of the EAR. Web modules, on the other hand, do have a separate classloader, but the WAR’s classloader will be the EAR’s classloaders child. Therefore, the EAR and the WAR have a parent child relationship w.r.t classloaders.

Why do l need to know this, l hear you ask? Well, its all about scope. As the Single Bean Factory per Classloader pattern suggests, a core principle is the single instance of the Bean Factory per classloader. Therefore the object that constructs the Spring Bean Factory must be on the EAR’s classloader and not on the Web Modules class loader. How do you guarantee this? Package the Bean Factory Singleton wrapper into the EAR level. You can then instantiate the Singleton Bean Factory wrapper from the EJB module or Web Module and you’ll be guaranteed to have a single instance.

Now that we have a clear understanding of “the classloader aspect”, lets talk about the second principle; “load application contexts from a standard location”. This way, you can abstract the dependency aspects of your spring defined components to be managed by the a dependency tool, like Ivy and link them from your components on the classloader. What the hell does this mean? Well, you have not read blog entry Aspects of Spring on a monolithic codebase! For those who have not read it, l’ll summarise. Its real simple; ensure that you have one or many (keep it consistent though) number of “main” spring application context xml files that you stored in a standard location in the JAR, i.e. META-INF/components. That way, the code to find the application context files is generic:

getClass().getClassLoader().getResources("META-INF/components/components.xml");

There you have it. This pattern has the capability to really increase the manageability of your spring based applications. Enjoy.

I remember reading about Spring two years ago, and although Dependency Injection has been in my bag-of-tricks for a while now, l was excited about the semantics Spring provided when defining Java beans. It was simple, a few XML files scattered with a number of beans, and you were well on your way to making your application more testable, configurable and all the other wonderful things that using Spring provides.

Id been using it for about a year on small to medium sized projects with lots of success. Then came the monolith. I joined a large scale internet banking project which made such heavy use of Spring that the Application Context files had become a large aspect of the system. Sure, each component of the system was Spring wired to provide all the benefits of using DI, but overall, as each component depended on another, the Spring aspect became more and more pervasive. This made life very difficult for a lot of developers on the team. Let me explain why in a little more detail.

Each project in the Eclipse workspace was, loosely speaking, a component in the application. Typically, each project exposed some beans for other projects to consume. Each project had, on average, 5 spring XML files which defined the beans implemented in the component (project). If you wanted to use another bean from another project, you would; (a) add the project as a dependency in the ivy.xml file (we used Ivy as the dependency management tool), (b) import the specific spring application context xml files from the project you just added to the ivy.xml file and (c) wire up the imported bean to your component. Simple right?

Well, let me tell you, it wasn’t. The best way to describe this pattern is by giving an example of something thats familiar to all Java developers; JAR files. A single JAR file contains many classes. When you need a class or set of classes from a library, do you unzip the JAR and import a single class file into your project? The answer to this question (for all those Java newbies out there) is NO. You import the whole JAR and use what you need. What we were effectively doing was exactly that; picking a spring XML file(s) from a JAR file and importing only the ones we selected; trying to ignore all the other spring xml files in the library. As you can imagine, trying to determine the dependency of the spring file (even within the same JAR) is very difficult and error prone, especially when there is a complex dependency relationships in the bean definitions. This was a monolithic abstraction leakage; a leakage comparable to the Great Mississippi Flood of 1927.

After some time thinking about the problem, l realised that the answer to the problem was in the fundamentals of Object Oriented Principles; Abstraction. The solution turned out to be very simple. Each project was to present a single set of standard spring application contexts to the bean factory for loading. I named these standard files the “Public Interface Context”.

The solution was to create two files, the componets.xml and resources.xml files. The components.xml file contained all spring beans that are loosely defined as components of the project, e.g. services, helpers, processors etc. The resources.xml file contained beans for resource related objects, e.g. Hibernate Session Factories, JMS Connection Factories etc. Each of the projects that compiled to a JAR must have a /META-INF/components directory where the public interface context files are to be saved. These public interface context files imported referenced all the other spring xml files in the project; this time, through the public interface context xml files.

After the magic of Ivy, when all EAR’s are build, all the assembled JAR’s contain the public interface contexts are saved and available for import in a standard location: META-INF/components . Therefore, when constructing your bean factory, the application contexts are loaded like:

pubic class FooSingleton {
    private XmlBeanFactory beanFactory = null;
    private FooSingleton() {
        Enumeration compCtxtCfg =
            getClass().getClassLoader().getResources("META-INF/components/components.xml");

        Enumeration resrcCtxCfg =
            getClass().getClassLoader().getResources("META-INF/components/resources.xml");
            /* Loop through all the spring xml files and load bean factory. */

          }
}

Now, once you have build all your EAR’s, WAR’s and JAR’s, your application classapath will determine which spring application contexts will be loaded! The elegance of abstraction.

Lesson learned: Always question patterns that seem overly complicated and cumbersome.

Were finally up! After 3 months of effort, odecee has completed the company site and we have launched our blog for all to read and respond to. Its been a great journey for all those involved in setting up the site material.

Thanks to all those who have supported us by providing and reviewing the site content. We are very grateful for all your hard work.

Now its time to begin our journey…