[
https://issues.apache.org/jira/browse/SOLR-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999129#comment-12999129
]
Uwe Schindler edited comment on SOLR-1656 at 2/24/11 11:52 PM:
---------------------------------------------------------------
Here is a first mockup (branch_3.x like the previous patch) of the version with
EntityResolver.
This patch has some backwards breaks, because for XML files it is always broken
to parse without a system identifier, so the ctors of SolrSchema and SolrConfig
should not take InputStream but more a InputSource wrapper. With this patch
everything compiles and tests and resolves correctly, but plugins using old
methods may fail (needs review).
How it works:
The system identifier is no longer a plain filename with path, it gets
initialized using a custom URI scheme "solrres:". This scheme is resolved using
the EntityResolver that utilizes SolrResourceLoader. As long as somebody only
gives relative URLs in XIncludes or anywhere else (this is also extendable to
other places, not only xinclude, e.g. external XML entities inside XSLs, config
of DIH,...), the files are staying using this scheme and are resolved by the
custom EntityResolver. As soon as scheme changes, the default resolver is used.
Because of this, the good thing is, that somebody can still use absolute
filesystem URLs or even external URLs in the xincludes, by using full schemed
URIs like file:///my/absolute/path.
Other places in Solr that load XML and support Xinclude must also changed to
this, currently almost every place where solr loads XML files from
ResourceLoader using InputStreams are broken.
Questionable is also backwards compatibibility. Ideally there should be a
loadResourceAsInputSource() method in ResourceLoader so DIH can also use it,
which would also break backwards (interface!).
This patch is currently only for review about the idea. Comments welcome!
was (Author: thetaphi):
Here is a first mockup (branch_3.x like the previous patch) of the version
with EntityResolver.
This patch has some backwards breaks, because for XML files it is always broken
to parse without a system identifier, so the ctors of SolrSchema and SolrConfig
should not take InputStream but more a InputSource wrapper. With this patch
everything compiles and tests and resolves correctly, but plugins using old
methods may fail (needs review).
How it works:
The system identifier is no longer a plain filename with path, it gets
initialized using a custom URI scheme "solrres:". This scheme is resolved using
the EntityResolver that utilizes SolrResourceLoader. As long as somebody only
gives relative URLs in XIncludes or anywhere else (this is also extendable to
other places, not only xinclude, e.g. external XML entities inside XSLs, config
of DIH,...).
The good thing with the separate scheme is, that somebody can still use
absolute filesystem URLs or even external URLs in the xincludes, by using full
schemed URIs like file:///my/absolute/path.
Other places in Solr that load XML and support Xinclude must also changed to
this, currently almost every place where solr loads XML files from
ResourceLoader using InputStreams are broken.
Questionable is also backwards compatibibility. Ideally there should be a
loadResourceAsInputSource() method in ResourceLoader so DIH can also use it,
which would also break backwards (interface!).
This patch is currently only for review about the idea. Comments welcome!
> XInclude's are resolved relative CWD, not instance dir
> ------------------------------------------------------
>
> Key: SOLR-1656
> URL: https://issues.apache.org/jira/browse/SOLR-1656
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.4
> Reporter: Hoss Man
> Attachments: SOLR-1656-mockup.patch,
> SOLR-1656_Support_SAX_SystemId_via_wrapping_InputStream.patch,
> Support_SAX_SystemId_via_wrapping_InputStream.patch
>
>
> As noted on the mailing list, when an XInclude in a config files refrences a
> relative path, it's resolved relative the CWD of the servlet container, and
> not the instanceDir of the core...
>
> http://old.nabble.com/using-Xinclude-with-multi-core-to26548400.html#a26548400
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
