On 8 July 2016 at 18:31, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <van...@cloudera.com> wrote: > >> Answering based on old knowledge of this code, but I don't believe it >> has changed... >> >> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > The delivered jar file contains a native .so file, and this .so file is >> > _extracted_ and _installed_ on the user's machine at runtime? See >> > NativeCodeLoader.extractLibraryFile(). >> >> It's not really installed, but copied to a temp location. There might >> be flags to configure a permanent location (which would bypass this >> code that finds the library inside the jar), but I don't remember if >> that was added to crypto. >> >> This feature is borrowed from Snappy's java bindings, and is pretty >> helpful on distributed applications where a "launcher" app starts >> processes on a whole bunch of different machines (and needs these >> libraries). >> >> > Does this mean that the jar will contain all possible native formats >> (.so, >> > .dll, what about 32 vs. 64 bit, or are we only dealing with 64 bit?) and >> > extract the right one at runtime for the current platform? Seems wasteful >> > in space but portable and clever. >> >> That's the goal if multiple OSes are to be supported; I'm not sure how >> easy it would be to achieve with the current build system available >> (haven't really looked into it), but I have ideas of how to hack >> something like that in maven (using a few separate jobs per OS + a >> final job to collect everything). >> >> I've heard comments here about using JNA, so maybe this whole >> discussion will eventually become moot? >> > > The JNA code is in place, it's just much slower than the JNI path.
Have you managed to get it going on Windows? So far I have failed. It's tricky getting JNA to find the crypto DLL, and then it hangs for me on the ERR_load_crypto_strings() call. [Or it is so slow that it seems like it is hanging] I was able to get SSLeay_version(int type) working in a simple app that does not do the ERR_load call. But if I leave out the ERR_load from OpenSslNativeJna.java the tests still hang. > Gary > > >> >> -- >> Marcelo >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org