Announcement Announcement Module
Collapse
No announcement yet.
specify import, scan package or classname based on property value (not system prop) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • specify import, scan package or classname based on property value (not system prop)

    Hi, is there anyway other than system property to pass values dynamically for the import filename, scan package base or classnames (other than factory for dynamic class) ?

    Alternatively, just a way to provide a default in the case that a property is not defined would be ideal too - i tried various methods to define this & use property placeholders etc but they all get invoked after imports & bean creations are executed.

    We're looking for some way to decide which files to include based on environment, and as this is Websphere to avoid system property as nescessity.

    thanks

  • #2
    I'm not sure if this will help you exactly or not, but I often do something like this to read property values:

    <contextroperty-placeholder location="./WEB-INF/bootstrap/${runtime.env}/jdbc.properties"/>

    So this DOES use a system property set to a specific environment (DEV, QA, TEST, PROD....), but THEN it allows to load what property values you want/need and use them via ${property_name} de-referencing.

    Comment


    • #3
      There are several ways to do that. It depends on the version of Spring you're using and whether you want to select configuration at build time or at load time. If build-time environment selection suits your needs and you use Maven, you may use Maven build profiles and resource filtering to replace ${environment} property with actual target environment.

      If you need load-time environment selection, then you probably need some external setting that is not part of your build artifact to choose the right configuration. System properties and environment variables are natural candidates for such external settings. Anything fancier (like DB lookup, etc.) requires custom resolution mechanism. Spring 3.1.M1 has some nice new features to help you with this task, check out http://blog.springsource.com/2011/02...ty-management/

      Comment


      • #4
        thanks - scenario 1 is exactly what i'm after

        Originally posted by Osvaldas Grigas View Post
        There are several ways to do that. It depends on the version of Spring you're using and whether you want to select configuration at build time or at load time. If build-time environment selection suits your needs and you use Maven, you may use Maven build profiles and resource filtering to replace ${environment} property with actual target environment.

        If you need load-time environment selection, then you probably need some external setting that is not part of your build artifact to choose the right configuration. System properties and environment variables are natural candidates for such external settings. Anything fancier (like DB lookup, etc.) requires custom resolution mechanism. Spring 3.1.M1 has some nice new features to help you with this task, check out http://blog.springsource.com/2011/02...ty-management/
        Thanks - will just have to hack around this until we get onto 3.1

        Comment


        • #5
          It is not much of hack - Scenario 1 is supported as long as you can use an environment variable to specify the import tag's filename [or subdirectory] name....

          Comment


          • #6
            ??

            Hmm, you just had to say some complpete waste of bits comment justjoe? I mention something explicitly, in our usage yes it is a bit of a hack. Ideally an env-entry or similar which is configurable per application would be usable, and is scriptable and the ha cluster knows to replicate to all our nodes, unlike an env var or system property, so yes i call it a hack for now.

            Comment

            Working...
            X