[
https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617321#action_12617321
]
noble.paul edited comment on SOLR-614 at 7/27/08 11:06 AM:
-----------------------------------------------------------
bq.perhaps I'm missing something... where/how does this get rid of any XPath?
Within a NamedListInitalizedPlugin, the plugin writer does not have access to
the Node and can't use it anyway? The plugin writer just has access to a
NamedList.
The NamedList instance contains everything you can add in an xml. so no more
XPath needed .
For instance ,the UpdateprocessorChain coud have easily been a
NamedListInitializedPlugin . All we need to do is add a method to
SolrConfig#getNodeAsNamedList(String xpath). All components can start from
there. (of cource the first xpath cannot be avoided)
bq.Yes, the latter is better looking, but considering that folks are already
forced to use the former, it seems wrong (and asking for trouble) mix and match.
We are *not* changing anything here.
{code:xml}
<lst name="defaults"><str name="echoParams">explicit</str></lst>
{code}
is not same as
{code}
<defaults echoParams="explicit" />
{code}
Unless the component writer explicitly changes his code (which I am not
recommending now)
The use case is as follows:
For instance in SOLR-561 I do not wish to keep this configuration
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler" >
<lst name="master">
<!--Replicate on 'optimize' it can also be 'commit' -->
<str name="replicateAfter">commit</str>
<!--Config files to be to be replicated-->
<str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
<str name="snapShootAfter">optimize</str>
<str name="snapDir">/user/datadir</str>
</lst>
</requestHandler>
{code}
I wish to have a configuration
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler" >
<master replicateAfter="commit"
confFiles="schema.xml,stopwords.txt,elevate.xml"
snapShootAfter="optimize" snapDir="/user/datadir"/>
</requestHandler>
{code}
But ,it is not possible w/o resorting to xpath .
with this code change. I can do something like
{code:java}
NamedList master = (NamedList )initArgs.get("master");
String replicateAfter = (String)master.get("@replicateAfter");
String confFiles= (String)master.get("@confFiles");
String snapDir= (String)master.get("@snapDir");
{code}
This feature is not going to be a part of Solr1.3. But it may be deployed in
our organization as an addon feature.
The second usecase is components like UpdateHandler , UpdateRequestProcessor
etc. which already has a syntax that is clean. They can cleanup their java code
with no xpath
was (Author: noble.paul):
bq.perhaps I'm missing something... where/how does this get rid of any
XPath? Within a NamedListInitalizedPlugin, the plugin writer does not have
access to the Node and can't use it anyway? The plugin writer just has access
to a NamedList.
The NamedList instance contains everything you can add in an xml. so no more
XPath needed .
For instance ,the UpdateprocessorChain coud have easily been a
NamedListInitializedPlugin . All we need to do is add a method to
SolrConfig#getNodeAsNamedList(String xpath). All components can start from
there. (of cource the first xpath cannot be avoided)
bq.Yes, the latter is better looking, but considering that folks are already
forced to use the former, it seems wrong (and asking for trouble) mix and match.
We are *not* changing anything here.
{code:xml}
<lst name="defaults"><str name="echoParams">explicit</str></lst>
{code}
is not same as
{code}
<defaults echoParams="explicit" />
{code}
Unless the component writer explicitly changes his code (which I am not
recommending now)
The use case is as follows
For instance in SOLR-561 I do not wish to keep this configuration
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler" >
<lst name="master">
<!--Replicate on 'optimize' it can also be 'commit' -->
<str name="replicateAfter">commit</str>
<!--Config files to be to be replicated-->
<str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
<str name="snapShootAfter">optimize</str>
<str name="snapDir">/user/datadir</str>
</lst>
</requestHandler>
{code}
I wish to have a configuration
{code:xml}
<requestHandler name="/replication" class="solr.ReplicationHandler" >
<master replicateAfter="commit"
confFiles="schema.xml,stopwords.txt,elevate.xml"
snapShootAfter="optimize" snapDir="/user/datadir"/>
</requestHandler>
{code}
But ,it is not possible w/o resorting to xpath . This is not going to be a part
of Solr1.3. But it may be deployed in our organization as an addon feature.
The second usecase is components like UpdateHandler , UpdateRequestProcessor
etc. which already has a syntax that is clean. They can cleanup their java code
with no xpath
> Allow components to read any kind of XML from solrconfig
> --------------------------------------------------------
>
> Key: SOLR-614
> URL: https://issues.apache.org/jira/browse/SOLR-614
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Priority: Trivial
> Fix For: 1.3
>
> Attachments: SOLR-614.patch, SOLR-614.patch, SOLR-614.patch
>
>
> All the components initialized by Solr have an init(NamedList args)
> initializer. This leads us to writing the configuration needed for the
> component in the NamedList xml format. People familiar with Solr may know the
> format but most of what is written is noise than information. For users who
> are not familiar w/ the format find it too difficult to understand why they
> have to write it this way. Moreover , it is not a very efficient way to
> configure .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
