[JBoss JIRA] (DROOLS-330) Rule Inheritance using Extends keyword fails when the Sub Rule Appears before the Super Rule
by Mike Fauzy (JIRA)
Mike Fauzy created DROOLS-330:
---------------------------------
Summary: Rule Inheritance using Extends keyword fails when the Sub Rule Appears before the Super Rule
Key: DROOLS-330
URL: https://issues.jboss.org/browse/DROOLS-330
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Ubuntu 12.04 LTS in VM
Reporter: Mike Fauzy
Assignee: Mark Proctor
Priority: Minor
In Drools 5.5.0.Final the extends keyword allows one rule (SubRule) to extend another rule (SuperRule). SubRule should only fire if all of the conditions for SubRule and SuperRule are met.
If SubRule is listed after SuperRule after in the .drl file, then it works correctly. However, if SubRule is listed before SuperRule in the .drl file, then only the SubRule's conditions need to be met for the rule to fire.
A temporary workaround is to list all SubRules after the SuperRules.
This might be related to: https://issues.jboss.org/browse/DROOLS-100
To reproduce:
I have a junit test packaged for Maven and Eclipse, but I don't see any place to add the file.
Create 2 .drl files where rule "sub" extends rule "super". Setup a boolean that is true for the sub, but false for the super.
In the first file, place the sub before the super. In the second file, reverse the two.
Observe that the sub fires when it is in the file before the super, but not after. It should not fire either time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by gui borland (JIRA)
[ https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin.... ]
gui borland commented on WFLY-2454:
-----------------------------------
I've attached the jbossts-properties.xml file below. You'll need to uncomment the VolatileStore to reproduce the problem.
I've set the com.arjuna.ats.arjuna.common.propertiesFile in the JAVA_OPTS environment variable before launching jboss
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<!--
JBoss, Home of Professional Open Source
Copyright 2009, Red Hat Middleware LLC, and individual contributors
as indicated by the @author tags.
See the copyright.txt in the distribution for a
full listing of individual contributors.
This copyrighted material is made available to anyone wishing to use,
modify, copy, or redistribute it subject to the terms and conditions
of the GNU Lesser General Public License, v. 2.1.
This program is distributed in the hope that it will be useful, but WITHOUT A
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License,
v.2.1 along with this distribution; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301, USA.
(C) 2009,
@author JBoss, a division of Red Hat.
-->
<properties>
<!--
This is the JBossTS configuration file for running ArjunaJTS.
It should be called jbossts-properties.xml.
You need a different version for ArjunaCore or JTA usage.
***************************
Property values may be literals or be tokens of the form ${p1[,p2][:v]}
in which case the token values are substituted for the values of the corresponding system
properties as follows:
- Any occurance of ${p} with the System.getProperty(p) value.
If there is no such property p defined, then the ${p} reference will remain unchanged.
- If the property reference is of the form ${p:v} and there is no such property p,
then the default value v will be returned.
- If the property reference is of the form ${p1,p2} or ${p1,p2:v} then
the primary and the secondary properties will be tried in turn, before
returning either the unchanged input, or the default value.
The property ${/} is replaced with System.getProperty("file.separator")
value and the property ${:} is replaced with System.getProperty("path.separator").
Note this substitution applies to property values only at the point they are read from
the config file. Tokens in system properties won't be substituted.
-->
<!-- (default is YES) -->
<entry key="CoordinatorEnvironmentBean.commitOnePhase">YES</entry>
<!-- default is under user.home - must be writeable!) -->
<entry key="ObjectStoreEnvironmentBean.objectStoreDir">PutObjectStoreDirHere</entry>
<!-- Using volatile store make jboss shutdown fail (recovery can not get stopped correctly
Also, this setting will be ignore if the use-hornetq option is selected in the standalone-xml file. That will enable the hornetq- store no matter what
<entry key="ObjectStoreEnvironmentBean.objectStoreType">com.arjuna.ats.internal.arjuna.objectstore.VolatileStore</entry>
-->
<entry key="com.arjuna.ats.arjuna.allowMultipleLastResources">true</entry>
<entry key="com.arjuna.ats.arjuna.disableMultipleLastResourcesWarning">true</entry>
<entry key="ObjectStoreEnvironmentBean.objectStoreSync">OFF</entry>
<!-- (default is ON) -->
<entry key="ObjectStoreEnvironmentBean.transactionSync">OFF</entry>
<!-- (Must be unique across all Arjuna instances.) -->
<entry key="CoreEnvironmentBean.nodeIdentifier">1</entry>
<!-- Which Xid types to recover -->
<entry key="JTAEnvironmentBean.xaRecoveryNodes">1</entry>
<entry key="JTAEnvironmentBean.xaResourceOrphanFilterClassNames">
com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter
com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter
</entry>
<!--
Base port number for determining a unique number to associate with an instance of the transaction service
(which is needed in order to support multiple instances on the same machine).
Use the value 0 to allow the system to select the first available port number.
If the port number is non-zero and the port is in use then the value will be incremented until either a successful binding
to the loopback address is created or until the the maximum number of ports (specified by the
CoreEnvironmentBean.socketProcessIdMaxPorts property) have been tried or until the port number
reaches the maximum possible port number.
-->
<entry key="CoreEnvironmentBean.socketProcessIdPort">0</entry>
<!--
Periodic recovery modules to use. Invoked in the order they appear in the list.
Check http://www.jboss.org/community/docs/DOC-10788 for more information
on recovery modules and their configuration when running in various
deployments.
-->
<entry key="RecoveryEnvironmentBean.recoveryModuleClassNames">
com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule
com.arjuna.ats.internal.txoj.recovery.TORecoveryModule
com.arjuna.ats.internal.jts.recovery.transactions.TopLevelTransactionRecoveryModule
com.arjuna.ats.internal.jts.recovery.transactions.ServerTransactionRecoveryModule
com.arjuna.ats.internal.jta.recovery.jts.XARecoveryModule
</entry>
<!-- Expiry scanners to use (order of invocation is random). -->
<entry key="RecoveryEnvironmentBean.expiryScannerClassNames">
com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.jts.recovery.contact.ExpiredContactScanner
com.arjuna.ats.internal.jts.recovery.transactions.ExpiredToplevelScanner
com.arjuna.ats.internal.jts.recovery.transactions.ExpiredServerScanner
</entry>
<!--
Add the following to the set of expiryScannerClassNames above to move logs that cannot be completed by failure recovery.
But be sure you know what you are doing and why!
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner
-->
<!--
The address and port number on which the recovery manager listens
If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
-->
<entry key="RecoveryEnvironmentBean.recoveryPort">4712</entry>
<entry key="RecoveryEnvironmentBean.recoveryAddress"></entry>
<!--
Use this to fix the port on which the TransactionStatusManager listens,
The default behaviour is to use any free port.
-->
<entry key="RecoveryEnvironmentBean.transactionStatusManagerPort">0</entry>
<!--
Use this to fix the address on which the TransactionStatusManager binds,
The default behaviour is to use the loopback address (ie localhost).
If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
-->
<entry key="RecoveryEnvironmentBean.transactionStatusManagerAddress"></entry>
<!--
For cases where the recovery manager is in process with the transaction manager and nothing else uses
the ObjectStore, it is possible to disable the socket based recovery listener by setting this to NO.
Caution: use of this property can allow multiple recovery processes to run on the same ObjectStore
if you are not careful. That in turn can lead to incorrect transaction processing. Use with care.
-->
<entry key="RecoveryEnvironmentBean.recoveryListener">NO</entry>
<!-- Recovery Activators to use. -->
<entry key="RecoveryEnvironmentBean.recoveryActivatorClassNames">com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement</entry>
<entry key="JTAEnvironmentBean.transactionManagerClassName">com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple</entry>
<entry key="JTAEnvironmentBean.userTransactionClassName">com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple</entry>
<entry key="JTAEnvironmentBean.transactionSynchronizationRegistryClassName">com.arjuna.ats.internal.jta.transaction.jts.TransactionSynchronizationRegistryImple</entry>
<entry key="OrbPortabilityEnvironmentBean.bindMechanism">CONFIGURATION_FILE</entry>
<entry key="OrbPortabilityEnvironmentBean.orbInitializationProperties">
<!-- This class handles context propagation issues, and should never be commented out or removed. -->
com.arjuna.orbportability.orb.PreInit1=com.arjuna.ats.internal.jts.context.ContextPropagationManager
<!-- This property ensures the JTS knows which ORB to use and should never be commented out or removed -->
com.arjuna.orbportability.orb.PostInit=com.arjuna.ats.jts.utils.ORBSetup
<!-- This property ensures the crash recovery is initialised correctly and should never be commented out or removed -->
com.arjuna.orbportability.orb.PostInit2=com.arjuna.ats.internal.jts.recovery.RecoveryInit
<!-- This property ensures the JTS knows which ORB to use and should never be commented out or removed -->
com.arjuna.orbportability.orb.PostSet1=com.arjuna.ats.jts.utils.ORBSetup
</entry>
<!--
This property controls the port on which the Recovery ORB listens
-->
<entry key="JTSEnvironmentBean.recoveryManagerPort">4711</entry>
<!--
This property controls the address on which the Recovery ORB binds - defaults to the loopback connection
If running within an AS then the address the AS is bound to (jboss.bind.address) takes precedence
-->
<entry key="JTSEnvironmentBean.recoveryManagerAddress"></entry>
</properties>
> Cannot stop recovery manager when configured with volatile store
> ----------------------------------------------------------------
>
> Key: WFLY-2454
> URL: https://issues.jboss.org/browse/WFLY-2454
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
> I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2480) Infinispan test XML files do not validate against XSD yet are parsed ok
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-2480:
------------------------------------
Summary: Infinispan test XML files do not validate against XSD yet are parsed ok
Key: WFLY-2480
URL: https://issues.jboss.org/browse/WFLY-2480
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.CR1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 8.0.0.Final
So one or the other should to change.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'mixed-keyed-jdbc-store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected.
cvc-complex-type.2.4.d: Invalid content was found starting with element 'binary-keyed-table'. No child element is expected at this point.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2479) Security subsystem transformers for 1.1.0 do not reject expressions, or test for it
by Kabir Khan (JIRA)
Kabir Khan created WFLY-2479:
--------------------------------
Summary: Security subsystem transformers for 1.1.0 do not reject expressions, or test for it
Key: WFLY-2479
URL: https://issues.jboss.org/browse/WFLY-2479
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Beta1
Reporter: Kabir Khan
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
Getting it to test for it is going to be a bit different than the usual RejectExpressionsConfig. The add handler transformers (correctly from what I can tell) use the existing child xxx-module resource to create the transformed add operation.
However, I think with the ModelTestUtils.checkFailedTransformedBootOperations() stuff set up the way it is the child resource/model used to populate the ops. A possible solution is to override the RejectExpressionsConfig to correct the main model as part of correcting the ops.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test cases need updating
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2478:
---------------------------------
Summary: Infinispan subsystem test cases need updating (was: Infinispan subsystem test case needs updating)
> Infinispan subsystem test cases need updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test case needs updating
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2478:
---------------------------------
Fix Version/s: 8.0.0.CR1
> Infinispan subsystem test case needs updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test case needs updating
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2478?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2478:
---------------------------------
Priority: Critical (was: Major)
> Infinispan subsystem test case needs updating
> ---------------------------------------------
>
> Key: WFLY-2478
> URL: https://issues.jboss.org/browse/WFLY-2478
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> Needs clean up and update:
> InfinispanSubsystemTransformerTestCase
> * testTransformer720 is missing
> * getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
> SubsystemParsingTestCase
> * seems to test 1.1. only
> * doesnt test 1.0 all the way to 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2478) Infinispan subsystem test case needs updating
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-2478:
------------------------------------
Summary: Infinispan subsystem test case needs updating
Key: WFLY-2478
URL: https://issues.jboss.org/browse/WFLY-2478
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.0.0.Beta1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Needs clean up and update:
InfinispanSubsystemTransformerTestCase
* testTransformer720 is missing
* getSubsystemXml should feed in the latest xml, so 2.0 not 1.4
SubsystemParsingTestCase
* seems to test 1.1. only
* doesnt test 1.0 all the way to 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months