October 2013 - jboss-jira - Jboss List Archives

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

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-275: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > 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: Mario Fusco > > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1913: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from NEW to ASSIGNED > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1913: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=991469, https://bugzilla.redhat.com/show_bug.cgi?id=1014921 (was: https://bugzilla.redhat.com/show_bug.cgi?id=991469) > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1913: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] Description of problem: A regression has been introduced by the bz991469 fix. It breaks module add command included in a CLI module archive. For details see https://issues.jboss.org/browse/WFLY-1913?focusedCommentId=12808246&page=... Version-Release number of selected component (if applicable): EAP 6.2.0.ER1 How reproducible: Create a CLI module archive which includes 'module add' command involving a resource taken from the module archive. An example of such an archive can be found at WFLY-1913. > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1712) FRAG / FRAG2: CONFIG event overrides user-configured frag_size value

by Bela Ban (JIRA)

Bela Ban created JGRP-1712: ------------------------------ Summary: FRAG / FRAG2: CONFIG event overrides user-configured frag_size value Key: JGRP-1712 URL: https://issues.jboss.org/browse/JGRP-1712 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.4 When we have multiple FRAG or FRAG2 in the same stack (with different IDs), then each fragmentation protocol sends a CONFIG event (with {{frag_size}}) up and down the stack. When this event is received by a different frag protocol, then it will set its own {{frag_size}}, overriding the previously set value. Investigate whether we still need the CONFIG event. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2136) persistence.xml with org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM 4.3.x

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-2136?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-2136. ------------------------------ > persistence.xml with org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM 4.3.x > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2136 > URL: https://issues.jboss.org/browse/WFLY-2136 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 8.0.0.Alpha1 > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 8.0.0.CR1 > > > currently users migrating from earlier app server versions will get http://pastebin.com/4tRk75vh -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-279) Implement automatic retraction policies other than temporal expiration

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-279: ------------------------------------- Summary: Implement automatic retraction policies other than temporal expiration Key: DROOLS-279 URL: https://issues.jboss.org/browse/DROOLS-279 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR4, 5.5.1.Final Reporter: Davide Sottara Assignee: Mark Proctor Priority: Minor Retract events automatically when the only potentially matching patterns are connected to sliding length windows -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear but doesn't deploy contained ejb module

by Matías Blasi (JIRA)

Matías Blasi created JBASMP-52: ---------------------------------- Summary: jboss-as:deploy deploys ear but doesn't deploy contained ejb module Key: JBASMP-52 URL: https://issues.jboss.org/browse/JBASMP-52 Project: JBoss AS Maven Plugins Issue Type: Bug Components: deploy Affects Versions: 7.4.Final Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux Reporter: Matías Blasi Assignee: James Perkins I have a simple ear application (build with maven-ear-plugin). This application contains just a persistence-unit definition (persistence.xml) and a ejb-module. The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin. The ear file is correctly built: myapp.ear | + META-INF/application.xml + lib/allmylibs.jar + myejb.jar When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command. Finally, an ear file is present under $JBOSS_HOME/standalone/data/content The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed) Nothing found in google! :( I tried with all the plugin version from 7.1.1 to 7.4. Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work. Regards, Matías. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBAS-9548) JBoss 5.0 log file is stopped getting updated after a while

by Ramesh Kodali (JIRA)

Ramesh Kodali created JBAS-9548: ----------------------------------- Summary: JBoss 5.0 log file is stopped getting updated after a while Key: JBAS-9548 URL: https://issues.jboss.org/browse/JBAS-9548 Project: Application Server 3 4 5 and 6 Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-5.0.1.GA Environment: Java 2.6, JBoss 5.1 Reporter: Ramesh Kodali Assignee: Alessio Soldano We are using log back xml to configure application specific log file and copied the log back XML in JBoss class path. After server restarts, JBoss is generating the log files successfully. It was working from some time even in production. Recently we have noticed a weird issue in our dev environment that, application logs are writing in to log file and stopped writing after a while. We have to restart the JBoss to get back the Log files status. This issue seems coming continuously now a days. I would like to know is it some thing related to JBoss or more of environment issue. Here below the log back configuration we had <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${jboss.server.log.dir}/cbs2.log</File> <Append>true</Append> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${jboss.server.log.dir}/cbs2.%d{yyyy-MM-dd}.%i.log.gz </FileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>200MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{yyyy-MM-dd;HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%M:%L] [%X{id}->%X{bcId}:%X{userId}:%X{loginId}] - %msg%n</Pattern> </layout> </appender> -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2208) CLI over HTTP should switch to / be redirected to https automatically.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-2208: -------------------------------------- Summary: CLI over HTTP should switch to / be redirected to https automatically. Key: WFLY-2208 URL: https://issues.jboss.org/browse/WFLY-2208 Project: WildFly Issue Type: Enhancement Components: CLI, Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.0.0.Beta1 When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm. With the switch to http with an upgrade there is no automatic switch to https. -- 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, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013