[JBoss JIRA] (WFLY-10996) Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
[ https://issues.jboss.org/browse/WFLY-10996?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-10996:
--------------------------------------------
Tested same steps with wildfly 13 and there its woking fine. To be honest, i think its a basic test case to fail with a major release like v14.0.0/v14.0.1. :( (n)
> Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10996
> URL: https://issues.jboss.org/browse/WFLY-10996
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Environment: CentOS 7
> WildFly 14.0.0 / WildFly 14.0.1
> Reporter: Rakesh K. Cherukuri
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
>
>
> Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
> The changes are so minimal that it should basically work.
> Attached:
> # error.log - exception in the server log
> # jpa-war.tar.gz - maven module that can be used to reproduce the issue
> # pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
> # standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10996) Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
[ https://issues.jboss.org/browse/WFLY-10996?page=com.atlassian.jira.plugin... ]
Rakesh K. Cherukuri commented on WFLY-10996:
--------------------------------------------
Just to rule out, issue exists with postgresql-42.2.5 driver too. So, its unlikely that the driver is the cause. Moreover, the exception is clear that there is some module/class path issues with ironjacamar and/or hibernate
> Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10996
> URL: https://issues.jboss.org/browse/WFLY-10996
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 14.0.1.Final, 14.0.0.Final
> Environment: CentOS 7
> WildFly 14.0.0 / WildFly 14.0.1
> Reporter: Rakesh K. Cherukuri
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
>
>
> Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
> The changes are so minimal that it should basically work.
> Attached:
> # error.log - exception in the server log
> # jpa-war.tar.gz - maven module that can be used to reproduce the issue
> # pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
> # standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10996) Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
by Rakesh K. Cherukuri (JIRA)
Rakesh K. Cherukuri created WFLY-10996:
------------------------------------------
Summary: Database queries result in NoClassDefFound for org/wildfly/transaction/client/ContextTransactionManager
Key: WFLY-10996
URL: https://issues.jboss.org/browse/WFLY-10996
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 14.0.0.Final, 14.0.1.Final
Environment: CentOS 7
WildFly 14.0.0 / WildFly 14.0.1
Reporter: Rakesh K. Cherukuri
Assignee: Scott Marlow
Priority: Blocker
Attachments: error.log, jpa-war.tar.gz, pgsql.driver.tar.gz, standalone-full.diff
Basically WildFly is unable to either build the persistence context or it fails to query postgres db.
The changes are so minimal that it should basically work.
Attached:
# error.log - exception in the server log
# jpa-war.tar.gz - maven module that can be used to reproduce the issue
# pgsql.module.tar.gz - postgres driver module that can be unpacked under modules/system/layers/base/org/postgresql
# standalone-full.diff - diff that can be applied to standalone-full.xml to define required datasource
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4099) Prevent failures due to MSC-240 in 'critical' code
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4099?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4099:
-------------------------------------
Description:
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4090 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
A possible fix for this is simply incorporating an MSC release that has MSC-240 adequately resolved. (Note that adequate doesn't mean completely fixed; simply preventing problems in the methods annotated as CRITICAL is sufficient.) Barring that a fix would be to avoid or deal with the UOE.
was:
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4090 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
> Prevent failures due to MSC-240 in 'critical' code
> --------------------------------------------------
>
> Key: WFCORE-4099
> URL: https://issues.jboss.org/browse/WFCORE-4099
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 6.0.2.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
> Attachments: ServiceBuilderusage.txt
>
>
> As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
> WFCORE-4090 is an example of such a failure.
> I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
> A possible fix for this is simply incorporating an MSC release that has MSC-240 adequately resolved. (Note that adequate doesn't mean completely fixed; simply preventing problems in the methods annotated as CRITICAL is sufficient.) Barring that a fix would be to avoid or deal with the UOE.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4100) Prevent failures due to MSC-240 in 'critical' code
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-4100:
----------------------------------------
Summary: Prevent failures due to MSC-240 in 'critical' code
Key: WFCORE-4100
URL: https://issues.jboss.org/browse/WFCORE-4100
Project: WildFly Core
Issue Type: Bug
Components: Management, Server
Affects Versions: 6.0.2.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Blocker
Attachments: ServiceBuilderusage.txt
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4090 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
A possible fix for this is simply incorporating an MSC release that has MSC-240 adequately resolved. (Note that adequate doesn't mean completely fixed; simply preventing problems in the methods annotated as CRITICAL is sufficient.) Barring that a fix would be to avoid or deal with the UOE.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4099) Prevent failures due to MSC-240 in 'critical' code
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4099?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4099:
-------------------------------------
Attachment: ServiceBuilderusage.txt
> Prevent failures due to MSC-240 in 'critical' code
> --------------------------------------------------
>
> Key: WFCORE-4099
> URL: https://issues.jboss.org/browse/WFCORE-4099
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 6.0.2.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
> Attachments: ServiceBuilderusage.txt
>
>
> As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
> WFCORE-4090 is an example of such a failure.
> I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4099) Prevent failures due to MSC-240 in 'critical' code
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4099?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-4099:
-------------------------------------
Description:
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4090 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
was:
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4040 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
> Prevent failures due to MSC-240 in 'critical' code
> --------------------------------------------------
>
> Key: WFCORE-4099
> URL: https://issues.jboss.org/browse/WFCORE-4099
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Server
> Affects Versions: 6.0.2.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
>
> As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
> WFCORE-4090 is an example of such a failure.
> I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4099) Prevent failures due to MSC-240 in 'critical' code
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-4099:
----------------------------------------
Summary: Prevent failures due to MSC-240 in 'critical' code
Key: WFCORE-4099
URL: https://issues.jboss.org/browse/WFCORE-4099
Project: WildFly Core
Issue Type: Bug
Components: Management, Server
Affects Versions: 6.0.2.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Blocker
As discussed in MSC-240, different impls of the MSC ServiceBuilder interface will support different subsets of the ServiceBuilder API, throwing UnsupportedOperationException if methods not in that subset are invoked. This makes code that accepts an SB from unknown origins vulnerable to failure if the wrong type of SB is passed in.
WFCORE-4040 is an example of such a failure.
I've done an analysis WildFly and WildFly Core use of ServiceBuilder looking for problematic cases. I will attach the analysis. This JIRA is to fix the items in WF Core that are annotated with the CRITICAL notation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JBEE-197) ModuleNotFoundException: org.jboss.resteasy.resteasy-jaxrs-api:main
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBEE-197?page=com.atlassian.jira.plugin.s... ]
Alessio Soldano updated JBEE-197:
---------------------------------
Forum Reference: https://developer.jboss.org/message/985011
> ModuleNotFoundException: org.jboss.resteasy.resteasy-jaxrs-api:main
> -------------------------------------------------------------------
>
> Key: JBEE-197
> URL: https://issues.jboss.org/browse/JBEE-197
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxrs-api
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
>
> {noformat}
> java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
> at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:146)
> at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:89)
> at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:49)
> at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:21)
> at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:144)
> ... 17 more
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:103)
> at com.github.dockerjava.jaxrs.JerseyDockerCmdExecFactory.init(JerseyDockerCmdExecFactory.java:229)
> at com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:161)
> at com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:47)
> at org.arquillian.cube.docker.impl.util.DefaultDocker.getDefaultDockerClient(DefaultDocker.java:13)
> at org.arquillian.cube.docker.impl.client.CubeDockerConfigurationResolver.resolveSystemDefaultSetup(CubeDockerConfigurationResolver.java:217)
> at org.arquillian.cube.docker.impl.client.CubeDockerConfigurationResolver.resolve(CubeDockerConfigurationResolver.java:70)
> at org.arquillian.cube.docker.impl.client.CubeDockerConfigurator.configure(CubeDockerConfigurator.java:82)
> at org.arquillian.cube.docker.impl.client.CubeDockerConfigurator.configure(CubeDockerConfigurator.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.ManagerImpl.bindAndFire(ManagerImpl.java:232)
> at org.jboss.arquillian.core.impl.InstanceImpl.set(InstanceImpl.java:67)
> at org.arquillian.cube.impl.client.CubeConfigurator.configure(CubeConfigurator.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.ManagerImpl.bindAndFire(ManagerImpl.java:232)
> at org.jboss.arquillian.core.impl.InstanceImpl.set(InstanceImpl.java:67)
> at org.jboss.arquillian.config.impl.extension.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.ManagerImpl.start(ManagerImpl.java:253)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.<init>(EventTestRunnerAdaptor.java:61)
> ... 22 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at javax.ws.rs.client.FactoryFinder.getModuleClassLoader(FactoryFinder.java:258)
> at javax.ws.rs.client.FactoryFinder.find(FactoryFinder.java:203)
> at javax.ws.rs.client.ClientBuilder.newBuilder(ClientBuilder.java:87)
> ... 65 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at javax.ws.rs.client.FactoryFinder.getModuleClassLoader(FactoryFinder.java:250)
> ... 67 more
> Caused by: org.jboss.modules.ModuleNotFoundException: org.jboss.resteasy.resteasy-jaxrs-api:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
> ... 72 more
> {noformat}
> The fix for JBEE-169 didn't consider the scenario in which JBoss Modules is actually available in the classpath, but the module is not there.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months