Error when deploying

Error when deploying

I'm receiving the following error when trying to deploy Connect on WildFly. My OS is Ubuntu Linux.

Invalid bean definition with name 'NhinDocRetrieve30' defined in null: Could not resolve placeholder 'nhinc.properties.dir' in string value \"file:///${nhinc.properties.dir}

The following is set in my standalone.conf file in the WildFly bin directory:
# configuration directory
JAVA_OPTS="$JAVA_OPTS -Dnhinc.properties.dir=/opt/bitnami/wildfly/modules/system/layers/base/org/connectopensource/configuration/main/"

Re: Error when deploying

OK, I was finally able to get the application deployed. Now I seem to be having an SSL configuration problem. I installed the CONNECT Admin GUI and the services are not available. PING fails.

While SSH'D into the server, I see the following when trying to connect:

20:52:11,565 ERROR [io.undertow.request] (default I/O-2) UT005086: Failed to accept SSL request: java.lang.IllegalStateException: SSLContextImpl is not initialized
at sun.security.ssl.SSLContextImpl.engineCreateSSLEngine(SSLContextImpl.java:200)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:258)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:159)
at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:60)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)

Re: Error when deploying

Thank you for the reply! Sure, I will post up my logs here shortly.

I should also note that the services are showing as unavailable in the CONNECT Admin GUI dashboard. When I try to ping them in the GUI under exchange services, the ping then shows as failed - you can see the error messages appear on the console (logged in via PUTTY). I have not tried a SOAPUI test as the Admin GUI shows them as non-functional at this time.

Re: Error when deploying

First, I'm seeing a bunch of read-time-outs when the server is launching.

Here's one example:

2018-07-18 21:06:25,973 WARN [org.apache.cxf.phase.PhaseInterceptorChain] (ServerService Thread Pool -- 70) Interceptor for {http://nhind.org/config}ConfigurationServiceService#{http://nhind.org/config}listDomains has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy263.listDomains(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokeTheMethod(WebServiceProxyHelper.java:279)
at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePort(WebServiceProxyHelper.java:359)
at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePortWithRetry(WebServiceProxyHelper.java:407)
at gov.hhs.fha.nhinc.webserviceproxy.WebServiceProxyHelper.invokePort(WebServiceProxyHelper.java:333)
at gov.hhs.fha.nhinc.messaging.client.CONNECTBaseClient.invokePort(CONNECTBaseClient.java:54)
at gov.hhs.fha.nhinc.admingui.proxy.DirectConfigProxyWebServiceUnsecuredCXFImpl.pingDirectConfig(DirectConfigProxyWebServiceUnsecuredCXFImpl.java:379)
at gov.hhs.fha.nhinc.admingui.display.DirectDisplayController.pingDirectConfig(DirectDisplayController.java:78)
at gov.hhs.fha.nhinc.admingui.display.DirectDisplayController.directConfigEnabled(DirectDisplayController.java:63)
at gov.hhs.fha.nhinc.admingui.display.DirectDisplayController.checkDisplay(DirectDisplayController.java:52)
at gov.hhs.fha.nhinc.admingui.servlet.InitServlet.init(InitServlet.java:46)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:300)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:140)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:579)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:550)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1526)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:592)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:1378)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking http://localhost:8080/CONNECTDirectConfig/ConfigurationService: Read timed out
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1377)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1361)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 47 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:332)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doProcessResponseCode(HTTPConduit.java:1578)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1607)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1551)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348)
... 50 more

This may or may not be related. They're not HTTPS endpoints though. This could be a configuration issue.

Setting that aside for a moment, these are followed by a pretty specific complaint that CONNECT can't find gateway.jks, which is its keystore. This is more directly tied to the problem you're describing:

2018-07-18 21:07:07,399 ERROR [io.undertow.request] (default I/O-4) UT005086: Failed to accept SSL request: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:231)
at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.engineCreateSSLEngine(SSLContextService.java:257)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:361)
at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:159)
at io.undertow.protocols.ssl.UndertowAcceptingSslChannel.accept(UndertowAcceptingSslChannel.java:60)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289)
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:131)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:202)
at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:164)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:131)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.getKeyManagers(AbstractKeyManagerService.java:110)
at org.jboss.as.domain.management.security.SSLContextService$LazyInitSSLContext$LazyInitSpi.doInit(SSLContextService.java:228)
... 12 more
Caused by: java.io.FileNotFoundException: /opt/bitnami/wildfly/opt/bitnami/wildfly/modules/system/layers/base/org/connectopensource/configuration/main/gateway.jks (No such file or directory)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
at org.jboss.as.domain.management.security.FileKeyManagerService.generateFileKeyStore(FileKeyManagerService.java:192)
... 16 more

This pairs up nicely with your complaint that the SSL Context is not initialized because 1) Most of the services are SSL (TLS) *required* to begin with, and 2) since CONNECT/wildfly can't find the keypair to use, it can't set up TLS/SSL.

Is gateway.jks present at the described file path?

If it is, this could be a permissions issue with the user that you're running wildfly as. If it's not, you may have missed a step in the initial deployment steps.