[JBoss JIRA] (DROOLS-1071) NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
by Ido Flax (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1071?page=com.atlassian.jira.plugi... ]
Ido Flax commented on DROOLS-1071:
----------------------------------
I found the cause for this on my end, there were some null properties in the entities optaplanner was operating on.
> NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1071
> URL: https://issues.jboss.org/browse/DROOLS-1071
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Beta2
> Environment: JDK: Java 7
> OS: Mac OSX 10.10.2
> IDE: Spring Tool Suite 3.6.4
> Reporter: Ido Flax
> Assignee: Mario Fusco
> Attachments: AbstractPlannerDto.java, activity-scoring.drl, EquipmentEquipmentTypesPlannerDto.java, LabourDayOffPlannerDto.java, OnHandForProduct.java, ProductInventoryTransactionPlannerDto.java, ProductPlannerDto.java, SkillsAndRatesPlannerDto.java, TaskPlannerDto.java, TaskResourceAllocationPlannerDto.java, TaskResourcePlannerDto.java, UserPlannerDto.java
>
>
> The attached code generates an NPE when running optaplanner/drools, but that stacktrace doesn't tell me which DRL line is responsible for it.
> Stacktrace:
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at ConditionEvaluatoreaa3997683d949e28ce6eaf6feca0ced.evaluate(Unknown Source) <================ No source DRL line
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:226)
> at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:111)
> at org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:112)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:75)
> 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.evalNode(RuleNetworkEvaluator.java:369)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:329)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:120)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:84)
> at org.optaplanner.core.impl.solver.recaller.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:70)
> at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:197)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:175)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6296) Method duplication in undertow tests
by Shishir Subramanyam (JIRA)
Shishir Subramanyam created WFLY-6296:
-----------------------------------------
Summary: Method duplication in undertow tests
Key: WFLY-6296
URL: https://issues.jboss.org/browse/WFLY-6296
Project: WildFly
Issue Type: Enhancement
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Shishir Subramanyam
Assignee: Stuart Douglas
Priority: Trivial
All the undertow subsystems classes: UndertowSubsystemTestCase (6 files) contain the same definition of the method testRuntime. This method contains some hard coded settings (65 lines)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6295) Wrong header comments on integration-tests.sh script
by Eduardo Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6295?page=com.atlassian.jira.plugin.... ]
Eduardo Silva updated WFLY-6295:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8739
> Wrong header comments on integration-tests.sh script
> ----------------------------------------------------
>
> Key: WFLY-6295
> URL: https://issues.jboss.org/browse/WFLY-6295
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Reporter: Eduardo Silva
> Assignee: Jason Greene
> Priority: Minor
>
> Wrong header comments on integration-tests.sh script, the header of integration-tests.sh script was copied of the build.sh script.
> ### ====================================================================== ###
> ## ##
> ## This is the main entry point for the build system. ##
> ## ##
> ## Users should execute this file rather than 'mvn' to ensure ##
> ## the correct version is being used with the correct configuration. ##
> ## ##
> ### ====================================================================== ###
> # $Id: build.sh 105735 2010-06-04 19:45:13Z pgier $
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6295) Wrong header comments on integration-tests.sh script
by Eduardo Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6295?page=com.atlassian.jira.plugin.... ]
Eduardo Silva updated WFLY-6295:
--------------------------------
Component/s: Documentation
Description:
Wrong header comments on integration-tests.sh script, the header of integration-tests.sh script was copied of the build.sh script.
### ====================================================================== ###
## ##
## This is the main entry point for the build system. ##
## ##
## Users should execute this file rather than 'mvn' to ensure ##
## the correct version is being used with the correct configuration. ##
## ##
### ====================================================================== ###
# $Id: build.sh 105735 2010-06-04 19:45:13Z pgier $
Priority: Minor (was: Major)
> Wrong header comments on integration-tests.sh script
> ----------------------------------------------------
>
> Key: WFLY-6295
> URL: https://issues.jboss.org/browse/WFLY-6295
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Reporter: Eduardo Silva
> Assignee: Jason Greene
> Priority: Minor
>
> Wrong header comments on integration-tests.sh script, the header of integration-tests.sh script was copied of the build.sh script.
> ### ====================================================================== ###
> ## ##
> ## This is the main entry point for the build system. ##
> ## ##
> ## Users should execute this file rather than 'mvn' to ensure ##
> ## the correct version is being used with the correct configuration. ##
> ## ##
> ### ====================================================================== ###
> # $Id: build.sh 105735 2010-06-04 19:45:13Z pgier $
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (DROOLS-1072) Generate warning or error when Ruletemplate files specified in kmodule.xml does not exist
by Alex Vincent (JIRA)
Alex Vincent created DROOLS-1072:
------------------------------------
Summary: Generate warning or error when Ruletemplate files specified in kmodule.xml does not exist
Key: DROOLS-1072
URL: https://issues.jboss.org/browse/DROOLS-1072
Project: Drools
Issue Type: Enhancement
Components: decision tables
Affects Versions: 6.4.0.Beta2
Reporter: Alex Vincent
Assignee: Mario Fusco
When you specify a ruletemplate for a given kbase in the kmodule.xml, it does not generate a warning or an error if the template or dtable does not exist.
For instance the following kmodule.xml:
<?xml version="1.0" encoding="UTF-8"?>
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
<kbase name="KBase1" packages="process, rules, decisiontables, ruletemplates">
<ruleTemplate dtable="decisiontables/dt_duplicate_facts.xls"
template="ruletemplates/tpl_duplicate_facts.drt"
row="2" col="2"/>
<ruleTemplate dtable="doesnotexist/dt_duplicate_facts.xls"
template="doesnotexist/tpl_duplicate_facts.drt"
row="2" col="2"/>
<ksession name="KSession1"/>
</kbase>
</kmodule>
This does not generate an error or warning even with trace log level. The user should be notified that these files don't exist (doesnotexist/dt_duplicate_facts.xls and doesnotexist/tpl_duplicate_facts.drt).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6192) JAXBUsageTestCase fails with security manager
by Eduardo Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6192?page=com.atlassian.jira.plugin.... ]
Eduardo Silva commented on WFLY-6192:
-------------------------------------
With the latest WFLY version I was not able to test since the
org.wildfly:wildfly-testsuite-shared:jar:10.1.0.Final-SNAPSHOT is not on the nexus repository:
http://repository.jboss.org/nexus/content/groups/public/org/wildfly/wildf...
The latest version over there is 10.0.0.Alpha1
> JAXBUsageTestCase fails with security manager
> ---------------------------------------------
>
> Key: WFLY-6192
> URL: https://issues.jboss.org/browse/WFLY-6192
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
>
> *org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.jaxb.unit.JAXBUsageTestCase#testJAXBServlet}}
> Fails with:
> {code}
> ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /jaxb-webapp//jaxbServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/jaxb-webapp.war/WEB-INF/classes <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Thread.getContextClassLoader(Thread.java:500)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
> at org.jboss.as.test.integration.jaxb.JAXBUsageServlet.doGet(JAXBUsageServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> at java.security.AccessController.doPrivileged(AccessController.java:650)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan commented on WFCORE-433:
---------------------------------------
[~harald.pehl] ah that sounds great. Yeah the management console + the back end could be the same pod, which might help any CORS issues.
We probably also need to check the security stuff too; so that an authenticated user in the OpenShift console can start using the WF management console if they have the right karma and we get SSO but proper ACLs and stuff. I remember folks had to tinker a little with hawtio / jolokia for the "Java console" part in the OpenShift console when you look inside the JMX view of a JVM with jolokia port exposed to view JMX / Camel routes et al - we had to get the back end to generate a new token with OpenShift to ensure things were properly secure etc.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by James Strachan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
James Strachan commented on WFCORE-433:
---------------------------------------
[~brian.stansberry] agreed with all that!
I think having a standard kubernetes based rolling upgrade approach has lots of value as a single canonical way to do any kind of rolling upgrade; whether its a configuration change, a patch to the operating system, JDK or wildfly container itself or a users new deployment being rolled out etc. Then operations folks in testing / production have one way to do rolling updates of all software etc. We can then all reuse really nice rolling upgrade visualisations etc
However in development; all the things wildfly has done over the years to do incremental updates (e.g. redeploying WARs on the fly, reloading classes, reconfiguring on the fly) is really useful as developers build and test their code. i.e. developers want the fastest possible feedback of changes when they are writing code - in the "pre commit" flow; though once a commit is done (or a config value has changed), in testing & production its kinda better to use immutable images that startup - as it just avoids all kinds of complex bugs due to restarting things & possibly having concurrent / reload edge cases that introduces bugs or resource leakage or whatever. i.e. its less risky and more 'ops-ish" to just startup clean containers in production. Its more "developer-ish" to mutate running containers. Both have value at different stages in the overall software production line.
In the Karaf world, we've now a build system that generates an immutable application server image; so that all the image can do is startup what its statically configured to startup - you can't even try to deploy a new version or change a configuration value at runtime. That kind of behaviour could be useful for testing/production environments - while leaving development containers more open to incremental change so that developers don't have to keep waiting for containers to restart to test out their changes etc
A few other thoughts on your main numbered points:
1) - you could do the git stuff either inside wildfly directly; or you can let kubernetes do the git for you with the gitRepo volume; so that the wiidlfy container then just loads config files from disk as usual. ConfigMap can work the same way too; you can mount the files from ConfigMap to the canonical place on disk where the wildfly docker image expects to load them. That way you've 1 wildfly image and you can use the kubernetes pod template manifest to configure whether its using git or configmap. The docker image is then unaware of the differences. i.e. its all just enabled by the kubernetes manifest (a blob of JSON / YAML you generate as part of you build etc)
2) yes, the Admin Console needs a REST/DMR back end that it posts changes of the configuration to. That service ideally would not be the same container as the cluster of wildfly pods you're configuring. There could be a git based back end that does a git commit/push per change, or a ConfigMap back end that does the change. (Or the WildFly Admin console could directly post to kubernetes ConfigMap; but that might be too big a change for the Admin Console? So it might be simpler to just reuse whatever REST / remote API the AdminConsole uses right now to save changes; and have 2 implementations of the back end; one for git, one for ConfigMap? Using a separate WF container image for this sounds totally fine to me. It can be anything really - whatever you folks think is best!
3) I think there needs to be a WildFly specific management console to let folks configure things in an environment (via git / ConfigMap). Running WF on Atomic/OpenShift should generally try to look and feel like using a traditional DC - i.e. folks should have at least the same capabilities and power.
I figured once the WF Admin Console could work nicely with WF inside kubernetes; we'd then just wire the UI into the OpenShift console somehow so it feels like its one piece of glass; but using links and so forth to join the 2 things. We need to do similar things with the iPaaS where we have iPaaS specific screens linked into the OpenShift console. They are actually separate web applications developed by different teams on different release schedules; we just need to style them and link them so they feel like parts of one universal console. e.g. we ship a jolokia / hawtio UI we link to on a per pod basis in OpenShift right now which is really a totally separate UI - we just link them.
However I'd expect the WF team to own their admin console that changes the WF configuration & provides any other WF specific visualisation, metrics, reporting or whatever. I don't know the various console options in WF well enough to make a call on whether a new console should be written or if we can reuse/refactor the current Admin Console. Be that as it may I think folks will want to have a nice WF specific console when using Atomic/OpenShift as the runtime environment - and if the admin console can work with git / ConfigMap back ends; then thats a pretty compelling user experience IMHO.
4) Totally agreed. Both the iPaaS and BRMS folks have very similar requirements; particularly when things change in git that there's a rolling upgrade process kick in (using a slightly different Replication Controller manifest to use the latest git commit revision) etc. So I'd hope thats all generic functionality that the WF team don't have to do really.
In terms of the DC comparison; you could just say using Kubernetes along with gitRepo volumes (and the revision in the ReplicationController's manifest) or ConfigMap is a kind of DC implementation. You could still use the DC, conceptually and maybe some code too, if you want to do the "rolling upgrade and fall back if there is a failure" type logic. So I don't think you need to throw away the DC idea; just we could do with an implementation that uses immutable containers and volumes (git or ConfigMap) rather than swizzling runtime containers. So I see this as more of an implementation detail of how DC should work for testing/production environments really. But its your call really on if, pretending this new immutable containers + git/configmap approach is a DC is too strange for WF users ;)
Though I guess rather like point 4) you raised; the DC concept (when git / config map changes, do a rolling upgrade and if things go bad, rollback, maybe revert the change and raise some user event to warn the user the change was bad) - is maybe a generic thing; as its not really got much in there thats WF centric. e.g. that kind of logic could be reused by the iPaaS and BRMS too
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (DROOLS-1068) java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1068?page=com.atlassian.jira.plugi... ]
Bill Tuminaro updated DROOLS-1068:
----------------------------------
Attachment: UnsupportedOperationTest.java
Person.java
UnsupportedOperationTest.drl
Mario,
I created a much simpler version of the reproducer for this issue that uses the existing drools package structure and extended a class in your model.
I need to sort out getting the CLA signed, so I can put the files in the git repository.
In the mean time, I have attached the files to this comment.
-BillT
> java.lang.UnsupportedOperationException thrown by org.drools.core.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:535)
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1068
> URL: https://issues.jboss.org/browse/DROOLS-1068
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: droolsReproducer.jar, droolsReproducer.jar, Person.java, UnsupportedOperationTest.drl, UnsupportedOperationTest.java
>
>
> We have encountered this issue when we insert a fact matching a certain rule, delete the fact then call fire all rules.
> A reproducer is attached.
> -BillT
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months