Re: [Hawkular-dev] Property passing into Hawkular(-metrics)
My opinion is don't keep our own versions of modified WildFly files in our own
repositories as they will inevitably go stale and out of date.
We can do tricks in our mvn poms and assembly scripts to alter them during the build
(using ant scripts or whatever). We can look into standalone.conf (don't they provide
something like this?) Or contribute the change back to WildFly folks.
Worst case is we keep our own copies of modified WildFly files - but I just don't like
that option.
----- Original Message -----
Hey,
currently one can pass properties/options like the C* to use
via -Dkey=value pairs to standalone.sh/bat
This is a bit cumbersome and also does not work in cases, where
the command line is set at "compile time" like in a Dockerfile,
but the property needs to be set at run time (when docker run
a pre-made image).
There would be the option to set JAVA_OPTS before starting
the script, but JAVA_OPTS is
a) something that may apply to multiple java programs on a machine
and is thus not specific
b) inside standalone.conf not additive, so one has to repeat all the
options from standalone.conf on JAVA_OPTS
So I propose hat we add (similar to RHQ) some HAWKULAR_OPTS
that are additive to JAVA_OPTS.
We need to modify standalone.sh/bat to source them (and keep the
modified versions in our git repo.
Alternatives could be
- create wrapper scripts that set JAVA_OPTS and call standalone.sh,
but that only indirectly solves [1]
- as the WildFly team to add some WF_LOCAL_OPTS in upcoming releases.
I fear that may take too long.
Opinions?
[1] https://issues.jboss.org/browse/HAWKULAR-288
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev