June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-125) Automation Testcase

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-125: ----------------------------------------- Summary: Automation Testcase Key: HAWKULARQE-125 URL: https://issues.jboss.org/browse/HAWKULARQE-125 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-124) Manual Testcases - Create and Run

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-124: ----------------------------------------- Summary: Manual Testcases - Create and Run Key: HAWKULARQE-124 URL: https://issues.jboss.org/browse/HAWKULARQE-124 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-122) Automation Testcase

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-122: ----------------------------------------- Summary: Automation Testcase Key: HAWKULARQE-122 URL: https://issues.jboss.org/browse/HAWKULARQE-122 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-121) Manual Testcases - Create and Run

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-121: ----------------------------------------- Summary: Manual Testcases - Create and Run Key: HAWKULARQE-121 URL: https://issues.jboss.org/browse/HAWKULARQE-121 Project: Hawkular QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8524) OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8524?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-8524: ---------------------------------- Assignee: Tomasz Adamski (was: Paul Ferraro) > OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-8524 > URL: https://issues.jboss.org/browse/WFLY-8524 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Reporter: David Lloyd > Assignee: Tomasz Adamski > Priority: Critical > > The transaction manager is allowed to create more than one Transaction object for an imported transaction, and has been observed to do so in at least distributed JTA cases if not other cases. > The JTA specification says that the equals method must return true for two objects that refer to the same transaction. Therefore OwnableReentrantLock must use equals() on its owner argument. > As an aside, that class should probably also null-check its owner object on lock() to avoid weird states. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-120) [QE] - JMAN4-127 - Deploy JDBC Driver and Datasource to Server Group

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-120: ----------------------------------------- Summary: [QE] - JMAN4-127 - Deploy JDBC Driver and Datasource to Server Group Key: HAWKULARQE-120 URL: https://issues.jboss.org/browse/HAWKULARQE-120 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley Priority: Minor See [JMAN4-127|https://issues.jboss.org/browse/JMAN4-127] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8524) OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8524?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-8524: ---------------------------------- Assignee: Paul Ferraro (was: Tomasz Adamski) > OwnableReentrantLock can't recognize two different but equal transaction objects as the same transaction > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-8524 > URL: https://issues.jboss.org/browse/WFLY-8524 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Reporter: David Lloyd > Assignee: Paul Ferraro > Priority: Critical > > The transaction manager is allowed to create more than one Transaction object for an imported transaction, and has been observed to do so in at least distributed JTA cases if not other cases. > The JTA specification says that the equals method must return true for two objects that refer to the same transaction. Therefore OwnableReentrantLock must use equals() on its owner argument. > As an aside, that class should probably also null-check its owner object on lock() to avoid weird states. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8960) CachedConnectionManager custom operations are read-only

by Martin Simka (JIRA)

Martin Simka created WFLY-8960: ---------------------------------- Summary: CachedConnectionManager custom operations are read-only Key: WFLY-8960 URL: https://issues.jboss.org/browse/WFLY-8960 Project: WildFly Issue Type: Sub-task Components: JCA Reporter: Martin Simka Assignee: Brian Stansberry *CRITICAL: DO NOT IMPLEMENT THIS IF WFCORE-2858 IS NOT IN PLACE.* Otherwise existing behavior will regress. Subtask for the following item from the parent issue: {quote} JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior. {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8960) CachedConnectionManager custom operations are read-only

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8960?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFLY-8960: ------------------------------- Parent: (was: WFLY-8849) Issue Type: Bug (was: Sub-task) > CachedConnectionManager custom operations are read-only > ------------------------------------------------------- > > Key: WFLY-8960 > URL: https://issues.jboss.org/browse/WFLY-8960 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Martin Simka > Assignee: Brian Stansberry > > *CRITICAL: DO NOT IMPLEMENT THIS IF WFCORE-2858 IS NOT IN PLACE.* Otherwise existing behavior will regress. > Subtask for the following item from the parent issue: > {quote} > JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8959) Clean up managed domain handling of the transaction subsystem's 'probe' operation

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8959?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFLY-8959: ------------------------------- Parent: (was: WFLY-8849) Issue Type: Bug (was: Sub-task) > Clean up managed domain handling of the transaction subsystem's 'probe' operation > --------------------------------------------------------------------------------- > > Key: WFLY-8959 > URL: https://issues.jboss.org/browse/WFLY-8959 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Martin Simka > Assignee: Michael Musgrove > > Subtask for this item from the parent issue: > {quote} > The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could: > a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless. > b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only > a semi-breaking change. > c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout. > Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work. > {quote} > The parent issue will do choice c); this issue is to decide the final status. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017