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