Runtime Property Configuration using injection question

[bonnyr]

I'm having a conceptual (?) problem with properties and injection:

I'm converting a legacy system to use spring and have done a lot of
DI using Spring to great effect, removing a lot of singletons in the
process...

However, there's one area in the application which I cannot seem to get
my head around and that is the use of properties (as in System properties)
together with Spring. The application is deployed onto some installation
directory (it is a stand alone application), and it requires references to
names of directories in which it can find resources, or into which it can
create new files. These directory names are resolved during installation
and are placed using some known property names in the global property
file, which is read during startup to bring this info into the application.

My problem is two fold, essentially:

1. What is a good practice to replace calls like GlobalProperties.get(KEY),
using Spring? Basically a typical pattern of current code in the Legacy
system is:

 
... 
private static final String DIR_NAME = GlobalProperties.get(KEY);
...
void method() { ... new File(DIR_NAME, fileName); ...}

The reason is that there are many such properties and
so configuring using Spring would require a large number of injections,
into a large number of classes, or essentially copying from the
propery file into a singleton which holds
these values. There is of course the intention to avoid
dependency on/knowledge of the Spring application context
as much as possible (this is why we use this IoC in the first place).

2. How does Spring address the issue of run time configuration values in
a way that does not expose the Spring xml configuration files to the
end user? This, in my mind, the difference between the role Spring plays
to wire up application components (which is fixed) and usage of these
run time parameters, which is fairly dynamic and may be unknown at
coniguration time.


Thanks for any answer / clarification

[Alarmnummer]

I'm having a conceptual (?) problem with properties and injection:

My problem is two fold, essentially:


1. What is a good practice to replace calls like GlobalProperties.get(KEY),
using Spring? Basically a typical pattern of current code in the Legacy
system is:

See 3.8. Customizing bean factories with BeanFactoryPostProcessors

2. How does Spring address the issue of run time configuration values in
a way that does not expose the Spring xml configuration files to the
end user? This, in my mind, the difference between the role Spring plays
to wire up application components (which is fixed) and usage of these
run time parameters, which is fairly dynamic and may be unknown at
coniguration time.

You can use property files (if a user finds that acceptable):

directory=c:/temp
maximumSize=10

I believe there are other postprocessorimplementations as well (not part of the Spring distribution). If my memory serves me right there also is a database version. So your system needs a webinterface for the enduser te modify system properties in the db. But I don`t know how easy it is going to be to update the system with the new values. I believe that in one of the next versions of Spring this problem will be solved.

[bonnyr]

See 3.8. Customizing bean factories with BeanFactoryPostProcessors

I'm not sure I've explained correctly (or otherwise, that I understand your
response :oops. I suppose what I'm asking is what should I replace my
legacy code mentioned in my post with - is there a 'Spring' way to achieve
this?
The intent in the legacy code is to use some sort of a registry singleton
(which happens to be a class with a bunch of static methods), and I think
it is certainly conveyed by the method chosen. I would like to achieve
the same thing using Spring without the various classes using the registry
knowing about spring. I do not see how I can avoid using the concept of
the registry in the first place (hence my confusion) because the usage
is spread throughout the code...

Have I missed the point here?

[Alarmnummer]

See 3.8. Customizing bean factories with BeanFactoryPostProcessors

I'm not sure I've explained correctly (or otherwise, that I understand your
response :oops.

I think I didn`t understand what you want. I thought you needed to move properties declared in the appcontext to an external property file. But my guess is that this isn`t the problem. You have a legacy system and you want to make Spring responsible of the properties and not a property file.

Hmm.. I don`t know what the advantage of Spring would be in this case. I would stick with the propertyfiles and if you abstract it in some kind of function, the choice between Spring and the property file would (for the client of the code) only be an implementation detail.

I do not see how I can avoid using the concept of
the registry in the first place (hence my confusion) because the usage
is spread throughout the code...

If you register the app context with some kind of singleton (the application can also be retrieved from the servlet context btw) everybody could make use of the appcontext. If you only provide some getters for properties, the clients of the code wouldn`t need to know about Spring.

Have I missed the point here?[/quote]

[bonnyr]

Alan,

No, I think this time, we're both on the same page .

This just means that the current registry design is there to stay, and it
would not benefit from using Spring. Since I'm rather a novice with Spring,
I was looking for somce advice on what's being practiced out there...