October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-263) JASPI Support for Web Services

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-263?page=com.atlassian.jira.plugin.s... ] Alessio Soldano updated WFLY-263: --------------------------------- Assignee: Jim Ma (was: Alessio Soldano) > JASPI Support for Web Services > ------------------------------ > > Key: WFLY-263 > URL: https://issues.jboss.org/browse/WFLY-263 > Project: WildFly > Issue Type: Feature Request > Components: Security, Web Services > Reporter: Anil Saldhana > Assignee: Jim Ma > Fix For: 8.0.0.Beta1 > > > Take care of the JASPI requirements for SOAP layer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-284) Timer nullpointer due to race condition during update

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-284: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> made a comment on [bug 1015323|https://bugzilla.redhat.com/show_bug.cgi?id=1015323] Fixed by Mark with this commit: https://github.com/droolsjbpm/drools/commit/859b1a5915fe89ba37483afc84c6d... > Timer nullpointer due to race condition during update > ----------------------------------------------------- > > Key: DROOLS-284 > URL: https://issues.jboss.org/browse/DROOLS-284 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-284) Timer nullpointer due to race condition during update

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-284: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1015323|https://bugzilla.redhat.com/show_bug.cgi?id=1015323] from NEW to MODIFIED > Timer nullpointer due to race condition during update > ----------------------------------------------------- > > Key: DROOLS-284 > URL: https://issues.jboss.org/browse/DROOLS-284 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2164) Read only App, Module and Comp Naming Contexts

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2164?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-2164: ---------------------------------- Description: Java EE 7 (and its TCK) mandates that java:app, java:module and java:comp contexts to be read only. was:Wildfly allows EE components to modify their naming environment (and every other naming context too), and such behaviour may be undesirable, thus the EE subsystem configuration should include an attribute to globally turn on or off such functionality. > Read only App, Module and Comp Naming Contexts > ---------------------------------------------- > > Key: WFLY-2164 > URL: https://issues.jboss.org/browse/WFLY-2164 > Project: WildFly > Issue Type: Feature Request > Components: EE, Naming > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Java EE 7 (and its TCK) mandates that java:app, java:module and java:comp contexts to be read only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-283) SegmentMemory staged LeftTuples not always accessed correctly

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin... ] Mario Fusco updated DROOLS-283: ------------------------------- Issue Type: Bug (was: Feature Request) > SegmentMemory staged LeftTuples not always accessed correctly > ------------------------------------------------------------- > > Key: DROOLS-283 > URL: https://issues.jboss.org/browse/DROOLS-283 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > Some times it accesses the current staging list, instead of the one in the segment memory. > The NotNode should use the passed staging list, and not retrieve it directly. > They should always use takeAll, to ensure they are thread safe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-284) Timer nullpointer due to race condition during update

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin... ] Mario Fusco updated DROOLS-284: ------------------------------- Issue Type: Bug (was: Feature Request) > Timer nullpointer due to race condition during update > ----------------------------------------------------- > > Key: DROOLS-284 > URL: https://issues.jboss.org/browse/DROOLS-284 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-283) SegmentMemory staged LeftTuples not always accessed correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-283: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015208, https://bugzilla.redhat.com/show_bug.cgi?id=999851 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1015208) > SegmentMemory staged LeftTuples not always accessed correctly > ------------------------------------------------------------- > > Key: DROOLS-283 > URL: https://issues.jboss.org/browse/DROOLS-283 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > Some times it accesses the current staging list, instead of the one in the segment memory. > The NotNode should use the passed staging list, and not retrieve it directly. > They should always use takeAll, to ensure they are thread safe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-280) lock-on-active broken

by Anthony Patricio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin... ] Anthony Patricio updated DROOLS-280: ------------------------------------ Description: Hi, lock-on-active is not working as expected. I seems to work as activation-group. Works fine with 5.x Fails with 6.0.0 CR3 and CR4 Fact: {code:java} public class Poc implements Serializable { private static final long serialVersionUID = 1L; private long id = 1; private boolean test1 = false; private boolean test2 = false; private int foundTest = 0; ... } {code} Rule: {code:java} rule "test1" lock-on-active dialect "mvel" when $poc:Poc( isTest1() ) then System.out.println("test1 found"); modify($poc) { setFoundTest($poc.getFoundTest() + 1) } end rule "test2" lock-on-active dialect "mvel" when $poc:Poc( isTest2() ) then System.out.println("test2 found"); modify($poc) { setFoundTest($poc.getFoundTest() + 1) } end {code} Test: {code:java} @Test public void lockOnActiveTest() { // Get the Knowledge base from the DRL file KieSession kSession = getSF(); Poc poc = new Poc(); poc.setTest1(true); poc.setTest2(true); kSession.insert(poc); // Fire the rules kSession.fireAllRules(); assertTrue("broken",poc.getFoundTest()==2); // Clean up kSession.dispose(); } {code} was: Hi, lock-on-active is not working as expected. I seems to work as activation-group. Works fine with 5.x Fails with 6.0.0 CR3 and CR4 Fact: public class Poc implements Serializable { private static final long serialVersionUID = 1L; private long id = 1; private boolean test1 = false; private boolean test2 = false; private int foundTest = 0; ... } Rule: rule "test1" lock-on-active dialect "mvel" when $poc:Poc( isTest1() ) then System.out.println("test1 found"); modify($poc) { setFoundTest($poc.getFoundTest() + 1) } end rule "test2" lock-on-active dialect "mvel" when $poc:Poc( isTest2() ) then System.out.println("test2 found"); modify($poc) { setFoundTest($poc.getFoundTest() + 1) } end Test: @Test public void lockOnActiveTest() { // Get the Knowledge base from the DRL file KieSession kSession = getSF(); Poc poc = new Poc(); poc.setTest1(true); poc.setTest2(true); kSession.insert(poc); // Fire the rules kSession.fireAllRules(); assertTrue("broken",poc.getFoundTest()==2); // Clean up kSession.dispose(); } > lock-on-active broken > --------------------- > > Key: DROOLS-280 > URL: https://issues.jboss.org/browse/DROOLS-280 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Anthony Patricio > > Hi, > lock-on-active is not working as expected. > I seems to work as activation-group. > Works fine with 5.x > Fails with 6.0.0 CR3 and CR4 > Fact: > {code:java} > public class Poc implements Serializable { > private static final long serialVersionUID = 1L; > private long id = 1; > private boolean test1 = false; > private boolean test2 = false; > private int foundTest = 0; > ... > } > {code} > Rule: > {code:java} > rule "test1" > lock-on-active > dialect "mvel" > when > $poc:Poc( isTest1() ) > then > System.out.println("test1 found"); > modify($poc) { setFoundTest($poc.getFoundTest() + 1) } > end > rule "test2" > lock-on-active > dialect "mvel" > when > $poc:Poc( isTest2() ) > then > System.out.println("test2 found"); > modify($poc) { setFoundTest($poc.getFoundTest() + 1) } > end > {code} > Test: > {code:java} > @Test > public void lockOnActiveTest() { > // Get the Knowledge base from the DRL file > KieSession kSession = getSF(); > > Poc poc = new Poc(); > poc.setTest1(true); > poc.setTest2(true); > > kSession.insert(poc); > > // Fire the rules > kSession.fireAllRules(); > > assertTrue("broken",poc.getFoundTest()==2); > > // Clean up > kSession.dispose(); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2164) Read only App, Module and Comp Naming Contexts

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2164?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-2164: ---------------------------------- Summary: Read only App, Module and Comp Naming Contexts (was: EE subsystem config to define if EE naming contexts are modifiable by EE components) > Read only App, Module and Comp Naming Contexts > ---------------------------------------------- > > Key: WFLY-2164 > URL: https://issues.jboss.org/browse/WFLY-2164 > Project: WildFly > Issue Type: Feature Request > Components: EE, Naming > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Wildfly allows EE components to modify their naming environment (and every other naming context too), and such behaviour may be undesirable, thus the EE subsystem configuration should include an attribute to globally turn on or off such functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-280) lock-on-active broken

by Anthony Patricio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin... ] Anthony Patricio updated DROOLS-280: ------------------------------------ Affects Version/s: 6.0.0.CR4 > lock-on-active broken > --------------------- > > Key: DROOLS-280 > URL: https://issues.jboss.org/browse/DROOLS-280 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Anthony Patricio > > Hi, > lock-on-active is not working as expected. > I seems to work as activation-group. > Works fine with 5.x > Fails with 6.0.0 CR3 and CR4 > Fact: > public class Poc implements Serializable { > private static final long serialVersionUID = 1L; > private long id = 1; > private boolean test1 = false; > private boolean test2 = false; > private int foundTest = 0; > ... > } > Rule: > rule "test1" > lock-on-active > dialect "mvel" > when > $poc:Poc( isTest1() ) > then > System.out.println("test1 found"); > modify($poc) { setFoundTest($poc.getFoundTest() + 1) } > end > rule "test2" > lock-on-active > dialect "mvel" > when > $poc:Poc( isTest2() ) > then > System.out.println("test2 found"); > modify($poc) { setFoundTest($poc.getFoundTest() + 1) } > end > Test: > @Test > public void lockOnActiveTest() { > // Get the Knowledge base from the DRL file > KieSession kSession = getSF(); > > Poc poc = new Poc(); > poc.setTest1(true); > poc.setTest2(true); > > kSession.insert(poc); > > // Fire the rules > kSession.fireAllRules(); > > assertTrue("broken",poc.getFoundTest()==2); > > // Clean up > kSession.dispose(); > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013