On 06/17/2010 04:30 PM, Costin Manolache wrote: > > > On Thu, Jun 17, 2010 at 12:56 AM, jean-frederic clere <jfcl...@gmail.com > <mailto:jfcl...@gmail.com>> wrote: > > On 06/16/2010 07:44 PM, Costin Manolache wrote: > > On Tue, Jun 15, 2010 at 11:14 PM, jean-frederic clere > <jfcl...@gmail.com <mailto:jfcl...@gmail.com>>wrote: > > > >> On 06/16/2010 07:08 AM, Mladen Turk wrote: > >>> On 06/16/2010 12:34 AM, Costin Manolache wro te: > >>>> Hi, > >>>> > >>>> There are some methods in SSLContext to create and use a new > BIO. Are > >>>> there > >>>> any examples/tests for this ? I can't find how to attach the > BIO to a > >>>> socket, it seems SSL_set_bio is never called, can't figure what > >>>> SSLContext.setBIO() does. > >>>> > >>> > >>> I'd suggest you forget about those ;) > >>> > >>> SSL BIO allows to write a java code that will SSL use > >>> for read/write to the sockets. > >>> Jean-Frederic created those but cannot tell for what reason. > >> > >> The idea was to use java socket directly to have just the crypto > layer > >> done by SSL but tc-native went another way. > >> > > > > > > I know - it allows one to use OpenSSL like SSLEngine - without > doing the > > network > > IO trough OpenSSL. > > > > I'm not worried about the 4-5 extra JNI calls - we're talking > about slow > > encryption here. > > > > For tomcat-lite - JSSE is a dead end, there is no way to support > SPDY and a > > lot of other > > things are bad/missing ( i.e. most SSL extensions - hostname, session > > tickets, etc ). > > However I want to separate the I/O from the encryption. > > May be we should just start another native module so that we don't need > to use APR but only OpenSSL. > > > What do you mean by 'native module' ? I hope not another .so - it's hard > enough to deal with this > one. Build, install, documentations, deb/rpm, etc.
Well the actual tc-native.so depends on APR. I was thinking of something that depends only on Openssl. > > If you mean a separate directory - or just a set of files - that provide > only JNI for OpenSSL, without > dependencies to APR, or with minimal deps - I think it's a great idea. yep that would be great. > OpenSSL has its own portability layer, so it doesn't really need APR - > but there is no harm in having both in the same library. That is more packaging issues then development. > > The purpose of tc-native (IMHO) is to allow access to native libraries > that provide better implementation than the Java one, or provide things > that are not available in java. I think the original plan was to have it > as a very thin layer - exposing as closely as possible the native > library, up to pointers and alloc/free. > > But short term - either remove BIO if it's broken ( no point on having > it if it can't be used), or better we should fix it and add a test. Ok if we think we should go for a possibly thinner layer we should fix it and provide examples. Cheers Jean-Frederic --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
