August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3217) Relax the WFCORE-2849 requirement

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3217: ------------------------------------- Description: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log a WARN, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. was: WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9821). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log a WARN, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. > Relax the WFCORE-2849 requirement > --------------------------------- > > Key: WFCORE-3217 > URL: https://issues.jboss.org/browse/WFCORE-3217 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 3.0.0.Final, 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 4.0.0.Alpha1, 3.0.2.Final > > > WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9281). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. > Instead I would like to log a WARN, and have the problematic 'addStep' call simply return without adding the step. > Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3217) Relax the WFCORE-2849 requirement

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3217: ---------------------------------------- Summary: Relax the WFCORE-2849 requirement Key: WFCORE-3217 URL: https://issues.jboss.org/browse/WFCORE-3217 Project: WildFly Core Issue Type: Task Components: Domain Management Affects Versions: 3.0.1.Final, 3.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Blocker Fix For: 4.0.0.Alpha1, 3.0.2.Final WFCORE-2849 fails ops against domain profile resources if the OSH tries to register a Stage.RUNTIME step. But we are still hitting cases where we have OSHs that try to do this (see WFLY-9821). Since those OSHs have worked for years without this causing major trouble, failing the op seems excessive. Instead I would like to log a WARN, and have the problematic 'addStep' call simply return without adding the step. Perhaps this could be a DEBUG, but really if an OSH is doing this it is a bug and I'd like to not hide that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9281) Unable to remove an installed resource adapter

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9281?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9281: ----------------------------------- Fix Version/s: 11.0.0.Final Priority: Blocker (was: Major) This is a regression that we need to fix for 11.0.0.Final. The handler for this :remove op should be fixed so it doesn't violate the WFCORE-2849 requirement, but given the fact that we are still finding issues like this quite a while after the WFCORE-2849 makes me think we need to relax that check and have it just log a WARN or something rather than failing the op. Thank you, [~kznpoike] for the report. > Unable to remove an installed resource adapter > ---------------------------------------------- > > Key: WFLY-9281 > URL: https://issues.jboss.org/browse/WFLY-9281 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 11.0.0.CR1 > Reporter: John Huntley > Assignee: Stefano Maestri > Priority: Blocker > Fix For: 11.0.0.Final > > Attachments: wf11-ra-error.txt > > > Running a :remove operation for a defined resource adapter fails with error WFLYCTL0123. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9285) Make IONA interoperability work with OpenJDK ORB

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-9285?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-9285: --------------------------------- Description: IONA interoperability worked on JacORB, we would like the same functionality to be added to OpenJDK ORB. > Make IONA interoperability work with OpenJDK ORB > ------------------------------------------------ > > Key: WFLY-9285 > URL: https://issues.jboss.org/browse/WFLY-9285 > Project: WildFly > Issue Type: Bug > Reporter: Tomasz Adamski > Assignee: Jason Greene > > IONA interoperability worked on JacORB, we would like the same functionality to be added to OpenJDK ORB. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9285) Make IONA interoperability work with OpenJDK ORB

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-9285?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-9285: --------------------------------- Summary: Make IONA interoperability work with OpenJDK ORB (was: iona) > Make IONA interoperability work with OpenJDK ORB > ------------------------------------------------ > > Key: WFLY-9285 > URL: https://issues.jboss.org/browse/WFLY-9285 > Project: WildFly > Issue Type: Bug > Reporter: Tomasz Adamski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9285) iona

by Tomasz Adamski (JIRA)

Tomasz Adamski created WFLY-9285: ------------------------------------ Summary: iona Key: WFLY-9285 URL: https://issues.jboss.org/browse/WFLY-9285 Project: WildFly Issue Type: Bug Reporter: Tomasz Adamski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3064) Suffix in Elytron periodic-rotating-file-audit-log cannot include 's' or 'S' in text

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3064?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3064: ---------------------------------- Priority: Major (was: Critical) > Suffix in Elytron periodic-rotating-file-audit-log cannot include 's' or 'S' in text > ------------------------------------------------------------------------------------ > > Key: WFCORE-3064 > URL: https://issues.jboss.org/browse/WFCORE-3064 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > Suffix in Elytron periodic-rotating-file-audit-log cannot include second-of-minute or fraction-of-second symbol. However this symbol is checked even in text (some string in ''). This means that symbols 's' or 'S' cannot be used in text. It is probably caused by incorrectly implemented condition in {{org.wildfly.extension.elytron.validators.SuffixValidator.validateParameter}} method [1]. > [1] https://github.com/wildfly/wildfly-core/blob/7032d8b6cf5a87ab32cc27b2712b... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3064) Suffix in Elytron periodic-rotating-file-audit-log cannot include 's' or 'S' in text

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3064?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3064: --------------------------------------- This is not critical IMO. The logging subsystem also has this same issue as does management audit logging. > Suffix in Elytron periodic-rotating-file-audit-log cannot include 's' or 'S' in text > ------------------------------------------------------------------------------------ > > Key: WFCORE-3064 > URL: https://issues.jboss.org/browse/WFCORE-3064 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Critical > > Suffix in Elytron periodic-rotating-file-audit-log cannot include second-of-minute or fraction-of-second symbol. However this symbol is checked even in text (some string in ''). This means that symbols 's' or 'S' cannot be used in text. It is probably caused by incorrectly implemented condition in {{org.wildfly.extension.elytron.validators.SuffixValidator.validateParameter}} method [1]. > [1] https://github.com/wildfly/wildfly-core/blob/7032d8b6cf5a87ab32cc27b2712b... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 3:00 PM: ---------------------------------------------------------------------- Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... The commented class diagram for applying the change you recommended is here: https://drive.google.com/open?id=0B_dEiNBGUsxqY3VJZVl0d19Ub3M I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. was (Author: nuno.godinhomatos): Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... The commented class diagram for this applying the change you recommended is here: https://drive.google.com/open?id=0B_dEiNBGUsxqY3VJZVl0d19Ub3M I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. > Wildfly 10 with eclipselink Onscucess observer gets stale entity > ---------------------------------------------------------------- > > Key: WFLY-8954 > URL: https://issues.jboss.org/browse/WFLY-8954 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Nuno Godinho de Matos > Assignee: Scott Marlow > > Hi, > In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. > When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. > Then the observer will be working with stale entities that do not reflect the modifications done to the entity. > A sample application for this issue is available in: > https://github.com/99sono/wildfly10-observe-on-success-stale-entity > The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. > Many thanks for taking a look. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 3:00 PM: ---------------------------------------------------------------------- Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... The commented class diagram for this applying the change you recommended is here: https://drive.google.com/open?id=0B_dEiNBGUsxqY3VJZVl0d19Ub3M I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. was (Author: nuno.godinhomatos): Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. > Wildfly 10 with eclipselink Onscucess observer gets stale entity > ---------------------------------------------------------------- > > Key: WFLY-8954 > URL: https://issues.jboss.org/browse/WFLY-8954 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Nuno Godinho de Matos > Assignee: Scott Marlow > > Hi, > In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. > When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. > Then the observer will be working with stale entities that do not reflect the modifications done to the entity. > A sample application for this issue is available in: > https://github.com/99sono/wildfly10-observe-on-success-stale-entity > The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. > Many thanks for taking a look. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017