Lowell Kirsh wrote: > I have a Mapper class which needs access to several dependencies (such > as a db). It seems that because the framework is new'ing up instances of > my Mapper class, I have little control over its lifecycle. Up to now, > I've been setting them up as static fields in that class, which is not > ideal. Is there a better way to inject my dependencies?
Lowell: The way I've handled this in the past is to use the Mapper to instantiate a Spring ApplicationContext with all dependencies wired together. The advantages of this is that the guts of the application remain (mostly) unaware of, and do not require, the M/R infrastructure for testing. This also allows me to write the Mapper once and continue to iterate on the application logic by redeploying the Spring config. This also keeps the Mapper stateless between invocations of the M/R job which, in my opinion, is good. The downside is that there is start up overhead to Spring. In my case, that's fine; the overhead of the M/R setup / tear down is still less than the overall processing overhead without M/R on a single node (which is simply not possible). This also creates a dependency on Spring which for me isn't a problem. You can replace Spring with your DI framework of choice, of course, but this pattern works well for me. Hope this helps! Best regards. -- Eric Sammer e...@lifless.net http://esammer.blogspot.com