OK guys,
I think that the approach of using BC directly is not the right one.
Instead, I've just committed all that's needed for us to avoid globally
registering a Provider.
Now, in this process I also found out the reason why I had it like I did
earlier - namely, many of the methods in the BC CMS package takes a
provider String, but not a Provider instance. And there is in fact a few
places in java.security that does the same thing. Very annoying. The
problem is - for the string to work, the provider named needs to be
globally registered.
I have taken a fairly brute force approach to this problem - namely
implementing a method that will insert the provider, run the code in
question, and the remove the provider directly after that. It works and
all tests pass (except for the Cipher one, and I think we might just
revert that).
This solves the problem of the sideways memory leak, and is also a
smaller thing to implement than the wholesale conversion to BC directly.
(I especially fear that the x509store things will be a real pain)
Any objections to this approach? Charles, what say you to reverting
Cipher and see if we can get all tests passing?
Cheers
--
Ola Bini (http://ola-bini.blogspot.com)
JRuby Core Developer
Developer, ThoughtWorks Studios (http://studios.thoughtworks.com)
Practical JRuby on Rails (http://apress.com/book/view/9781590598818)
"Yields falsehood when quined" yields falsehood when quined.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
