Upgrade to Java 17 , Wildfly 29.0.1 Causes exception Socket is closed

[tulips jay]

Hello,

We are migrating to java17 and wildfly29.0.1 . The application uses
Java 17, Wildfly 29.0.1, Jakarta ee 10 and Axis2 1.7.8 for webservices.

During webservice call getting an exception like following

17:27:04,912 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) I/O exception (java.net.SocketException) caught when processing request: Socket is closed
17:27:04,912 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) Retrying request
17:27:05,267 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) I/O exception (java.net.SocketException) caught when processing request: Socket is closed
17:27:05,268 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) Retrying request
17:27:05,629 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) I/O exception (java.net.SocketException) caught when processing request: Socket is closed
17:27:05,629 INFO [org.apache.commons.httpclient.HttpMethodDirector] (pool-25-thread-2) Retrying request
17:27:05,981 INFO [org.apache.axis2.transport.http.impl.httpclient3.HTTPSenderImpl] (pool-25-thread-2) Unable to sendViaPost to url[https://webservicesurl...]: java.net.SocketException: Socket is closed
at java.base/sun.security.ssl.SSLSocketImpl.getInputStream(SSLSocketImpl.java:883)
at deployment.webapp.war//org.apache.commons.ssl.HostnameVerifier$AbstractVerifier.check(HostnameVerifier.java:312)
at deployment.webapp.war//org.apache.commons.ssl.HostnameVerifier$AbstractVerifier.check(HostnameVerifier.java:253)
at deployment.webapp.war//org.apache.commons.ssl.SSL.doPostConnectSocketStuff(SSL.java:506)
at deployment.webapp.war//org.apache.commons.ssl.Java14.buildSocket(Java14.java:155)
at deployment.webapp.war//org.apache.commons.ssl.JavaImpl.createSocket(JavaImpl.java:206)
at deployment.webapp.war//org.apache.commons.ssl.SSL.createSocket(SSL.java:543)
at deployment.webapp.war//org.apache.commons.ssl.SSLClient.createSocket(SSLClient.java:221)
at deployment.webapp.war//org.apache.commons.ssl.HttpSecureProtocol.createSocket(HttpSecureProtocol.java:90)
at deployment.webapp.war//org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at deployment.webapp.war//org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at deployment.webapp.war//org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at deployment.webapp.war//org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at deployment.webapp.war//org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at deployment.webapp.war//org.apache.axis2.transport.http.impl.httpclient3.HTTPSenderImpl.executeMethod(HTTPSenderImpl.java:872)
at deployment.webapp.war//org.apache.axis2.transport.http.impl.httpclient3.HTTPSenderImpl.sendViaPost(HTTPSenderImpl.java:212)
at deployment.webapp.war//org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:121)
at deployment.webapp.war//org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:403)
at deployment.webapp.war//org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:234)
at deployment.webapp.war//org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:431)
at deployment.webapp.war//org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:399)
at deployment.webapp.war//org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:225)
at deployment.webapp.war//org.apache.axis2.client.OperationClient.execute(OperationClient.java:150)

Is this related to java  or wildlfy upgrade?

Thanks & regards

Jay

[Paul Ferraro]

Your issue seems to have nothing to do with WildFly, but rather with Apache Axis.  I suggest upgrading to a later version, e.g. 1.8.x.

[tulips jay]

Hello Paul,

Thank you very much for your reply!!!

As you said, We upgraded to axis 1.8.2, but got a runtime error like javax package classes not found

Caused by: java.lang.NoClassDefFoundError: javax/activation/DataSource
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.impl.stream.stax.pull.AxiomXMLStreamReaderHelper.<init>(AxiomXMLStreamReaderHelper.java:44)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.impl.stream.stax.pull.AxiomXMLStreamReaderHelperFactory.createHelper(AxiomXMLStreamReaderHelperFactory.java:34)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.core.stream.stax.pull.input.StAXPullInput.createReader(StAXPullInput.java:48)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.core.impl.builder.BuilderImpl.<init>(BuilderImpl.java:38)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.impl.common.factory.meta.BuilderFactory$1.createBuilder(BuilderFactory.java:46)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.impl.llom.factory.AxiomNodeFactoryImpl.createOMBuilder(Unknown Source)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.OMXMLBuilderFactory.createOMBuilder(OMXMLBuilderFactory.java:165)
12:34:31,904 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.OMXMLBuilderFactory.createOMBuilder(OMXMLBuilderFactory.java:145)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axiom.om.OMXMLBuilderFactory.createOMBuilder(OMXMLBuilderFactory.java:116)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.util.XMLUtils.toOM(XMLUtils.java:554)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.util.XMLUtils.toOM(XMLUtils.java:539)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.deployment.DescriptionBuilder.buildOM(DescriptionBuilder.java:97)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:90)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:628)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:116)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:64)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:210)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.client.ServiceClient.configureServiceClient(ServiceClient.java:151)
12:34:31,905 ERROR [stderr] (default task-8) at deployment.webapp.war//org.apache.axis2.client.ServiceClient.<init>(ServiceClient.java:143)
Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource from [Module "deployment.webapp.war" from Service Module Loader]
12:46:05,199 ERROR [stderr] (default task-3) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:200)
12:46:05,199 ERROR [stderr] (default task-3) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
12:46:05,199 ERROR [stderr] (default task-3) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
12:46:05,199 ERROR [stderr] (default task-3) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)

So continued to trouble shoot the issue while using  previous Axis2 1.7.8 version itself.

And the socket closed exception was due to the following error

Caused by: java.lang.IllegalAccessException: class org.apache.commons.ssl.Certificates$CRLHolder cannot access class sun.net.www.protocol.http.HttpURLConnection (in module java.base) because module java.base does not export sun.net.www.protocol.http to unnamed module.

It is seen that Issue is due to modular restriction (JDK-1.9 onwards) on sun.net.* packages , as they are internal to JDK.

As a solution added JAVA_OPTS in standalone.sh
--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED

Which solved the issue .

Is this a correct way to solve the above issue, do you have a suggestion?

Another case

To solve the following issue

java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: org/w3c/dom/css/CSSPrimitiveValue

added WEB_INF/jboss-deployment-structure.xml 

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">

<deployment>

<dependencies>

<system export="true">

<paths>

<path name="org/w3c/dom/css" />

</paths>

</system>

</dependencies>

</deployment>

</jboss-deployment-structure>

Is this case the same as above, like adding JAVA_OPTS --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED    ?

Thanks And Regards,

Jay

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/fe6b2279-2c95-438f-8162-0430aa635a0bn%40googlegroups.com.

[Paul Ferraro]

Ah - I did not realize that Apache Axis is not yet compatible with Jakarta EE 9/10.

You would need to either leverage https://github.com/wildfly-extras/deployment-transformer-feature-pack 
or use the Eclipse Transformer project https://github.com/eclipse/transformer to create a Jakarta variant of Apache Axis for use in your deployment.

Regarding your module restriction issue, using --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED is perfectly reasonable.

Regarding NoClassDefFoundError: org/w3c/dom/css/CSSPrimitiveValue, your solution is also correct.  Alternatively, you could also have specified the module dependency within your deployment's /META-INF/MANIFEST.MF

See: https://docs.wildfly.org/29/Developer_Guide.html#dependencies-manifest-entries