You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Clemens Wyss DEV <cl...@mysign.ch> on 2015/01/28 16:52:02 UTC
CoreContainer#createAndLoad, existing cores not loaded
My problem:
I create cores dynamically using container#create( CoreDescriptor ) and then add documents to the very core(s). So far so good.
When I restart my app I do
container = CoreContainer#createAndLoad(...)
but when I then call container.getAllCoreNames() an empty list is returned.
What cores should be loaded by the container if I call
CoreContainer#createAndLoad(...)
? Where does the container lookup the "existing cores"?
AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
No <cores>-element in my solr.xml
My folder structure looks alike:
[solr]
-solr.xml
-[configsets]
...
-[cores]
--[de]
---[data]
...
--[fr]
...
--[it]
...
So you say, if I copy an empty core.proerties file into the [cores] folder it should work? Even with 4.10.3?
Thanks also for all your warnings going the "bleeding edge"-way!
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Donnerstag, 29. Januar 2015 18:10
An: solr-user@lucene.apache.org
Betreff: Re: AW: CoreContainer#createAndLoad, existing cores not loaded
On 1/29/2015 12:13 AM, Clemens Wyss DEV wrote:
> BTW:
> None of my core folders contains a core.properties file ... ? Could it be due to the fact that I am (so far) running only EmbeddedSolrServer, hence no real Solr-Server?
I'm not sure how it's working without core.properties files, unless your solr.xml file has a <cores> element and the cores are defined there.
The old-style solr.xml file works in 4.10.3.
The minimum config you need in a core.properties file is nothing at all
-- it just needs to exist. The name of the core defaults to the name of the directory where it is found, and the dataDir defaults to "data"
relative to the directory where the core.properties was found. I myself only have "name" and "dataDir" defined in my core.properties files, because I need both to be different from the default.
[root@bigindy5 cores]# cat s0_0/core.properties #Written by CorePropertiesLocator #Mon Jan 26 23:38:42 MST 2015 name=s0build
dataDir=../../data/s0_0
[root@bigindy5 cores]# cat s0_1/core.properties #Written by CorePropertiesLocator #Mon Jan 26 23:38:42 MST 2015 name=s0live
dataDir=../../data/s0_1
To answer your other question about whether you should go with 5.0 ...
that depends on how close you are to your production deployment and how willing you are to deal with bleeding edge software. The first release of a new major version is always a risky proposition ... I plan to wait for the 5.2 or 5.3 release before rolling it into production, and waiting long enough after the release to make sure that no big problems are reported by users. Minor Lucene/Solr releases happen on a very quick timeline, so I won't have to wait very long.
The following info is available on the dev list, so I'm not giving away any secrets when I tell you that the first release candidate for 5.0 has failed to pass the vote. There will be a new one soon that includes some additional bugfixes. If all goes well with that candidate, there should be a release announcement within a week of the new RC being cut.
Thanks,
Shawn
Re: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/29/2015 12:13 AM, Clemens Wyss DEV wrote:
> BTW:
> None of my core folders contains a core.properties file ... ? Could it be due to the fact that I am (so far) running only EmbeddedSolrServer, hence no real Solr-Server?
I'm not sure how it's working without core.properties files, unless your
solr.xml file has a <cores> element and the cores are defined there.
The old-style solr.xml file works in 4.10.3.
The minimum config you need in a core.properties file is nothing at all
-- it just needs to exist. The name of the core defaults to the name of
the directory where it is found, and the dataDir defaults to "data"
relative to the directory where the core.properties was found. I myself
only have "name" and "dataDir" defined in my core.properties files,
because I need both to be different from the default.
[root@bigindy5 cores]# cat s0_0/core.properties
#Written by CorePropertiesLocator
#Mon Jan 26 23:38:42 MST 2015
name=s0build
dataDir=../../data/s0_0
[root@bigindy5 cores]# cat s0_1/core.properties
#Written by CorePropertiesLocator
#Mon Jan 26 23:38:42 MST 2015
name=s0live
dataDir=../../data/s0_1
To answer your other question about whether you should go with 5.0 ...
that depends on how close you are to your production deployment and how
willing you are to deal with bleeding edge software. The first release
of a new major version is always a risky proposition ... I plan to wait
for the 5.2 or 5.3 release before rolling it into production, and
waiting long enough after the release to make sure that no big problems
are reported by users. Minor Lucene/Solr releases happen on a very
quick timeline, so I won't have to wait very long.
The following info is available on the dev list, so I'm not giving away
any secrets when I tell you that the first release candidate for 5.0 has
failed to pass the vote. There will be a new one soon that includes
some additional bugfixes. If all goes well with that candidate, there
should be a release announcement within a week of the new RC being cut.
Thanks,
Shawn
AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
BTW:
None of my core folders contains a core.properties file ... ? Could it be due to the fact that I am (so far) running only EmbeddedSolrServer, hence no real Solr-Server?
-----Ursprüngliche Nachricht-----
Von: Clemens Wyss DEV [mailto:clemensdev@mysign.ch]
Gesendet: Donnerstag, 29. Januar 2015 08:08
An: solr-user@lucene.apache.org
Betreff: AW: CoreContainer#createAndLoad, existing cores not loaded
Thx Shawn. I am running latest-greatest Solr (4.10.3) Solr home is e.g.
/opt/webs/<siteX>/WebContent/WEB-INF/solr
the core(s) reside in
/opt/webs/<siteX>/WebContent/WEB-INF/solr/cores
Should these be found by core discovery?
If not, how can I configure coreRootDirectory in sorl.xml to be "cores folder below <slorHome>"
<str name="coreRootDirectory">${coreRootDirectory:<solrHome>/cores}</str>
Note:
the solr.xml is to be used for any of our 150sites we host. Therefore like it to be "generic" -> <solrHome>/cores
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Mittwoch, 28. Januar 2015 17:08
An: solr-user@lucene.apache.org
Betreff: Re: CoreContainer#createAndLoad, existing cores not loaded
On 1/28/2015 8:52 AM, Clemens Wyss DEV wrote:
> My problem:
> I create cores dynamically using container#create( CoreDescriptor ) and then add documents to the very core(s). So far so good.
> When I restart my app I do
> container = CoreContainer#createAndLoad(...) but when I then call
> container.getAllCoreNames() an empty list is returned.
>
> What cores should be loaded by the container if I call
> CoreContainer#createAndLoad(...)
> ? Where does the container lookup the "existing cores"?
If the solr.xml is the old format, then cores are defined in solr.xml, in the <cores> section of that config file.
There is a new format for solr.xml that is supported in version 4.4 and later and will be mandatory in 5.0. If that format is present, then Solr will use core discovery -- starting from either the solr home or a defined coreRootDirectory, solr will search for core.properties files and treat each directory where one is found as a core's instanceDir.
http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
Thanks,
Shawn
AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
https://issues.apache.org/jira/browse/SOLR-6718
looks like I am not alone with my "weird" questions/ideas ;)
And I should really switch over to 5 ;)
-----Ursprüngliche Nachricht-----
Von: Clemens Wyss DEV [mailto:clemensdev@mysign.ch]
Gesendet: Donnerstag, 29. Januar 2015 08:08
An: solr-user@lucene.apache.org
Betreff: AW: CoreContainer#createAndLoad, existing cores not loaded
Thx Shawn. I am running latest-greatest Solr (4.10.3) Solr home is e.g.
/opt/webs/<siteX>/WebContent/WEB-INF/solr
the core(s) reside in
/opt/webs/<siteX>/WebContent/WEB-INF/solr/cores
Should these be found by core discovery?
If not, how can I configure coreRootDirectory in sorl.xml to be "cores folder below <slorHome>"
<str name="coreRootDirectory">${coreRootDirectory:<solrHome>/cores}</str>
Note:
the solr.xml is to be used for any of our 150sites we host. Therefore like it to be "generic" -> <solrHome>/cores
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Mittwoch, 28. Januar 2015 17:08
An: solr-user@lucene.apache.org
Betreff: Re: CoreContainer#createAndLoad, existing cores not loaded
On 1/28/2015 8:52 AM, Clemens Wyss DEV wrote:
> My problem:
> I create cores dynamically using container#create( CoreDescriptor ) and then add documents to the very core(s). So far so good.
> When I restart my app I do
> container = CoreContainer#createAndLoad(...) but when I then call
> container.getAllCoreNames() an empty list is returned.
>
> What cores should be loaded by the container if I call
> CoreContainer#createAndLoad(...)
> ? Where does the container lookup the "existing cores"?
If the solr.xml is the old format, then cores are defined in solr.xml, in the <cores> section of that config file.
There is a new format for solr.xml that is supported in version 4.4 and later and will be mandatory in 5.0. If that format is present, then Solr will use core discovery -- starting from either the solr home or a defined coreRootDirectory, solr will search for core.properties files and treat each directory where one is found as a core's instanceDir.
http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
Thanks,
Shawn
AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
I looked into sources of CoreAdminHandler#handleCreateAction
...
SolrCore core = coreContainer.create(dcore);
// only write out the descriptor if the core is successfully created
coreContainer.getCoresLocator().create(coreContainer, dcore);
...
I was missing the "coreContainer.getCoresLocator().create(coreContainer, dcore);"
When doing the two calls:
a) Core.properties is being created
AND
b) the cores are being loaded upon container-startup ;)
:-)
-----Ursprüngliche Nachricht-----
Von: Clemens Wyss DEV [mailto:clemensdev@mysign.ch]
Gesendet: Freitag, 30. Januar 2015 07:38
An: solr-user@lucene.apache.org
Betreff: AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
> The recommendation these days is to NOT use the embedded server
We would love to, as it is clear that this is not the "Solr-way" to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it?
Or can for example a 4.10.3 client "talk" to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed?
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Donnerstag, 29. Januar 2015 20:30
An: solr-user@lucene.apache.org
Betreff: Re: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
On 1/29/2015 10:15 AM, Clemens Wyss DEV wrote:
>> to put your solr home inside the extracted WAR
> We are NOT using war's
>
>> coreRootDirectory
> I don't have this property in my sorl.xml
>
>> If there will only be core.properties files in that cores directory
> Again, I see no core.properties file. I am creating my cores through
> CoreContainer.createCore( CordeDescriptor). The folder(s) are created
> but no core.properties file
I am pretty clueless when it comes to the embedded server, but if you are creating the cores in the java code every time you create the container, I bet what I'm telling you doesn't apply at all. The solr.xml file may not even be used.
The recommendation these days is to NOT use the embedded server. There are too many limitations and it doesn't receive as much user testing as the webapp. Start Solr as a separate process and access it over http.
The overhead of http on a LAN is minimal, and over localhost it's almost nothing.
To do that, you would just need to change your code to use one of the client objects. That would probably be HttpSolrServer, which is renamed to HttpSolrClient in 5.0. They share the same parent object as EmbeddedSolrServer. Most of the relevant methods used come from the parent class, so you would need very few code changes.
Thanks,
Shawn
Re: AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/29/2015 11:37 PM, Clemens Wyss DEV wrote:
>> The recommendation these days is to NOT use the embedded server
> We would love to, as it is clear that this is not the "Solr-way" to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it?
>
> Or can for example a 4.10.3 client "talk" to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed?
Cross-version compatibility between SolrJ and Solr is very high, as long
as you're not running SolrCloud. SolrCloud is *incredibly* awesome, but
it's not for everyone.
Without SolrCloud, the communication is http only, using very stable
APIs that have been around since pretty much the beginning of Solr. In
the 1.x and 3.x days, there were occasional code tweaks required for
cross-version compatibility, but the API has been extremely stable since
early 4.x -- for a couple of years now.
SolrCloud is much more recent and far more complex, so problems or
deficiencies are sometimes found with the API. Fixing those bugs
sometimes requires changes that are incompatible with other versions of
the Java client. The SolrJ java client is an integral part of Solr
itself, so SolrCloud functionality in the client is tightly coupled to
specifics in the API that are undergoing rapid change from version to
version.
I don't think that SolrCloud is even possible with the embedded server,
because it requires HTTP for inter-server communication. The embedded
server doesn't listen for HTTP.
Thanks,
Shawn
AW: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
> The recommendation these days is to NOT use the embedded server
We would love to, as it is clear that this is not the "Solr-way" to go. The reason for us building upon EmbeddedSolrServer is, we have more than 150sites, each with ist own index (core). If we'd go client server then we could no easily update the solr server(s) without also updating all clients (i.e. the 150 sites) at same time. And having a dedicated Solr server for every client/site is not really an option, is it?
Or can for example a 4.10.3 client "talk" to a Solr 5/6 Server? Also when updating the Solr server, doesn't that also require a re-index of all data as the Luncene-storage format might have changed?
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Donnerstag, 29. Januar 2015 20:30
An: solr-user@lucene.apache.org
Betreff: Re: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
On 1/29/2015 10:15 AM, Clemens Wyss DEV wrote:
>> to put your solr home inside the extracted WAR
> We are NOT using war's
>
>> coreRootDirectory
> I don't have this property in my sorl.xml
>
>> If there will only be core.properties files in that cores directory
> Again, I see no core.properties file. I am creating my cores through
> CoreContainer.createCore( CordeDescriptor). The folder(s) are created
> but no core.properties file
I am pretty clueless when it comes to the embedded server, but if you are creating the cores in the java code every time you create the container, I bet what I'm telling you doesn't apply at all. The solr.xml file may not even be used.
The recommendation these days is to NOT use the embedded server. There are too many limitations and it doesn't receive as much user testing as the webapp. Start Solr as a separate process and access it over http.
The overhead of http on a LAN is minimal, and over localhost it's almost nothing.
To do that, you would just need to change your code to use one of the client objects. That would probably be HttpSolrServer, which is renamed to HttpSolrClient in 5.0. They share the same parent object as EmbeddedSolrServer. Most of the relevant methods used come from the parent class, so you would need very few code changes.
Thanks,
Shawn
Re: AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/29/2015 10:15 AM, Clemens Wyss DEV wrote:
>> to put your solr home inside the extracted WAR
> We are NOT using war's
>
>> coreRootDirectory
> I don't have this property in my sorl.xml
>
>> If there will only be core.properties files in that cores directory
> Again, I see no core.properties file. I am creating my cores through CoreContainer.createCore( CordeDescriptor). The folder(s) are created but no core.properties file
I am pretty clueless when it comes to the embedded server, but if you
are creating the cores in the java code every time you create the
container, I bet what I'm telling you doesn't apply at all. The
solr.xml file may not even be used.
The recommendation these days is to NOT use the embedded server. There
are too many limitations and it doesn't receive as much user testing as
the webapp. Start Solr as a separate process and access it over http.
The overhead of http on a LAN is minimal, and over localhost it's almost
nothing.
To do that, you would just need to change your code to use one of the
client objects. That would probably be HttpSolrServer, which is renamed
to HttpSolrClient in 5.0. They share the same parent object as
EmbeddedSolrServer. Most of the relevant methods used come from the
parent class, so you would need very few code changes.
Thanks,
Shawn
AW: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
> to put your solr home inside the extracted WAR
We are NOT using war's
>coreRootDirectory
I don't have this property in my sorl.xml
> If there will only be core.properties files in that cores directory
Again, I see no core.properties file. I am creating my cores through CoreContainer.createCore( CordeDescriptor). The folder(s) are created but no core.properties file
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Donnerstag, 29. Januar 2015 17:28
An: solr-user@lucene.apache.org
Betreff: Re: AW: CoreContainer#createAndLoad, existing cores not loaded
On 1/29/2015 12:08 AM, Clemens Wyss DEV wrote:
> Thx Shawn. I am running latest-greatest Solr (4.10.3) Solr home is
> e.g.
> /opt/webs/<siteX>/WebContent/WEB-INF/solr
> the core(s) reside in
> /opt/webs/<siteX>/WebContent/WEB-INF/solr/cores
> Should these be found by core discovery?
> If not, how can I configure coreRootDirectory in sorl.xml to be "cores folder below <slorHome>"
>
> <str
> name="coreRootDirectory">${coreRootDirectory:<solrHome>/cores}</str>
>
> Note:
> the solr.xml is to be used for any of our 150sites we host. Therefore
> like it to be "generic" -> <solrHome>/cores
The first thing to say is that it is a bad idea to put your solr home inside the extracted WAR. The "WEB-INF" above is what makes me think you have done this. Extracted war directories can get wiped out at any time, and we often recommend wiping them out manually in order to clear up certain problems.
If there will only be core.properties files in that cores directory and not any other location under the solr home, just remove coreRootDirectory from the config entirely. It will default to the solr home and everything in "cores" will be found with no problem. That would only be a problem if you have core.properties files in some other directory that is also underneath the solr home. I think that's a bad idea ... if you want a staging area where you create new cores manually, keep it outside the solr home, to avoid confusing either yourself or Solr.
Relative paths should be possible in coreRootDirectory, but they are currently resolved from the current working directory instead of the solr home. There's a bug report for that issue, but it is only fixed in 5.0, which isn't out yet. I placed a note with the info above on the Jira issue. It's the last comment right now:
https://issues.apache.org/jira/browse/SOLR-6718
Since I converted to core discovery, my solr.xml file is extremely minimal -- all the defaults work perfectly for me:
<?xml version="1.0" encoding="UTF-8" ?>
<solr>
</solr>
Thanks,
Shawn
Re: AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/29/2015 12:08 AM, Clemens Wyss DEV wrote:
> Thx Shawn. I am running latest-greatest Solr (4.10.3)
> Solr home is e.g.
> /opt/webs/<siteX>/WebContent/WEB-INF/solr
> the core(s) reside in
> /opt/webs/<siteX>/WebContent/WEB-INF/solr/cores
> Should these be found by core discovery?
> If not, how can I configure coreRootDirectory in sorl.xml to be "cores folder below <slorHome>"
>
> <str name="coreRootDirectory">${coreRootDirectory:<solrHome>/cores}</str>
>
> Note:
> the solr.xml is to be used for any of our 150sites we host. Therefore like it to be "generic" -> <solrHome>/cores
The first thing to say is that it is a bad idea to put your solr home
inside the extracted WAR. The "WEB-INF" above is what makes me think
you have done this. Extracted war directories can get wiped out at any
time, and we often recommend wiping them out manually in order to clear
up certain problems.
If there will only be core.properties files in that cores directory and
not any other location under the solr home, just remove
coreRootDirectory from the config entirely. It will default to the solr
home and everything in "cores" will be found with no problem. That
would only be a problem if you have core.properties files in some other
directory that is also underneath the solr home. I think that's a bad
idea ... if you want a staging area where you create new cores manually,
keep it outside the solr home, to avoid confusing either yourself or Solr.
Relative paths should be possible in coreRootDirectory, but they are
currently resolved from the current working directory instead of the
solr home. There's a bug report for that issue, but it is only fixed in
5.0, which isn't out yet. I placed a note with the info above on the
Jira issue. It's the last comment right now:
https://issues.apache.org/jira/browse/SOLR-6718
Since I converted to core discovery, my solr.xml file is extremely
minimal -- all the defaults work perfectly for me:
<?xml version="1.0" encoding="UTF-8" ?>
<solr>
</solr>
Thanks,
Shawn
AW: CoreContainer#createAndLoad, existing cores not loaded
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
Thx Shawn. I am running latest-greatest Solr (4.10.3)
Solr home is e.g.
/opt/webs/<siteX>/WebContent/WEB-INF/solr
the core(s) reside in
/opt/webs/<siteX>/WebContent/WEB-INF/solr/cores
Should these be found by core discovery?
If not, how can I configure coreRootDirectory in sorl.xml to be "cores folder below <slorHome>"
<str name="coreRootDirectory">${coreRootDirectory:<solrHome>/cores}</str>
Note:
the solr.xml is to be used for any of our 150sites we host. Therefore like it to be "generic" -> <solrHome>/cores
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Mittwoch, 28. Januar 2015 17:08
An: solr-user@lucene.apache.org
Betreff: Re: CoreContainer#createAndLoad, existing cores not loaded
On 1/28/2015 8:52 AM, Clemens Wyss DEV wrote:
> My problem:
> I create cores dynamically using container#create( CoreDescriptor ) and then add documents to the very core(s). So far so good.
> When I restart my app I do
> container = CoreContainer#createAndLoad(...) but when I then call
> container.getAllCoreNames() an empty list is returned.
>
> What cores should be loaded by the container if I call
> CoreContainer#createAndLoad(...)
> ? Where does the container lookup the "existing cores"?
If the solr.xml is the old format, then cores are defined in solr.xml, in the <cores> section of that config file.
There is a new format for solr.xml that is supported in version 4.4 and later and will be mandatory in 5.0. If that format is present, then Solr will use core discovery -- starting from either the solr home or a defined coreRootDirectory, solr will search for core.properties files and treat each directory where one is found as a core's instanceDir.
http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
Thanks,
Shawn
Re: CoreContainer#createAndLoad, existing cores not loaded
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/28/2015 8:52 AM, Clemens Wyss DEV wrote:
> My problem:
> I create cores dynamically using container#create( CoreDescriptor ) and then add documents to the very core(s). So far so good.
> When I restart my app I do
> container = CoreContainer#createAndLoad(...)
> but when I then call container.getAllCoreNames() an empty list is returned.
>
> What cores should be loaded by the container if I call
> CoreContainer#createAndLoad(...)
> ? Where does the container lookup the "existing cores"?
If the solr.xml is the old format, then cores are defined in solr.xml,
in the <cores> section of that config file.
There is a new format for solr.xml that is supported in version 4.4 and
later and will be mandatory in 5.0. If that format is present, then
Solr will use core discovery -- starting from either the solr home or a
defined coreRootDirectory, solr will search for core.properties files
and treat each directory where one is found as a core's instanceDir.
http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
Thanks,
Shawn