Shawn, thanks. need any more jiras on this?

On May 19, 2013, at 6:37 PM, Shawn Heisey <s...@elyograg.org> wrote:

> On 5/19/2013 11:27 AM, Benson Margulies wrote:
>> Starting with the shipped solr.xml, I added a new-style <str> child to
>> configure a shared lib, and i was rewarded with:
>>
>> Caused by: org.apache.solr.common.SolrException: Should not have found
>> solr/str[@name='sharedLib'] solr.xml may be a mix of old and new style
>> formats.
>> at org.apache.solr.core.ConfigSolrXml.failIfFound(ConfigSolrXml.java:169)
>> at org.apache.solr.core.ConfigSolrXml.init(ConfigSolrXml.java:150)
>> at org.apache.solr.core.ConfigSolrXml.<init>(ConfigSolrXml.java:94)
>> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:387)
>> ... 42 more
>
> There are serious problems with the new solr.xml format in 4.3.  Due to
> major changes in the code between 4.3 and 4.4, the problems will not be
> fixed in 4.3.1.  You'll need to wait for 4.4 before attempting to use
> it.  The new format will be used in the example in 4.4.
>
> I have updated the ConfiguringSolr page with some additional info, and
> reorganized it.  I believe the "4.3 and beyond" page should be changed
> to "4.4 and beyond."
>
> The sharedLib attribute is broken in 4.3.0, fixed in 4.3.1 with
> SOLR-4791, which should be out very soon.  A workaround is to put your
> jars in ${solr.solr.home}/lib which does not require configuration.
>
> After 4.3.1 comes out (or if you a use dev version), if you want to use
> sharedLib in the old-style solr.xml file, it will not be a str tag, it
> is an attribute on the solr tag.  The sharedLib values are relative to
> solr.solr.home:
>
> <solr persistent="true" sharedLib="libextra">
>  <cores adminPath="/admin/cores">
>
> Thanks,
> Shawn
>

Reply via email to