[JBoss JIRA] (DROOLS-4943) Guided Decision Table Validation and Verification feature is broken
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-4943?page=com.atlassian.jira.plug... ]
Toni Rikkola edited comment on DROOLS-4943 at 1/16/20 11:41 AM:
----------------------------------------------------------------
I tried with -Dfull and it worked.
Sounds like the good old "full build not executed" issue. Now that the V&V is in the panel I think we need to make the GWT build run by default. And just to make it easier to test.
was (Author: rikkola):
Sounds like the good old "full build not executed" issue. Now that the V&V is in the panel I think we need to make the GWT build run by default. And just to make it easier to test.
> Guided Decision Table Validation and Verification feature is broken
> -------------------------------------------------------------------
>
> Key: DROOLS-4943
> URL: https://issues.redhat.com/browse/DROOLS-4943
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.32.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2020-01-16 16-01-08.png
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFCORE-4800) Add an env var driven expression to the standard deployment scanner scan-interval
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4800:
----------------------------------------
Summary: Add an env var driven expression to the standard deployment scanner scan-interval
Key: WFCORE-4800
URL: https://issues.redhat.com/browse/WFCORE-4800
Project: WildFly Core
Issue Type: Enhancement
Components: Deployment Scanner
Reporter: Brian Stansberry
Assignee: Emmanuel Hugonnet
Recurring deployment scans in a production container don't make a lot of sense. But our standard container images do rely on the boot time scan, so we don't want to just not use the scanner in images.
A middle ground is to make it easy to turn off the recurring scans by using an expression for our standard config's scanner interval, instead of the static "5000". Default would still be 5000 for compatibility.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-10852) smallrye-config: Consider logging a message when properties with same key and ordinal are present
by Michal Jurc (Jira)
[ https://issues.redhat.com/browse/WFLY-10852?page=com.atlassian.jira.plugi... ]
Michal Jurc updated WFLY-10852:
-------------------------------
Tester: Jan Stourac
> smallrye-config: Consider logging a message when properties with same key and ordinal are present
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-10852
> URL: https://issues.redhat.com/browse/WFLY-10852
> Project: WildFly
> Issue Type: Enhancement
> Components: MP Config
> Reporter: Michal Jurc
> Assignee: Jeff Mesnil
> Priority: Major
>
> Consider a deployment with default {{microprofile-config.properties}}:
> {code}managementDefault=Default value from default microprofile-config.properties{code}
> Deployment is deployed on server with the following {{ConfigSource}} defined:
> {code}[standalone@localhost:9990 /] /subsystem=microprofile-config-smallrye/config-source=testdefault:read-resource
> {
> "outcome" => "success",
> "result" => {
> "class" => undefined,
> "dir" => undefined,
> "ordinal" => 100,
> "properties" => {"managementDefault" => "Value from WildFly microprofile-config-smallrye config-source"}
> }
> }
> {code}
> Property {{"managementDefault"}} is always resolved to {{"Value from WildFly microprofile-config-smallrye config-source"}} in deployment.
> It would be useful to log a {{WARN}} level message when there is conflict like this with a notification of {{ConfigSources}} to save detective work in real world scenarios.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months