[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, 3 months
[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, 3 months
[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 commented on WFLY-8954:
---------------------------------------------
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, 3 months
[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 2:26 PM:
----------------------------------------------------------------------
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
.doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}
I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}}
{panel}
The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect.
Let us see how the fishing goes...
Looks promising, the changes on how the wildfly transaction controller registers on the container seem to have produced positive effect.
The test passed successfully on my system right.
{panel}
Running org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.288 sec - in org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.33 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.047 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
Running org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.73 sec - in org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
Running org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.209 sec - in org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
Results :
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
{panel}
I want to see what hapens on our system tests when I hack this library into my wildfly.
I will soon make a provisory commit with the changes.
Many thanks.
was (Author: nuno.godinhomatos):
Hi,
As requested, there is now a branch based on the master with the source code to run the discussed test.
The following branch comparison shows the changes.
https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from...
This branch is called:
WFLY-8954-from-master
I do not have a big time window available to me.
But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components.
And see where I might be bale to override functionality to what you suggest.
The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue.
https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc
Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using.
I setup a smal rest service to return me the output of:
{panel}
(TransactionSynchronizationRegistry) initContext
.doLookup("java:comp/TransactionSynchronizationRegistry");
{panel}
I get a good result.
{panel}
{"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}}
{panel}
The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect.
Let us see how the fishing goes.
Many thanks.
> 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, 3 months
[JBoss JIRA] (ELY-1351) Elytron - Unable to create security domain without a realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1351?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1351:
----------------------------
Labels: (was: eap7.1.0-to-prd)
> Elytron - Unable to create security domain without a realm
> ----------------------------------------------------------
>
> Key: ELY-1351
> URL: https://issues.jboss.org/browse/ELY-1351
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Server
> Affects Versions: 1.2.0.Beta1
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> It's not possible to create an Elytron security domain without a security realm (default-realm attribute is mandatory).
> When an administrator wants to allow just ANONYMOUS access, he/she has to use a dummy security realm to configure such a security domain. It should be possible to have domain without realms too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3216) Elytron - Unable to create security domain without a realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3216?page=com.atlassian.jira.plugi... ]
Jan Kalina moved JBEAP-12929 to WFCORE-3216:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3216 (was: JBEAP-12929)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.1.Final
(was: 7.1.0.ER1)
> Elytron - Unable to create security domain without a realm
> ----------------------------------------------------------
>
> Key: WFCORE-3216
> URL: https://issues.jboss.org/browse/WFCORE-3216
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.1.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> It's not possible to create an Elytron security domain without a security realm (default-realm attribute is mandatory).
> When an administrator wants to allow just ANONYMOUS access, he/she has to use a dummy security realm to configure such a security domain. It should be possible to have domain without realms too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months