[JBoss JIRA] (WFCORE-3220) Enhanced help for CLI
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3220?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-3220:
--------------------------------------------
Assignee: Jean-Francois Denise
> Enhanced help for CLI
> ---------------------
>
> Key: WFCORE-3220
> URL: https://issues.jboss.org/browse/WFCORE-3220
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> Replace help text file by “on the fly” generation of help content. The source of input for this generation are the Command Annotations and Bundle files that contain descriptions.
> Furthermore the help content currently doesn’t scale with the complexity of commands. The help has to be attached to command and command’s actions.
> Low level operations usage is aligned with command documentation.
> Both commands and operations help are available from the help command.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Giovanni Lovato (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Giovanni Lovato commented on WFLY-9053:
---------------------------------------
[~sannegrinovero] Thank you very much for the explanation! Hope to see ORM 5.2.11 released soon to test it out.
> AbstractMethodError with Hibernate 5.2
> --------------------------------------
>
> Key: WFLY-9053
> URL: https://issues.jboss.org/browse/WFLY-9053
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Giovanni Lovato
> Assignee: Scott Marlow
>
> I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider:
> {code:xml}
> <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" />
> {code}
> Hibernate 5.2 modules are placed in the {{modules}} directory.
> This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object;
> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (DROOLS-1719) Problems when defining a test scenario in Spanish with a Date field
by R D (JIRA)
R D created DROOLS-1719:
---------------------------
Summary: Problems when defining a test scenario in Spanish with a Date field
Key: DROOLS-1719
URL: https://issues.jboss.org/browse/DROOLS-1719
Project: Drools
Issue Type: Bug
Affects Versions: 6.5.0.Final
Environment: KIE Workbench 6.5.0
WildFly 1.10.x
Reporter: R D
Assignee: Edson Tirelli
Priority: Minor
Attachments: MyTestEnglish_EnglishWorkbench.PNG, MyTestEnglish_SpanishWorkbench.PNG, MyTestSpanish_EnglishWorkbench.PNG, MyTestSpanish_SpanishWorkbench.PNG
We detect two bugs:
1. When executing a test scenario in a KIE workbench in Spanish, a field defined as Date seems not to be parsed correctly and always enters the rule file as null.
2. When switching to English in the KIE workbench the test scenario we defined in Spanish does not load. When we change back to Spanish the page with the test scenario loads again.
Why is this a bug?
1. When we create the same test scenario in a KIE workbench in English, the field defined as Date has a value in the rule file and this value is the one that is provided in the test scenario .
2. When we switch the KIE workbench to Spanish, the test scenario defined in English does not load.
--
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 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:
---------------------------------------------
No.
The issue not solved!
I have a system test where this issue can still be reproduced.
I can no longer reproduce it using the sample application, but we do have a scenario in a system test where after refreshing the entity we get different data than what we have in the server session cache.
Not good...
> 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
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue edited comment on WFLY-9251 at 9/1/17 5:10 AM:
------------------------------------------------------------
Hello Tomaz,
Thank you for your answer.
I'm working with Charles and I'm assigned to this task.
We reproduce our issue with wildfly-11.0.0.Beta1 and wildfly-11.0.0.CR1.
But there's something noticeable:
* with wildfly-10.1.0.Final:
** {failed_count: 103, shots_count: 1000, succeeded_count: 897}
* with wildfly-11.0.0.Beta1:
** {failed_count: 2, shots_count: 1000, succeeded_count: 998}
* with wildfly-11.0.0.CR1:
** {failed_count: 4, shots_count: 1000, succeeded_count: 996}
What do you think about that?
Regards,
Rémy.
(In attachment, the script I used to reproduce the issue. [^wildfly-auth-overloader.js])
was (Author: clivia):
Hello Tomaz,
Thank you for your answer.
I'm working with Charles and I'm assigned to this task.
We reproduce our issue with wildfly-11.0.0.Beta1 and wildfly-11.0.0.CR1.
But there's something noticeable:
* with wildfly-10.1.0.Final: {failed_count: 103, shots_count: 1000, succeeded_count: 897}
* with wildfly-11.0.0.Beta1: {failed_count: 2, shots_count: 1000, succeeded_count: 998}
* with wildfly-11.0.0.CR1: {failed_count: 4, shots_count: 1000, succeeded_count: 996}
What do you think about that?
Regards,
Rémy.
(In attachment, the script I used to reproduce the issue. [^wildfly-auth-overloader.js])
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue commented on WFLY-9251:
------------------------------------
Hello Tomaz,
Thank you for your answer.
I'm working with Charles and I'm assigned to this task.
We reproduce our issue with wildfly-11.0.0.Beta1 and wildfly-11.0.0.CR1.
But there's something noticeable:
* with wildfly-10.1.0.Final: {failed_count: 103, shots_count: 1000, succeeded_count: 897}
* with wildfly-11.0.0.Beta1: {failed_count: 2, shots_count: 1000, succeeded_count: 998}
* with wildfly-11.0.0.CR1: {failed_count: 4, shots_count: 1000, succeeded_count: 996}
What do you think about that?
Regards,
Rémy.
(In attachment, the script I used to reproduce the issue. [^wildfly-auth-overloader.js])
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Rémy Delerue (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Rémy Delerue updated WFLY-9251:
-------------------------------
Attachment: wildfly-auth-overloader.js
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildfly-auth-overloader.js, wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
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 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 9/1/17 4:54 AM:
---------------------------------------------------------------------
I have now tried to patch my local wildfly with this version of the library.
On the sample application I had already written for this the issue is no longer manifested.
{panel}
####2017-09-01 10:45:43,875 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: true, After Refresh: true. Value on entity passed by event object as new value was: true <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: true, After Refresh: true <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:48:37,479 ThreadId:504 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@72f07690 we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventB> <default task-20>
####2017-09-01 10:48:37,501 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: false, After Refresh: false. Value on entity passed by event object as new value was: false <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: false, After Refresh: false <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:50,330 ThreadId:505 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@2681802a we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventA> <default task-21>
####2017-09-01 10:48:50,338 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: true, After Refresh: true. Value on entity passed by event object as new value was: true <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: true, After Refresh: true <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:53,160 ThreadId:506 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@756c3ae6 we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventA> <default task-22>
####2017-09-01 10:48:53,167 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,170 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: false, After Refresh: false. Value on entity passed by event object as new value was: false <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,170 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: false, After Refresh: false <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,171 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
{panel}
The current module configuration being exprimented looks as follows.
{panel}
<module xmlns="urn:jboss:module:1.3" name="company.org.eclipse.persistence">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<!-- resource-root path="jipijapa-eclipselink-10.1.0.Final.jar"/ -->
<!-- This version of the module should address bug: WFLY-8954 -->
<resource-root path="jipijapa-eclipselink-11.0.0.Final-SNAPSHOT.jar"/>
<resource-root path="eclipselink-2.6.4.jar">
<filter>
<exclude path="javax/**" />
</filter>
</resource-root>
</resources>
<dependencies>
<module name="asm.asm"/>
<module name="javax.api"/>
<module name="javax.annotation.api"/>
<module name="javax.enterprise.api"/>
<module name="javax.persistence.api"/>
<module name="javax.transaction.api"/>
<module name="javax.validation.api"/>
<module name="javax.xml.bind.api"/>
<module name="org.antlr"/>
<module name="org.dom4j"/>
<module name="org.javassist"/>
<module name="org.jboss.as.jpa.spi"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.vfs"/>
<!-- Add dependency on rest api to allow moxy to work (should go back to jackson asap) -->
<module name="javax.ws.rs.api" />
</dependencies>
</module>
{panel}
was (Author: nuno.godinhomatos):
I have now tried to patch my local wildfly with this version of the library.
On the sample application I had already written for this the issue is no longer manifested.
{panel}
####2017-09-01 10:45:43,875 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: true, After Refresh: true. Value on entity passed by event object as new value was: true <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: true, After Refresh: true <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:45:43,878 ThreadId:502 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-19>
####2017-09-01 10:48:37,479 ThreadId:504 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@72f07690 we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventB> <default task-20>
####2017-09-01 10:48:37,501 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: false, After Refresh: false. Value on entity passed by event object as new value was: false <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: false, After Refresh: false <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:37,505 ThreadId:504 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeBEvent <LogContext:SomeEntityChangeEventObserverBFacade.observeEvent> <default task-20>
####2017-09-01 10:48:50,330 ThreadId:505 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@2681802a we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventA> <default task-21>
####2017-09-01 10:48:50,338 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: true, After Refresh: true. Value on entity passed by event object as new value was: true <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: true, After Refresh: true <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:50,340 ThreadId:505 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-21>
####2017-09-01 10:48:53,160 ThreadId:506 INFO onsuccess.facade.ModifyEntityAndFireEventFacade - We will now modify the entity: db.model.SomeEntity@756c3ae6 we will toogle the text to either true or false <LogContext:ModifyEntityAndFireEventFacade.modifyEntityAndFireEventA> <default task-22>
####2017-09-01 10:48:53,167 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - START: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,170 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - Before Refresh value was: false, After Refresh: false. Value on entity passed by event object as new value was: false <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,170 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - The entity remeained unchanged before and after refresh. Before Refresh value was: false, After Refresh: false <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
####2017-09-01 10:48:53,171 ThreadId:506 INFO onsuccess.facade.AbstractSomeEntityChangeEventObserverFacade - ENDED: TEST VALIDATION - FOR FIRED EVENT: wildfly.bug.onsuccess.event.SomeEntityChangeAEvent <LogContext:ExecutorFacadeImpl.executoreSynchronousNewJta> <default task-22>
{panel}
The current module configuration being exprimented looks as follows.
{panel}
<module xmlns="urn:jboss:module:1.3" name="company.org.eclipse.persistence">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<!-- resource-root path="jipijapa-eclipselink-10.1.0.Final.jar"/ -->
<!-- This version of the module should address bug: WFLY-8954 -->
<resource-root path="jipijapa-eclipselink-11.0.0.Final-SNAPSHOT.jar"/>
<resource-root path="eclipselink-2.6.4.jar">
<filter>
<exclude path="javax/**" />
</filter>
</resource-root>
</resources>
<dependencies>
<module name="asm.asm"/>
<module name="javax.api"/>
<module name="javax.annotation.api"/>
<module name="javax.enterprise.api"/>
<module name="javax.persistence.api"/>
<module name="javax.transaction.api"/>
<module name="javax.validation.api"/>
<module name="javax.xml.bind.api"/>
<module name="org.antlr"/>
<module name="org.dom4j"/>
<module name="org.javassist"/>
<module name="org.jboss.as.jpa.spi"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.vfs"/>
<!-- Add dependency on rest moxy api -->
<module name="javax.ws.rs.api" />
</dependencies>
</module>
{panel}
> 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