Eric Sammer wrote:
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
welcome?
I have looked at this in the past, a "what would it take to move to a
config factory", and concluded it would be pretty tricky undertaking.
There are lot of places that create new Configuration instances.
That said, I would like, it, after I've got my lifecycle patches up to
date and in.
(I'd also like things like datanode and tasktracker to reread from
config things like the namenode and JT addresses whenever they have to
reconnect to the master nodes, but that's even more complex)
