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 [EMAIL PROTECTED] 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.
