[JBoss JIRA] Created: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory
by Juergen none (JIRA)
Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory
-------------------------------------------------------------------------------------------------------------------
Key: JBRULES-449
URL: http://jira.jboss.com/jira/browse/JBRULES-449
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.0.4
Environment: jdk 1.4.2_10
Reporter: Juergen none
Assigned To: Mark Proctor
A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted.
Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract)
Its a buggy (R5 twice) implementation of a accumulating set of rules I posted in the user list some time ago.
FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned)
classes without @ have only one instance in working memory
a XXX
R0: XXX -> al DDD
a AAA (external assert)
Sequence of rules fired
R1: AAA -> al GGG
R2: DDD, GGG -> al CCC
R3: GGG -> al EEE
R4: EEE, DDD, CCC -> a BBB@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c)
R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B)
R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@16d8ba contributes to Hash/equals))
---
r AAA (external retract)
-> (according to listener):
r AAA
r GGG
r EEE
r CCC
breakpoint, screenshot --> justifier list is invalid, contains retracted handles
PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple
r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too)
->
r XXX
r DDD
workingMemory.getObjects() lists FFF@b2d75c(A) and FFF@b274de(B)
for Rulebase-properties:
- RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY
- empty
Major lead could be that after commenting out "mod CCC", FFF(A) is retracted (+ R5 not fired a second time)
+ problem with changed hashcode of CCC ?
+ problem with second instances of BBB and FFF(A) being asserted
+ FFF(B) being assert normally, not logically
--
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, 3 months
[JBoss JIRA] Created: (JBPM-708) Version control of the process definition
by Aravind Kumar (JIRA)
Version control of the process definition
-----------------------------------------
Key: JBPM-708
URL: http://jira.jboss.com/jira/browse/JBPM-708
Project: JBoss jBPM
Issue Type: Feature Request
Components: Core Engine
Affects Versions: jBPM 3.1.1
Reporter: Aravind Kumar
Assigned To: Tom Baeyens
When working with jBPM in developement environment, there is no control over the version of the process-definition.
Each time the server is restarted, a new version is deployed.
The work around that I did:
<boolean name="update-definition" value="false"/>
this tag is included in the jbpm.cfg.xml
& a check at JbpmContext.java:
public void deployProcessDefinition(ProcessDefinition processDefinition) {
if(JbpmConfiguration.Configs.getBoolean("update-definition")) {
getGraphSession().deployProcessDefinition(processDefinition);
}
}
This works fine for a single process defifnition. In case, there are multiple process definitions and some needs to be updates and some need not be.
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-375) "?" doesn't seem to be recognized in the excel spreadsheet.
by wen Lin (JIRA)
"?" doesn't seem to be recognized in the excel spreadsheet.
-------------------------------------------------------------
Key: JBRULES-375
URL: http://jira.jboss.com/jira/browse/JBRULES-375
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Decision tables
Affects Versions: 3.0.1
Environment: window xp, eclipses-3.1.2
Reporter: wen Lin
Assigned To: Mark Proctor
In the action cell, I have
int score = (i.getMyScore()< $param)? i.getMyScore(): $param; c.setAdjustScore(score); c.setFlag(false); modify( c );
and got the following errors:
[mTokens]: line 25:39 state 0 (decisionfiltered=16) no viable alt line 25:39; char='?'
[mTokens]: line 37:39 state 0 (decisionfiltered=16) no viable alt line 37:39; char='?'
[mTokens]: line 49:39 state 0 (decisionfiltered=16) no viable alt line 49:39; char='?'
[mTokens]: line 61:39 state 0 (decisionfiltered=16) no viable alt line 61:39; char='?'
[mTokens]: line 73:39 state 0 (decisionfiltered=16) no viable alt line 73:39; char='?'
[mTokens]: line 85:39 state 0 (decisionfiltered=16) no viable alt line 85:39; char='?'
[mTokens]: line 97:39 state 0 (decisionfiltered=16) no viable alt line 97:39; char='?'
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
Rule Compilation error Syntax error on token ")", ? expected after this token
------------------------------------------------------------------
but the problem disappears while I use the following instead:
c.setAdjustScore(Math.min(i.getMyScore (), $param));
---------------------------------------------------------------------------------------
It seems to me that either "?" is not recognized or "(a>b)? a:b" doesn't work ...
--
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, 3 months
[JBoss JIRA] Created: (JBBUILD-323) JBossBuild needs to be able to calculate component version using highest common denominator algorithm
by Alex Pinkin (JIRA)
JBossBuild needs to be able to calculate component version using highest common denominator algorithm
-----------------------------------------------------------------------------------------------------
Key: JBBUILD-323
URL: http://jira.jboss.com/jira/browse/JBBUILD-323
Project: JBoss Build System
Issue Type: Feature Request
Affects Versions: JBossBuild-1.1 DR2
Reporter: Alex Pinkin
We've already had this discussion, and thought that it's not easy to implement. However, I do think we need this done since I don't want all projects to enumerate all their 3rd party dependencies in build-thirdparty.xml.
Example: these products include the following javassist versions
1. aop 1.5.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA
2. ws 1.0.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA
3. ejb3 1.0.0.CR8: javassist 3.2.0.CR1, 3.2.0.CR2, 3.2.0.GA
JBossBuild needs to be able to determine that javassist 3.2.0.CR2 is the highest common denominator. Current behaviour is that JBossBuild takes the highest version of the component whenever it runs into it for the first time during the dependency graph traversal.
Does Maven already support this? It seems like this should be one of the core maven features.
Could you please look more info feasibility of implementing this in JBossBuild?
--
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, 3 months
[JBoss JIRA] Created: (JBPM-734) org.jbpm.util.XmlException: couldn't parse xml
by Ivan Garcia (JIRA)
org.jbpm.util.XmlException: couldn't parse xml
----------------------------------------------
Key: JBPM-734
URL: http://jira.jboss.com/jira/browse/JBPM-734
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.2
Reporter: Ivan Garcia
Assigned To: Tom Baeyens
This code
try{
String cfg = "<jbpm-configuration>";
cfg += "</jbpm-configuration>";
jbpmConfiguration = JbpmConfiguration.parseXmlString(cfg);
}catch(Exception e){
e.printStackTrace();
}
launch this exception,
org.jbpm.util.XmlException: couldn't parse xml
at org.jbpm.util.XmlUtil.parseXmlInputSource(XmlUtil.java:78)
at org.jbpm.util.XmlUtil.parseXmlResource(XmlUtil.java:60)
at org.jbpm.configuration.ObjectFactoryParser.parseElementsFromResource(ObjectFactoryParser.java:104)
at org.jbpm.JbpmConfiguration.parseObjectFactory(JbpmConfiguration.java:299)
at org.jbpm.JbpmConfiguration.parseXmlString(JbpmConfiguration.java:318)
Caused by: java.net.MalformedURLException
at java.net.URL.<init>(URL.java:601)
at java.net.URL.<init>(URL.java:464)
at java.net.URL.<init>(URL.java:413)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at org.jbpm.util.XmlUtil.parseXmlInputSource(XmlUtil.java:76)
... 6 more
and i dont know why :-(
Thanks
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-460) Please allow ftp downloads to "resume"
by hoogenbj (JIRA)
Please allow ftp downloads to "resume"
--------------------------------------
Key: JBRULES-460
URL: http://jira.jboss.com/jira/browse/JBRULES-460
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: Any
Reporter: hoogenbj
Assigned To: Mark Proctor
Priority: Minor
Hi Guys
In my part of the world (South Africa) we still get dropped connections and here a 128kbps connection counts as broadband. It is extremely &*^&^$%#$ annoying if I lose a connection while trying to download a 23MB file (JBoss Rules 3.0.4 binary with deps) and I have to start from the beginning because your ftp server does not allow "resume". (I've already made 3 attempts today)
PLEASE PLEASE PLEASE change it. Other parts of JBoss do allow it so why not you?
I'm not sure why you disallow it. Maybe you think that people multiplexing a download over multiple connections (with DAP) put too much load on the server?
Think about it: you are actually increasing the load by not allowing it, because someone like me have to make multiple attempts at downloading something before succeeding. If I have to try 3 times and come close to succeeding the first two times, it is effectively the same as three people downloading the same software. Allow resume and I'll succeed sooner and go away sooner.
Again, PUHHLEASSEEE!
Regards
Johan Hoogenboezem
--
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, 3 months
[JBoss JIRA] Created: (JBSER-84) Improve serialization of immutable objects
by Michael Santos (JIRA)
Improve serialization of immutable objects
------------------------------------------
Key: JBSER-84
URL: http://jira.jboss.com/jira/browse/JBSER-84
Project: JBoss Serialization
Issue Type: Feature Request
Reporter: Michael Santos
Assigned To: Clebert Suconic
It is common for objects to contain references to hundreds or thousands of equal immutable object instances, especially java.lang.Number subclasses. Some immutable objects produce a considerable serialized amount of information, such as java.math.BigDecimal. However, there's usually no reason for different instances being used to represent the same value; they only exist due to the way they were produced (parsing &, conversion APIs and JDBC are definitely fine examples of that). Experiments on a particular project have shown replacing all these equal instances by one of them can reduce the serialized size of some objects by half.
Therefore, JBoss Serialization should provide way to allow users to tell it's ok to use the same reference for all these immutable instances and which classes are to be considered immutable and replace them during the writing phase. This would be much more efficient and wouldn't require developers to rewrite their code in order to optimize serialization of some objects. A global way, such as system property, of telling the API to do this by default with the most commonly used Java SE classes would be desirable as well.
--
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, 3 months