Raul, to define it explicitly I would not modify existing method signature but add a new method for XMLSignature and XMLCipher to set a provider, somthing like "setJCEProvider(String id)" .
This way the implementation can check and propagate the info to other classes is required. Defining a specific provider may be required if the application that uses XMLSignature or XMLCipher is not authorized to register new JCE providers but have the requirement to use a specific JCE provider, maybe because of some specific implementation of an algorithm. Of course, if no JCEProvider was set the standard provider will be used. Just as a note: When registering a new JCE provider never ever insert it at position 1 - this position seems to be resereved by Sun for the provider that validates the JCE provider jar file. This provider does not have other methods. Registering a new provider at position 2 is ok. Doing so guarantees that this provider will be used if it provides the necessary algorithm. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Raul Benito > Gesendet: Montag, 20. März 2006 18:31 > An: [email protected] > Betreff: Re: [xml-sec] Some thought about the JCE provider > > Hi Werner, > > I have been thinking about your proposal I don't see how it's > possible to implement your second approach without changing the public > API (a see the biggest problem while verifying). But I'm sure you > already have an idea. Can you share with me? > > Regards, > > Raul > > On 3/12/06, Werner Dittmann <[EMAIL PROTECTED]> wrote: > > All, > > > > currently xml-sec use two different ways to specify which provider > > to use for a specific algorithm: > > > > 1. Set the provider id is a class variable in JCEMapper. An explicit > > check must be made to see if the provider id is set and > then use it. > > > > 2. The XMLCipher uses different getInstance(...) methods to specify > > a provider. Thus it is sort of an explicit definition. > > > > Porposal: Use only one way to specify a JCE provider. I would opt > > for the second way (definie ti explicitly). For some time we could > > declare the "old" method as deprecated. > > > > In that sens I would also propose to implement a sort of fallback > > mechanisms if the specified provider is either not avaliable or does > > not provider the required algorithm. In such a case > > > > - issue a "log.warning" message (not an error) and > > > > - fallback to a standard provider. Only if this also fails throw an > > exception. > > > > What do you think? > > > > Regards, > > Werner > > > > > -- > http://r-bg.com >
