October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1763) Dependent rule not firing

by David Wade (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ] David Wade updated DROOLS-1763: ------------------------------- Attachment: 7.0.0.Beta6.txt > Dependent rule not firing > ------------------------- > > Key: DROOLS-1763 > URL: https://issues.jboss.org/browse/DROOLS-1763 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Beta7, 7.3.0.Final > Environment: Linux all versions. > JDK 1.8.0 Update 144 > Reporter: David Wade > Assignee: Edson Tirelli > Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt > > > We have been using Drools since 2.x. > Currently we use 7.0.0.Beta6 which works. > We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final. > Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions > {code} > rule "H2" > salience -300 > when > segment:SegmentWithTax( > containsTax("SQ") > , notContainsTax("H2", "RC") > ) > then > segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT"); > end > rule "SQ" > when > segment:SegmentWithTax( > !containsTax("SQ") > ) > then > modify(segment) { > addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS") > } > end > {code} > Will attach Drools trace logging output * 2. One for 7.0.0.Beta6, one for 7.3.0.Final. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1763) Dependent rule not firing

by David Wade (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1763?page=com.atlassian.jira.plugi... ] David Wade updated DROOLS-1763: ------------------------------- Attachment: 7.3.0.Final.txt > Dependent rule not firing > ------------------------- > > Key: DROOLS-1763 > URL: https://issues.jboss.org/browse/DROOLS-1763 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Beta7, 7.3.0.Final > Environment: Linux all versions. > JDK 1.8.0 Update 144 > Reporter: David Wade > Assignee: Edson Tirelli > Attachments: 7.0.0.Beta6.txt, 7.3.0.Final.txt > > > We have been using Drools since 2.x. > Currently we use 7.0.0.Beta6 which works. > We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final. > Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions > {code} > rule "H2" > salience -300 > when > segment:SegmentWithTax( > containsTax("SQ") > , notContainsTax("H2", "RC") > ) > then > segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT"); > end > rule "SQ" > when > segment:SegmentWithTax( > !containsTax("SQ") > ) > then > modify(segment) { > addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS") > } > end > {code} > Will attach Drools trace logging output * 2. One for 7.0.0.Beta6, one for 7.3.0.Final. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1763) Dependent rule not firing

by David Wade (JIRA)

David Wade created DROOLS-1763: ---------------------------------- Summary: Dependent rule not firing Key: DROOLS-1763 URL: https://issues.jboss.org/browse/DROOLS-1763 Project: Drools Issue Type: Bug Affects Versions: 7.3.0.Final, 7.0.0.Beta7 Environment: Linux all versions. JDK 1.8.0 Update 144 Reporter: David Wade Assignee: Edson Tirelli We have been using Drools since 2.x. Currently we use 7.0.0.Beta6 which works. We can't upgrade because since 7.0.0.Beta7 rules dependent on the consequence of another rule are not firing for some reason. This happens for us on 7.0.0.Beta7 through to 7.3.0.Final. Consider the following two rules. When run on 7.0.0.Beta6 both rules fire. From Beta7 through to 7.3.0.Final, only the SQ rule fire, despite the RC rule passing its conditions {code} rule "H2" salience -300 when segment:SegmentWithTax( containsTax("SQ") , notContainsTax("H2", "RC") ) then segment.addPercentageTaxEntry(taxCodeMap,"SQ","RC_13_PERCENT"); end rule "SQ" when segment:SegmentWithTax( !containsTax("SQ") ) then modify(segment) { addTaxEntry(taxCodeMap,"SQ_TRANSFER_TRANSIT_LESS_THAN_FOUR_HOURS") } end {code} Will attach Drools trace logging output * 2. One for 7.0.0.Beta6, one for 7.3.0.Final. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-179) el-api jigsaw package conflict

by Klemen Ferjancic (JIRA)

[ https://issues.jboss.org/browse/JBEE-179?page=com.atlassian.jira.plugin.s... ] Klemen Ferjancic closed JBEE-179. --------------------------------- Resolution: Rejected Opened an issue in error, the conflict is probably due to importing el-api and impl modules at the same time. Will reopen if issue is actually in spec jar. > el-api jigsaw package conflict > ------------------------------ > > Key: JBEE-179 > URL: https://issues.jboss.org/browse/JBEE-179 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Reporter: Klemen Ferjancic > Assignee: Scott Marlow > > When trying to use el-api spec in java 9 there is a package conflict in automatic module: > {code:java} > Error:java: module mymodule reads package javax.el from both javax.el.api and javax.el > {code} > Seems to be a similar issue to https://issues.jboss.org/browse/WELD-2305 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-179) el-api jigsaw package conflict

by Klemen Ferjancic (JIRA)

Klemen Ferjancic created JBEE-179: ------------------------------------- Summary: el-api jigsaw package conflict Key: JBEE-179 URL: https://issues.jboss.org/browse/JBEE-179 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-el-api Reporter: Klemen Ferjancic Assignee: Scott Marlow When trying to use el-api spec in java 9 there is a package conflict in automatic module: {code:java} Error:java: module mymodule reads package javax.el from both javax.el.api and javax.el {code} Seems to be a similar issue to https://issues.jboss.org/browse/WELD-2305 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-178) el-api jigsaw auto module naming broken

by Klemen Ferjancic (JIRA)

Klemen Ferjancic created JBEE-178: ------------------------------------- Summary: el-api jigsaw auto module naming broken Key: JBEE-178 URL: https://issues.jboss.org/browse/JBEE-178 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-el-api Reporter: Klemen Ferjancic Assignee: Scott Marlow /usr/lib/jvm/java-9-openjdk-9.0.0.181-1.fc26.x86_64/bin/jar --file=jboss-el-api_3.0_spec-1.0.10.Final.jar --describe-module Unable to derive module descriptor for: jboss-el-api_3.0_spec-1.0.10.Final.jar jboss.el.api.3.0.spec: Invalid module name: '3' is not a Java identifier Basically identical problem as https://github.com/jboss/jboss-transaction-api_spec/pull/5 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3355) logging subsystem should skip if directories can't be listed

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3355?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3355: ------------------------------------- Issue Type: Enhancement (was: Feature Request) > logging subsystem should skip if directories can't be listed > ------------------------------------------------------------ > > Key: WFCORE-3355 > URL: https://issues.jboss.org/browse/WFCORE-3355 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Affects Versions: 2.1.0.Final, 3.0.5.Final > Reporter: Janine Eichler > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > Following condition: > - a mounted volume within the jboss.log.dir > - the mounted volume is an ext filesystem > as a consequence a lost+found directory is automatically created, owned by root.root, permissions are 700. > Now when you spin up a jboss instance, the logging directory is recursively scanned, due to the lost+found folder the logging subsystem throws the error https://github.com/wildfly/wildfly-core/blob/802d4dfcf58e24030d6c43ed2b01... > using the cli or mgmt console to read the log is then not possible. > it might be good to skip reading those files/directories and continue rather than throwing an error. > i tested it using the EAP7 (so wildfly-logging-2.1.2-final-redhat.jar), but also built the 3.0.6-SNAPSHOT and used this jar in the logging subsystem to check whether it may have been already fixed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB

by Juan Martin Runge (JIRA)

Juan Martin Runge created WFLY-9443: --------------------------------------- Summary: Random deploy error with @Startup @Singleton EJB Key: WFLY-9443 URL: https://issues.jboss.org/browse/WFLY-9443 Project: WildFly Issue Type: Bug Components: CDI / Weld, Class Loading, EJB Affects Versions: 11.0.0.CR1 Environment: Wildfly 11.0CR1 + Vaadin 8.1.4 Tested on Debian 9.1 and Windows 10 Reporter: Juan Martin Runge Assignee: Martin Kouba Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean. Attached sample app, project, log with error and log with success. If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange. Also, this didnt happened with Wildfly 9 (same app deployed perfectly) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3359) Use non-compact ModelNode.writeString to print operation failure messages on multiple lines in the log

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3359?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3359: ------------------------------------------ I agree about log parsing. And these message already can be multiline, and for service issues almost always will be. So any parsing people are doing already has to account for multiline. If that kind of parsing is just scanning for the presence of certain message codes that would still work. It's only if they are doing complex parsing that they would have a problem and I have no interest in trying to avoid breaking changes to that kind of thing. Also, if people are truly parsing the string into DMR, or into some other data structure that has the same parsing rules as DMR, then this would not be a breaking change, as the non-compact output is a valid, parseable DMR representation. > Use non-compact ModelNode.writeString to print operation failure messages on multiple lines in the log > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3359 > URL: https://issues.jboss.org/browse/WFCORE-3359 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > When we log operation failures perhaps the logging would be better if we used the non-compact representation of DMR. > We need to confirm with GSS and folks like [~jamezp] that this is a good idea. A concern is the message has more lines, but it's often already a multi-line message. > See also some of the discussion on JBEAP-10713. > I think this is basically a change at: > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3359) Use non-compact ModelNode.writeString to print operation failure messages on multiple lines in the log

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3359?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3359: --------------------------------------- I think it would be okay to pretty print the DMR output. We have plenty of other places where multiline messages are used. The one area of concern would be users using some kind of log collector that parses the server log. However I'm generally of the opinion that parsing log output is not a good idea. > Use non-compact ModelNode.writeString to print operation failure messages on multiple lines in the log > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3359 > URL: https://issues.jboss.org/browse/WFCORE-3359 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > When we log operation failures perhaps the logging would be better if we used the non-compact representation of DMR. > We need to confirm with GSS and folks like [~jamezp] that this is a good idea. A concern is the message has more lines, but it's often already a multi-line message. > See also some of the discussion on JBEAP-10713. > I think this is basically a change at: > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 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 October 2017