[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- an INFO, 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. A WARN OTOH seems too high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op.
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-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- an INFO, 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. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op.
> 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- an INFO, 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. A WARN OTOH seems too high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[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- an INFO, 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. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op.
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-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.
> 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- an INFO, 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. A WARN OTOH seems to high, as this likely does not harm the end user and there is nothing they can do about it other than not invoking the op.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations
by Xavier Mourgues (JIRA)
[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ]
Xavier Mourgues edited comment on JBEE-171 at 9/1/17 12:17 PM:
---------------------------------------------------------------
Hello,
I'm, currently facing this issue.
Is there any workaround available ?
Cheers
was (Author: xqvier):
Hello,
I', currently facing this issue.
Is there any workaround available ?
Cheers
> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
> Key: JBEE-171
> URL: https://issues.jboss.org/browse/JBEE-171
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jsf-api
> Reporter: Markus Pollak
> Assignee: Dmitrii Tikhomirov
>
> Hello,
> I’ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems…
> Best Regards,
> Markus Pollak
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations
by Xavier Mourgues (JIRA)
[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ]
Xavier Mourgues commented on JBEE-171:
--------------------------------------
Hello,
I', currently facing this issue.
Is there any workaround available ?
Cheers
> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
> Key: JBEE-171
> URL: https://issues.jboss.org/browse/JBEE-171
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jsf-api
> Reporter: Markus Pollak
> Assignee: Dmitrii Tikhomirov
>
> Hello,
> I’ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems…
> Best Regards,
> Markus Pollak
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3227) Legacy slaves can't understand new enum version values
by Ken Wills (JIRA)
Ken Wills created WFCORE-3227:
---------------------------------
Summary: Legacy slaves can't understand new enum version values
Key: WFCORE-3227
URL: https://issues.jboss.org/browse/WFCORE-3227
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Priority: Blocker
[Host Controller] 10:53:50,342 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("add") failed - address: ([("host-exclude" => "EAP70")]) - failure description: "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"
[Host Controller] 10:53:50,366 ERROR [org.jboss.as.host.controller] (Host Controller Service Threads - 2) WFLYHC0143: Failed to apply domain-wide configuration from master host controller. Operation outcome: failed. Failure description {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"}}
[Host Controller] 10:53:50,448 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://192.168.122.71:9999 -- 1-$-
[Host Controller] 10:53:50,449 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
[Host Controller] 10:53:50,451 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3226) Legacy slaves can't understand new enum version values
by Ken Wills (JIRA)
Ken Wills created WFCORE-3226:
---------------------------------
Summary: Legacy slaves can't understand new enum version values
Key: WFCORE-3226
URL: https://issues.jboss.org/browse/WFCORE-3226
Project: WildFly Core
Issue Type: Bug
Reporter: Ken Wills
Priority: Blocker
Attachments: domain.xml, host-slave.xml
[Host Controller] 10:53:50,342 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 2) WFLYCTL0013: Operation ("add") failed - address: ([("host-exclude" => "EAP70")]) - failure description: "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"
[Host Controller] 10:53:50,366 ERROR [org.jboss.as.host.controller] (Host Controller Service Threads - 2) WFLYHC0143: Failed to apply domain-wide configuration from master host controller. Operation outcome: failed. Failure description {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0248: Invalid value EAP7.0 for host-release; legal values are [EAP6.3, EAP6.2, WildFly10.0, EAP6.4]"}}
[Host Controller] 10:53:50,448 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://192.168.122.71:9999 -- 1-$-
[Host Controller] 10:53:50,449 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
[Host Controller] 10:53:50,451 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3225) CLI, keep full stack trace
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-3225:
--------------------------------------------
Summary: CLI, keep full stack trace
Key: WFCORE-3225
URL: https://issues.jboss.org/browse/WFCORE-3225
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Priority: Minor
CLI is re-throwing the exception thrown in the async task. The calling stack is lost. It has no impact for CLI users but is annoying when using CLI programmatically.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-386:
---------------------------------
I think it would probably be a good idea to support both names.
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-386:
--------------------------------
Problem in *DHE-DSS-CBC-SHA* is there are two OpenSSL names for one standard name:
{code}
TLS_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,...
TLS_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-CBC-SHA,...
{code}
We would need to implement aliases for OSSL names (currectly we have aliases only for stdNames), or at least to allow more entries for one stdName (which currently causes warning and ignore second definition).
[~dmlloyd] Do we want to support both OSSL names for TLS_DHE_DSS_WITH_DES_CBC_SHA? It looks like most of projects supports only one of this names.
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-8954:
------------------------------------
Rather than lookup the "java:comp/TransactionSynchronizationRegistry", which requires "java:comp" to be setup, we might be able to instead use JNDI "java:jboss/TransactionSynchronizationRegistry".
Your approach to the change looks very good! :-)
When you create a WildFly pull request for this change, please update this jira. If you have any questions about submitting the pull request, please refer to the [https://developer.jboss.org/wiki/HackingOnWildFly]. Or you can ask questions here as well.
Thanks,
Scott
> 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)
6 years, 7 months