[JIRA] Updated: (MDA-67) allow the setting of Spring variables from the command line

[Ian Young (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/MDA-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Young updated MDA-67:
-------------------------

    Description: 
At the moment, if you want to get something dynamic into the Spring configuration, the easiest way to do it appears to be to use a JVM -Dfoo=bar and then use something like this:

<constructor-arg value="#{systemProperties['foo']}"/>

It would be nice to be able to collapse this to a normal command-line -Dfoo=bar resulting in setting a Spring variable referenced something like this:

<constructor-arg value="#foo"/>

This isn't trivial to do with the current (as of 0.7) CLI infrastructure, as jargs doesn't permit options with that syntax and neither does it permit multiple occurrences of an option.  So to do this "natively" in jargs you'd need to have a syntax something like this:

   --define=foo=bar,two=baz

One option, of course, is to move to another CLI parser.  We may want to do that anyway to simplify licensing concerns.

If we stick with jargs, though, we can do this another way.  When we obtain an args array to parse, we can pre-scan it for options starting with -D and then parse those manually and remove them from the array.  Then, after collecting the "defines" we can allow jargs' normal parsing to be applied to whatever is left.

This isn't hard, but I'm splitting it out here because I don't think that the relative benefit warrants delaying the 0.7 release.

  was:
At the moment, if you want to get something dynamic into the Spring configuration, the easiest way to do it appears to be to use a JVM -Dfoo=bar and then use something like this:

<constructor-arg value="#{systemProperties['foo']}"/>

It would be nice to be able to collapse this to a normal command-line -Dfoo=bar resulting in setting a Spring variable referenced something like this:

<constructor-arg value="#foo"/>

This isn't trivial to do with the current (as of 0.7) CLI infrastructure, as jargs doesn't permit options with that syntax and neither does it permit multiple occurrences of an option.  So to do this "natively" in jargs you'd need to have a syntax something like this:

   --define=foo=bar,two=baz

One option, of course, is to move to another CLI parser.  We may want to do that anyway to simplify licensing concerns.

If we stick with jargs, though, we can do this another way.  When we obtain an args array to parse, we can pre-scan it for options starting with -D and then parse those manually and remove them from the array.  Then, after collecting the "defines" we can allow jargs' normal parsing to be applied to whatever is left.

This isn't hard, but I'm splitting it out here because I don't think that the relative benefit doesn't warrant delaying the 0.7 release.


> allow the setting of Spring variables from the command line
> -----------------------------------------------------------
>
>                 Key: MDA-67
>                 URL: https://issues.shibboleth.net/jira/browse/MDA-67
>             Project: Metadata Aggregator
>          Issue Type: Improvement
>          Components: Command Line
>    Affects Versions: 0.7
>            Reporter: Ian Young
>            Assignee: Ian Young
>            Priority: Minor
>             Fix For: 0.8
>
>
> At the moment, if you want to get something dynamic into the Spring configuration, the easiest way to do it appears to be to use a JVM -Dfoo=bar and then use something like this:
> <constructor-arg value="#{systemProperties['foo']}"/>
> It would be nice to be able to collapse this to a normal command-line -Dfoo=bar resulting in setting a Spring variable referenced something like this:
> <constructor-arg value="#foo"/>
> This isn't trivial to do with the current (as of 0.7) CLI infrastructure, as jargs doesn't permit options with that syntax and neither does it permit multiple occurrences of an option.  So to do this "natively" in jargs you'd need to have a syntax something like this:
>    --define=foo=bar,two=baz
> One option, of course, is to move to another CLI parser.  We may want to do that anyway to simplify licensing concerns.
> If we stick with jargs, though, we can do this another way.  When we obtain an args array to parse, we can pre-scan it for options starting with -D and then parse those manually and remove them from the array.  Then, after collecting the "defines" we can allow jargs' normal parsing to be applied to whatever is left.
> This isn't hard, but I'm splitting it out here because I don't think that the relative benefit warrants delaying the 0.7 release.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira