Start operation semantics for AS - Request for Feedback
Larry O'Leary
loleary at redhat.com
Wed May 2 17:08:27 UTC 2012
On Wed, 2012-05-02 at 12:43 -0400, Jay Shaughnessy wrote:
> ...
> If startScriptArgs is unset, then the start script defaults to the
> legacy behavior and applies the Configuration and Bind Address
> discovered in the individual connection props. This is also not a
> union. If any startScriptArgs are specified then those will be the only
> script args applied. The discovery code is designed to try and discover
> all of the originally supplied script args.
>
> One question is whether the current behavior is correct when and if the
> Configuration or Bind Address connection properties are edited or, for
> any other reason, don't match the settings in startScriptArgs. As
> stated above, those property values are ignored of startScriptArgs is
> set. Meaning, the value in startScriptArgs will supersede any setting
> for the individual properties.
>
> My feeling is that this is OK, it's possible those script args will even
> apply if the customer is using a custom script. The property
> descriptions could be updated to make clear that the value is overridden
> if startScriptArgs is set. Additionally, the behavior can be formally
> documented and referenced in the release notes.
>
> If you have an opinion on any of the above semantics please let us know
> so the new feature can be finalized. Thanks, Jay and Ian.
>
I think this is okay. However, an enhancement to the feature should be
to support connection property substitution within the startScriptArgs
value. For example:
-b @config.bindAddress@ -c @config.serverName@ -Dmycustom.system.prop=true -Djboss.platform.mbeanserver
This will allow the current behavior to continue to be used and control
the command line with actual configuration values in the event they
change.
I can not seem to find the BZ that described this behavior but the
original request was to support 'additional' command-line arguments to
the start and stop scripts. So that the legacy behavior continues to be
used by additional arguments be passed in more easily. I like your
solution better but feel that we could handle the use-case to improve
usability instead of complicating it with a "NOTE: this stuff becomes
hard-coded if you set anything here"
--
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513
More information about the rhq-devel
mailing list