Hrm, it is an API change but a minor, single, well-localized one. I
would stay with 1.3.1 for this release. I haven't looked carefully at
the changes, but is there a reason you couldn't wrap API backwards
compatibility by doing something like (in X509CertificateResolver):
public boolean engineCanResolve(Element element, String BaseURI,
StorageResolver storage) {
// figure out what to resolve as X
X509Certificate cert = this.engineResolveX(element, baseURI, storage);
return cert != null;
}
This would be inefficient, and maybe obviously stupid and not worth it,
it all depends on how much hackery full API backwards compatibility
would be worth and whether this would work in the first place.
In my mind 1.4 would be including some new features (hopefully StAX
canonicalization!)
Chris
Raul Benito wrote:
Hi,
I'm planning to do a minor release of java xmlsec 1.3.1. The main
reason, is the bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=38605 , that hits
when the library is used in multithreads and use X509 resolvers,
resolving this has change slightly the API of the resolvers (see the
comment #3 in the bugzilla entry). But there are more bugfixes, and
some small optimizations (I don't like to do releases with
optimizations but this is how the things gone), The Changelog so far
is:
Fixed bug 38655
Fixed bug 38444.
Fixed bug 38605.
Fixed bug 39200
Refactored the way keyresolver works instead of calling
canResolve/resolveX only resolveX is used and if it returns null it
means it cannot resolve.
Minor Performance Opts(see http://r-bg.com/2005/Dec/26 &
http://r-bg.com/2006/Jan/14 for more info).
So what do you think of doing a release 1.3.1, or do you think the API
changes leads to a 1.4 release?
Regards,
Raul
--
http://r-bg.com
