[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-security-dev
Subject:    DO NOT REPLY [Bug 40512]  - Fix incompatible API changes to TransformSpi
From:       bugzilla () apache ! org
Date:       2006-09-25 21:10:18
Message-ID: 20060925211018.70EAD71428E () brutus ! apache ! org
[Download RAW message or body]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40512>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40512





------- Additional Comments From sean.mullan@sun.com  2006-09-25 21:10 -------
(In reply to comment #5)
> I have just made TransformSPI backward compatible. Now it is possible to use old
> implementations made for the >1.3 versions paying the performance hit of the old
> way.
> I have adapt a little the ideas above. Instead of doing the try..catch in the
> transform object I change the new method to have the implementation that call
> the old api method. And have the old method throw the NotImplemented exception.
> I have done a small test case that seems to pass but I have not test with a real
> implementation. So I wait for your feedback before closing the bug.

It looks fine and have tested with an implementation.
 
> The problem in keyresolver still lings on. It is a little diferent than this one.
> In KeyresolverSPI & other resolvers there were two methods boolean
> engineCanResolveX and engineResolveX. And they were called with a code like that:
> X x=null;
> while(x!=null && hasMoreResolvers) {
>   if (engineCanResolveX(...)) {
>      x=engineResolveX(...);
>   }
> }
> 
> The new code is simple and works like this:
> X x=null;
> while(x!=null && hasMoreResolvers) {
>      x=engineResolveX(...);
> }
> 
> It doesn't call engineCanResolve but it goes straight forward to the
> engineResolveX if it is null it keeps trying with other resolver.
> This change can impact resolvers that expect engineCanResolve be called before
> engineResolve(there is one in the old code) that now will be called always
> without engineCanResolve(indeed the engineCanResolve is no more a method of the
> resolver).
> 
> SO it is a change in the contract in the api. Well, we neve document very well
> the API and this was not written but I think it follows the semantic of the
> names of the methods.
> 
> We have two options.
>   1. Document the current behavior and wait and see if there are any out of the
> tree resolver that expect this behavior.
>  2. Change the name of the new method engineLookAndResolve() and let this call
> the old methods like we do in the TransformSpi.

I prefer to be on the safe side and preserve compatibility so I vote  2.

However, if the consensus is to break compatibility (1) then all of 
the engineResolve methods need to changed to clearly specify that null should 
be returned if the key material cannot be resolved. They do not document 
that behavior right now.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[prev in list] [next in list] [prev in thread] [next in thread]