Matthias Ernst's Weblog

Spring prototype definitions as a factory

Mike wrote about using spring to create job processors dynamically from job types. We use a similar pattern in our content management system. Documents in our CMS have types and different attributes based on type. Document types are grouped in a hierarchy. It's obvious to map document types to a Java class hierarchy - and it's obvious that an application programmer wants to extend these classes.

We want to provide the developer with a factory interface that you can hand an arbitrary document and you'll receive an instance of the corresponding java class. Easy enough, we thought, we'll have a map from document types to class objects, call #newInstance and #setDocument. However, it's not that easy. The application developer will want to access different application services from within such a bean - we either need to provide a service locator or the services need to be injected into the beans. I disliked the service locator idea and since we're using spring to wire our framework objects it was only natural to let the developer tap into that functionality as well. So instead of having our own map, we simply ask spring's bean factory for an implementation (which must not be a singleton, of course), based on a naming convention:

  <bean id="doctypeA" class="ABean" singleton="false"/> <!-- no services -->
  <bean id="doctypeB" class="BBean" singleton="false"> <!-- inject service -->
    <property name="service">...</property>
  </bean>

This way, our factory is basically just a thin wrapper around a spring bean factory:

Object getObject(Document document) {
  result = beanFactory.getBean(document.type.name); // create bean
  result.document = document;
  return result;
}

Although the principle is so simple, I still find the effect of DI stunning. This factory pattern actually reminds me of the technique of currying: in a way, what the factory holds for "docTypeB" is a parameterless function that is the result of pre-binding the "service" parameter.

ariadna: memory leaks be gone

I've posted ariadna, a tool for dumping a JVM's heap and analyzing it for unwanted reference chains.

The tool, respectively its predecessor heapprofile, grew out of my frustration about commercial profilers. You have a piece of software that you know leaks memory. Go ahead and find a tool that helps you. All I found was all-encompassing profiler packages >50MB that run very slowly. And they try to visualize ten thousands of objects as boxes in a graph on a small canvas. Ridiculous. Also they record where objects are created. Pretty unnecessary, my IDE can tell me that. All I want is a tool that shows me: "there's 200 JSomethings" where there shouldn't and "this JSomething is around because ...". HAT is such a tool and it's been around forever. We used it to debug our editor back with JDK 1.2. Only it took a lot of memory and the agent required in the VM would slow things down, too. Reproducing in slo-mo.

Anyway, ariadna is my attempt at attacking this. I guess tools have become better by now but feeling up the VM from your agent is fun anyway. What it does? At first, I load all classes, tag them and remember their name. Then I iterate over the heap, again tagging each object with a unique id (I wonder how much memory that costs in the VM; have to browse the 1.5 SRL code). Finally I iterate over all references, dumping referrer and referee tag to a file. For each object, I also dump its class tag. An analyzer server maps the file into memory, sorts it by referee's tag. Now the incoming references of each object can be found in O(log(n)) which feels lightning fast on small heaps. It's so fast that the shortest reference chain from the root set is displayed with every object you navigate to. I'll should have tried larger heaps before going public ...

Enter

This is my third attempt at writing my very first blog entry. I decided it would be on the blog software I chose. My web space doesn't provide any CGI/PHP/Perl and I actually don't want to administer it anyway.

Thingamablog is completely standalone, written in Java and will publish my entries as static files along with an RSS 2.0 feed via FTP. Nice. A rich client UI makes it all the better. Kudos so far. I've expected much worse of a Java UI because I've only seen worse.

In the future, I hope to let you know about me and what I'm doing. And if nobody reads this it can be my journal.