August 2017 - jboss-jira - Jboss List Archives

[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: --------------------------------------- Hi all, we will not update WildFly 11 to Hibernate ORM 5.2.x, but we will be making Hibernate ORM 5.2.x releases which people can unpack on WF11 to use it as an alternative. The latest ORM releases were meant for WildFly 10, so I patched it to target WildFly 11 instead. This should work fine with the next release Hibernate ORM 5.2.11.Final : HHH-11950 > 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

1
0
0 / 0

[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 updated WFLY-9053: ---------------------------------- Affects Version/s: (was: 11.0.0.Alpha1) > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

Loren Chang created WFLY-9275: --------------------------------- Summary: wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) Key: WFLY-9275 URL: https://issues.jboss.org/browse/WFLY-9275 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.0.0.Final Reporter: Loren Chang -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Eduardo Martins edited comment on WFCORE-3205 at 8/29/17 9:03 AM: ------------------------------------------------------------------ Honestly I don't see any bug here, just lacking proper documentation about the class loading specifics? was (Author: emmartins): Honestly I don't see any bug here, just proper documentation about the class loading specifics? > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Eduardo Martins commented on WFCORE-3205: ----------------------------------------- Honestly I don't see any bug here, just proper documentation about the class loading specifics? > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Eduardo Martins commented on WFCORE-3205: ----------------------------------------- [~ge0ffrey] create the embedded as the migration tool does above, pass "org.jboss.logmanager" as system package. > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-3210: ------------------------------------- I think that this issue has become massively confused. I will explain a couple things about class loading here. First, non-determinism is not synonymous with "bug"; if you do something that is not supported or defined, like introduce a race into server initialization by way of two competing versions of the same classes, you get precisely what you pay for, whether or not you understand it. Class isolation is working 100% of the time; no class loader is "soiled" in this process. Rather you are misunderstanding the consequences of a race condition that is introduced by an erroneous module graph. This entire thing has been described as an "XY problem", where you have a solution in mind but it does not and can not work, whereas the actual problem is still not clear. Are you simply trying to configure log4j-compatible appenders? Are you trying to configure logging on a per-application basis? Start from the beginning. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-173) UX Improvement - When adding a datasource - MIQ Sprint-67

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-173?page=com.atlassian.jira.pl... ] Sunil kondkar commented on HAWKULARQE-173: ------------------------------------------ Below issue blocks adding jdbc drivers using UI: https://github.com/ManageIQ/manageiq-providers-hawkular/issues/36 > UX Improvement - When adding a datasource - MIQ Sprint-67 > --------------------------------------------------------- > > Key: HAWKULARQE-173 > URL: https://issues.jboss.org/browse/HAWKULARQE-173 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > From MIQ Sprint-67 Demo: > UX Improvement - When adding a datasource, there is a need to fetch available jdbc drivers from middleware server. If a provider is not running, do not display an exception when fetching jdbc drivers, but show a descriptive warning message and allow the user to close the wizard. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Geoffrey De Smet edited comment on WFCORE-3205 at 8/29/17 7:44 AM: ------------------------------------------------------------------- We're using the same war file for the normal and the embedded setup (in GWT Super Dev Mode to allow GWT debugging), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround? was (Author: ge0ffrey): We're using the same war file for the normal and the embedded setup (which in GWT Super Dev Mode), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround? > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3205?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on WFCORE-3205: ------------------------------------------ We're using the same war file for the normal and the embedded setup (which in GWT Super Dev Mode), so the workaround of excluding the jboss-logmanager is convoluted. Is there any other workaround? > Logging does not work in the embedded server > -------------------------------------------- > > Key: WFCORE-3205 > URL: https://issues.jboss.org/browse/WFCORE-3205 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017