In short: - When running Tomcat on Windows, if current directory (when starting Tomcat) is not $CATALINA_HOME\bin then the tcnative-1.dll is not found. The default "java.library.path" on Windows includes "." current directory, but does not include "$CATALINA_HOME\bin". My main concern is running Tomcat as a Server in Eclipse IDE. Steps to reproduce: 1. Download and unzip apache-tomcat-8.5.23-windows-<arch>.zip 2. Download, install and run Eclipse IDE for Java EE developers (I am using Neon.3 aka 4.6.3) 3. Create a Tomcat 8.5 server in the IDE https://wiki.apache.org/tomcat/FAQ/Developing#Q6 (Window > Show view > Other... > Server/Servers, add a new server) 4. Start it Result: [[[ Oct 18, 2017 4:17:59 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [...;;D:\eclipse_4_6;;.] ]]] In Eclipse the default working directory when running a new server is the same as default working directory of Eclipse IDE. In my case: "D:\eclipse_4_6" Possible ways to resolve this: a. Improve documentation. Add a note and a recipe to https://tomcat.apache.org/tomcat-8.5-doc/apr.html#Windows and https://wiki.apache.org/tomcat/FAQ/Developing#Q6 b. Implement some way to search for tcnative-1.dll in ${catalina.home}/bin ?
> b. Implement some way to search for tcnative-1.dll in ${catalina.home}/bin ? For this solution I thought that maybe 1. Allow to configure an explicit path to the dll in AprLifecycleListener 2. Use System.load(filename) call to load the library from an explicitly specified filename. The current code (in org.apache.tomcat.jni.Library) calls a different method - System.loadLibrary(name). Generally, loading a DDL from an explicit path is better than performing a search. A deficiency in this solution is that such configuration is specific to Microsoft Windows. It cannot be included in the default *.zip download of Apache Tomcat, but it can be included "Windows" flavors of zip downloads.
> a. Improve documentation. Add a note and a recipe to My recipe is to configure "java.library.path" explicitly. For running Tomcat in Eclipse IDE the steps are the following: 1. Open edit dialog for the Server (In "Servers" view select the server and double-click it or press "F3" (Open)) See http://markmail.org/message/7zkyocvph56b6t6q 2. Click "Open launch configuration" link An "Edit launch configuration properties" dialog opens. 3. Switch to "Arguments" tab and edit "VM arguments". Add -Djava.library.path="<your path of catalina.home>\bin"
For 56676, I added bin/native as a default location for tcnative. So ... : - The default location can be changed to just "bin" and the testsuite should be adjusted to reflect that - The installer/zip should now install to bin/native to avoid the issue Decision ? Personally, I prefer bin/native to avoid polluting my bin folder.
I am strongly +1 for being consistent with the native library location across the test suite, the installer and the other distributions. I'm neutral on whether it should be bin or bin/native bin - is what we use currently - minimal change for existing users - adds 'clutter' to the dir contents bin/native - new location - change for existing users - cleaner/neater I can see pros and cons of both. I still don't have a preference one way or the other.
(In reply to Mark Thomas from comment #4) > bin/native > - new location I didn't make it up, it's really used by the testsuite, line 82 of build.xml: <property name="test.apr.loc" value="${test.basedir}/bin/native"/> But it's not a real "user", so I'll change it.
Should be fixed in 9.0.11, although I didn't verify Windows.
But it broke CI, since it would be using the old location. The test.apr.loc property can be changed in the env there (but I don't know how to do it).
The problem (on buildbot) is that bin/native did not exist so the test for APR failed (it looks for the directory) so the APR tests did not run. With this change the dir does exist, so the APR tests run and then fail because the APR lib is not present. I'll see if I can get the native lib built and configured for buildbot.
Buildbot fixed. We might want to revisit the change to test.apr.loc since changing to a directory that exists by default enables the APR test run which then fails when APR is not present.