Announcement Announcement Module
Collapse
No announcement yet.
Runtime Property Configuration using injection question Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Runtime Property Configuration using injection question

    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:
    Code:
     
    ... 
    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

  • #2
    Re: Runtime Property Configuration using injection question

    Originally posted by bonnyr
    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):
    Code:
    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.

    Comment


    • #3
      Re: Runtime Property Configuration using injection question

      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?

      Comment


      • #4
        Re: Runtime Property Configuration using injection question

        Originally posted by bonnyr
        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]

        Comment


        • #5
          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...

          Comment

          Working...
          X