You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "Nicholas Sushkin (JIRA)" <xa...@xml.apache.org> on 2006/11/01 03:13:53 UTC
[jira] Created: (XALANJ-2332) If a URIResolver is provided, don't
call SystemIDResolver.getAbsoluteURI in document() function
If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI in document() function
-----------------------------------------------------------------------------------------------
Key: XALANJ-2332
URL: http://issues.apache.org/jira/browse/XALANJ-2332
Project: XalanJ2
Issue Type: Bug
Affects Versions: Latest Development Code, 2.6, 2.7
Reporter: Nicholas Sushkin
Assigned To: Brian Minchau
Fix For: Latest Development Code
If the user provides a URIResolver that returns the Source given the absolute URI of the stylesheet module doing the include/import and the relative URI from the href attribute, and if that Source has its system ID set, then there is no reason for the XSLT processor to get involved with the contents of the URIs. The user has provided the full management of stylesheet URIs, to resolve all included/imported Source stylesheet modules and their absolute URIs.
The URIs are supposed to be legitimate URIs, but wheter or not they actually are should be in the user's control. For example the URIs might be of the form "file:///..." with directories or filenames that have characters in them that are not allowed in legitimate URIs.
On the other hand, if the user hasn't provided a URIResolver, or that resolver doesn't return a Source, or that Source doesn't have its system ID set, then the fallback of using SystemIDResolver to get the base URI of the included document is OK. If the URIs are not legitimate, the services provided by this class may throw MalformedURIException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-2332) If a URIResolver is provided, don't
call SystemIDResolver.getAbsoluteURI in document() function
Posted by "Brian Minchau (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-2332?page=comments#action_12450544 ]
Brian Minchau commented on XALANJ-2332:
---------------------------------------
I have been reviewing Kevin's attached patch to XSLTC and can't approve it at this time. It may be correct but it needs more investigation.
The thing is this, when a user provides a URI resolver they want to be totally in control of the URIs.
When running with JAXP the initial URI of the primary stylesheet module is coming from the Source object created in the user code before the stylesheet is parsed. This Source had better have its systemID set to an "absolute" URI value (I leave it to the user to define what "absolute" is).
Now when one hits an xsl:include or xsl:import during parsing the resolver is passed the "absolute" URI of the parent module doing the include or import, and the href value. The user's URIResolver should then use these two values and create a Source object with its system ID set, and that value should be "absolute" because this secondary module may itself include/import ... and so on. Basically whatever Source objects a resolver creates its system ID may come back to the resolver later on when doing deeper include/import.
When running from the command line with the -URIRESOLVER option I saw that SystemIDResolver was still being called (which looked strange ... I thought the user's resolver would do everything) and I saw that Kevin's patch had the chance of changing the behavior of the URI of base of the stylesheet. However, on further consideration this is probably because when running from the command line the initial Source object is internally generated hence the calls to SystemIDResolver in this case.
Perhaps when running with JAXP this is not an issue. Kevin had some concerns about his patch causing changes in behavior, such as some calls to getAbsoluteURI not being done for the primary stylesheet module when you have a URI resolver set, thus a change in behavior. I hope that this change is only from the Process command line, and in any case if the user has set a resolver we shouldn't be mucking with any URIs so I'd argue that a change in behavior for the primary module is a GOOD thing.
Needs more investigation. Plus I don't think Kevin's patch to XSLTC is what Nicholas is looking for, pretty sure he wants it for Xalan-J interpreted.
> If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI in document() function
> -----------------------------------------------------------------------------------------------
>
> Key: XALANJ-2332
> URL: http://issues.apache.org/jira/browse/XALANJ-2332
> Project: XalanJ2
> Issue Type: Bug
> Affects Versions: Latest Development Code, 2.6, 2.7
> Reporter: Nicholas Sushkin
> Assigned To: Brian Minchau
> Fix For: Latest Development Code
>
> Attachments: j2332-test.zip, j2332.patch, MyResolver.java
>
>
> If the user provides a URIResolver that returns the Source given the absolute URI of the stylesheet module doing the include/import and the relative URI from the href attribute, and if that Source has its system ID set, then there is no reason for the XSLT processor to get involved with the contents of the URIs. The user has provided the full management of stylesheet URIs, to resolve all included/imported Source stylesheet modules and their absolute URIs.
> The URIs are supposed to be legitimate URIs, but wheter or not they actually are should be in the user's control. For example the URIs might be of the form "file:///..." with directories or filenames that have characters in them that are not allowed in legitimate URIs.
> On the other hand, if the user hasn't provided a URIResolver, or that resolver doesn't return a Source, or that Source doesn't have its system ID set, then the fallback of using SystemIDResolver to get the base URI of the included document is OK. If the URIs are not legitimate, the services provided by this class may throw MalformedURIException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-2332) If a URIResolver is provided, don't
call SystemIDResolver.getAbsoluteURI in document() function
Posted by "Brian Minchau (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-2332?page=comments#action_12447558 ]
Brian Minchau commented on XALANJ-2332:
---------------------------------------
triaged November 6, 2006
Kevin Cormier agreed to come up with a patch for this issue.
> If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI in document() function
> -----------------------------------------------------------------------------------------------
>
> Key: XALANJ-2332
> URL: http://issues.apache.org/jira/browse/XALANJ-2332
> Project: XalanJ2
> Issue Type: Bug
> Affects Versions: Latest Development Code, 2.6, 2.7
> Reporter: Nicholas Sushkin
> Assigned To: Brian Minchau
> Fix For: Latest Development Code
>
>
> If the user provides a URIResolver that returns the Source given the absolute URI of the stylesheet module doing the include/import and the relative URI from the href attribute, and if that Source has its system ID set, then there is no reason for the XSLT processor to get involved with the contents of the URIs. The user has provided the full management of stylesheet URIs, to resolve all included/imported Source stylesheet modules and their absolute URIs.
> The URIs are supposed to be legitimate URIs, but wheter or not they actually are should be in the user's control. For example the URIs might be of the form "file:///..." with directories or filenames that have characters in them that are not allowed in legitimate URIs.
> On the other hand, if the user hasn't provided a URIResolver, or that resolver doesn't return a Source, or that Source doesn't have its system ID set, then the fallback of using SystemIDResolver to get the base URI of the included document is OK. If the URIs are not legitimate, the services provided by this class may throw MalformedURIException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[jira] Commented: (XALANJ-2332) If a URIResolver is provided, don't
call SystemIDResolver.getAbsoluteURI in document() function
Posted by "Nicholas Sushkin (JIRA)" <xa...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XALANJ-2332?page=comments#action_12446149 ]
Nicholas Sushkin commented on XALANJ-2332:
------------------------------------------
In the "document()" function, the same issue is still unresolved. If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI.
The change should be somewhere in org/apache/xalan/xsltc/dom/LoadDocument.java
Perhaps need to reuse or factor out the new function "private Source getSourceFromUriResolver(StylesheetHandler handler)" from org/apache/xalan/processor/ProcessorInclude.java
Without knowing the inner working of Xalan, I would venture to guess the candidates for rewrite are as follows:
- setting of baseUri in "document(2 args)" implemented in
"public static DTMAxisIterator documentF(Object arg1, DTMAxisIterator arg2, String xslURI, AbstractTranslet translet, DOM dom)"
- setting of baseUri variable in "document(1 arg)" implemented in
"public static DTMAxisIterator documentF(Object arg, String xslURI, AbstractTranslet translet, DOM dom)"
- In the function that actually creates a Source from the arguments of document function, do the same modification as in Bug #XALANJ-2205. In other words, in function
"private static DTMAxisIterator document(String uri, String base, AbstractTranslet translet, DOM dom, boolean cacheDOM)"
Instead of doing basically
uri = SystemIDResolver.getAbsoluteURI(uri, base);
dtmManager.getDTM(new StreamSource(uri), ...);
do
// Get the Source from the user's URIResolver (if any).
Source sourceFromURIResolver = getSourceFromUriResolver(handler);
dtmManager.getDTM(sourceFromURIResolver, ...)
> If a URIResolver is provided, don't call SystemIDResolver.getAbsoluteURI in document() function
> -----------------------------------------------------------------------------------------------
>
> Key: XALANJ-2332
> URL: http://issues.apache.org/jira/browse/XALANJ-2332
> Project: XalanJ2
> Issue Type: Bug
> Affects Versions: Latest Development Code, 2.6, 2.7
> Reporter: Nicholas Sushkin
> Assigned To: Brian Minchau
> Fix For: Latest Development Code
>
>
> If the user provides a URIResolver that returns the Source given the absolute URI of the stylesheet module doing the include/import and the relative URI from the href attribute, and if that Source has its system ID set, then there is no reason for the XSLT processor to get involved with the contents of the URIs. The user has provided the full management of stylesheet URIs, to resolve all included/imported Source stylesheet modules and their absolute URIs.
> The URIs are supposed to be legitimate URIs, but wheter or not they actually are should be in the user's control. For example the URIs might be of the form "file:///..." with directories or filenames that have characters in them that are not allowed in legitimate URIs.
> On the other hand, if the user hasn't provided a URIResolver, or that resolver doesn't return a Source, or that Source doesn't have its system ID set, then the fallback of using SystemIDResolver to get the base URI of the included document is OK. If the URIs are not legitimate, the services provided by this class may throw MalformedURIException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org