[JBoss JIRA] (WFCORE-4266) Classes for newer versions are not loaded from Multi-Release-JARs in WARs
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFCORE-4266?page=com.atlassian.jira.plugi... ]
Ilia Vassilev updated WFCORE-4266:
----------------------------------
Labels: downstream_dependency (was: )
> Classes for newer versions are not loaded from Multi-Release-JARs in WARs
> -------------------------------------------------------------------------
>
> Key: WFCORE-4266
> URL: https://issues.jboss.org/browse/WFCORE-4266
> Project: WildFly Core
> Issue Type: Bug
> Components: VFS
> Environment: Java 9+
> Reporter: Daniel Schwering
> Assignee: David Lloyd
> Priority: Major
> Labels: downstream_dependency
> Fix For: 8.0.0.Beta3, 8.0.0.Final
>
> Attachments: buggywar.src.zip, buggywar.war, multireleaselib-0.0.1-SNAPSHOT.jar, multireleaselib-0.0.1-SNAPSHOT.jar, multireleaselib.src.zip, multireleaselib.src.zip
>
>
> 1
> down vote
> favorite
> Since Java 9 there are Multi-Release JARs ([MRJARS|https://openjdk.java.net/jeps/238]) that allow different classes for different Java versions to be included in one JAR file. I was surprised when a Wildfly 14 running on Java 11 executed Java-8-code in a JAR included in a WAR although the JAR was a MRJAR with code for Java 11. That JAR included as a dependency for a regular Java SE project is running different code depending on the running JRE, but when included in a WAR, the Java-11-code seems to be ignored.
> Is that expected behavior for a webserver, as Java EE 8 does not explicitly require Java 9 (which introduced MRJARs) but only Java 8?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Ilia Vassilev updated WFLY-11489:
---------------------------------
Labels: downstream_dependency (was: )
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Fix For: 17.0.0.Beta1
>
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10725) Repeating WARN log message "Notified of connection failure" after every xa recovery when read-timeout is configure with a smaller value than default client-failure-check-period (30 seconds)
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFLY-10725?page=com.atlassian.jira.plugin... ]
Ilia Vassilev updated WFLY-10725:
---------------------------------
Labels: downstream_dependency (was: )
> Repeating WARN log message "Notified of connection failure" after every xa recovery when read-timeout is configure with a smaller value than default client-failure-check-period (30 seconds)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10725
> URL: https://issues.jboss.org/browse/WFLY-10725
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Final
> Environment: - two JBoss EAP instances which are based on standalone-full.xml
> - one instance is configured as JMS server, which has {{read-timeout}} setting on the undertow {{http-listener}} and the specified value is smaller than *default* {{client-failure-check-period}} (30 seconds)
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
> <server name="default">
> <security enabled="false"/>
> ...
> <http-acceptor name="http-jms-acceptor" http-listener="default"/>
> <jms-queue name="jms.TEST" entries="java:jboss/exported/jms.TEST"/>
> </server>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:undertow:4.0">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" read-timeout="5000"/> <!-- this issue happens when a smaller value than *default* client-failure-check-period (30 seconds) is specified to read-timeout. -->
> ...
> </server>
> ...
> </subsystem>
> {code}
> - another instance is configured as JMS client, which connects to the remote JMS server using {{pooled-connection-factory}}
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
> <server name="default">
> <security enabled="false"/>
> ...
> <http-connector name="remote-http-jms-connector" endpoint="http-jms-acceptor" socket-binding="jms-remote-server"/>
> <pooled-connection-factory name="remote-jms.TEST" entries="java:/jms/jms.TEST" connectors="remote-http-jms-connector" client-failure-check-period="4000"/> <!-- this issue happens even if client-failure-check-period is configured with a smaller value than read-timeout -->
> </server>
> </subsystem>
> {code}
> Reporter: Masafumi Miura
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Labels: downstream_dependency
> Attachments: config-to-reproduce.zip
>
>
> With the above configuration, The following WARN log message "{{Notified of connection failure ...: ActiveMQNotConnectedException\[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected\]}}" is thrown when passing {{read-timeout}} (5 seconds in the above config) after every xa recovery:
> {code}
> 14:38:41,362 WARN [org.jboss.activemq.artemis.wildfly.integration.recovery] (Thread-1 (ActiveMQ-client-global-threads)) Notified of connection failure in xa discovery, we will retry on the next recovery: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:956)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 14:38:41,392 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Thread-1 (ActiveMQ-client-global-threads)) AMQ122014: Notified of connection failure in xa recovery connectionFactory for provider org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@4f7f708 will attempt reconnect on next pass: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:956)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 14:38:51,402 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Thread-1 (ActiveMQ-client-global-threads)) AMQ122014: Notified of connection failure in xa recovery connectionFactory for provider org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@49e1f93a will attempt reconnect on next pass: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:956)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Note that this happens even if {{client-failure-check-period}} is configured with a smaller value than {{read-timeout}} on the {{pooled-connection-factory}} in the JMS client instance.
> From the byteman debug, it looks {{org.jboss.activemq.artemis.wildfly.integration.recovery.WildFlyRecoveryDiscovery#start}} and {{org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper#connect}} does not use the parameters specified on the {{pooled-connection-factory}} (like {{client-failure-check-period}} and {{connection-ttl}}). So, it uses the default values. Hence, {{read-timeout}} will close the connection due to inactivity on the server side and this WARN log message is thrown on the client.
> A new connection can be established correctly on the next xa recovery, so I think this WARN log message can be ignored. However, if xa recovery can establish a connection with the configured parameters (like {{client-failure-check-period}} and {{connection-ttl}}) on {{pooled-connection-factory}}, we can avoid this WARN log message by setting a smaller value to {{client-failure-check-period}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-10808) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFLY-10808?page=com.atlassian.jira.plugin... ]
Ilia Vassilev updated WFLY-10808:
---------------------------------
Labels: downstream_dependency (was: )
> Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10808
> URL: https://issues.jboss.org/browse/WFLY-10808
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Reporter: Joshua Swett
> Assignee: Bartosz Baranowski
> Priority: Minor
> Labels: downstream_dependency
> Fix For: 16.0.0.Beta1, 16.0.0.Final
>
> Attachments: TestWAR.war
>
>
> The jboss-ejb-client.xml deployment descriptor file can be used to configure the pass semantics of the local EJB receiver using the local-receiver-pass-by-value attribute.
> As per the EJB spec, the default behaviour should be to pass by value, and this is appropriately reflected in the jboss-ejb-client XSD. As of Wildfly 11, the *omission* of the local-receiver-pass-by-value attribute in a jboss-ejb-client deployment descriptor actually results in remote EJB parameters and the return value being passed by reference as opposed to the documented default of being passed by value.
> It appears that this bug is a result of changes made for WFLY-5403. The root cause is that the EJBClientDescriptorMetaDataProcessor.java class only uses the pass-by-value receiver if the local-receiver-pass-by-value attribute is Boolean.TRUE (line 177 in 13.0.0.Final), but EJBClientDescriptor10Parser.java defaults the value to null if it is not included in the jboss-ejb-client.xml (line 132 in 13.0.0.Final). The old and working behaviour was to fallback to the value configured at the ejb subsystem level if the jboss-ejb-client.xml excluded the attribute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFCORE-4265) Latest DB2 11.1 JDBC driver requires additional IBM JDK system dependency
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFCORE-4265?page=com.atlassian.jira.plugi... ]
Ilia Vassilev updated WFCORE-4265:
----------------------------------
Labels: downstream_dependency (was: )
> Latest DB2 11.1 JDBC driver requires additional IBM JDK system dependency
> -------------------------------------------------------------------------
>
> Key: WFCORE-4265
> URL: https://issues.jboss.org/browse/WFCORE-4265
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Environment: IBM DB2 11.1 JDBC driver (version 4.24.92)
> IBM JDK 8:
> {noformat}
> $ java -version
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 8.0.5.22 - pxa6480sr5fp22-20180919_01(SR5 FP22))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20180915_397057 (JIT enabled, AOT enabled)
> OpenJ9 - 6c152c2
> OMR - 15647c3
> IBM - d734883)
> JCL - 20180821_01 based on Oracle jdk8u181-b12
> {noformat}
> Reporter: Martin Simka
> Assignee: Lin Gao
> Priority: Critical
> Labels: downstream_dependency
> Fix For: 8.0.0.Beta2, 8.0.0.Final
>
>
> Running on IBM JDK 8 latest DB2 11.1 JDBC driver (version 4.24.92) fails to connect to database with error:
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: com/ibm/dataaccess/ByteArrayUnmarshaller
> at com.ibm.db2.jcc.a.j.h(j.java:21)
> at com.ibm.db2.jcc.a.i.g(i.java:151)
> at com.ibm.db2.jcc.a.i.b(i.java:76)
> at com.ibm.db2.jcc.t4.y.q(y.java:1373)
> at com.ibm.db2.jcc.t4.z.c(z.java:4792)
> at com.ibm.db2.jcc.t4.z.b(z.java:4740)
> at com.ibm.db2.jcc.t4.z.a(z.java:4726)
> at com.ibm.db2.jcc.t4.z.l(z.java:547)
> at com.ibm.db2.jcc.t4.z.d(z.java:153)
> at com.ibm.db2.jcc.t4.b.k(b.java:1442)
> at com.ibm.db2.jcc.t4.b.b(b.java:1354)
> at com.ibm.db2.jcc.t4.b.a(b.java:6687)
> at com.ibm.db2.jcc.t4.b.b(b.java:888)
> ... 244 more
> {noformat}
> It doesn't matter whether driver is installed as module or deployed to deployments folder.
> DB2 11.1 driver versions
> || Driver version|| status ||
> | 4.21.29 | OK |
> | 4.22.29 | OK |
> | 4.23.42 | Fail |
> | 4.24.92 | Fail |
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months