September 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2173) Get subsystem test framework working with AS 7.2.0 legacy controller

by Kabir Khan (JIRA)

Kabir Khan created WFLY-2173: -------------------------------- Summary: Get subsystem test framework working with AS 7.2.0 legacy controller Key: WFLY-2173 URL: https://issues.jboss.org/browse/WFLY-2173 Project: WildFly Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 8.0.0.CR1 -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1759) Existing management WS section improvements / consolidation

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-1759?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-1759: --------------------------------------- Also see https://github.com/wildfly/wildfly/pull/5162 > Existing management WS section improvements / consolidation > ----------------------------------------------------------- > > Key: WFLY-1759 > URL: https://issues.jboss.org/browse/WFLY-1759 > Project: WildFly > Issue Type: Enhancement > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Beta1 > > > We need to clarify the ws integration behavior when user provides not valid or undefined values in the webservices section of the domain. It's also not clear what the stack does after values are set in fields requiring re-load. > We should also consider creating services for EndpointConfigAdd/Remove, HandlerAdd/Remove, HandlerChainAdd/Remove, PropertyAdd/Remove (at least for the first couple), similarly to what has been done for ClientConfigAdd/Remove in WFLY-227. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1 generates rules looping

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-276: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012933 > Stream mode with CR4-Pre1 generates rules looping > -------------------------------------------------- > > Key: DROOLS-276 > URL: https://issues.jboss.org/browse/DROOLS-276 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Environment: Drools 6.0.0.CR4-Pre1 > Reporter: Richard Bourner > Assignee: Mark Proctor > Attachments: Drools6Stream.zip > > > When in STREAM mode, our rules are looping because of an update. > The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1 generates rules looping

by Richard Bourner (JIRA)

[ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin... ] Richard Bourner updated DROOLS-276: ----------------------------------- Attachment: Drools6Stream.zip > Stream mode with CR4-Pre1 generates rules looping > -------------------------------------------------- > > Key: DROOLS-276 > URL: https://issues.jboss.org/browse/DROOLS-276 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Environment: Drools 6.0.0.CR4-Pre1 > Reporter: Richard Bourner > Assignee: Mark Proctor > Attachments: Drools6Stream.zip > > > When in STREAM mode, our rules are looping because of an update. > The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1 generates rules looping

by Richard Bourner (JIRA)

Richard Bourner created DROOLS-276: -------------------------------------- Summary: Stream mode with CR4-Pre1 generates rules looping Key: DROOLS-276 URL: https://issues.jboss.org/browse/DROOLS-276 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR4 Environment: Drools 6.0.0.CR4-Pre1 Reporter: Richard Bourner Assignee: Mark Proctor When in STREAM mode, our rules are looping because of an update. The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2155) Defining <outbound-connections> in <management> prevents the server to start

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2155: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from POST to MODIFIED > Defining <outbound-connections> in <management> prevents the server to start > ---------------------------------------------------------------------------- > > Key: WFLY-2155 > URL: https://issues.jboss.org/browse/WFLY-2155 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Darran Lofthouse > Priority: Blocker > Labels: rbac-filed-by-qa > Fix For: 8.0.0.Beta1 > > > If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message: > {code} > 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.UnsupportedOperationException > at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final] > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > ... 3 more > 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section): > {code:xml} > <outbound-connections> > <ldap name="ldap" url="ldap://localhost:10389"/> > </outbound-connections> > {code} > Then I try to start the server (using plain old {{./bin/standalone.sh}}). -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2135) Change distributed config on address settings to Page instead of Block

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2135: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074] from POST to MODIFIED > Change distributed config on address settings to Page instead of Block > ---------------------------------------------------------------------- > > Key: WFLY-2135 > URL: https://issues.jboss.org/browse/WFLY-2135 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 8.0.0.Alpha4 > Reporter: Clebert Suconic > Assignee: Clebert Suconic > Fix For: 8.0.0.Beta1 > > > We have had so many cases of questions about why the producing is blocked when not consuming. > Users are expecting Page by default, so we should change the default. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-275) RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-275: ----------------------------------- Summary: RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock) Key: DROOLS-275 URL: https://issues.jboss.org/browse/DROOLS-275 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR3 Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40 Reporter: Duncan Doyle Assignee: Mark Proctor I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule: rule "SimpleFactTimeWindow" when $s1: SimpleFact() from entry-point LinkyStream $s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream then System.out.println("Rule fired, found 2 Facts within the time window."); end I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:724) Caused by: java.lang.NullPointerException at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304) at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80) at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117) at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150) at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183) at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936) at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233) at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142) at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7) ... 6 more Exception in ReteOO: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:724) Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction@2e3aeda at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225) at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371) at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278) at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131) at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56) at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140) at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7) ... 6 more Caused by: java.lang.NullPointerException at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324) at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67) at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108) at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147) at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99) at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213) at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73) at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135) at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125) at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47) at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39) at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502) at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387) at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430) at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266) at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592) at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223) ... 12 more What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected). I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/ I've added some Maven profiles so you can easily observe the behaviour: - mvn -PallRuns exec:java : this runs both the persistence and the reload in the same JVM, no exception, everything works fine. - mvn -PfirstRun exec:java : this runs the first part of the test, and saves the KieSession to a file. - mvn -PsecondRun exec:java : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE. All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1511: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from ASSIGNED to POST > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1511: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] Relevant PR: https://github.com/jbossas/jboss-eap/pull/476 > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- 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

12 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 September 2013