[JBoss JIRA] Created: (JBRULES-1960) Syntaxcoloring wrong if DSL contains a "#"-Character
by Norbert Ziegler (JIRA)
Syntaxcoloring wrong if DSL contains a "#"-Character
----------------------------------------------------
Key: JBRULES-1960
URL: https://jira.jboss.org/jira/browse/JBRULES-1960
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-eclipse
Affects Versions: 5.0.0.M5
Environment: eclipse 3.4, WinXP, jre6u10
Reporter: Norbert Ziegler
Assignee: Mark Proctor
Priority: Minor
While editing a DSL-File one can see that everything after an #-Character is colored as comment, regardless of the position of the #.
Indeed, it is not a comment.
Imagine the following line in a DSL:
Compute noselength to #MYVAR * #AGE
then everything at / after "#MYVAR" is rendered as a comment.
In this case a comment should only be recognized if the first non-empty-char of the line is the "#"
--
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
15 years, 3 months
[JBoss JIRA] Created: (JBRULES-2586) ForEach Node does not work correctly with incorparated subflow nodes
by Grégoire Botquin (JIRA)
ForEach Node does not work correctly with incorparated subflow nodes
--------------------------------------------------------------------
Key: JBRULES-2586
URL: https://jira.jboss.org/browse/JBRULES-2586
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.0.1.FINAL
Environment: Windows7
Reporter: Grégoire Botquin
Assignee: Mark Proctor
A ForEach node should process sequentially all elements inside the collection it has to iterate on. This works fine unless there is a SubFlow node incorparted in the ForEachNode. In this case, the messages are not processed sequentially anymore. It looks like that the subflow starts/continue only when the ForEach has terminated its loop.
Note : The problem happens when the subflow has a RuleFlowGroup node.
--
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
15 years, 3 months
[JBoss JIRA] Created: (JBRULES-2300) SingleSessionCommandService revisited: facyHandle is null while insert it in a stateful session
by Francesco Chiarelli (JIRA)
SingleSessionCommandService revisited: facyHandle is null while insert it in a stateful session
-----------------------------------------------------------------------------------------------
Key: JBRULES-2300
URL: https://jira.jboss.org/jira/browse/JBRULES-2300
Project: Drools
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: All
Affects Versions: 5.1.0.M1
Environment: jre 1.5 - jboss 5.0.1.GA - Eclipse with jbossTools
Reporter: Francesco Chiarelli
Assignee: Mark Proctor
Priority: Blocker
I had need to implement a new SingleSessionCommandService (logical mirror of the original unless registerRollbackSync (), which is no longer invoked and JoinTransaction).
The primary thread creates statefulKnowledgeSession via JPA (JTA). The secondary thread load the session, insert facts, fire rules, startProcess, and dispose.
In @PreUpdate on SessionInfo, when you create the same snapshot is retrieved correctly, during the insertion of a fact, I get a NPE on org.drools.reteoo.ReteooWorkingMemory at 245: factHandle is null. In debugging I verified that the method throws the exception FromNode.evaluateAndPropagate captured by the command.
--
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
15 years, 3 months
[JBoss JIRA] Created: (JBRULES-2714) Drools Persistence Should Not Rely on an Existing Named Query in "META-INF/orm.xml"
by Anatoly Polinsky (JIRA)
Drools Persistence Should Not Rely on an Existing Named Query in "META-INF/orm.xml"
-----------------------------------------------------------------------------------
Key: JBRULES-2714
URL: https://jira.jboss.org/browse/JBRULES-2714
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
There is a named query "ProcessInstancesWaitingForEvent" that lives in a drools persistence jar under "META-INF/orm.xml".
The problem is not even that the query is wrong ( org.hibernate.QueryException: cannot dereference scalar collection element.. ), but that majority of applications that sit on top of JPA rely on its own mappings, and hence this query either:
1. Lost, since the custom "persistence.xml" will redefine the path to other mapping files
2. Will result in "Duplicate query mapping" exception if defined in a custom mapping file ( http://opensource.atlassian.com/projects/hibernate/browse/HHH-4152 )
Would be more logical not to depend that everyone knows to look inside "drools persistence jar", and to have an extensive documentation explaining "ProcessInstancesWaitingForEvent". It maybe hardcoded through @NamedQuery or just be available as an OPTIONAL file to use by Drools clients: e.g. "<mapping-file>META-INF/persistence/mapping/drools/drools-named-queries.xml</mapping-file>" ( and again: documented.. )
/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
15 years, 3 months