[ 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to