method signature issue in xmlsec 2.2.0

[Ian Young]

Hi there,

I have been looking at upgrading our xmlsec dependency to 2.2.0, on the basis 
that at some point the 2.1.x series will lose support. Is that already the 
case? Not obvious from the web site at present.

Anyway, I ran into an issue with method signatures that I am not sure was 
intended in 2.2.0. It seems to have come about from this issue:

https://issues.apache.org/jira/browse/SANTUARIO-522 "Refactor encryption 
Serializers"

This resulted in commit 5259754cbda006d440ca2787ff59d78878c0df6d "SANTUARIO-522 
- Make Serializer final in XMLCipher"

Amongst other changes, this added a method with the following signature:

    public static XMLCipher getProviderInstance(
        String transformation, String provider, Serializer serializer, String 
digestMethod
    )

This has a very similar signature to a method we've been using:

   /**
     * Returns an <code>XMLCipher</code> that implements the specified
     * transformation, operates on the specified context document and serializes
     * the document with the specified canonicalization algorithm before it
     * encrypts the document.
     * <p>
     *
     * @param transformation    the name of the transformation
     * @param provider          the JCE provider that supplies the 
transformation
     * @param canon             the name of the c14n algorithm, if 
<code>null</code> use standard
     *                          serializer
     * @param digestMethod      An optional digestMethod to use
     * @return the XMLCipher
     * @throws XMLEncryptionException
     */
    public static XMLCipher getProviderInstance(
        String transformation, String provider, String canon, String 
digestMethod
    )

Specifically, if you're passing canon=`null` to the pre-existing method (which 
is explicitly contemplated in its Javadoc), the compiler can't distinguish 
these two signatures and refuses to compile your code if you upgrade to 2.2.0.

It doesn't seem to me as if this was intentional (given the Javadoc allows the 
original method to be passed a `null`), and the Jira ticket doesn't discuss 
adding new methods. I guess I'd be interested to know what the thinking was 
here, whether this was intentional and whether it might make sense to fix the 
regression in a future 2.2.x release.

Cheers,

    -- Ian

smime.p7s
Description: S/MIME cryptographic signature