On Fri, Jul 8, 2016 at 10:37 AM, 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? >
I have only tried running the unit tests which are either green or skipped. I am OK if we say we do not support Windows for 1.0. I am just concerned that we get the public API right to allow for both JNI and JNA, which should all be under the covers and hidden to the API user anyway. Gary > > 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 > > -- 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
