|
Attaching an updated fix. The code is cleaned up a bit, there are more comments, but most significantly StylesheetHandler has
one more stack. For a given baseURI and href value, the user's URIResolver.reslove(hrefVal, baseURI) should only be called once. In the call to ProcessorInclude.starteElement() the resolver would be called to the the Source, and from in the sytem ID, but only the system ID was used to be pushed onto the stack that helps check for circular includes (e.g. Sheet A -> includes Sheet B -> includes Sheet A ). startElement() would call ProcessorInclude.process() which again would call URIResolver.reslove(hrefVal, baseURI) yet again, to get the Source (and use it this time). It doesn't seem right to me to call URIResolver.resolve twice with the same strings. We don't know what the user's URIResolver does when called, and calling twice might mess things up. So the additional stack in StylesheetHandler is a stack of Source objects from the user's URI resolver, and process() just uses the one on the top of the stack, i.e. the one pushed by startElement() just befor it called process(). Likewise the original stack of system IDs, previously used to check for circular includes, is also used to obtain the system ID that was previously calculated in startElement(). All in all, with this patch the URIResolver and the Source that it returns now give the user total control on the parsing and meaning of the URIs. Assigning to Brian Minchau, setting reviewer to Christine Li (thanks Christine!).
Attaching patch4 (same as patch3 but with an unused field introduced in patch3 removed).
I will be deleting earlier attached patches. The patch looks fine and should resolve the problem. Reviewed by Christine Li
Comments from JIRA bug Triage on Febrary 7, 2006:
> Brian needs to apply the patch You also "blindly use SystemIDResolver" in class org.apache.xalan.xsltc.dom.LoadDocument.
Could you also make that class use user's URIResolver, if it is set. Thanks. See http://svn.apache.org/viewvc/xalan/java/trunk/src/org/apache/xalan/xsltc/dom/LoadDocument.java?view=markup Per the JIRA meeting on Oct 16, 2005, with the new remark by Nicholas Sushkin the old patch should be applied and a separate mini-patch should be added to this issue, and then reviewed/approved/applied.
The patch for this fix was applied to the code way back on
September 29, 2005. I think there is more work to do than just apply the patch of September 29, 2005. The 2005 patch does not fix org.apache.xalan.xsltc.dom.LoadDocument.java. Please see my comment of 23/May/06.
In the "document()" function, the same issue is still unresolved. If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI. Would you reopen this bug or should I file it as a separate bug?
Thanks Nicholas,
please open a separate issue for this. If you have a patch for that fix, or can point to the code that you think needs to be changed that would be great. As you can see right now for the 2.7.1 release coming up we are focusing on cleaning up issues that have patches attached to them. With a patch the fix is far more likely to make 2.7.1 (and who knows how long until the next release). This issue is no longer relevant for 2.7.1, it is fixed in 2.7.1.
Changing the affected version to 2.7. Would the originator of this issue please verify that this issue is fixed in the 2.7.1 release, by adding a comment to this issue, so that we can close this issue.
A lack of response by February 1, 2008 will be taken as consent that we can close this resolved issue. Regards, Brian Minchau |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI
SystemIDResolver.getAbsoluteURI()
to get the base URI of the included document.
ProcessorInclude.processSource() is much more careful. It checks if the user has provided a URIResolver,
if that resolver returns a Source, and if the Source has a system ID. So things are a bit inconsistent.
Also startElement() only wants the base URI so that it can check for circular includes of stylesheet modules, but
the side effect is that it also checks the validity of the URIs. As stated before, if the user provided URIResolver, and
the Source that it returns has a system ID set, then there is no reason to blindly use SystemIDResolver at all.
The patch provided uses the user provided URIResolver more consistently.