On 8 July 2016 at 18:37, sebb <seb...@gmail.com> wrote: > 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 now works using MinGW to build the JNI library and a more recent OpenSSL DLL. > 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. The JNA code now works fine on Windows. I think the problem earlier was that the wrong DLL was being loaded. This should not cause a hang - that needs to be investigated. >> 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
