[JBoss JIRA] Created: (BPEL-203) replace implicit tokens with implicit termination disablement in the scope lifecycle
by Alejandro Guizar (JIRA)
replace implicit tokens with implicit termination disablement in the scope lifecycle
------------------------------------------------------------------------------------
Key: BPEL-203
URL: http://jira.jboss.com/jira/browse/BPEL-203
Project: JBoss jBPM BPEL
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 1
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Fix For: jBPM BPEL 1.1 beta 2
Early jBPM 3 versions did not provide a mechanism to prevent implicit token termination. Such a mechanism was required to implement the event handling semantics of BPEL scopes.
Early jBPM BPEL versions introduced so-called "implicit" tokens that prevented the scope token from being terminated when a) the nested activity completed, but event handling was still in progress or b) event handling completed, but the activity was still in progress.
The behavior described in the previous paragraph remained in latter jBPM BPEL versions. It must be updated to take advantage of the mechanism to prevent implicit termination introduced in latter jBPM versions. This will save the creation of 1-2 tokens per executed scope.
--
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
19 years
[JBoss JIRA] Created: (BPEL-205) employ inheritance instead of enumeration to distinguish sublanguage uses
by Alejandro Guizar (JIRA)
employ inheritance instead of enumeration to distinguish sublanguage uses
-------------------------------------------------------------------------
Key: BPEL-205
URL: http://jira.jboss.com/jira/browse/BPEL-205
Project: JBoss jBPM BPEL
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 1
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Fix For: jBPM BPEL 1.1 beta 2
ScriptDefinition has a property of enum type Use to distinguish the intent of the sublanguage snippet in the context where it appears. Collecting this information is important because each use has different semantics.
Inheritance models the relationship between the diverse uses better from an object-oriented perspective. Therefore, the Use enumeration has to be dropped in favor of a Snippet hierarchy.
--
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
19 years
[JBoss JIRA] Created: (BPEL-198) prevent stale object state exceptions
by Alejandro Guizar (JIRA)
prevent stale object state exceptions
-------------------------------------
Key: BPEL-198
URL: http://jira.jboss.com/jira/browse/BPEL-198
Project: JBoss jBPM BPEL
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: jBPM BPEL 1.1 beta 1
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Priority: Critical
Fix For: jBPM BPEL 1.1 beta 2
After incorporating optimistic concurrency control, Hibernate frequently throwed StaleObjectStateExceptions due to the integration service's enabling of RequestListeners as soon as the process instance reached an inbound message activity. When the expected message comes before the transaction that reached the activity ends, nothing prevents JMS from delivering it. The unavoidable outcome of this situation is a StaleObjectStateException.
We must find a way to enable RequestListeners after the originating transaction ends.
--
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
19 years
[JBoss JIRA] Created: (BPEL-197) integers are represented with a decimal point when used as source content
by Alejandro Guizar (JIRA)
integers are represented with a decimal point when used as source content
-------------------------------------------------------------------------
Key: BPEL-197
URL: http://jira.jboss.com/jira/browse/BPEL-197
Project: JBoss jBPM BPEL
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1 beta 1
Reporter: Alejandro Guizar
Assigned To: Alejandro Guizar
Fix For: jBPM BPEL 1.1 beta 2
When the evaluation of an expression results in a Number value, and this value is latter used to compute a source content TII, the resulting TII contains a decimal point and a trailing zero.
The BPEL 2 spec, section 8.4.2, states:
> Once the information item is returned from the source, a TII will be computed based upon it. [...] This is analogous to the XPath 1.0 string() function.
However, jBPM BPEL converts an object of a type other than node-set to a string by calling the toString() method. This method does not match the behavior of the string() function for a number.
In particular, the XPath 1 spec, section 4.2 states:
> if the number is an integer, the number is represented in decimal form as a Number with no decimal point and no leading zeros, preceded by a minus sign (-) if the number is negative
--
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
19 years
[JBoss JIRA] Created: (JBRULES-503) Compiler Throwing an exception on generics
by jasonc411 (JIRA)
Compiler Throwing an exception on generics
------------------------------------------
Key: JBRULES-503
URL: http://jira.jboss.com/jira/browse/JBRULES-503
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 3.0.4
Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
Reporter: jasonc411
Assigned To: Mark Proctor
#created on: Sep 15, 2006
package com.ca.data.dsrules
#list any import classes here.
import com.ca.data.model.base.DataSourceEnum;
import com.ca.data.model.issuer.Issuer;
import java.util.ArrayList;
import java.util.List;
import com.ca.data.model.Data;
import com.ca.data.datasubs.utils.JMSServiceLocator;
import com.ca.data.jms.JMSTextMessageSender;
function void save(Issuer issuer){
JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
Data data = new Data();
List<Issuer> myIssuers = new ArrayList<Issuer>();
myIssuers.add(issuer);
Data.setIssuerList(myIssuers);
cleanQueue.simpleSend(issuer);
}
rule "Persist Validated Data"
agenda-group "Data In"
no loop
salience 1
when
issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
then
System.out.println("Validated");
save(issuer);
end
--
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
19 years
[JBoss JIRA] Created: (JBRULES-704) Drools 3.1.M1 Rules build results in java.lang.UnsupportedOperationException
by Thomas Gonzalez (JIRA)
Drools 3.1.M1 Rules build results in java.lang.UnsupportedOperationException
----------------------------------------------------------------------------
Key: JBRULES-704
URL: http://jira.jboss.com/jira/browse/JBRULES-704
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 3.1-m1
Environment: Windows 2k
Reporter: Thomas Gonzalez
Assigned To: Mark Proctor
Initial issue description sent in following email test:
yep - looks like a bug to me on a quick look - do you want to attach a simple test to a JIRA?
On 2/23/07, Tom Gonzalez < tomgon(a)nortel.com> wrote:
Getting exception below building rules that build in 3.0.4.
Looking at FunctionBuilder we have at line 106. The code in red looks suspicious? Seems it should be mapping "mapping" against the name.
But that is not what is the cause of the exception apparently put is not supported?
String name = pkg.getName() + "." + ucFirst( functionDescr.getName() );
LineMappings mapping = new LineMappings( name );
mapping.setStartLine( functionDescr.getLine() );
mapping.setOffset( functionDescr.getOffset() );
lineMappings.put( name, lineMappings );
[java] INFO: ============== Start build RulePackage: [engrules.ers8600] ===
======
[java] Feb 21, 2007 2:38:28 PM com.nortel.connect.rbuilder.RulePackage addR
ulesFromDrlFile
[java] INFO: adding Rules from: ERS8600Rules.drl (no associated DSL)
[java] Feb 21, 2007 2:38:28 PM com.nortel.connect.rbuilder.RulePackage addR
ulesFromDrlFile
[java] INFO: parsed rules no dsl
[java] java.lang.UnsupportedOperationException
[java] at java.util.AbstractMap.put(AbstractMap.java:228)
[java] at org.drools.semantics.java.FunctionBuilder.build(FunctionBuild
er.java:110)
[java] at org.drools.compiler.PackageBuilder.addFunction(PackageBuilder
.java:326)
[java] at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.
java:214)
[java] at com.nortel.connect.rbuilder.RulePackage.addRulesFromDrlFile(R
ulePackage.java:226)
[java] at com.nortel.connect.rbuilder.RulePackager.build(RulePackager.j
ava:205)
[java] at com.nortel.connect.rbuilder.RulePackager.buildAll(RulePackage
r.java:141)
[java] at com.nortel.connect.rbuilder.RulePackager.main(RulePackager.ja
va:91)
A second problem is the cause of the UnsupportedOperationException turns out to be our use of the PackageBuilder in 3.0.4 that is no longer supported by 3.1.M1. We are using the merge rules constructor when we create a rule package from scratch as follows:
this.droolsPackage = new org.drools.rule.Package(packageName);
PackageBuilderConfiguration config = new PackageBuilderConfiguration();
config.setJavaLanguageLevel("1.5");
this.packageBuilder = new PackageBuilder(droolsPackage, config);
This used to work before but in version 3.1.M1 in PackageBuilder the Map lineMappings is only initialized with a HashMap when the newPackage() method is invoked and not when the mergePackage() method is invoked. The assumption is the lineMappings has been initialized when mergePackage() has been invoked.
Changing to properly use from scratch and merge constructors
--
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
19 years
[JBoss JIRA] Created: (JBRULES-854) I have following problem with null valuated string properties
by Vesa Tuononen (JIRA)
I have following problem with null valuated string properties
-------------------------------------------------------------
Key: JBRULES-854
URL: http://jira.jboss.com/jira/browse/JBRULES-854
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.0.MR2
Environment: Windows XP SP2
Reporter: Vesa Tuononen
Assigned To: Mark Proctor
Priority: Blocker
I have very simple object with PropertyChangeSupport.
Java code listed bellow object and test method:
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.InputStreamReader;
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.StatefulSession;
import org.drools.compiler.DroolsParserException;
import org.drools.compiler.PackageBuilder;
public class OwnTest{
public static class Row{
private final PropertyChangeSupport changes = new PropertyChangeSupport( this );
private String field1;
private String field2;
public Row(){}
public String getField1() {
return field1;
}
public void setField1(String field1) {
String oldField1 = this.field1;
this.field1 = field1;
this.changes.firePropertyChange( "field1",
oldField1,
this.field1 );
}
public String getField2() {
return field2;
}
public void setField2(String field2) {
String oldField2 = this.field2;
this.field2 = field2;
this.changes.firePropertyChange( "field2",
oldField2,
this.field2 );
}
public void addPropertyChangeListener(final PropertyChangeListener l) {
this.changes.addPropertyChangeListener( l );
}
public void removePropertyChangeListener(final PropertyChangeListener l) {
this.changes.removePropertyChangeListener( l );
}
}
/**
* @param args
* @throws Exception
* @throws DroolsParserException
* @throws Exception
*/
public static void main(String[] args) throws Exception {
Row r = new Row();
r.setField1(null);
r.setField2(null);
PackageBuilder builder = new PackageBuilder();
builder.addPackageFromXml(new InputStreamReader( OwnTest.class.getResourceAsStream("rule.xml")));
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage( builder.getPackage() );
StatefulSession workingMemory = ruleBase.newStatefulSession();
workingMemory.assertObject(r, true);
workingMemory.fireAllRules();
}
}
and rule.xml
<?xml version="1.0" encoding="UTF-8"?>
<package name="test"
xmlns="http://drools.org/drools-3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
xs:schemaLocation="http://drools.org/drools-3.0 drools-3.0.xsd">
<import name="OwnTest.Row"/>
<rule name="1">
<lhs>
<pattern object-type="Row">
<field-constraint field-name="field1">
<literal-restriction evaluator="==" value="1" />
</field-constraint>
</pattern>
</lhs>
<rhs>
System.out.println("--"+input.getField1());
input.setField1("2");
</rhs>
</rule>
<rule name="2">
<lhs>
<pattern identifier="input" object-type="Row">
<field-constraint field-name="field1">
<literal-restriction evaluator="==" value="2" />
</field-constraint>
</pattern>
</lhs>
<rhs>
System.out.println("--"+input.getField1());
input.setField1("3");
</rhs>
</rule>
<rule name="3">
<lhs>
<pattern identifier="input" object-type="Row">
<field-constraint field-name="field1">
<literal-restriction evaluator="==" value="3" />
</field-constraint>
</pattern>
</lhs>
<rhs>
System.out.println("--"+input.getField1());
input.setField1("4");
</rhs>
</rule>
<rule name="4">
<lhs>
<pattern identifier="input" object-type="Row">
<field-constraint field-name="field1">
<literal-restriction evaluator="==" value="4" />
</field-constraint>
</pattern>
</lhs>
<rhs>
System.out.println("--"+input.getField1());
input.setField1("0");
input.setField2("5");
</rhs>
</rule>
<rule name="5">
<lhs>
<pattern identifier="input" object-type="Row">
<field-constraint field-name="field2">
<literal-restriction evaluator="==" value="2" />
</field-constraint>
</pattern>
</lhs>
<rhs>
System.out.println("--"+input.getField1());
System.out.println("--"+input.getField2());
input.setField2("2b");
</rhs>
</rule>
</package>
with this rule set I get following StackTrace:
Exception in thread "main" java.lang.NullPointerException
at org.drools.reteoo.CompositeObjectSinkAdapter$HashKey.setValue(CompositeObjectSinkAdapter.java:478)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:292)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:183)
at org.drools.reteoo.Rete.assertObject(Rete.java:121)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:201)
at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:70)
at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:724)
at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:568)
but if I remove some rules everything works fine.
--
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
19 years