Raul, also +1 for having a global setting available. Thus I would then use the following algorithm:
- first check if a provider was set using XMLSignature / XMLCipher setJCEprovider method, if set use this an propgate it to the other implemntation classes. - If no specific provider was set, check for a global setting and use it in the same way as for the specific setting - otherwise do nothing, that is use standard provider Thoughts? Regards, Werner > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Raul Benito > Gesendet: Dienstag, 21. März 2006 10:41 > An: [email protected] > Betreff: Re: [xml-sec] Some thought about the JCE provider > > +1 to me.... > But as user I also think it will be very good to have a global(over > writable) configuration like we have right now. I should check the > provider at position 2. But I think we should add this info in the > xml-sec FAQ... > > Regards, > > Raul > > On 3/21/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > -- > http://r-bg.com >
