Ola Bini wrote:
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).
Is it possible for us to implement those pieces that require a
registered provider using BC APIs directly?
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?
If the approach of passing in a provider for everything works for most
cases, what about modifying BC to accept provider where it doesn't now?
I would agree that if we can get everything working using JCE interfaces
passed an explicit provider, we'd be better off than any other solution.
I do not particularly like temporarily registering the provider since it
won't be thread/app safe and it's almost certain to bite us at some
point in the future.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
