Another MVEL hiccup
by Wolfgang Laun
This is not correct:
Foo( id == "\a" )
and it is rightly flagged as a syntax error, but the ensuing stack dump is
uncalled for:
Exception in thread "main" [Error: illegal escape sequence: a]
[Near : {... "\a" ....}]
^
[Line: 1, Column: 3]
at org.mvel2.util.ParseTools.handleEscapeSequence(ParseTools.java:889)
at org.mvel2.util.ParseTools.handleStringEscapes(ParseTools.java:1533)
at org.mvel2.compiler.AbstractParser.nextToken(AbstractParser.java:1105)
at
org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:128)
at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
at org.mvel2.MVEL.analysisCompile(MVEL.java:670)
at org.mvel2.MVEL.analysisCompile(MVEL.java:674)
at org.drools.rule.builder.PatternBuilder.setInputs(PatternBuilder.java:942)
at
org.drools.rule.builder.PatternBuilder.buildRelationalExpression(PatternBuilder.java:638)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:588)
at
org.drools.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:449)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:296)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:118)
at
org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:65)
at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:80)
at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:2503)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:847)
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:443)
at
org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:626)
at
org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:41)
at foobar.Main.setup(Main.java:68)
at foobar.Main.main(Main.java:124)
-W
12 years, 10 months
5.3.x regression in TypeDeclarationDescr
by Michael Anstis
Hi,
There appears to be a regression in TypeDeclarationDescr in 5.3.x branch,
as illustrated by the below.
Bean2 is shown as having a super-type of "Object" whereas it should be
"Bean1". The fields are correctly listed.
This is causing tests in Guvnor to fail.
Could somebody please take a look?
Thanks,
Mike
package org.drools.ide.common.server.rules;
import java.io.StringReader;
import java.util.List;
import org.drools.compiler.DrlParser;
import org.drools.compiler.DroolsError;
import org.drools.compiler.PackageBuilder;
import org.drools.definition.type.FactField;
import org.drools.lang.descr.PackageDescr;
import org.drools.lang.descr.TypeDeclarationDescr;
import org.junit.Test;
public class RegressionTest {
@Test
public void regression() {
String drl = "package foo \n"
+ "declare Bean1 \n"
+ "age: int \n"
+ "name : String \n"
+ "end \n"
+ "declare Bean2 extends Bean1\n"
+ "cheese : String \n"
+ "end";
PackageBuilder builder = new PackageBuilder();
try {
DrlParser parser = new DrlParser();
PackageDescr pkgDescr = parser.parse( drl );
for ( TypeDeclarationDescr baseType :
pkgDescr.getTypeDeclarations() ) {
String declaredSuperTypeName = baseType.getSuperTypeName();
System.out.println( baseType.getTypeName() + " extends " +
declaredSuperTypeName );
}
builder.addPackageFromDrl( new StringReader( drl ) );
System.out.println("foo.Bean1 fields=");
List<FactField> fieldsBean1 = builder.getPackage().getFactType(
"foo.Bean1" ).getFields();
for ( FactField field : fieldsBean1 ) {
System.out.println( field.getName() );
}
System.out.println("foo.Bean2 fields=");
List<FactField> fieldsBean2 = builder.getPackage().getFactType(
"foo.Bean2" ).getFields();
for ( FactField field : fieldsBean2 ) {
System.out.println( field.getName() );
}
if ( builder.hasErrors() ) {
for ( DroolsError e : builder.getErrors().getErrors() ) {
System.out.println( e.getMessage() );
}
}
} catch ( Exception e ) {
e.printStackTrace();
}
}
}
12 years, 10 months
droolsjbpm-integration keeps failing
by Toni Rikkola
Here are the failing tests:
org.drools.camel.component.CamelEndpointWithJaxWrapperCollectionTest.testWorkingSetGlobalTestSessionSetAndGetGlobal
* org.drools.camel.component.CamelEndpointWithJaxbTest.testSessionInsert
* org.drools.camel.component.CamelEndpointWithJaxbTest.testSessionGetObject
* org.drools.camel.component.CamelEndpointWithJaxbTest.testSessionModify
* org.drools.camel.component.CamelEndpointWithJaxbTest.testInsertElements
* org.drools.camel.component.CamelEndpointWithJaxbTest.testQuery
* org.drools.camel.component.CamelEndpointWithJaxbTest.testProcess
* org.drools.camel.component.CamelEndpointWithJaxbXSDModelTest.testSessionInsert
* org.drools.runtime.pipeline.impl.JaxbFactTest.testFact
* org.drools.runtime.pipeline.impl.JaxbGlobalTest.testGlobal
* org.drools.runtime.pipeline.impl.JaxbTest.testDirectRoot
* org.drools.runtime.pipeline.impl.JaxbTest.testNestedIterable
Is somebody looking at these? I'll start looking for who to blame later today.
Toni
12 years, 10 months
Major/blocking bug in 5.3.0 and 5.4.0.Beta2
by Wolfgang Laun
Executing both of the following rules causes an NPE in
RuleTerminalNode.java:
rule "addSet"
no-loop true
when
$ms: MySet()
then
modify( $ms ){ add( "three", "four" ) }
insert( new MySet( "x", "y" ) );
end
rule "xySet"
no-loop true
when
$ms: MySet()
then
modify( $ms ){ add( "z" ) }
end
import java.util.*;
public class MySet {
Set<String> set = new HashSet<>();
public MySet( String... strings ){
add( strings );
}
public void add( String... strings ){
for( String s: strings ){
set.add( s );
}
}
}
-W
12 years, 10 months
3rd party jars
by Wolfgang Laun
Is there a standard procedure for Drools releases, regulating whether
they contain 3rd party jars that are essential for core (!) functions
of Drools?
For example: After downloading and installing 5.3.0, I tried to use a
rule calendar, but there's no "quartz" to be found in all the *.jar
files in /drools-distribution-5.3.0.Final/binaries.
Downloading quartz is no problem, but it would be NICE if there were a
hint in the ReadMeDrools.txt. (And what else is required but not
included?)
-W
12 years, 10 months
Drools & jBPM Event : London 8th March 2012
by Mark Proctor
http://blog.athico.com/2012/02/drools-jbpm-event-london-8th-march-2012.html
-----
Register now to join us for the free Drools & jBPM London 2012 event,
hurry limited spaces :)
http://redhat-mail.com/t/XRU-OE4J-824IMOYW1D/cr.aspx
When Thursday 8th March
Where Stationers Hall, London
Agenda trans
trans trans trans
trans
trans
09:00 trans Registration, tea and coffee
trans
09:30 trans Introduction/ Welcome
trans
09:45 trans Rules, Events & Processes: the Open Source way
Mark Proctor - Worldwide Technical Lead for BRMS & BPMS, Red Hat
trans
10:45 trans Decision Tables
Michael Anstis, JBoss Core Developer, Red Hat
trans
11:15 trans Tea/Coffee Break
trans
11:30 trans BPMN2 and jBPM5
Kris Verlaenen, JBoss Core Developer, Red Hat
trans
12:15 trans Solving Planning Problems
Geoffrey de Smet, JBoss Core Developer, Red Hat
trans
12:45 trans Case Studies
trans
13:00 trans Lunch and Networking
trans
12 years, 10 months
bad test names
by Mark Proctor
When committing tests, please use meaningful names:
@Test
public void testJBRULES3323() throws Exception {
Later on, no one knows what that is testing. If you have a dozen or more
of those in a single file, having to keep opening a browser is a PITA.
By all means leave the jira number in a comment associated with the test.
Mark
12 years, 10 months
api's, factories and services
by Mark Proctor
Just a reminder when doing api's
Stage interfaces in internal-api and make sure you do factories for
them, almost never expose "new" constructors to users. We provide both
static factories and a service registry, and we ideally should continue
to support both. i.e. we have
KnowledgeBuilderFactory (static method factory, actually wraps below)
KnowledgeBuilderFactoryService (singleton service)
static example:
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder()
singleton service exmaple:
KnowledgeBuilderFactoryService kbuilderfs =
ServiceRegistry.getInstance().get( KnowledgeBuilderFactoryService.class )
KnowledgeBuilder kbuilder = kbuilderfs .newKnowledgeBuilder()
All of our factory services should be registered in
org.drools.util.ServiceRegistryImpl, this has delegation to say OSGi if
it exists (via the service locator pattern). So we become much more
friendly to OSGi or other container environments that are service
locator oriented.
"new" should almost never be used, apart from when construcing say
default or debug listener implementations.
Mark
12 years, 10 months
