[JBoss JIRA] (JBRULES-3690) Property Reactive: bitmask not being correctly calculated when field name is 'empty'
by Esteban Aliverti (JIRA)
Esteban Aliverti created JBRULES-3690:
-----------------------------------------
Summary: Property Reactive: bitmask not being correctly calculated when field name is 'empty'
Key: JBRULES-3690
URL: https://issues.jboss.org/browse/JBRULES-3690
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.5.0.Final
Reporter: Esteban Aliverti
Assignee: Mario Fusco
When using Property Reactive facts, the property name 'empty' prevents rules to be activated.
If the property name is changed, rules work as expected.
The problem could be related to the fact that 'empty' is internally translated to 'isEmpty()' and this could cause problems when the pattern's bitmask is calculated.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-3414) Symbolic links inside deployed ear/war are not followed by web server
by Ronen Angluster (JIRA)
Ronen Angluster created AS7-3414:
------------------------------------
Summary: Symbolic links inside deployed ear/war are not followed by web server
Key: AS7-3414
URL: https://issues.jboss.org/browse/AS7-3414
Project: Application Server 7
Issue Type: Bug
Components: Web Services
Affects Versions: 7.1.0.CR1, 7.1.0.Beta1
Environment: Fedora 16
Reporter: Ronen Angluster
Assignee: Alessio Soldano
when creating a symbolic link inside a deployed ear/war the symbolic link's target is not followed when
accessing it from a web browser
i.e.
in jboss-as/standalone/deplyoment/somedomain.ear/files we created a symbolic link named "version.js"
which points to /usr/share/something/version.js
the target file (/usr/share/...) is accessible by all (chmod'd to 777) and is readable by the jboss-as user which runs
the Jboss application server.
when accessing http://domain:8080/something/files/version.js we get an 404 error, seems like the file is not found by
the server.
when placing the file instead of symbolic link, the file is accessible and all is well
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (AS7-6029) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6029?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on AS7-6029:
------------------------------------
The impact is that recovery will never be performed on remote nodes when using "Distributed JTA"
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: AS7-6029
> URL: https://issues.jboss.org/browse/AS7-6029
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6030) Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6030?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on AS7-6030:
------------------------------------
See linked Jira for explanation of the issue.
> Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
> -------------------------------------------------------------------------------------------
>
> Key: AS7-6030
> URL: https://issues.jboss.org/browse/AS7-6030
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Attachments: logs_commitHaltRevClient.tgz
>
>
> The recovery process is not fully triggered on a distributed transaction when the transaction falls down at commit phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from that crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to commitHaltRevClient and commitHaltRevServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests.
> The test starts two servers, the client and the server (on filesystem called jbossts and jbossts2), creates a transaction on the client which then invokes the server and propagates the transaction to it. After crash, the mock XA resource is committed during periodic recovery on the client, but on the server an XA record still keeps in the tx log and no recovery happens there. The following message repeatedly appears in log of the client:
> {noformat}
> 14:01:32,622 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016038: No XAResource to recover < formatId=131077,
> gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-50a7ae4c:503cb145:13, node_name=1,
> branch_uid=0:ffff7f000001:-50a7ae4c:503cb145:1f, subordinatenodename=null, eis_name=unknown eis name >
> {noformat}
> The failure for commitHaltRevServer is similar.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of commitHaltRevClient run are attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6029) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6029?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on AS7-6029:
------------------------------------
This looks like server 1 is not configured to connect to server 2 to recover the transactions.
To the new assignee, this is not a JBoss Transactions issue, it is a small issue in the integration code where you are meant to configure a XARecoveryModule that can connect to known servers to see if they have any transactions that were started at this server.
This is a "distributed JTA" issue, not JTA/JTS.
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: AS7-6029
> URL: https://issues.jboss.org/browse/AS7-6029
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6030) Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6030?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson moved JBTM-1232 to AS7-6030:
------------------------------------------
Project: Application Server 7 (was: JBoss Transaction Manager)
Key: AS7-6030 (was: JBTM-1232)
Affects Version/s: (was: 4.16.4)
Component/s: EJB
Remoting
(was: Testing)
(was: Recovery)
Security: (was: Public)
Fix Version/s: (was: 5.0.0.M2)
(was: 4.17.3)
> Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
> -------------------------------------------------------------------------------------------
>
> Key: AS7-6030
> URL: https://issues.jboss.org/browse/AS7-6030
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: Tom Jenkinson
> Attachments: logs_commitHaltRevClient.tgz
>
>
> The recovery process is not fully triggered on a distributed transaction when the transaction falls down at commit phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from that crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to commitHaltRevClient and commitHaltRevServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests.
> The test starts two servers, the client and the server (on filesystem called jbossts and jbossts2), creates a transaction on the client which then invokes the server and propagates the transaction to it. After crash, the mock XA resource is committed during periodic recovery on the client, but on the server an XA record still keeps in the tx log and no recovery happens there. The following message repeatedly appears in log of the client:
> {noformat}
> 14:01:32,622 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016038: No XAResource to recover < formatId=131077,
> gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-50a7ae4c:503cb145:13, node_name=1,
> branch_uid=0:ffff7f000001:-50a7ae4c:503cb145:1f, subordinatenodename=null, eis_name=unknown eis name >
> {noformat}
> The failure for commitHaltRevServer is similar.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of commitHaltRevClient run are attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6030) Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6030?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated AS7-6030:
-------------------------------
Assignee: jaikiran pai (was: Tom Jenkinson)
> Recovery not fully triggered when distributed transaction falls down at commit phase of 2PC
> -------------------------------------------------------------------------------------------
>
> Key: AS7-6030
> URL: https://issues.jboss.org/browse/AS7-6030
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Attachments: logs_commitHaltRevClient.tgz
>
>
> The recovery process is not fully triggered on a distributed transaction when the transaction falls down at commit phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from that crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to commitHaltRevClient and commitHaltRevServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests.
> The test starts two servers, the client and the server (on filesystem called jbossts and jbossts2), creates a transaction on the client which then invokes the server and propagates the transaction to it. After crash, the mock XA resource is committed during periodic recovery on the client, but on the server an XA record still keeps in the tx log and no recovery happens there. The following message repeatedly appears in log of the client:
> {noformat}
> 14:01:32,622 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016038: No XAResource to recover < formatId=131077,
> gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-50a7ae4c:503cb145:13, node_name=1,
> branch_uid=0:ffff7f000001:-50a7ae4c:503cb145:1f, subordinatenodename=null, eis_name=unknown eis name >
> {noformat}
> The failure for commitHaltRevServer is similar.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#commitHaltRevServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of commitHaltRevClient run are attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6029) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6029?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated AS7-6029:
-------------------------------
Assignee: jaikiran pai (was: Tom Jenkinson)
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: AS7-6029
> URL: https://issues.jboss.org/browse/AS7-6029
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: jaikiran pai
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6029) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6029?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson moved JBTM-1231 to AS7-6029:
------------------------------------------
Project: Application Server 7 (was: JBoss Transaction Manager)
Key: AS7-6029 (was: JBTM-1231)
Affects Version/s: (was: 4.16.4)
Component/s: EJB
Remoting
(was: Testing)
(was: Recovery)
Security: (was: Public)
Fix Version/s: (was: 5.0.0.M2)
(was: 4.17.3)
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
> Key: AS7-6029
> URL: https://issues.jboss.org/browse/AS7-6029
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Reporter: Ivo Studensky
> Assignee: Tom Jenkinson
> Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log.
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.
> Tom, could you take a look at this please?
> Thanks a lot.
--
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
12 years, 11 months
[JBoss JIRA] (AS7-6028) CLONE - NillableOrExpressionParameterValidator fails when undefining a nillable attribute
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-6028:
-------------------------------------
Summary: CLONE - NillableOrExpressionParameterValidator fails when undefining a nillable attribute
Key: AS7-6028
URL: https://issues.jboss.org/browse/AS7-6028
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.3.Final (EAP)
Reporter: Wolf-Dieter Fink
Assignee: Stefan Guilhen
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
Undefining a nillable attribute via CLI results in a validation error:
{code}
[standalone@localhost:9999 /] /subsystem=security/security-domain=other:undefine-attribute(name=cache-type)
{
"outcome" => "failed",
"failure-description" => "JBAS014746: value may not be null",
"rolled-back" => true
}
{code}
This is caused by the validateResolvedParameter method in the NillableOrExpressionParameterValidator. The method incorrectly qualifies the value as an expression when its undefined:
{code}
if (!value.isDefined()) {
if (!allowExpression) {
throw MESSAGES.nullNotAllowed(parameterName);
}
} else {
delegate.validateResolvedParameter(parameterName, value);
}
{code}
It should check the value type instead, just like validateParameter does.
--
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
12 years, 11 months