[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:
---------------------------------------------
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
[JBoss JIRA] (DROOLS-1718) Accept hexadecimal values in rule LHS
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1718?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-1718:
-----------------------------------
Summary: Accept hexadecimal values in rule LHS (was: Guided Editor: Accept hexadecimal values in rule LHS)
> Accept hexadecimal values in rule LHS
> -------------------------------------
>
> Key: DROOLS-1718
> URL: https://issues.jboss.org/browse/DROOLS-1718
> Project: Drools
> Issue Type: Bug
> Reporter: Uli Bubenheimer
> Priority: Minor
>
> It is not possible to use a hexadecimal value in the LHS of a rule.
> The manual says: "All standard Java numeric primitives are supported." As hexadecimal values are standard Java numeric primitives, this could be considered not just a new feature, but a bug (documentation bug at least).
> I found this issue first mentioned in the referenced user forum post from 2006; sadly, the poster did not create a JIRA issue as suggested, or at least I could not find one.
> Example:
> rule "bla"
> when
> Value( tag == 0x00080060 ) // ERROR!
> then
> //something
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (DROOLS-1718) Accept hexadecimal values in rule LHS
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1718?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-1718:
-----------------------------------
Labels: (was: field_value_editor)
> Accept hexadecimal values in rule LHS
> -------------------------------------
>
> Key: DROOLS-1718
> URL: https://issues.jboss.org/browse/DROOLS-1718
> Project: Drools
> Issue Type: Bug
> Reporter: Uli Bubenheimer
> Priority: Minor
>
> It is not possible to use a hexadecimal value in the LHS of a rule.
> The manual says: "All standard Java numeric primitives are supported." As hexadecimal values are standard Java numeric primitives, this could be considered not just a new feature, but a bug (documentation bug at least).
> I found this issue first mentioned in the referenced user forum post from 2006; sadly, the poster did not create a JIRA issue as suggested, or at least I could not find one.
> Example:
> rule "bla"
> when
> Value( tag == 0x00080060 ) // ERROR!
> then
> //something
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (DROOLS-1718) Guided Editor: Accept hexadecimal values in rule LHS
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1718?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-1097 to DROOLS-1718:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-1718 (was: GUVNOR-1097)
Issue Type: Bug (was: Feature Request)
Workflow: GIT Pull Request workflow (was: classic default workflow)
> Guided Editor: Accept hexadecimal values in rule LHS
> ----------------------------------------------------
>
> Key: DROOLS-1718
> URL: https://issues.jboss.org/browse/DROOLS-1718
> Project: Drools
> Issue Type: Bug
> Reporter: Uli Bubenheimer
> Priority: Minor
>
> It is not possible to use a hexadecimal value in the LHS of a rule.
> The manual says: "All standard Java numeric primitives are supported." As hexadecimal values are standard Java numeric primitives, this could be considered not just a new feature, but a bug (documentation bug at least).
> I found this issue first mentioned in the referenced user forum post from 2006; sadly, the poster did not create a JIRA issue as suggested, or at least I could not find one.
> Example:
> rule "bla"
> when
> Value( tag == 0x00080060 ) // ERROR!
> then
> //something
> end
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months