[JBoss JIRA] Created: (JBRULES-2298) Can't use functions when MVEL dialect is set at package level
by Michael Neale (JIRA)
Can't use functions when MVEL dialect is set at package level
-------------------------------------------------------------
Key: JBRULES-2298
URL: https://jira.jboss.org/jira/browse/JBRULES-2298
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.1.FINAL
Reporter: Michael Neale
Assignee: Edson Tirelli
Priority: Critical
package jboss.cloud
dialect "mvel"
#trying to get functions working...
rule "something"
when
s: SimpleFact(id == 42, name == "michael")
then
System.out.println("hello");
end
function String doSomething() {
return "hey";
}
And I get:
java.lang.NullPointerException
at org.drools.rule.builder.dialect.mvel.MVELDialect.compile(MVELDialect.java:510)
at org.drools.rule.builder.dialect.mvel.MVELDialect.addFunction(MVELDialect.java:338)
at org.drools.compiler.PackageBuilder.addFunction(PackageBuilder.java:1104)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:626)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:290)
at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:488)
at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBRULES-2797) HashTableIterator of AbstractHashTable is not Thread Safe
by Anatoly Polinsky (JIRA)
HashTableIterator of AbstractHashTable is not Thread Safe
----------------------------------------------------------
Key: JBRULES-2797
URL: https://jira.jboss.org/browse/JBRULES-2797
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core, drools-core (flow)
Affects Versions: 5.1.1.FINAL, FUTURE
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
public static class HashTableIterator has a shared state that gets inconsistent when multiple threads work on the getting the next entity:
public Object next() {
if ( this.entry != null ) {
PART 1 >> this.entry = this.entry.getNext();
}
// if no entry keep skipping rows until we come to the end, or find one that is populated
while ( this.entry == null && ++this.row < this.length ){
PART II >> this.entry = this.table[this.row];
}
return this.entry;
}
In "PART 1", the race condition causes "this.entry" be NULL in "this.entry.getNext()", and throws the exception below.
In "PART 2", the race condition causes inconsistent state of "this.row", and throws multiple exceptions, but mostly the one that is described in: https://jira.jboss.org/browse/JBRULES-2794
java.util.concurrent.ExecutionException: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1ff323
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.custom.workflow.stress.test.WorkflowStressTest.shouldRunFlow(WorkflowStressTest.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:94)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:192)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
Caused by: org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction@1ff323
at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1473)
at org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1631)
at org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:318)
at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:99)
at org.drools.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:38)
at org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:285)
at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.startProcess(CommandBasedStatefulKnowledgeSession.java:193)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:692)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
at org.custom.workflow.stress.test.WorkflowRunner.call(WorkflowRunner.java:38)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
at org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:312)
at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:323)
at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:303)
at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:257)
at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:92)
at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:68)
at org.drools.reteoo.Rete.assertObject(Rete.java:111)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:280)
at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:360)
at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1471)
... 24 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBRULES-2834) TimerAndCalendarTest will fail 4 tests on non english environments
by Burkhard Vogel (JIRA)
TimerAndCalendarTest will fail 4 tests on non english environments
------------------------------------------------------------------
Key: JBRULES-2834
URL: https://issues.jboss.org/browse/JBRULES-2834
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.2.0.M1
Environment: Windows XP 32bit *ESP*, JDK 1.6.0_21
Reporter: Burkhard Vogel
Assignee: Mark Proctor
Priority: Minor
When running the mvn install target on a non English system the following test will fail
- testCalendarsWithIntervalsAndStartAndEnd
- testCalendarsWithIntervalsAndStartAndLimit
- testCalendarsWithCronAndStartAndEnd
- testCalendarsWithCronAndStartAndLimit
All these use dates like 03-JAN-2010 in the internal rule definition with will not work in countries where there does not exist a month starting with JAN, for instance in Spanish that would be ENE (from enero) and the test result spills out a date format exception.
These can be alleviated by running the command with two parameters (-Ddrools.defaultcountry=US -Ddrools.defaultlanguage=en) but still the attached patch has to be applied for four other language specific dates within the test code.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBRULES-3281) Drools Expert User Guide > The Basics, various edits
by Dr Alt (Created) (JIRA)
Drools Expert User Guide > The Basics, various edits
----------------------------------------------------
Key: JBRULES-3281
URL: https://issues.jboss.org/browse/JBRULES-3281
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-docs-expert
Affects Versions: 5.3.0.Final
Reporter: Dr Alt
Assignee: Mark Proctor
Starting at http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-docs/html_...
*Stateless Knowledge Session*
Application pseudo code is missing method names:
(!) The following should read {{application.isValid()}} in both occurrences (assertTrue(..) and assertFalse(..)), instead of {{application()}}
{quote}
StatelessKnowledgeSession ksession = kbase.newStatelessKnowledgeSession();
Applicant applicant = new Applicant( "Mr John Smith", 16 );
Application application = new Application();
assertTrue( application.isValid() );
ksession.execute( Arrays.asList( new Object[] \{ application, applicant } ) );
assertFalse( application.isValid() );
{quote}
*Stateful Knowledge Session*
(!) Example code shows "public -classs- Sprinkler" should be "public +class+ Sprinkler".
(!) The sentence after that, "the concepts of inserting and matching against data -was- introduced" should read "+were+"
(!) The fire alarm sample Java code has errors. "builder.getErrors()" should be "kbuilder.getErrors()" and kbase should be initialized before kbase.addKnowledgePackages as:
{{KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();}}
(!) {{ksession.fireAllRules()}} requires a semi-colon.
(!) After retracting the two fire facts, the output should be:
{quote}
Cancel the alarm
Turn +off+ the sprinkler for room office
Turn +off+ the sprinkler for room kitchen
Everything is ok
{quote}
(Eventually, I'll learn how to make these changes myself and request git pulls.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (JBRULES-3366) When adding resources using both MVEL and Java dialects the JavaDialect constructor fails when dialectData is found and stored.
by Alan Zall (JIRA)
Alan Zall created JBRULES-3366:
----------------------------------
Summary: When adding resources using both MVEL and Java dialects the JavaDialect constructor fails when dialectData is found and stored.
Key: JBRULES-3366
URL: https://issues.jboss.org/browse/JBRULES-3366
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.3.1.Final
Environment: Linux
Reporter: Alan Zall
Assignee: Mark Proctor
In the constructor of JavaDialect, if pkg.getDialectRuntimeRegistry().getDialectData( ID ) returns a non null value, then a null is passed into the PackageStore constructor.
if ( pkg.getDialectRuntimeRegistry().getDialectData( ID ) == null ) {
data = new JavaDialectRuntimeData();
this.pkg.getDialectRuntimeRegistry().setDialectData( ID,
data );
data.onAdd( this.pkg.getDialectRuntimeRegistry(),
this.packageBuilder.getRootClassLoader() );
}
this.packageStoreWrapper = new PackageStore( data,
this.results );
is fixed by:
if (( data = (JavaDialectRuntimeData) pkg.getDialectRuntimeRegistry().getDialectData( ID )) == null ) {
data = new JavaDialectRuntimeData();
this.pkg.getDialectRuntimeRegistry().setDialectData( ID,
data );
data.onAdd( this.pkg.getDialectRuntimeRegistry(),
this.packageBuilder.getRootClassLoader() );
}
this.packageStoreWrapper = new PackageStore( data, this.results );
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBRULES-1665) put offending rule name in exception messages
by Alex McCarrier (JIRA)
put offending rule name in exception messages
---------------------------------------------
Key: JBRULES-1665
URL: http://jira.jboss.com/jira/browse/JBRULES-1665
Project: JBoss Drools
Issue Type: Feature Request
Components: Drl Parser/Builder
Affects Versions: FUTURE
Environment: all
Reporter: Alex McCarrier
Assigned To: Mark Proctor
Priority: Minor
It would be nice if drools compiler error messages would include the rule that caused the error. For instance, predicate eval errors, or "unable to resolve property" errors would state which rule was being evaluated when it encountered an error. Currently the developer has to go through the rules file looking for lines similar to the one reported in the error. Also, when it's this much work for a developer to find the offending rule, it is pretty much impossible for business users to figure out which rule they messed up.
If it's at all possible to add the rule name to these error messages, please do so. It would make our lives a lot easier. :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (JBRULES-680) Support real-time problem modification during solving with utils for the single thread subsystem
by Geoffrey De Smet (JIRA)
Support real-time problem modification during solving with utils for the single thread subsystem
------------------------------------------------------------------------------------------------
Key: JBRULES-680
URL: http://jira.jboss.com/jira/browse/JBRULES-680
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Solver
Reporter: Geoffrey De Smet
Assigned To: Geoffrey De Smet
Rete/Drools is single threaded, and so is the current implementation of the localsearchsolver,
but this single thread subsystem should be documented
and utils should be provided to allow for real-time problem modification
A simple way would be to use a producer-consumer pattern with a non blocking queue which holds "problem moves".
Each step the problem moves could be used.
Problems:
- bestsolutionrecalled also needs it's score adjusted. so we'll need a 2th working memory:
-- EITHER temporary, just for the problem move (or set of problem moves)
-- EITHER all the time, but then we'd have to hold a chain of moves, some of which might not be doable at the end
- cached selectors must be notified of refreshing their cache
- solution cloning normally doesn't clone the problem facts, just the proposed solution references. Do we need a full clone now?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months