On Fri, 12 Apr 2002, Pier Fumagalli wrote: > The _ONLY_ solution is to either force a GLOBAL loading of (let's say) APR > by a third library which is loaded LOCALLY and loads APR globally (a let's > say JNI->APR liaison) but at that point the linkage may fail, and you have > to handle all the cases when this happens, or to preload the library at > startup, either by linking your executable binary with the required library, > or using the LD_PRELOAD environment variable. If things get messy at that > point, the kernel will simply avoid to even start the process, and exit.
As long as the LD_LIBRARY_PATH is correct, or the libraries are in the right places and not duplicated - things should work fine on any system. We have a standard JNI library, which depends on various libraries ( including APR ). There is no trick or special case here - just plain JNI and plain C code. I a java VM or OS can't load JNI code - or can't load JNI code that depends on other libraries - it is broken, and we'll not use JNI with it. ( unless we find a workaround for that specific platform - PRELOAD may be a solution, or creating a wrapper library that loads and register functions ). AFAIK loading a JNI library that depends on other libs works on most platforms and OSes ( Solaris, Linux, Windows for sure ). What doesn't work well are tricks like loading libraries from non-standard locations or withoug a LD_LIBRARY_PATH. So my proposal for JK/JNI and it's APR dependencies is simple - use LD_LIBRARY_PATH and the most standard JNI. We do need APR and native code to support some advanced features - but none of that is required for normal functioning of jk, it just gives more performance and access to APR-exposed OS-specific features where possible. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
