[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
[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
[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
[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
[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
[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
[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