[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on WFLY-9053:
---------------------------------------
[~heruan] the version change I applied has some additional consequences, in particular it now pulls in the JipiJapa integration from WF11. Previously it would bundle the integration component meant for WF10, which was causing the exception you described.
[~andrei.ivanov] excellent question: this has been a very hard choice indeed. The WildFly project is very strict about backwards compatibility, but in the update of Hibernate ORM from 5.1 to 5.2 we had to break one single method's signature.
This change was essential for us (Hibernate team) as we're working on long term improvements and paving the road for very nice improvements in ORM 6, so after much debate we decided that breaking one single method was a reasonable compromise for our users. Since we understand it's not acceptable for everyone, we'll be maintaining 5.1 as well. You can effectively think 5.2 as a stepping stone in preparation for 6.
The "deal breaker" change can be found here:
https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2 Search for {{getFlushMode}}.
There are often many more changes of course, but this one affects public API and we believe it might be used quite frequently.
> 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)
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 11:58 AM:
-----------------------------------------------------------------------
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 "}}
{panel}
Hopefully these jndi lookups within the container are fast.
I have noticed that the MBean server in wildfly, when I clean queus on active MQ is significantly slower than on weblogic. So I am a bit afraid of expensive calls to get resources...
The rest call is taking me 22 ms, on average ... the timing here is too expensive.
Let us see how the fishing goes.
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
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] (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 11:31 AM:
-----------------------------------------------------------------------
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
Let us see how the fishing goes.
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.
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] (WFCORE-3215) Enhance CLI to support Aesh Commands
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3215:
----------------------------------------
Summary: Enhance CLI to support Aesh Commands
Key: WFCORE-3215
URL: https://issues.jboss.org/browse/WFCORE-3215
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
The patch command should be a candidate to validate this integration of aesh commands.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2088:
-----------------------------------------
Description:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
The patch command should be a candidate to validate this integration of aesh commands.
was:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
> Enhance CLI to support Aesh Commands
> ------------------------------------
>
> Key: WFCORE-2088
> URL: https://issues.jboss.org/browse/WFCORE-2088
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
> The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
> The patch command should be a candidate to validate this integration of aesh commands.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh Commands
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2088:
-----------------------------------------
Description:
In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
was:
This is the CLI.next project.
Aesh 1.0 will come with a Command API based on annotations. It makes full sense to redesign part of the existing commands, still offering backward compatibility using this API.
> Enhance CLI to support Aesh Commands
> ------------------------------------
>
> Key: WFCORE-2088
> URL: https://issues.jboss.org/browse/WFCORE-2088
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
> The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
--
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 10:48 AM:
-----------------------------------------------------------------------
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.
Let us see how the fishing goes.
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
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