santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40512] - Fix incompatible API changes to TransformSpi
Date Sun, 24 Sep 2006 17:46:25 GMT
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 raul-info@r-bg.com  2006-09-24 17:46 -------
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.

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.

What do you think?




-- 
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.

Mime
View raw message