hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Sammer <e...@lifeless.net>
Subject Static state in Configuration and elsewhere
Date Tue, 09 Feb 2010 03:01:56 GMT
All (notably commiters):

In walking through the source, it seems that there are a number of cases
where static state exists. o.a.h.conf.Configuration is a good example of
a case were there is a static cache (see Configuration.REGISTRY) as well
as some class level state for default resources. These static members
make some testing scenarios difficult and I think they confuse and
complicate certain issues such as object lifecycle management.

To that end, I started working on a patch to tease the registry
behavior, default resources, and other similar state and behavior into a
simple ConfigurationFactory that knows how to manufacture instances of
Configuration. For now, the Factory would act as a singleton but retains
a public constructor for simplifying testing and for what I hope is
easier integration with things like Spring down the road.

While working on this, I realized this might be too big of a departure
from the original design. Is the static state thing on purpose? Is it
interesting to the rest of the community to factor this out? Does it
bother / disrupt anyone else? Are these sorts of design related changes

There are more classes than Configuration that exhibit this mixed
lifecycle sort of design, but I thought this was a "safe" place to start
as I see a way of maintaining backward compatibility for as a long as
necessary (although it's unpleasant, to be sure). At the same time, it
isn't entirely trivial given the pervasive nature of something like
Configuration so I don't want to get too deep if this sort of thing is

Thanks in advance for comments, etc.
Eric Sammer

View raw message