[JBoss JIRA] (WFLY-13749) Add the bean-validation Galleon layer as an optional dependency for jpa and jpa-distributed Galleon layers
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13749:
-------------------------------------------
Summary: Add the bean-validation Galleon layer as an optional dependency for jpa and jpa-distributed Galleon layers
Key: WFLY-13749
URL: https://issues.redhat.com/browse/WFLY-13749
Project: WildFly
Issue Type: Task
Components: Build System, JPA / Hibernate
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Bean validation is not provisioned by default by the {{jpa}} / {{jpa-distributed}} Galleon layers. Users have to add this layer to their provisioning configuration to make Bean Validation work out of the box with a JPA deployment.
Adding the {{bean-validation}} Galleon layer to {{jpa}} / {{jpa-distributed}} Galleon layers will make bean validation work with a JPA application out of the box.
As a result of this task:
* If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, the deployment will succeed but bean validation won't work in the application code, because by default JPA uses ValidationMode.AUTO
* If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, and configures JPA with ValidationMode.CALLBACK, the deployment will fail because the persistent provider will thrown an exception.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13748) "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
by Julien Le Colloëc (Jira)
[ https://issues.redhat.com/browse/WFLY-13748?page=com.atlassian.jira.plugi... ]
Julien Le Colloëc updated WFLY-13748:
-------------------------------------
Description:
*Summary*: " Contains non-LDH ASCII characters " during any remote EJB call in IPV6 network on Kubernetes
*Problem Description*
We are doing EJB call from client container A to EJB located in container B. I reproduced this issue with two different remote EJB call.
Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
java.naming.provider.url=[https://my-server:8443/wildfly-services]
as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
My assumption is at some point in undertow wildfly code converts the hostname into a IPV6 adress.
*Other notes:*
• The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
• The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
• I can reproduce this issue with OpenJDK class SNIHostaneme with a local Junit using a IPV6 dummy adress [65:765]
{code:java}
public void testSNIHostName_Case_IPV6()
{
String hostname = "[65:765]";
SNIHostName sniHostname = new SNIHostName(hostname);
}
{code}
{noformat}
java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99){noformat}
It probably mean that in the following undertow code :
*Logs*
What we see in the log file of the client:
{{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more
2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
com.Exception: RemoteException while accessing ServiceRemote on cluster
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
.. 13 more
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more}}
*Other information:*
Java version:
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
Java arguments:
-Djava.net.preferIPv4Stack=false
Wildfly server version:
WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
was:
I'm seeing an issue with the 19.0.1.Final wildfly-client-all jar. I'm wondering if anyone else has seen the "Contains non-LDH ASCII characters" error when doing EJB call in docker IPV6 stack only environment. Should I raise a JIRA for this?
*Summary*: " Contains non-LDH ASCII characters " during remote EJB call; remote call failed with previous error
*Problem Description*
We are doing EJB call from client container A to EJB located in container B. I tested with two ejb call with or without arguments.
Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
java.naming.provider.url=https://my-server:8443/wildfly-services
as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
My assumption is at some point wildfly code converts the hostname into a IPV6 adress.
*Other notes:*
• The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
• The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
• Although I can reproduce this issue with OpenJDK class SNIHostaneme Junit locally, undertow may have to handle this case.
{{public void testSNIHostName_Case_IPV6() {String hostname = "[65:765]";SNIHostName sniHostname = new SNIHostName(hostname);}}}
{{java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)}}
*Logs*
What we see in the log file of the client:
{{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more
2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
com.Exception: RemoteException while accessing ServiceRemote on cluster
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
.. 13 more
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more}}
*Other information:*
Java version:
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
Java arguments:
-Djava.net.preferIPv4Stack=false
Wildfly server version:
WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
> "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
> --------------------------------------------------------------------------
>
> Key: WFLY-13748
> URL: https://issues.redhat.com/browse/WFLY-13748
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Julien Le Colloëc
> Assignee: Flavia Rainone
> Priority: Major
>
> *Summary*: " Contains non-LDH ASCII characters " during any remote EJB call in IPV6 network on Kubernetes
> *Problem Description*
> We are doing EJB call from client container A to EJB located in container B. I reproduced this issue with two different remote EJB call.
> Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
>
> The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
> java.naming.provider.url=[https://my-server:8443/wildfly-services]
> as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
> My assumption is at some point in undertow wildfly code converts the hostname into a IPV6 adress.
> *Other notes:*
> • The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
> • The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
> • I can reproduce this issue with OpenJDK class SNIHostaneme with a local Junit using a IPV6 dummy adress [65:765]
>
> {code:java}
> public void testSNIHostName_Case_IPV6()
> {
> String hostname = "[65:765]";
> SNIHostName sniHostname = new SNIHostName(hostname);
> }
> {code}
>
> {noformat}
> java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99){noformat}
> It probably mean that in the following undertow code :
>
>
>
> *Logs*
> What we see in the log file of the client:
> {{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
> 2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
> 2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
> 2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
> 2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
> 2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
> 2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
> 2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more
> 2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
> com.Exception: RemoteException while accessing ServiceRemote on cluster
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> .. 13 more
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more}}
> *Other information:*
> Java version:
> $ java -version
> openjdk version "1.8.0_252"
> OpenJDK Runtime Environment (build 1.8.0_252-b09)
> OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
> Java arguments:
> -Djava.net.preferIPv4Stack=false
> Wildfly server version:
> WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13748) "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13748?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13748:
------------------------------------
Component/s: EJB
> "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
> --------------------------------------------------------------------------
>
> Key: WFLY-13748
> URL: https://issues.redhat.com/browse/WFLY-13748
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Julien Le Colloëc
> Assignee: Flavia Rainone
> Priority: Major
>
> I'm seeing an issue with the 19.0.1.Final wildfly-client-all jar. I'm wondering if anyone else has seen the "Contains non-LDH ASCII characters" error when doing EJB call in docker IPV6 stack only environment. Should I raise a JIRA for this?
> *Summary*: " Contains non-LDH ASCII characters " during remote EJB call; remote call failed with previous error
> *Problem Description*
> We are doing EJB call from client container A to EJB located in container B. I tested with two ejb call with or without arguments.
> Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
>
> The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
> java.naming.provider.url=https://my-server:8443/wildfly-services
> as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
> My assumption is at some point wildfly code converts the hostname into a IPV6 adress.
> *Other notes:*
> • The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
> • The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
> • Although I can reproduce this issue with OpenJDK class SNIHostaneme Junit locally, undertow may have to handle this case.
> {{public void testSNIHostName_Case_IPV6() {String hostname = "[65:765]";SNIHostName sniHostname = new SNIHostName(hostname);}}}
> {{java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)}}
> *Logs*
> What we see in the log file of the client:
> {{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
> 2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
> 2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
> 2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
> 2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
> 2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
> 2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
> 2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more
> 2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
> com.Exception: RemoteException while accessing ServiceRemote on cluster
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> .. 13 more
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more}}
> *Other information:*
> Java version:
> $ java -version
> openjdk version "1.8.0_252"
> OpenJDK Runtime Environment (build 1.8.0_252-b09)
> OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
> Java arguments:
> -Djava.net.preferIPv4Stack=false
> Wildfly server version:
> WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13748) "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
by Julien Le Colloëc (Jira)
[ https://issues.redhat.com/browse/WFLY-13748?page=com.atlassian.jira.plugi... ]
Julien Le Colloëc updated WFLY-13748:
-------------------------------------
Summary: "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network (was: "Contains non-LDH ASCII" characters during remote call in IPV6 network)
> "Contains non-LDH ASCII" characters during remote EJB call in IPV6 network
> --------------------------------------------------------------------------
>
> Key: WFLY-13748
> URL: https://issues.redhat.com/browse/WFLY-13748
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.1.0.Final
> Reporter: Julien Le Colloëc
> Assignee: Flavia Rainone
> Priority: Major
>
> I'm seeing an issue with the 19.0.1.Final wildfly-client-all jar. I'm wondering if anyone else has seen the "Contains non-LDH ASCII characters" error when doing EJB call in docker IPV6 stack only environment. Should I raise a JIRA for this?
> *Summary*: " Contains non-LDH ASCII characters " during remote EJB call; remote call failed with previous error
> *Problem Description*
> We are doing EJB call from client container A to EJB located in container B. I tested with two ejb call with or without arguments.
> Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
>
> The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
> java.naming.provider.url=https://my-server:8443/wildfly-services
> as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
> My assumption is at some point wildfly code converts the hostname into a IPV6 adress.
> *Other notes:*
> • The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
> • The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
> • Although I can reproduce this issue with OpenJDK class SNIHostaneme Junit locally, undertow may have to handle this case.
> {{public void testSNIHostName_Case_IPV6() {String hostname = "[65:765]";SNIHostName sniHostname = new SNIHostName(hostname);}}}
> {{java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)}}
> *Logs*
> What we see in the log file of the client:
> {{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
> 2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
> 2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
> 2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
> 2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
> 2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
> 2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
> 2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more
> 2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
> com.Exception: RemoteException while accessing ServiceRemote on cluster
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
> at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
> at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
> at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
> at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
> at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
> at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
> at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
> at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
> 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)
> Caused by: java.rmi.RemoteException: Error; nested exception is:
> java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> at com.sun.proxy.$Proxy12.register(Unknown Source)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
> at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
> at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
> .. 13 more
> Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
> at java.net.IDN.toASCIIInternal(IDN.java:296)
> at java.net.IDN.toASCII(IDN.java:122)
> at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
> at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
> .. 4 more}}
> *Other information:*
> Java version:
> $ java -version
> openjdk version "1.8.0_252"
> OpenJDK Runtime Environment (build 1.8.0_252-b09)
> OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
> Java arguments:
> -Djava.net.preferIPv4Stack=false
> Wildfly server version:
> WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13748) "Contains non-LDH ASCII" characters during remote call in IPV6 network
by Julien Le Colloëc (Jira)
Julien Le Colloëc created WFLY-13748:
----------------------------------------
Summary: "Contains non-LDH ASCII" characters during remote call in IPV6 network
Key: WFLY-13748
URL: https://issues.redhat.com/browse/WFLY-13748
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 19.1.0.Final
Reporter: Julien Le Colloëc
Assignee: Flavia Rainone
I'm seeing an issue with the 19.0.1.Final wildfly-client-all jar. I'm wondering if anyone else has seen the "Contains non-LDH ASCII characters" error when doing EJB call in docker IPV6 stack only environment. Should I raise a JIRA for this?
*Summary*: " Contains non-LDH ASCII characters " during remote EJB call; remote call failed with previous error
*Problem Description*
We are doing EJB call from client container A to EJB located in container B. I tested with two ejb call with or without arguments.
Unfortunately, this is only happening on some of our servers. It's difficult to reproduce since we need Kubernetes/IPV6 stack only - and I don't have a test case for it locally.
The wildfly context use to get the ejb (javax.naming.InitialContext) in our app is using this url
java.naming.provider.url=https://my-server:8443/wildfly-services
as you can see the hostname is my-server. my-server does not have illegal characters and SNIHostName does not throw an exception when using it in a small unit test.
My assumption is at some point wildfly code converts the hostname into a IPV6 adress.
*Other notes:*
• The issue is seen on the client side. The client is a java standalone client. The issue is seen under kubernetes.
• The issue is seen with the 19.0.1.Final wildfly-client-all jar. It is also seen with 18.0.0.Final wildfly-client-all jar. It looks to me like an issue in SNIHostName(destinationURI.getHost()) in UndertowXnioSsl.
• Although I can reproduce this issue with OpenJDK class SNIHostaneme Junit locally, undertow may have to handle this case.
{{public void testSNIHostName_Case_IPV6() {String hostname = "[65:765]";SNIHostName sniHostname = new SNIHostName(hostname);}}}
{{java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)}}
*Logs*
What we see in the log file of the client:
{{2020-07-31 08:46:47,731 INFO [org.wildfly.naming] [RegistrationStateChangeNotification-pool-27-thread-1] WildFly Naming version 1.0.12.Final
2020-07-31 08:46:47,786 INFO [org.wildfly.security] [RegistrationStateChangeNotification-pool-27-thread-1] ELY00001: WildFly Elytron version 1.11.4.Final
2020-07-31 08:46:47,826 INFO [org.xnio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO version 3.7.7.Final
2020-07-31 08:46:47,837 INFO [org.xnio.nio] [RegistrationStateChangeNotification-pool-27-thread-1] XNIO NIO Implementation Version 3.7.7.Final
2020-07-31 08:46:47,868 INFO [org.jboss.threads] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Threads version 2.3.3.Final
2020-07-31 08:46:48,004 INFO [org.jboss.remoting] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss Remoting version 5.0.17.Final
2020-07-31 08:46:48,045 INFO [org.jboss.ejb.client] [RegistrationStateChangeNotification-pool-27-thread-1] JBoss EJB Client version 4.0.30.Final
2020-07-31 08:46:48,206 ERROR [com.application.lifecycle.internal.dataservice.ServiceImpl] [RegistrationStateChangeNotification-pool-27-thread-1] RemoteException while accessing ServiceRemote on cluster: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more
2020-07-31 08:46:48,208 WARN [com.application.lifecycle.internal.action.RegisterAction] [RegistrationStateChangeNotification-pool-27-thread-1] Failed to register with business tier. Retrying in 10 seconds.
com.Exception: RemoteException while accessing ServiceRemote on cluster
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.handleRemoteException(AbstractStatelessRemoteServiceProxy.java:112)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:130)
at com.application.lifecycle.internal.dataservice.ServiceImpl.register(ServiceImpl.java:38)
at com.application.lifecycle.internal.model.BusinessTierClusterModelImpl.register(BusinessTierClusterModelImpl.java:94)
at com.application.lifecycle.internal.action.RegisterAction.execute(RegisterAction.java:51)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.service.message.DelegatingMessageReceiver.delegate(DelegatingMessageReceiver.java:68)
at com.service.message.DelegatingMessageReceiver.receive(DelegatingMessageReceiver.java:50)
at com.af.app.message.DefaultMessageReceiver.execute(DefaultMessageReceiver.java:65)
at com.af.app.action.DefaultActionManager.executeRequest(DefaultActionManager.java:176)
at com.af.app.message.DefaultMessageReceiver.onMessage(DefaultMessageReceiver.java:154)
at com.af.app.impl.LocalMessageSenderImpl$SenderRunnable.run(LocalMessageSenderImpl.java:189)
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)
Caused by: java.rmi.RemoteException: Error; nested exception is:
java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:219)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
at com.sun.proxy.$Proxy12.register(Unknown Source)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:41)
at com.application.lifecycle.internal.dataservice.ServiceImpl$1.exec(ServiceImpl.java:38)
at com.service.remoteservice.AbstractStatelessRemoteServiceProxy.exec(AbstractStatelessRemoteServiceProxy.java:128)
.. 13 more
Caused by: java.io.IOException: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:450)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:416)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:333)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at io.undertow.protocols.ssl.UndertowXnioSsl$StreamConnectionChannelListener.handleEvent(UndertowXnioSsl.java:434)
.. 4 more}}
*Other information:*
Java version:
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
Java arguments:
-Djava.net.preferIPv4Stack=false
Wildfly server version:
WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13747) Add tests for the remoting layers
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13747:
---------------------------------------
Summary: Add tests for the remoting layers
Key: WFLY-13747
URL: https://issues.redhat.com/browse/WFLY-13747
Project: WildFly
Issue Type: Task
Components: Build System, Remoting, Test Suite
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
These layers are not valid in WildFly Core as they need Undertow to expose the http-connector.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13734:
-------------------------------------
{quote}
If the user excludes the bean-validation Galleon layer from jpa / jpa-distributed Galleon layers, and configures JPA with ValidationMode.CALLBACK, the deployment will fail because the persistent provider will thrown an exception.
{quote}
Correct, they will then either include bean-validation Galleon layer from jpa / jpa-distributed Galleon layers or stop using BeanValidation by switching to ValidationMode.NONE.
{quote}
Scott Marlow just wanted to confirm the following, I assume the JPA persistent provider is able to distinguish which ValidationMode has been configured, is this assumption correct?
{quote}
Yes, the JPA persistence provider is passed the same (javax.persistence.spi.PersistenceUnitInfo) "pu" variable which means the persistence provider can also call pu.getValidationMode() (it is also passed a "javax.persistence.validation.factory" property only if non-null).
{quote}
There is no distinction between the value the validatorFactory gets, it will be always null, when we don't have the "org.wildfly.bean-validation" capability and we are using either ValidationMode.CALLBACK or ValidationMode.AUTO. So the persistent provider should know that the configuration is ValidationMode.CALLBACK to throwing an exception.
{quote}
Correct, the persistence provider is responsible for throwing the exception for ValidationMode.CALLBACK and null validatorFactory.
> JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13734
> URL: https://issues.redhat.com/browse/WFLY-13734
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Major
> Fix For: No Release
>
>
> This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13746) Issues in MP REST Client QS README
by Martin Stefanko (Jira)
Martin Stefanko created WFLY-13746:
--------------------------------------
Summary: Issues in MP REST Client QS README
Key: WFLY-13746
URL: https://issues.redhat.com/browse/WFLY-13746
Project: WildFly
Issue Type: Bug
Components: Quickstarts
Affects Versions: 20.0.1.Final
Reporter: Martin Stefanko
Assignee: Martin Stefanko
# The JBoss Developer studio is mentioned in README (link to {{../shared-doc/run-the-quickstart-in-jboss-developer-studio.adoc}}) although it was renamed to Red Hat CodeReady Studio
# Line "...where ${version.microprofile.bom} is the full version of your JBoss EAP XP." - it would be nice to have an instruction how to find the version.
# Under "Setting up the model" header - "In this guide, we will be demonstrating how to consume a part of the REST API supplied by the country-server service which should be already deployed and running on your JBoss EAP XP server (check the introduction to this section)." - Which section? I found out this means text under "Creating the Maven Project", but it seems to me like I'm reading another section now. It also won't help that both headers use 2nd header level.
# In section "Configuring the REST client base URL/URI dynamically" there is example content of {{src/main/resources/META-INF/microprofile-config.properties}}. The first line should be "org.wildfly.quickstarts.microprofile.rest.client.CountriesServiceClient/mp-rest/url=[http://localhost:8080/country-server]".
# In section "Programmatic lookup" - the note says " You need to set the Java language level to 1.8 in order to use static interface method invocations." yet earlier it was already said, that user needs Java 1.8.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13674) WARN if deployment descriptor has ${...} but *property-replacement=false
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13674?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13674:
-----------------------------------------
The key value here IMHO is preventing deployments getting deployed that silently don't function as expected, so I don't think providing parsing context is a requirement. If expression resolution was enabled but the expression could not be resolved I don't think we provide such information when it fails. Providing the unresolved text should be sufficient to allow people to find the problem.
If it's reasonably straightforward to provide context, that's fine. Maybe the file name context is possible, as the code the associates the replacer with the parser might know. But I think providing the element/attribute name is likely too much as it would involve changing all the parsers to provide that data. Those parsers come from a variety of OSS projects, so getting consistent behavior would be a challenge.
I'm generally reluctant to add a lot of complexity and fragility to the server code in order to improve error messages reporting on user mistakes, beyond what's readily doable.
I think the scope of this would be the parsing that's governed by the two attributes on the EE subsystem, both spec and jboss.
> WARN if deployment descriptor has ${...} but *property-replacement=false
> ------------------------------------------------------------------------
>
> Key: WFLY-13674
> URL: https://issues.redhat.com/browse/WFLY-13674
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Affects Versions: 20.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Priority: Major
>
> WARN if deployment descriptor has ${...} but *property-replacement=false
> By default the property replacement defaults to true for jboss deployment descriptors and false for annotations and spec deployment descriptors:
>
> {code:java}
> "annotation-property-replacement" => false,
> "jboss-descriptor-property-replacement" => true,
> "spec-descriptor-property-replacement" => false, {code}
>
> In the persistence.xml for example, there is a freeform <properties> with properties that can change over time and default values. If *property-replacement is false , then ${...} is passed to the DUP to configure and can cause problems such as in this hibernate property which changed from default value of false to true and the user was unaware that system property substitution was not occurring because they had not enabled it.
>
> {code:java}
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence version="2.1"
> xmlns="http://xmlns.jcp.org/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
> <persistence-unit name=“example” transaction-type="JTA">
> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
> <properties>
> <property name="hibernate.cache.use_second_level_cache" value="${hibernate_cache.enabled:false}" />
> </properties>
> </persistence-unit>
> </persistence> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana commented on WFLY-13734:
---------------------------------------------
I think I misunderstood the point here. [~brian.stansberry], ignore my previous [#comment-14356058]
[~smarlow] My doubt was in relation to the need of adding the {{bean-validation}} Galleon layer to {{jpa}} / {{jpa-distributed}}. CDI is not a requirement to make bean validation to work. I understand we should add {{bean-validation}} Galleon layer as an optional dependency for {{jpa}} / {{jpa-distributed}} Galleon layers. That will allow the users, which are using a JPA application, to get by default the bean validation working for their deployments.
If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, the deployment will succeed but bean validation won't work in the application code.
If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, and configures JPA with ValidationMode.CALLBACK, the deployment will fail because the persistent provider will thrown an exception.
To sum up, adding the {{bean-validation}} Galleon layer to {{jpa}} / {{jpa-distributed}} Galleon layers will make bean validation work with a JPA application out of the box, which makes sense.
[~smarlow] just wanted to confirm the following, I assume the JPA persistent provider is able to distinguish which ValidationMode has been configured, is this assumption correct?
I'm asking because, looking at the common piece of code dealing with this on PersistenceUnitServiceHandler.java:
{code:java}
if (!ValidationMode.NONE.equals(pu.getValidationMode())) {
// Get the CDI-enabled ValidatorFactory
if (capabilitySupport.hasCapability("org.wildfly.bean-validation")) {
validatorFactory = deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY);
}
}
}
{code}
There is no distinction between the value the validatorFactory gets, it will be always null, when we don't have the "org.wildfly.bean-validation" capability and we are using either ValidationMode.CALLBACK or ValidationMode.AUTO. So the persistent provider should know that the configuration is ValidationMode.CALLBACK to throwing an exception.
> JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13734
> URL: https://issues.redhat.com/browse/WFLY-13734
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Major
> Fix For: No Release
>
>
> This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
- 1
- 0