On Wed, Mar 18, 2015 at 9:08 AM, James R. Perkins <jperkins(a)redhat.com> wrote:
This will definitely be an issue. I can guarantee that some will want
replace one option that's already defined resulting in a duplicate.
Processing the either option looking for duplicates is not an option.
Every time we introduce something that requires scanning JAVA_OPTS it's
extremely painful and error prone.
How do we recommend users to specify JAVA_OPTS in that case? Edit
In docker wouldn't we just do something like:
RUN echo "JAVA_OPTS=\"$JAVA_OPTS -Dkey.value\"" >>
This worked very well, thanks for the tip!
On 03/18/2015 06:57 AM, Darran Lofthouse wrote:
> One issue with that however is how you would cope with duplicate or
> conflicting options within the OPTS, all it could take is one conflict a
> script can not resolve and you are back to just defining the whole string.
> Darran Lofthouse.
> On 18/03/15 12:42, Arun Gupta wrote:
>> I'd like to not override the default JAVA_OPTS used by WildFly,
>> instead add my own value to it. I think that's where MORE_JAVA_OPTS or
>> EXTRA_JAVA_OPTS could be useful.
>> Copy/pasting the existing JAVA_OPTS and including my own does not feel right :)
>> On Tue, Mar 17, 2015 at 10:22 PM, Jaikiran Pai <jai.forums2013(a)gmail.com>
>>> Hi Arun,
>>> The WildFly startup scripts allow you to *override* the JAVA_OPTS by setting
>>> an environment variable of that same name. See the standalone.conf (for *nix
>>> OS) file for details. From what I see, there's no option to append to
>>> default JAVA_OPTS, by setting an environment variable. This could be worked
>>> around (in a bit brittle manner) by setting the overriding environment
>>> variable value to contain the default JAVA_OPTS (copied over from
>>> standalone.conf) plus the other custom/specific ones that the caller wants
>>> to pass.
>>> On Wednesday 18 March 2015 10:27 AM, Arun Gupta wrote:
>>>> Can standalone.sh script be extended such that it takes an additional
>>>> environment variable that is then added to JAVA_OPTS during startup?
>>>> This can be used for passing additional Java options from WildFly
>>>> Docker image. Cursory look at the script does not reveal anything like
>>>> that exist.
> wildfly-dev mailing list
James R. Perkins
JBoss by Red Hat
wildfly-dev mailing list