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? 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 unwelcome. Thanks in advance for comments, etc. Regards. -- Eric Sammer e...@lifeless.net http://esammer.blogspot.com
