[jboss-jira] [JBoss JIRA] (AS7-2695) Package APR native libraries correctly

[ https://issues.jboss.org/browse/AS7-2695?page=com.atlassian.jira.plugin.s... ] Mladen Turk commented on AS7-2695: ---------------------------------- There are few technical reasons why having product/lib/${platform}-${arch}/native.so would create some issues. 1. Libraries with dependencies won't load because operating system library loader will look for libraries only on PATH,LD_LIBRARY_PATH,DYLD_LIBRARY_PATH which is usually reflected in java.library.path 2. From distribution PoV it makes sense only if you distribute the entire product as platform specific Eg. similar to what Eclipse does. 3. Most contemporary linux distributions already provide tomcat-native as installable package. Since it is stored inside system library it will load without any additional configuration (like Remy noted) It is usually optimized at compile time to a given platform. If we ship something this would have to be generic so it can work on any linux. Also linux distributions are much better in applying security fixes then we are. To solve #1 (dependency loading) jbossweb would have to go trough list of dependencies and load them in reverse order by using System.load and then call System.loadLibrary Luckily only libapr-1.so is a dependency. Again APR could either be provided by us or used from os distribution, so we are basically again at #3. Same would have to be done for any other native component. The logical solution is to setup LD_LIBRARY_PATH (java.library.path) before loading JVM in which case the dependencies are handled by operating system library loader. If you have to set it up, then the actual location where the libraries are stored is irrelevant since this is handled by the application bootstrap code. Enterprise distribution also contains additional modules so if we ship that the way you propose it would mean that we would have to load the isapi_redirect.dll or mod jk from C:\jboss\jboss-as7\whatever-product\lib\windows-i386\x.dll Since this is certainly not appropriate we would have to have multiple root directories which would request fix directory names. Other solution is to split the way how we distribute native enterprise packages. We would need to embed some binaries inside AS and some in a separate package (which would mean some libraries would have to be separate). Then there is a problem how to make .rpm out of that. Bottom line. It makes sense if you ship everything as a bundle (both java and native code) usually as a platform specific distribution. In theory this could be done by merging java distribution and *all* native distributions into a single package, which means the native package becomes product mandatory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira