[jboss-jira] [JBoss JIRA] (WFCORE-2056) wildfly-openssl - wfssl.dll is not automatically loaded on Windows

wildfly-openssl - wfssl.dll is not automatically loaded on Windows ------------------------------------------------------------------ Key: WFCORE-2056 URL: https://issues.jboss.org/browse/WFCORE-2056 Project: WildFly Core Issue Type: Bug Components: Security, Server Environment: Windows 8.1 Pro, 64b OpenSSL taken from JBCS 2.4.6 (OpenSSL 1.0.1e) Reporter: Stuart Douglas Assignee: Stuart Douglas Labels: wilfly-openssl It seems that libraries to support OpenSSL via {{wildfly-openssl}} does not bind automatically under the Windows right now. When I am on Linux, to setup OpenSSL, all I need to do is to have installed OpenSSL on my machine or provide path to my custom OpenSSL libs via "org.wildfly.openssl.path" property. Then I start EAP, set up "openssl.TLS" provider and I am ready to go. On windows although this seems to be a little bit complicated. When I start EAP with path to my OpenSSL libraries (JBCS OpenSSL) and set up "openssl.TLS" provider, after reload operation I get following error message: {code} 2016-11-28 12:27:44,512 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service jboss.server.controller.management.security_realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:108) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi) at java.security.Provider$Service.newInstance(Unknown Source) at sun.security.jca.GetInstance.getInstance(Unknown Source) at sun.security.jca.GetInstance.getInstance(Unknown Source) at javax.net.ssl.SSLContext.getInstance(Unknown Source) at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:97) ... 5 more Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.wildfly.openssl.SSL.init(SSL.java:81) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:119) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:427) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) ... 10 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.wildfly.openssl.SSL.init(SSL.java:76) ... 16 more Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:188) ... 21 more {code} It seems that "wfssl" library that serves to search and bind OpenSSL libs does not load automatically although it is already present as a module in EAP. When I specify also {{org.wildfly.openssl.libwfssl.path}} property with path to the {{wfssl.dll}} file in the EAP modules, then OpenSSL is successfully initialized during the EAP startup and https requests from clients seems to be working too. My expectation here is that when "wfssl.dll" library is present as a module in EAP on Windows, it is loaded automatically and user does not have to specify its location.