Friday, 12 October 2007
Roll your own poor man's injection, dirty style..
So I have to be honest, I'm a big fan of dependency injection, declarative transactions and automated session management, but I'm not a great fan of the almighty container. One of the weaknesses of EJB3 in my view is that you don't get services ala carte. I want Hibernate session management, but do I REALLY need object pooling (which is oft bad for garbage collection on high performance multiprocessor systems)? I want resource injection or declarative transaction management, but do I really need a special interface? I understand some of the technical reasons for these, but the technology for going without the full monty exists. That is why I'm kind of excited by both the work that Bill Burke is doing on EJB 3.1 and Spring's embrace of annotations. Still sometimes both are way overkill. The other night I was explaining to someone that sometimes I do my own "dirty injection". Take the following example from the not yet committed LDAP integration code in Meldware:
ClassLoader loader = Thread.currentThread().getContextClassLoader();
Class handlerClass = null;
XMLCommand cmd = null;
try {
String classname = FULL_PKG+op+COMMAND_EXT;
handlerClass = loader.loadClass(classname);
cmd = (XMLCommand) handlerClass.newInstance();
} catch (Exception ex) {
// TODO remove stack trace, add formal error handling messages
ex.printStackTrace();
throw new RuntimeException(ex);
}
...
try {
Method m = handlerClass.getMethod("setUserProfile", new Class[]{UserProfileService.class});
m.invoke(cmd, new Object[]{this.ups});
} catch (Exception m1) {
}
The key part is at the end with the "Method m =" stuff. This is basically part of a servlet that delegates to command handlers, some of which need certain services and some of which don't. You could do this with annotations if you wanted, by calling getMethods(..) and checking them for the wanted annotation, but this isn't a general use framework so a naming convention is fine for us.
I'd probably be more inclined to use EJB3ish type stuff for things like this if I could just new up stuff sans container and get just the services I ask for. JBoss has the technology to do this in fact with CgLib and such, but I think Burke has an AOP and EJB mindset which means: classloaders and pre/postcompilers or the almighty container. On the other hand Spring wants me to learn about "The RequiredAnnotationBeanPostProcessor" which sounds just awful. Worse there still seems to be XML spawned, and I would possibly remove the angle brackets from my keyboard if they weren't so darn useful in if statements. I get the "I don't want to play tricks" but I dunno CgLib (used by hibernate to make its proxies) seems pretty solid to me and I realize I'll need some kind of factory that does essentially what the above does, but why does the amount of reading I have to do to use it have to exceed the length of the above code sample and this blog entry (which is full of bloviation to boot)? Could be the doc, could be that I'm in a cranky mood, or it could be that the implementation could still be simpler. I report, fair and balanced, you decide :-).
I guess my bias would be to go with Spring if I had to choose now a days. I love Burke and the gang but my tolerance for closed-committee design is low. I can tell that Burke wants that to change, his frequent and detailed technical blog entries virtually make EJB committee secrecy not worth the time, but unlike Burke, the rest of the committee isn't taking accountability for the ideas and all of the other BS that goes into a committee. Kudos to Burke for giving us an inside look into the witch potion making (I assume all secret committees are doing something unholy possibly involving bestiality and things that would make Hani blush)! I think that right now the representative to the EJB committee from Oracle must have just proven he doesn't understand relational databases! The representative from IBM has just insisted that we have 12 new required interfaces instead of none and that the EJB3.1 TCK contains terms which will prevent open source implementations. Why do I assume this? Because if they don't want me to know...they must be dirty and incompetent. Since I don't know -- I have a very vivid imagination. (And why has Sun made worshiping the "dark lord" a requirement of the EJB3.1 TCK license?)
Technorati Tags: EJB3.1 Spring Open Source JCP NDA
