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

Reply via email to