January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11661) async-handler not working / logging.properties incompletely updated

by Marco Schulze (Jira)

[ https://issues.jboss.org/browse/WFLY-11661?page=com.atlassian.jira.plugin... ] Marco Schulze updated WFLY-11661: --------------------------------- Steps to Reproduce: # Set up a WildFly 10 or 11 (other versions might be affected, too, but I didn't test). # Start this WildFly and deploy sth., i.e. use it normally. # Stop the server. # Change the standalone.xml file: ## Rename the regular "FILE" logging-handler to "FILE.sync". ## Add a new async-handler like this: {quote}<async-handler name="FILE"> <queue-length value="512"/> <overflow-action value="block"/> <subhandlers> <handler name="FILE.sync"/> </subhandlers> </async-handler>{quote} # Start the WildFly again and wait a bit until it updates the {{logging.properties}}. # Check the {{logging.properties}}: Both handlers exist, now, hence it has definitely been written, but: *It lacks the sub-handlers for the "FILE" handler.* # Check the log file: *Nothing is logged, anymore.* And here the following steps to work around this bug: # Stop the WildFly, again. # Delete the {{logging.properties}} file. # Start the WildFly, again and wait for the {{logging.properties}} to be recreated. # Check the {{logging.properties}} and the log file: Now, everything is correct. was: # Set up a WildFly 10 or 11 (other versions might be affected, too, but I didn't test). # Start this WildFly and deploy sth., i.e. use it normally. # Stop the server. # Change the standalone.xml file: ## Rename the regular "FILE" logging-handler to "FILE.sync". ## Add a new async-handler like this: {quote}<async-handler name="FILE"> <queue-length value="512"/> <overflow-action value="block"/> <subhandlers> <handler name="FILE.sync"/> </subhandlers> </async-handler>{quote} # Start the WildFly again and wait a bit until it updates the {{logging.properties}}. # Check the {{logging.properties}}: Both handlers exist, now, hence it has definitely been written, but: *It lacks the sub-handlers for the "FILE" handler.* # Check the log files: *Nothing is logged, anymore.* And here the following steps to work around this bug: # Stop the WildFly, again. # Delete the {{logging.properties}} file. # Start the WildFly, again and wait for the {{logging.properties}} to be recreated. # Check the {{logging.properties}} and the log files: Now, everything is correct. > async-handler not working / logging.properties incompletely updated > ------------------------------------------------------------------- > > Key: WFLY-11661 > URL: https://issues.jboss.org/browse/WFLY-11661 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final, 11.0.0.Final > Reporter: Marco Schulze > Assignee: Brian Stansberry > Priority: Major > > The {{logging.properties}} file which is generated from the {{standalone.xml}} is not correctly updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its {{subhandlers}}, the {{logging.properties}} then lacks the following line: > {quote}handler.FILE.handlers=FILE.sync{quote} > I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11661) async-handler not working / logging.properties incompletely updated

by Marco Schulze (Jira)

[ https://issues.jboss.org/browse/WFLY-11661?page=com.atlassian.jira.plugin... ] Marco Schulze updated WFLY-11661: --------------------------------- Description: The {{logging.properties}} file which is generated from the {{standalone.xml}} is not correctly updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its {{subhandlers}}, the {{logging.properties}} then lacks the following line: {quote}handler.FILE.handlers=FILE.sync{quote} I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. was: The {{logging.properties}} file which is generated from the standalone.xml is not always reliably updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its subhandlers, the logging.properties lacks the following line: {quote}handler.FILE.handlers=FILE.sync{quote} I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. > async-handler not working / logging.properties incompletely updated > ------------------------------------------------------------------- > > Key: WFLY-11661 > URL: https://issues.jboss.org/browse/WFLY-11661 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final, 11.0.0.Final > Reporter: Marco Schulze > Assignee: Brian Stansberry > Priority: Major > > The {{logging.properties}} file which is generated from the {{standalone.xml}} is not correctly updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its {{subhandlers}}, the {{logging.properties}} then lacks the following line: > {quote}handler.FILE.handlers=FILE.sync{quote} > I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11661) async-handler not working / logging.properties incompletely updated

by Marco Schulze (Jira)

[ https://issues.jboss.org/browse/WFLY-11661?page=com.atlassian.jira.plugin... ] Marco Schulze updated WFLY-11661: --------------------------------- Summary: async-handler not working / logging.properties incompletely updated (was: async-handler not working / logging.properties incompletely updated in at least WildFly 10 and 11) > async-handler not working / logging.properties incompletely updated > ------------------------------------------------------------------- > > Key: WFLY-11661 > URL: https://issues.jboss.org/browse/WFLY-11661 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final, 11.0.0.Final > Reporter: Marco Schulze > Assignee: Brian Stansberry > Priority: Major > > The {{logging.properties}} file which is generated from the standalone.xml is not always reliably updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its subhandlers, the logging.properties lacks the following line: > {quote}handler.FILE.handlers=FILE.sync{quote} > I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11661) async-handler not working / logging.properties incompletely updated in at least WildFly 10 and 11

by Marco Schulze (Jira)

Marco Schulze created WFLY-11661: ------------------------------------ Summary: async-handler not working / logging.properties incompletely updated in at least WildFly 10 and 11 Key: WFLY-11661 URL: https://issues.jboss.org/browse/WFLY-11661 Project: WildFly Issue Type: Bug Affects Versions: 11.0.0.Final, 10.1.0.Final Reporter: Marco Schulze Assignee: Brian Stansberry The {{logging.properties}} file which is generated from the standalone.xml is not always reliably updated. When switching to asynchronous logging by renaming the {{"FILE"}} handler to {{"FILE.sync"}} and then introducing an {{async-handler}} named {{"FILE"}} referencing {{"FILE.sync"}} in its subhandlers, the logging.properties lacks the following line: {quote}handler.FILE.handlers=FILE.sync{quote} I tested this with WildFly 10 and 11, but this bug might affect more (and newer) versions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3482) Terminology for DMN import

by Stetson Robinson (Jira)

[ https://issues.jboss.org/browse/DROOLS-3482?page=com.atlassian.jira.plugi... ] Stetson Robinson commented on DROOLS-3482: ------------------------------------------ [~tirelli], [~uxdlc], I see. Would we cover our bases better if we said *Included DMN artifacts* or *Included artifacts*? * Tab and page header: *Included DMN artifacts* / *Included artifacts* * Description: *Included DMN artifacts are externally defined DMN models or other DMN-related artifacts that have been added to this DMN file so that its decision requirements diagram or graph components are available to this DMN file.* Still not in love with the description wording, but would that general idea work? Would *assets* be better than *artifacts*? I hesitate to say "assets" because that's what we use in the general project import screen. > Terminology for DMN import > -------------------------- > > Key: DROOLS-3482 > URL: https://issues.jboss.org/browse/DROOLS-3482 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Stetson Robinson > Priority: Minor > Labels: drools-tools > > Define best term to use for importing a DMN file, from the project directory. Importing a .dmn file will include file nodes, data types, etc. The term will be used for a tab label, button labels, and the like. > UX mockups currently use "import" but other terms such as "include" have been discussed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2974) CLI completion after one or more spaces gives confusing result

by Vratislav Marek (Jira)

[ https://issues.jboss.org/browse/WFCORE-2974?page=com.atlassian.jira.plugi... ] Vratislav Marek commented on WFCORE-2974: ----------------------------------------- [~jdenise] If it is too risky to fix this issue because of CLI parser skip all whitespaces and then malformed command is unrecognize e.q.: {code:java} [standalone@localhost:9990 /] /subsystem=logging/logging-profile=myapp:add {"outcome" => "success"} {code} {code:java} [standalone@localhost:9990 /] /sub ystem=logging/logging-profile=myapp:add { "outcome" => "failed", "failure-description" => "WFLYCTL0030: No resource definition is registered for address [ (\"subystem\" => \"logging\"), (\"logging-profile\" => \"myapp\") ]", "rolled-back" => true } {code} What about fix this with modify Tab Completion to verify if number of characters is same as number of characters in trimed string e.q.: {code:java} "/sub ".length = 5; "/sub".length = 4; {code} Tab Completion must contains number of entred character, or not? > CLI completion after one or more spaces gives confusing result > -------------------------------------------------------------- > > Key: WFCORE-2974 > URL: https://issues.jboss.org/browse/WFCORE-2974 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Beta26 > Reporter: Chao Wang > Assignee: Jean-Francois Denise > Priority: Minor > > CLI completion after one or more spaces gives confusing result. > {noformat} > [standalone@localhost:9990 /] /sub[space]TabKey Here > above completion returns result: > [standalone@localhost:9990 /] /sub ystem= > It seems the space before TabKey is recognized as character 's'. > Go on for a second TabKey, it will not list any subsystem candidates. > {noformat} > I think the first completion is not necessary as the {{sub}} with a following space is not a valid path. It'd better stop there rather than return completion result {{/sub ystem=}}. But this is a minor case. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3583) A comment creates an infinite loop

by Osira Ben (Jira)

Osira Ben created DROOLS-3583: --------------------------------- Summary: A comment creates an infinite loop Key: DROOLS-3583 URL: https://issues.jboss.org/browse/DROOLS-3583 Project: Drools Issue Type: Bug Affects Versions: 7.16.0.Final Reporter: Osira Ben Assignee: Mario Fusco This rule file makes the engine stuck in an infinite loop. {code:drools} package com.example declare Counter value: int end rule "Init" when not Counter() then drools.insert(new Counter(0)); end rule "Loop" when c: Counter() then // removing this comment line removes the loop c.setValue(1); update(c); end {code} But the loop is not an issue. The issue is that if the commented line is removed the loop is gone. This code doesn't cause the loop. {code:drools} package com.example declare Counter value: int end rule "Init" when not Counter() then drools.insert(new Counter(0)); end rule "Loop" when c: Counter() then c.setValue(1); update(c); end {code} Java code used to run the engine. {code:java} public class DroolsLoopingTest { public static class LoopError extends RuntimeException { } public static void main(String[] args) { System.setProperty("drools.dump.dir", "."); final KieServices ks = KieServices.Factory.get(); final KieRepository kr = ks.getRepository(); final KieFileSystem kfs = ks.newKieFileSystem(); kfs.write("src/main/resources/loop.drl", new ClassPathResource("loop.drl")); final KieBuilder kb = ks.newKieBuilder(kfs); kb.buildAll(); if (kb.getResults().hasMessages(Message.Level.ERROR)) throw new RuntimeException(kb.getResults().toString()); final KieContainer kContainer = ks.newKieContainer(kr.getDefaultReleaseId()); KieSession kSession = kContainer.newKieSession(); kSession.addEventListener(new DefaultAgendaEventListener() { private int i = 0; @Override public void afterMatchFired(AfterMatchFiredEvent event) { System.out.println(event); if (++i > 10) throw new LoopError(); } }); try { kSession.fireAllRules(); throw new RuntimeException("Expected loop error"); } catch (LoopError e) { System.out.println("Loop detected"); } } } {code} I noticed a difference in generated code. The rule file with the comment line generates this code {code:java} public static void defaultConsequence(KnowledgeHelper drools, com.example.Counter c, org.kie.api.runtime.rule.FactHandle c__Handle__ ) throws java.lang.Exception { org.kie.api.runtime.rule.RuleContext kcontext = drools; // removing this comment line removes the loop c.setValue(1); { drools.update( c__Handle__, org.drools.core.util.bitmask.AllSetButLastBitMask.get(), com.example.Counter.class ); }; } {code} While the rule file without the comment line generates this code {code:java} public static void defaultConsequence(KnowledgeHelper drools, com.example.Counter c, org.kie.api.runtime.rule.FactHandle c__Handle__ ) throws java.lang.Exception { org.kie.api.runtime.rule.RuleContext kcontext = drools; c.setValue(1); { drools.update( c__Handle__, new org.drools.core.util.bitmask.LongBitMask(2L), com.example.Counter.class ); }; } {code} Expected result is that comments should not affect engine behavior. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4302: ---------------------------------------- Assignee: (was: Darran Lofthouse) > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-11660 to WFCORE-4302: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4302 (was: WFLY-11660) Component/s: Security (was: Security) Affects Version/s: 7.0.0.Final (was: 15.0.0.Final) (was: 15.0.1.Final) > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Darran Lofthouse > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11660) SNI wildcard mappings match multiple level of subdomain

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFLY-11660?page=com.atlassian.jira.plugin... ] Jan Stourac commented on WFLY-11660: ------------------------------------ I've updated issue description with also reproduction steps and moved this to WFLY project as this applies for WildFly 15 now. > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFLY-11660 > URL: https://issues.jboss.org/browse/WFLY-11660 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 15.0.0.Final, 15.0.1.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Darran Lofthouse > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2019