how to avoid required sysprops
by John Mazzitelli
I saw Juca posted this in a github comment:
> That happens because the `keycloak.server.url` property is not set, so, it
> defaults to localhost:8080 . You can start the server with
> `-Dkeycloak.server.url=http://localhost:8180/auth`
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/hawkular/hawkular-btm/pull/281#issuecomment-176169067
I think this is the problem I saw yesterday with my inventory going screwy (not sure, but I was using …
[View More]port offset, and didn't set that sysprop).
I bring this up to ask - is there anything we can do to not require that sysprop to be set? For example, is there some startup hook we can have that sets this automatically? I don't know if it's possible, but, it is pretty clear this is going to be a common problem that people will forget to set this anytime they bind to a different address (using -b) or using a different port offset.
Is there a JIRA on this so we can try to address it in the future?
I suppose if we do have some kind of installer, one solution would be the installer would add this sysprop to the startup .conf file.
[View Less]
9 years, 2 months
Metrics contributors must remove the api-diff precommit hook
by Thomas Segismont
Hi,
A pull request which removes JAX-RS 1.1 support from Metrics has just
been merged. Future minor and major versions of Metrics will support
JAX-RS 2.0 only.
For Metrics contributors, it means you should remove the api-diff
precommit hook from your .git/hooks directory.
Regards,
Thomas
9 years, 2 months
Alert trigger flags
by Luba Roitman
Hi, I am trying to understand the relationship between a number of alert trigger flags. While behavior of each individual flag (autoDisable, autoEnable and autoResolve) is clear, I have some questions on how trigger behaves when some of this flags are turned on:
1. autoDisable + autoEnable: this combination seems possible and logical, the triggers gets disabled, the user tends to alerts fired by the trigger, resolves them, the trigger gets enabled2. autoDisable + autoResolve: does this …
[View More]combination make sense? I can imagine trigger fires an alert, goes into disabled state. Does it switch into evaluating autoresolve conditions? If user manually enables such trigger after it got disabled after firing, will it be evaluating autoresolve conditions?3. autoEnable + autoResolve: same questions as before: alert fires, trigger starts to evaluate resolve conditions, then got disabled manually. User resolves alerts, the trigger becomes enabled because of autoEnable flag, but does it evaluate resolve conditions or problem conditions?
I would appreciate your help in clarifying the questions.
Thanks, Luba
[View Less]
9 years, 2 months
What should be the replacement for printlns in tests?
by Peter Palaga
Hi *,
Short version: How to configure the log levels for individual
jboss.logging loggers in tests run by maven outside the container?
Long version:
I was recently assigned https://issues.jboss.org/browse/HAWKULAR-264 Add
println checks to the checkstyle. It says that "Tests shouldn't be
allowed to have printlns, we should enforce this via the checkstyle plugin."
I fully agree for tests being run on the server side - those can use
JBoss Logging in the very same manner as the server code.
…
[View More]
However, what is the best replacement for println()s in tests that are
run outside the server?
I tried using JBoss Logging there too but I failed completely to find a
way to configure the log levels for individual loggers. Does anybody
know how to do that?
To get my work done without using printlns, I started to use
java.util.logging configured via logging.properties :
https://github.com/hawkular/hawkular-agent/blob/master/hawkular-wildfly-a...
So what should be the replacement for printlns in tests?
Thanks,
Peter
[View Less]
9 years, 2 months
