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=42599>. 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=42599 ------- Additional Comments From [EMAIL PROTECTED] 2007-06-07 09:29 ------- Yes, I noticed the ID short-circuit case before, and I was wondering why you weren't just letting those be handled by the default fragment URI resolver (FragmentResolver) since that's exactly what it does. Meaning let that one run in the resolver chain before yours does. But I had not noticed that your impl has a mandatory single-arg constructor that takes the Node base node. Does this not mean that this resolver can not be configured in the ResourceResolver chain in the Apache config.xml , and must be manually registered (with the correct Node value) on each XMLSignature that you're going to process? So that means the caller has to know in advance that they're going to be processing XPointer references and do the appropriate base node resolution and resolver registration? If would be nice if this base node Node could be resolved/inferred from the 'Attr URI' and/or the 'String baseURI' that are passed into the engineResolve method of the ResourceResolverSpi, and eliminate the document-specific constructor requirement. Maybe this isn't possible due to the requirements of the XPath and XPointer processing, I'm only passingly familiar with those technologies. By the way, our OpenSAML user tried it out and it worked fine for him on the use case I originally posted (subject to the resolver registration limitation). -- 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.
