[JBoss JIRA] Created: (JBRULES-2774) CCE when using undeclared events
by Wolfgang Laun (JIRA)
CCE when using undeclared events
---------------------------------
Key: JBRULES-2774
URL: https://jira.jboss.org/browse/JBRULES-2774
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: 5.2.0.M1
It may not be possible to avoid a runtime error because the parser does not "understand" temporal operators although it should not be impossible to add this. But is should be possible to produce an error message that clearly indicates the problem, e.g., "Cannot use operator xxx on fact type YYY which is not an event" or "YYY must be declared with @role(event) when using temporal operators".
Omitting the declares for events, as in this DRL:
/**
declare CallStart
@role( event )
@timestamp( time )
end
declare CallEnd
@role( event )
@timestamp( time )
end
**/
rule "match-start-end"
when
$start: CallStart( $s: source, $d: destination, $st: time )
not CallStart( this before $start )
$end: CallEnd( source == $s, destination == $d, $et: time )
not CallEnd( source == $s, destination == $d, this before $end )
then
//...
end
results in a runtime exception:
Exception in thread "main" java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot be cast to org.drools.common.EventFactHandle
at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedRight(BeforeEvaluatorDefinition.java:316)
at org.drools.rule.VariableRestriction.isAllowedCachedRight(VariableRestriction.java:117)
at org.drools.rule.VariableConstraint.isAllowedCachedRight(VariableConstraint.java:121)
at org.drools.common.SingleBetaConstraints.isAllowedCachedRight(SingleBetaConstraints.java:151)
at org.drools.reteoo.NotNode.assertObject(NotNode.java:140)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:378)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1174)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1123)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
at call.Main.execute(Main.java:90)
at call.Main.main(Main.java:100)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2773) Rule delayed although temporal operator within not() refers to past events
by Wolfgang Laun (JIRA)
Rule delayed although temporal operator within not() refers to past events
--------------------------------------------------------------------------
Key: JBRULES-2773
URL: https://jira.jboss.org/browse/JBRULES-2773
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: 5.2.0.M1
The .drl:
declare Leave
@role( event )
@timestamp( timestamp )
end
rule "XXX Leave not !="
when
$leave: Leave()
not Leave( this != $leave )
then
System.out.println( "XXX only one Leave - not !=" );
end
rule "YYY Leave not after"
when
$leave: Leave()
not Leave( this before $leave )
then
System.out.println( "YYY only one Leave - not before" );
end
A) The pseudo-clock is advanced according to the timestamp; then
exactly one event Leave is inserted; then fireAllRules() is called.
1) Running in CLOUD mode, both rules fire.
2) But running in STREAM mode, ONLY rule XXX fires.
B) Like A, but the session clock is advanced by (at least) 1ms
prior to calling fireAllRules().
3) Either mode, both rules fire.
I think that A2) is incorrect; why should passing another msec change the logic? Rule YYY matches by looking into the past, so the "rule activation delay" described in 2.5.2.2. Negative Patterns in Stream Mode should not apply because the default parameter for before is [1ms,...].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2769) Create a "transaction"-like context for WMA to prevent inconsistent intermediate-states
by Edson Tirelli (JIRA)
Create a "transaction"-like context for WMA to prevent inconsistent intermediate-states
---------------------------------------------------------------------------------------
Key: JBRULES-2769
URL: https://jira.jboss.org/browse/JBRULES-2769
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Fix For: 5.2.0.M1
Create a "transaction"-like context for all WMA to prevent inconsistent states during propagation. The idea is to delay agenda changes (rule activations, cancellations and re-activations) until the whole propagation is finished. This is to avoid inconsistent states when the same fact is propagated through multiple RETE branches.
Examples of cases that require this include:
* forall re-activating on fact retractions
* fireUntilHalt immediately firing rules that are activated and canceled during the same WMA
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2735) ClassCastException for casting DefaultFactHandle to EventFactHandle when using Sliding Windows
by Will Lauer (JIRA)
ClassCastException for casting DefaultFactHandle to EventFactHandle when using Sliding Windows
----------------------------------------------------------------------------------------------
Key: JBRULES-2735
URL: https://jira.jboss.org/browse/JBRULES-2735
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.1.1.FINAL
Environment: Windows XP SP3, Java 1.6.0_21, Drools 5.1.1
Reporter: Will Lauer
Assignee: Mark Proctor
When playing with a simple sliding window test using a single type of fact with @role(event), the following ClassCastException is generated:
Exception in thread "main" java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot be cast to org.drools.common.EventFactHandle
at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedLeft(BeforeEvaluatorDefinition.java:333)
at org.drools.rule.VariableRestriction.isAllowedCachedLeft(VariableRestriction.java:110)
at org.drools.rule.VariableConstraint.isAllowedCachedLeft(VariableConstraint.java:115)
at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:142)
at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:274)
at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:138)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:189)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:64)
at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:662)
at org.drools.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:181)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:189)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:138)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:148)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:368)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1174)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1123)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
at net.wlauer.DroolsEngine.NonSpringRulesEngine.main(NonSpringRulesEngine.java:71)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2751) NullPointerException in DeclarationTypeFixer: An rule compilation error should give a clear errow warning with an indecation of which rule is the culprit instead of a NPE
by Geoffrey De Smet (JIRA)
NullPointerException in DeclarationTypeFixer: An rule compilation error should give a clear errow warning with an indecation of which rule is the culprit instead of a NPE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2751
URL: https://jira.jboss.org/browse/JBRULES-2751
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Fix For: 5.2.0.M1
{code}
Exception in thread "main" java.lang.NullPointerException
at org.drools.rule.builder.dialect.java.DeclarationTypeFixer.fix(DeclarationTypeFixer.java:17)
at org.drools.rule.builder.dialect.java.AbstractJavaRuleBuilder.createVariableContext(AbstractJavaRuleBuilder.java:90)
at org.drools.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:112)
at org.drools.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:54)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:223)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:108)
at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:79)
at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1149)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:631)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:270)
at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildRuleBase(LocalSearchSolverConfig.java:209)
at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:186)
at org.drools.planner.config.XmlSolverConfigurer.buildSolver(XmlSolverConfigurer.java:93)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.createSolver(CloudBalancingApp.java:43)
at org.drools.planner.examples.common.app.CommonApp.createSolutionBusiness(CommonApp.java:59)
at org.drools.planner.examples.common.app.CommonApp.<init>(CommonApp.java:38)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.<init>(CloudBalancingApp.java:30)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.main(CloudBalancingApp.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
{code}
Here's the rule which causes this:
{code}
rule "minimalCpuPowerTotal"
when
$cloudComputer : CloudComputer($cpuPower : cpuPower)
$minimalCpuPowerTotal : Number(intValue > $cpuPower) from accumulate(
CloudAssignment(
cloudComputer == $cloudComputer,
$minimalCpuPower : minimalCpuPower), // This is the problem, CloudAssignment.getMinimalCpuPower does not exist yet
sum($minimalCpuPower)
)
then
insertLogical(new IntConstraintOccurrence("minimalCpuPowerTotal", ConstraintType.NEGATIVE_HARD,
$minimalCpuPowerTotal - $cpuPower,
$cloudComputer));
end
{code}
CloudAssignment did not have a getter for minimalCpuPower yet.
The compilation error should clearly say that its the rule minimalCpuPowerTotal which has a problem and that the getter for the field minimalCpuPower wasn't found.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2696) KnowledgeBaseDefinitionParser Should Always Create KnowledgeBaseOptionsConfiguration
by Anatoly Polinsky (JIRA)
KnowledgeBaseDefinitionParser Should Always Create KnowledgeBaseOptionsConfiguration
------------------------------------------------------------------------------------
Key: JBRULES-2696
URL: https://jira.jboss.org/browse/JBRULES-2696
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: All
Affects Versions: 5.1.1.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
KnowledgeBaseOptionsConfiguration:
* <p>
* This class will automatically load default values from a number of places, accumulating properties from each location.
* This list of locations, in given priority is:
* System properties, home directory, working directory, META-INF/ of optionally provided classLoader
* META-INF/ of Thread.currentThread().getContextClassLoader() and META-INF/ of ClassLoader.getSystemClassLoader()
* </p>
Since this properties are only read when "RuleBaseConfiguration" ( KnowledgeBaseOptionsConfiguration implementor ) is constructed, this does not apply/work in case KnowledgeBase is defined via Spring without a <drools:configuration> due to the current sequence of events in "KnowledgeBaseDefinitionParser":
Element kbaseConf = DomUtils.getChildElementByTagName(element, "configuration");
if ( kbaseConf != null ) {
BeanDefinitionBuilder rbaseConfBuilder = BeanDefinitionBuilder.rootBeanDefinition( RuleBaseConfiguration.class );
// ... ... ...
factory.addPropertyValue( "conf", rbaseConfBuilder.getBeanDefinition() );
}
To fix it, RuleBaseConfiguration ( which implements KnowledgeBaseOptionsConfiguration ) should be created even though "<drools:configuration>" was not provided ( kbaseConf == null ):
Element kbaseConf = DomUtils.getChildElementByTagName(element, "configuration");
BeanDefinitionBuilder rbaseConfBuilder = BeanDefinitionBuilder.rootBeanDefinition( RuleBaseConfiguration.class );
if ( kbaseConf != null ) {
// ... ... ...
}
factory.addPropertyValue( "conf", rbaseConfBuilder.getBeanDefinition() );
Thank you,
/Anatoly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2695) Spring "Drools Resources" Need to be Modular
by Anatoly Polinsky (JIRA)
Spring "Drools Resources" Need to be Modular
--------------------------------------------
Key: JBRULES-2695
URL: https://jira.jboss.org/browse/JBRULES-2695
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: All
Affects Versions: 5.1.1.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
When development is done by multiple teams, there should be a way to reference the resources in a modular way.
Here is how it is / can be done now ( which is BAD / not modular ):
<drools:kbase id="kbase">
<drools:resources>
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_1.drf"/>
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_2.drf"/>
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team2_1.drf"/>
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team2_2.drf"/>
<drools:resource ref="team3_1"/>
<drools:resource ref="team3_2"/>
</drools:resources>
</drools:kbase>
Since clients need to be aware of _every_ little artifact of individual team, and have to reimport all artifacts into a knowledge base one by one.
Here is a better way to do it:
<drools:kbase id="kbase">
<drools:resources ref="team1-resources"/>
<drools:resources ref="team2-resources"/>
<drools:resources ref="team3-resources"/>
</drools:kbase>
where individual team's config may look as:
(e.g. team 1):
<drools:resources id="team1-resources">
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_1.drf"/>
<drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_2.drf"/>
</drools:resources/>
------------------------------------------------------------------------------
Long story short:
"drools:resources" needs:
1. ID, to be able to ref to it
2. REF, to be able to ref to an ID
"drools:kbase" needs:
1. To optionally take a list of "drools:resources"
Thank you,
/Anatoly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2816) Many dependencies are tagged scope provided, while the should probably be default scope with optional=true
by Geoffrey De Smet (JIRA)
Many dependencies are tagged scope provided, while the should probably be default scope with optional=true
----------------------------------------------------------------------------------------------------------
Key: JBRULES-2816
URL: https://jira.jboss.org/browse/JBRULES-2816
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Components: All
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Fix For: 5.2.0.M1
86 uses of scope provided. 13 usages of optional true.
Normally scope provided is used for JDK, JAva webstart and when deploying to a servlet container, the servlet API...
Targets
String '<scope>provided</scope>'
Found usages (86 usages)
drools (4 usages)
/home/gdesmet/projects/jboss/drools (4 usages)
pom.xml (4 usages)
(968, 9) <scope>provided</scope>
(975, 9) <scope>provided</scope>
(1576, 9) <scope>provided</scope>
(1582, 9) <scope>provided</scope>
drools-api (12 usages)
/home/gdesmet/projects/jboss/drools/drools-api (12 usages)
pom.xml (12 usages)
(18, 7) <scope>provided</scope>
(23, 7) <scope>provided</scope>
(28, 7) <scope>provided</scope>
(33, 7) <scope>provided</scope>
(38, 7) <scope>provided</scope>
(43, 7) <scope>provided</scope>
(48, 7) <scope>provided</scope>
(53, 7) <scope>provided</scope>
(58, 7) <scope>provided</scope>
(63, 7) <scope>provided</scope>
(68, 7) <scope>provided</scope>
(73, 7) <scope>provided</scope>
drools-bpmn2 (2 usages)
/home/gdesmet/projects/jboss/drools/drools-process/drools-bpmn2 (2 usages)
pom.xml (2 usages)
(119, 7) <scope>provided</scope>
(124, 7) <scope>provided</scope>
drools-camel (1 usage)
/home/gdesmet/projects/jboss/drools/drools-camel (1 usage)
pom.xml (1 usage)
(186, 7) <scope>provided</scope>
drools-compiler (7 usages)
/home/gdesmet/projects/jboss/drools/drools-compiler (7 usages)
pom.xml (7 usages)
(23, 7) <scope>provided</scope>
(28, 7) <scope>provided</scope>
(82, 7) <scope>provided</scope>
(87, 7) <scope>provided</scope>
(92, 7) <scope>provided</scope>
(97, 7) <scope>provided</scope>
(102, 7) <scope>provided</scope>
drools-core (7 usages)
/home/gdesmet/projects/jboss/drools/drools-core (7 usages)
pom.xml (7 usages)
(18, 7) <scope>provided</scope>
(23, 7) <scope>provided</scope>
(56, 7) <scope>provided</scope>
(61, 7) <scope>provided</scope>
(66, 7) <scope>provided</scope>
(71, 7) <scope>provided</scope>
(76, 7) <scope>provided</scope>
drools-decisiontables (2 usages)
/home/gdesmet/projects/jboss/drools/drools-decisiontables (2 usages)
pom.xml (2 usages)
(32, 7) <scope>provided</scope>
(37, 7) <scope>provided</scope>
drools-flow-compiler (7 usages)
/home/gdesmet/projects/jboss/drools/drools-flow-compiler (7 usages)
pom.xml (7 usages)
(17, 7) <scope>provided</scope>
(22, 7) <scope>provided</scope>
(42, 7) <scope>provided</scope>
(47, 7) <scope>provided</scope>
(52, 7) <scope>provided</scope>
(57, 7) <scope>provided</scope>
(62, 7) <scope>provided</scope>
drools-flow-core (7 usages)
/home/gdesmet/projects/jboss/drools/drools-flow-core (7 usages)
pom.xml (7 usages)
(17, 7) <scope>provided</scope>
(22, 7) <scope>provided</scope>
(37, 7) <scope>provided</scope>
(42, 7) <scope>provided</scope>
(47, 7) <scope>provided</scope>
(52, 7) <scope>provided</scope>
(57, 7) <scope>provided</scope>
drools-flow-persistence-jpa (4 usages)
/home/gdesmet/projects/jboss/drools/drools-flow-persistence-jpa (4 usages)
pom.xml (4 usages)
(98, 7) <scope>provided</scope>
(103, 7) <scope>provided</scope>
(109, 7) <scope>provided</scope>
(114, 7) <scope>provided</scope>
drools-grid (12 usages)
/home/gdesmet/projects/jboss/drools/drools-grid (3 usages)
pom.xml (3 usages)
(24, 13) <scope>provided</scope>
(29, 13) <scope>provided</scope>
(34, 13) <scope>provided</scope>
/home/gdesmet/projects/jboss/drools/drools-grid/drools-grid-distributed-api (3 usages)
pom.xml (3 usages)
(36, 10) <scope>provided</scope>
(41, 10) <scope>provided</scope>
(46, 10) <scope>provided</scope>
/home/gdesmet/projects/jboss/drools/drools-grid/drools-grid-local (3 usages)
pom.xml (3 usages)
(33, 7) <scope>provided</scope>
(38, 7) <scope>provided</scope>
(43, 7) <scope>provided</scope>
/home/gdesmet/projects/jboss/drools/drools-grid/drools-grid-remote-api (3 usages)
pom.xml (3 usages)
(38, 7) <scope>provided</scope>
(43, 7) <scope>provided</scope>
(48, 7) <scope>provided</scope>
drools-guvnor (5 usages)
/home/gdesmet/projects/jboss/drools/drools-guvnor (5 usages)
pom.xml (5 usages)
(205, 7) <scope>provided</scope>
(222, 7) <scope>provided</scope>
(265, 7) <scope>provided</scope>
(270, 7) <scope>provided</scope>
(296, 7) <scope>provided</scope>
drools-ide-common (1 usage)
/home/gdesmet/projects/jboss/drools/drools-ide-common (1 usage)
pom.xml (1 usage)
(37, 7) <scope>provided</scope>
drools-jsr94 (1 usage)
/home/gdesmet/projects/jboss/drools/drools-jsr94 (1 usage)
pom.xml (1 usage)
(73, 7) <scope>provided</scope>
drools-persistence-jpa (4 usages)
/home/gdesmet/projects/jboss/drools/drools-persistence-jpa (4 usages)
pom.xml (4 usages)
(83, 7) <scope>provided</scope>
(88, 7) <scope>provided</scope>
(94, 7) <scope>provided</scope>
(99, 7) <scope>provided</scope>
drools-spring (2 usages)
/home/gdesmet/projects/jboss/drools/drools-container/drools-spring (2 usages)
pom.xml (2 usages)
(53, 7) <scope>provided</scope>
(59, 7) <scope>provided</scope>
gwt-console-server-drools (8 usages)
/home/gdesmet/projects/jboss/drools/drools-process/drools-gwt-server-war (8 usages)
pom.xml (8 usages)
(46, 7) <scope>provided</scope>
(52, 7) <scope>provided</scope>
(58, 7) <scope>provided</scope>
(64, 7) <scope>provided</scope>
(70, 7) <scope>provided</scope>
(76, 7) <scope>provided</scope>
(82, 7) <scope>provided</scope>
(88, 7) <scope>provided</scope>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2814) DSL variable definition may create strange effects
by Wolfgang Laun (JIRA)
DSL variable definition may create strange effects
--------------------------------------------------
Key: JBRULES-2814
URL: https://jira.jboss.org/browse/JBRULES-2814
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler-DSL
Affects Versions: 5.1.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: 5.2.0.M1
The DSL parser accepts variable definitions
{name}
{name:pattern}
{name:q:pattern}
but also
{name:xyz:}
a) What *is* the purpose of "q"? It is tested in DSLMapWalker and influences what is used as a pattern, sometimes overriding a specified pattern: q pattern use-for-matching null null (.*?) null pattern pattern X null (.*?) X pattern pattern ENUM -- (.*?) DATE -- (.*?) BOOLEAN -- (.*?)
b) A "null" pattern is used for matching if {name:xyz:} is used.
I think the "q" is a relic and should be discarded. A ':' as delimiter in an area where any character is possible (as in a pattern) is bound to create ambiguities.
The "C" entry in the DSL below produces "null" in the pattern trying to match a condition; i.e., the string "null" is actually matched.
A, E, F result in pattern "(.*?)"
B, D use the pattern ("Boolean" or "Double", respectively)
DSL:
[when][]A {type} value=${type}: {type}()
[when][]B {type:Boolean} value=${type}: {type}()
[when][]C {type:xyz:} value=${type}: {type}()
[when][]D {type:xyz:Double} value=${type}: {type}()
[when][]E {type:ENUM:} value=${type}: {type}()
[when][]F {type:DATE:Float} value=${type}: {type}()
DSLR:
rule "rule 1"
when
A Integer value
B Boolean value
C Character value # fails; use "null" instead of Character to get a match
D Double value
E Enum value
F Float value
then
> System.out.println( "hello" );
end
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-2792) Provide accessability of types and metadata for declare-d types
by Wolfgang Laun (JIRA)
Provide accessability of types and metadata for declare-d types
---------------------------------------------------------------
Key: JBRULES-2792
URL: https://jira.jboss.org/browse/JBRULES-2792
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-api
Affects Versions: 5.1.1.FINAL
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: FUTURE
* All types created or enhanced by a DRL declare construct must be retrievable from the KnowledgeBase using
Declare getDeclare( String pkg, String name )
* A Declare object must provide getters String getPackageName(), getName(), Map<String,Object> getMetaData() (same as Rule)
* A Declare object must provide Class<?> getFactClass() returning the created or enhanced java-lang.Class.
* A Declare object must provide long getInferredExpires() returning (for @role(event)) the inferred expiration offset or -1 if none.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months