[JBoss JIRA] (DROOLS-628) DecisionTable incorrectly parsed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-628?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-628:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1150308|https://bugzilla.redhat.com/show_bug.cgi?id=1150308] from NEW to ASSIGNED
> DecisionTable incorrectly parsed
> ---------------------------------
>
> Key: DROOLS-628
> URL: https://issues.jboss.org/browse/DROOLS-628
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.2.0.CR1
>
>
> 5.2.0.CR1 creates incorrect drl from decision table. With 5.1.0.M1 the drl for the same decision table is correct.
> Wrong DRL from 5.2.0.CR1:
> rule "ProcessState"
> salience 65522
> ruleflow-group "CompleteSubOrder"
> activation-group "ProcessState"
> when
> $m:ModifiedMarker(processState==null, state ==null)
> $s:SubOrder
> then
> $m.setIsModified(true);
> $s.setProcessState(ProcessState.CREATED);
> end
> Correct DRL with 5.1.0.M1:
> rule "ProcessState"
> salience 65522
> ruleflow-group "CompleteSubOrder"
> activation-group "ProcessState"
> when
> $m:ModifiedMarker()
> $s:SubOrder(processState==null, state ==null)
> then
> $m.setIsModified(true);
> $s.setProcessState(ProcessState.CREATED);
> end
> The difference is that the constraints are put to $m instead of putting them to $s.
> The behaviour in 5.2.0.CR1 is the same for all decision tables in my project and prevents me from upgrading to newer drools versions.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3950) Remove @Ignore from SarTestCase
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-3950:
------------------------------------
Summary: Remove @Ignore from SarTestCase
Key: WFLY-3950
URL: https://issues.jboss.org/browse/WFLY-3950
Project: WildFly
Issue Type: Bug
Components: JMX
Reporter: Stuart Douglas
Assignee: David Lloyd
This test was ignored due to issues introduced by the security manager upgrade, as it now fails under the security manager due to checking being true by default.
The MBean server does an explicit check on the ProtectionDomain of the class, which is what causes the issue.
{noformat}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanTrustPermission" "register")" in code source "(vfs:/content/sar-example.sar <no signer certificates>)" of "null")
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-154) Patching does not process subdirectories
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFCORE-154:
-----------------------------------------
Summary: Patching does not process subdirectories
Key: WFCORE-154
URL: https://issues.jboss.org/browse/WFCORE-154
Project: WildFly Core
Issue Type: Bug
Components: Patching
Affects Versions: 1.0.0.Alpha9
Reporter: Bartosz Baranowski
Assignee: Bartosz Baranowski
Fix For: 1.0.0.Alpha10
If patched resource is in subdirectory of moduleRoot, it is not included as part of patch, even though it is present in patch zip.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-42) Add a ServerXml Parser which extends CommonXml
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-42?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFCORE-42:
---------------------------------
Fix Version/s: 1.0.0.Alpha10
(was: 1.0.0.Alpha9)
> Add a ServerXml Parser which extends CommonXml
> ----------------------------------------------
>
> Key: WFCORE-42
> URL: https://issues.jboss.org/browse/WFCORE-42
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha10
>
>
> Both StandaloneXml and AppclientXml parse XML starting from the server element.
> This duplication has always been problematic as AppclientXml is completely separate from the remaining domain config parsing, however with the core split this is even worse.
> This change is to introduce a ServerXml that can be the common base for both StandaloneXml and AppclientXml - except in extreme cases it will then be safe to ignore AppclientXml for further schema updates.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years