The jruby-openssl code already directly imports some of the BC code, and in other places explicitly passes the provider arg "BC" to the JCE interface.. So we wouldn't be creating a new dependency, it's already there. It would be *nice* if the provider were pluggable, but that isn't what we have now.
So I'd say the approach is fine (I was already looking at doing this for the DH impl, which I haven't quite finished), but will take some work. It might be easiest for now to stick (mostly) with the JCE interface, but just replace the various SomeJCEThingy.getInstance(xxx, "BC") calls with direct instantiation and/or retrieval of the corresponding BC class. If we all agree to this, I'll do this in the code I'm working on, but I can't commit now to doing this in the rest of the package. -Bill On Nov 30, 2007 8:11 AM, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote: > We've run into a problem with OpenSSL on some servers at Sun. Basically, > the problem goes like this: > > - multiple webapps launch that use jruby-openssl gem as part of Rails > stuff > - openssl creates a BC provider and registers it in Java security (each > webapp does this) > - when webapp undeploys, provider reference still exists, which prevents > the webapp's classloader from going away; over time this eventually > blows up permgen space > > It's pretty ugly. > > It appears the only really complete solution would be to replace all > invocations of JCE APIs (which depend on the provider being registered) > would be to invoke BouncyCastle APIs directly. This allows us to provide > OpenSSL functionality entirely independent of JCE, and avoids having > webapps register a provider at all. > > It's going to be a bit of work, so I wanted to toss it out there for > discussion, especially since Bill has said he's doing a bit of work on > OpenSSL for work. > > Thoughts? > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > >
