On Wed, May 27, 2009 at 4:29 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
...
>> This is a very common problem, but AFAIK is not adequately solved.
>>
>
> Yes.
>
> Specifically for programatic access I am wondering a interface bean proxy
> approach to property config files.
>
> @Properties("x.y.z")
> public interface XProps {
> @Name("...")
> int getValue();
> }
>
> The "x.y.z" is a virtual name that could be mapped to an actual location
> based on deployment requirements.
>
> IIRC GF internals has an interesting approach to getting immutable XML
> config information using its underlyng DI framework to help with the
> programmatic access.
This is one possibility, although the one that has worked best for me
has been to completely move this out of Java side. That is, to
pre-process things so that service itself uses static location
(relative to its environment root).
This location can be wired in using IoC, or isolated in specific part
of setup code; or like you suggest, via annotations. So this could be
complementary part.
What I did learn with tackling these problems (where is DB for
dev/qa/staging/prod; setting xyz only added to fleet of hosts in
europe etc) is that scripting languages are quite nifty for simple
templating.
And also that conventions are light-weight but powerful way, esp. when
coupled with templating, to produce most combinations that are needed
for actual real-life setup.
Oh and of course that the best way to solve the problems is to have
real problems to solve at hand, i.e. not trying to solve hypothetical
problems. It's hard to avoid over-engineering things, but it really
pays off. IMO.
-+ Tatu +-