+1 .

This is not the complete patch . only code changes .I guess we should change it in 1.4 itself

Let us see if we can clean this up in this release itself ?

This would mean that the configuration of mergePolicy and mergeScheduler become as follows

<mergePolicy class="org.apache.lucene.index.LogByteSizeMergePolicy"/>
<mergeSceduler class="org.apache.lucene.index.ConcurrentMergeScheduler" />

any setters of the class can be invoked on these classes by keeping attributes

Noble, looks good, can you include a test case?

Actually if we're going to change the solrconfig xml schema, I think it should look like:

<mergePolicy class="org.apache.lucene.index.LogByteSizeMergePolicy">
  <double name="maxMergeMB">64.0</double>
</mergePolicy>
<mergeSceduler class="org.apache.lucene.index.ConcurrentMergeScheduler">
  <int name="maxThreadCount">3</int>
</mergeScheduler>

Attributes are limiting. This way we can add more complex objects in the future if needed.

attributes are limiting. This way we can add more complex objects in the future if needed.

We are not limiting to attributes. If the Object is a NamedListInitializedPlugin it can use the sub attributes also. If we use external classes we cannot dictate that class to implement a NamedListInitializedPlugin . So let us have both

Here's a patch with a test case that implements init args.

If we stick with one system, it's less to document and debug later.

Jason .I am fine with this. I plan to commit this shortly

all the conf files needed to be modified for this

a test was failing

Noble, looks good, and all tests pass. I think it's tricky to commit this as is, because there's no back compat? Maybe we can allow:

<mergePolicy>org.apache.lucene.index.LogByteSizeMergePolicy</mergePolicy>
<mergeScheduler>org.apache.lucene.index.ConcurrentMergeScheduler</mergeScheduler>

or

<mergePolicy14 class="org.apache.lucene.index.LogByteSizeMergePolicy">
  <double name="maxMergeMB">64.0</double>
</mergePolicy14>
<mergeSceduler14 class="org.apache.lucene.index.ConcurrentMergeScheduler">
  <int name="maxThreadCount">3</int>
</mergeScheduler14>

It's ugly but more clear and this way users' installations won't immediately break on deployment.

yes, there is no back-compat. but changing the tag-name is not an option

The ideal fix would be to support both syntaxes.I guess it is still possible.

Why is changing the tag name not an option?

the back-compat thing is a temporary thing. After we remove it we would love to keep the name as mergePolicy or mergeScheduler itself. There is no reason we should have this arbitrary number at the end.

supports both syntax. logs out a warning if the old syntax is used

committed : r817650
Thanks Jason

this turned out to be a lot bigger

I think we need a legacy test?

I added a legacy test, and fixed a small NPE bug that happens via SolrPlugUtils

committed r817976

thanks Jason

Re-opening because the mergeScheduler and mergePolicy specified in the indexDefaults section is not honored.

Here's a test case which fails.

Still trying to understand and debug.

Fix which passes the test case posted earlier. I'll commit this shortly.

Committed revision 819401.

Bulk close for Solr 1.4