You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2008/08/07 20:51:05 UTC
Rename multicore.xml ?
I know I probably should have brought this up a little farther in advance
of releasing 1.3 (I think i did bring it up back when multicore was first
added ,but then I kind of forgot about it) but I have some concerns about
the name of the "multicore.xml" file. If I'm alone, I'll let it go, but
if other people think I have a point, we should make the change it prior
to the release.
Main Concern...
>From the standpoint of debugging, answering questions, and general
"Understanding" of a Solr installation the first thing you always have to
ask with 1.3 is "What is the Solr Home directory?" and the second thing is
"What does the ./conf/solrconfig.xml file look like?"
As the trunk stands now, the new second question becomes "Is there a
./multicore.xml?" ... because if there is, then it doesn't matter what
./conf/solrconfig.xml looks like, it's totally ignored 9and you can be
certain that some confusion like that will pop up as people switch from
traditional single core to usage to multicore usage, there will be some
./conf/solrconfig.xml files lying around).
The question can't even be "Is this instance of Solr using multiple
cores?" because that's not what really matters, what matters is the
multicore.xml file. A person might only be using one core, but if
multicore.xml exists it determines where to look for all of the configs
for that core, not ./conf/solrconfig.xml.
So far, I see two problems with this:
1) The name of the file corresponds with one specific way it can be
used, but may not be applicable to all usages (namely: you can
have a multicore.xml file but only use one core)
2) The "first" config file checked to determine the application's
behavior, and what paths will be checked for other config files
is named after one specific feature of the application.
>From a historical perspective, our current setup would be like if the
Apache HTTPD server had originally used ./conf/httpd.conf as the primary
config, but when VirtualHost features were added, started saying "If there
is a ./virtualhost.conf file it will be read first, and it will tell us
which httpd.conf files to read, even if there is only one VirtualHost."
This seems odd to me, and likely to confuse new users.
Am I alone in this opinion?
I have two suggested alternatives:
Suggestion #1: Rename multicore.xml something new.
The best suggestion I have is "solr.xml" -- It is a good name to represent
the "first" config file Solr looks for. If it exists in the Solr Home
Directory, it will tell us how many cores to run, and what directories to
use for them. (Someday we might even want to consider allowing a system
property / JNDI property specify it directly instead of specifying Solr
Home) and if it doesn't exist we assume a single core whose instanceDir is
the Solr Home Dir.
This seems pretty straight forward. The only changes we'd *have* to make
would be some string literals and some documentation (and svn renaming the
example multicore.xml). But we should also consider changing adding a new
root XML tag in multicore.xml wrapping the existing <multicore> with a
<solr> ... that would give us a little more flexibility in the future.
Suggestion #2: Change solrconfig.xml parsing to understand <multicore>
This one is a little weird, part of me thinks it's really the best way to
go, but part of me thinks i's really awkward compared to having a
solr.xml. The nushell would be that we always look for
./conf/solrconfig.xml first and if the root tag is <multicore> we go into
MultiCore mode, and if not we go into SingleCore mode.
The big advantage here would be that debuging a Solr instance or answering
questions becomes really straight forward. Instead of asking "Is there a
multicore.xml/solr.xml?" and then depending on the answer asking "What
does ./conf/xolrconfig.xml look like?" the only thing you have to know is
"What does ./conf/xolrconfig.xml look like?"
The possible downsides: More changes to code now before the release; A
somewhat awkward Solr Home directory structure when you are using multiple
cores (Even if you have different instanceDirs for each core, your main
Solr Home directory still needs to contain ./conf/ which needs to contain
a solrconfig.xml); And having one file support two radically different
types of content.
Most installs probably keep all of their instance dirs in Solr Home, so
the directory layout of Suggestion#2 doesn't seem too awkward compared to
Suggestion#1...
solr-home/ (Suggestion#1)
solr-home/solr.xml (current multicore.xml)
solr-home/instanceDir1/
solr-home/instanceDir1/...
solr-home/instanceDir2/
solr-home/instanceDir2/...
solr-home/...
...vs...
solr-home/ (Suggestion#2)
solr-home/conf/
solr-home/conf/solrconfig.xml (current multicore.xml)
solr-home/instanceDir1/
solr-home/instanceDir1/...
solr-home/instanceDir2/
solr-home/instanceDir2/...
solr-home/...
...But i'm sure opinions vary.
What do people think?
Is this going to confuse new users who come along, and make
troubleshooting as confusing as I suspect, or am I just being paranoid?
Even if I am being paranoid: is there any downside to Suggestion #1
-Hoss
Re: Rename multicore.xml ?
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
Let us have another JIRA issue for spring specific discussions. Let us
trash it out there so that all the points we make here do not get
lost when we actually have to make that decision.
I am suggesting this because , whenever we discuss something something
related to config this crops up and hijacks the real issue.
--Noble
On Mon, Aug 11, 2008 at 3:17 PM, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
>
> On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote:
>>
>> I don't really drink from the "Spring would solve all our config/init
>> problems" Kool-Aid
>
> Me neither, even though I'm a proponent of Solr aiming in that direction.
> In fact, I think Spring has the potential to make it much more
> convoluted/complicated to configure Solr (depending on how it's done).
>
> Spring-centric thinking benefits Solr by aiding in the design of things like
> IndexSchema and SolrConfig - such that they would not have a
> dependency/requirement that XML be involved at all.
>
> Springifying Solr doesn't mean littering Solr with Spring dependencies - it
> really should be vastly cleaner than that, such that Spring is NOT required
> to configure Solr at all (and this is the design benefit I see possible).
>
> I'd really love to see Solr get _out_ of dealing with configuration so
> directly instead spending our time on ugly tangential stuff.
>
> Erik
>
>
--
--Noble Paul
Re: Rename multicore.xml ?
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 11, 2008, at 5:47 AM, Erik Hatcher wrote:
>
> On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote:
>> I don't really drink from the "Spring would solve all our config/init
>> problems" Kool-Aid
>
> Me neither, even though I'm a proponent of Solr aiming in that
> direction. In fact, I think Spring has the potential to make it
> much more convoluted/complicated to configure Solr (depending on how
> it's done).
Yeah, I think we should choose the more complicated, convoluted
route... :-)
>
>
> Spring-centric thinking benefits Solr by aiding in the design of
> things like IndexSchema and SolrConfig - such that they would not
> have a dependency/requirement that XML be involved at all.
>
> Springifying Solr doesn't mean littering Solr with Spring
> dependencies - it really should be vastly cleaner than that, such
> that Spring is NOT required to configure Solr at all (and this is
> the design benefit I see possible).
Yes, this is how I see it too. I don't think we need all of Spring's
extra layers (MVC, JDBC, etc). I think the IOC layer, means we don't
need Spring at all if one wants to wire things up themselves.
Yet, many people clearly want XML config, so in my mind, Spring brings
some standardization to the game and gets us out of the config game
and allows us to focus on actually improving Solr's search
capabilities instead of having a gazillion different ways to init an
object.
-Grant
Re: Rename multicore.xml ?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Aug 7, 2008, at 6:46 PM, Chris Hostetter wrote:
> I don't really drink from the "Spring would solve all our config/init
> problems" Kool-Aid
Me neither, even though I'm a proponent of Solr aiming in that
direction. In fact, I think Spring has the potential to make it much
more convoluted/complicated to configure Solr (depending on how it's
done).
Spring-centric thinking benefits Solr by aiding in the design of
things like IndexSchema and SolrConfig - such that they would not have
a dependency/requirement that XML be involved at all.
Springifying Solr doesn't mean littering Solr with Spring dependencies
- it really should be vastly cleaner than that, such that Spring is
NOT required to configure Solr at all (and this is the design benefit
I see possible).
I'd really love to see Solr get _out_ of dealing with configuration so
directly instead spending our time on ugly tangential stuff.
Erik
Re: Rename multicore.xml ?
Posted by Chris Hostetter <ho...@fucit.org>.
: What about solr.xml and it is always there? A single core is just multicore
: with one core. I know that one's been tossed around before. Of course, back
: compat. gets in the way a bit.
Hence suggestion #1 -- things work exactly like they do today on the
trunk, we just rename one file.
: Also, maybe we should also mark multicore as experimental (starting to sound
: like a lot of Solr is "experimental", these days, what w/ a good number of
1) I don't think that's neccessary, it sounds like a lot of people have
been putting it through the paces.
2) I'm not sure what that would even mean ... marking a class or a method
or a response format experimental i can understand but a broad feature
like MultiCore?
: To be honest, I really think we need to start thinking a lot harder about Solr
: on Spring. All this config stuff just makes my head hurt. It can all be so
: much simpler, IMO. In fact, part of me thinks 1.3 should be our last 1.x
: release, but most of me knows that is not realistic. I think w/ Spring, we
I don't really drink from the "Spring would solve all our config/init
problems" Kool-Aid, but i don't disagree with you. My concern right now
is making sure that 1.3 doesn't have a config file with a confusing name
-- if we have more releases after 1.3 that use that our current config
files before we get arround to switching to Spring based configuration,
then that's all the more reason to get it right now -- but even if we said
that we were 100% certain we were switching strategies in the next
release, it still seems worthwhile to me to change the name for 1.3.
: At any rate, that is a side decision. If we really are going to take on the
: multicore issue, then we need to postpone the release, IMO. Otherwise, I
: think we should just label it as it is expected to change in the next release.
If we just rename the file, i really don't see it as being that big of a
deal ... i suspect it could be done pretty easily without needing to delay
the release.
-Hoss
Re: Rename multicore.xml ?
Posted by Yonik Seeley <yo...@apache.org>.
On Thu, Aug 7, 2008 at 3:39 PM, Grant Ingersoll <gs...@apache.org> wrote:
> What about solr.xml and it is always there?
And if it's not there (because of backward compatibility), then the
current dir is a solr home. This is just "Suggestion #1", right?
> Also, maybe we should also mark multicore as experimental (starting to sound
> like a lot of Solr is "experimental", these days, what w/ a good number of
> output formats marked w/ that warning).
Actually, perhaps we can remove that warning from the update
responses... it's been a while.
-Yonik
Re: Rename multicore.xml ?
Posted by Grant Ingersoll <gs...@apache.org>.
What about solr.xml and it is always there? A single core is just
multicore with one core. I know that one's been tossed around
before. Of course, back compat. gets in the way a bit.
Also, maybe we should also mark multicore as experimental (starting to
sound like a lot of Solr is "experimental", these days, what w/ a good
number of output formats marked w/ that warning).
To be honest, I really think we need to start thinking a lot harder
about Solr on Spring. All this config stuff just makes my head hurt.
It can all be so much simpler, IMO. In fact, part of me thinks 1.3
should be our last 1.x release, but most of me knows that is not
realistic. I think w/ Spring, we can keep the same core search
functionality, and input/output APIs, and make the config a lot
simpler, or at least more well known and obvious. I know, I should
submit a patch... There's also a part of me that thinks the config
and schema should be able to be initialized completely
programmatically w/o any XML whatsoever. Using Spring should allow
that.
At any rate, that is a side decision. If we really are going to take
on the multicore issue, then we need to postpone the release, IMO.
Otherwise, I think we should just label it as it is expected to change
in the next release.
-Grant
On Aug 7, 2008, at 3:26 PM, Yonik Seeley wrote:
> As far as name, I like solr.xml better than multicore.xml
> Option #2 is interesting... and might be even more so if files in the
> base conf directory could act as defaults (perhaps a future feature).
>
> -Yonik
>
>
> On Thu, Aug 7, 2008 at 2:51 PM, Chris Hostetter
> <ho...@fucit.org> wrote:
>>
>> I know I probably should have brought this up a little farther in
>> advance of
>> releasing 1.3 (I think i did bring it up back when multicore was
>> first added
>> ,but then I kind of forgot about it) but I have some concerns about
>> the name
>> of the "multicore.xml" file. If I'm alone, I'll let it go, but if
>> other
>> people think I have a point, we should make the change it prior to
>> the
>> release.
>>
>> Main Concern...
>>
>> From the standpoint of debugging, answering questions, and general
>> "Understanding" of a Solr installation the first thing you always
>> have to
>> ask with 1.3 is "What is the Solr Home directory?" and the second
>> thing is
>> "What does the ./conf/solrconfig.xml file look like?"
>>
>> As the trunk stands now, the new second question becomes "Is there a
>> ./multicore.xml?" ... because if there is, then it doesn't matter
>> what
>> ./conf/solrconfig.xml looks like, it's totally ignored 9and you can
>> be
>> certain that some confusion like that will pop up as people switch
>> from
>> traditional single core to usage to multicore usage, there will be
>> some
>> ./conf/solrconfig.xml files lying around).
>>
>> The question can't even be "Is this instance of Solr using multiple
>> cores?"
>> because that's not what really matters, what matters is the
>> multicore.xml
>> file. A person might only be using one core, but if multicore.xml
>> exists it
>> determines where to look for all of the configs for that core, not
>> ./conf/solrconfig.xml.
>>
>> So far, I see two problems with this:
>> 1) The name of the file corresponds with one specific way it can be
>> used, but may not be applicable to all usages (namely: you can
>> have a multicore.xml file but only use one core)
>> 2) The "first" config file checked to determine the application's
>> behavior, and what paths will be checked for other config files
>> is named after one specific feature of the application.
>>
>> From a historical perspective, our current setup would be like if
>> the Apache
>> HTTPD server had originally used ./conf/httpd.conf as the primary
>> config,
>> but when VirtualHost features were added, started saying "If there
>> is a
>> ./virtualhost.conf file it will be read first, and it will tell us
>> which
>> httpd.conf files to read, even if there is only one VirtualHost."
>>
>> This seems odd to me, and likely to confuse new users.
>> Am I alone in this opinion?
>>
>> I have two suggested alternatives:
>>
>> Suggestion #1: Rename multicore.xml something new.
>>
>> The best suggestion I have is "solr.xml" -- It is a good name to
>> represent
>> the "first" config file Solr looks for. If it exists in the Solr
>> Home
>> Directory, it will tell us how many cores to run, and what
>> directories to
>> use for them. (Someday we might even want to consider allowing a
>> system
>> property / JNDI property specify it directly instead of specifying
>> Solr
>> Home) and if it doesn't exist we assume a single core whose
>> instanceDir is
>> the Solr Home Dir.
>>
>> This seems pretty straight forward. The only changes we'd *have*
>> to make
>> would be some string literals and some documentation (and svn
>> renaming the
>> example multicore.xml). But we should also consider changing
>> adding a new
>> root XML tag in multicore.xml wrapping the existing <multicore>
>> with a
>> <solr> ... that would give us a little more flexibility in the
>> future.
>>
>>
>> Suggestion #2: Change solrconfig.xml parsing to understand
>> <multicore>
>>
>> This one is a little weird, part of me thinks it's really the best
>> way to
>> go, but part of me thinks i's really awkward compared to having a
>> solr.xml.
>> The nushell would be that we always look for ./conf/solrconfig.xml
>> first
>> and if the root tag is <multicore> we go into MultiCore mode, and
>> if not we
>> go into SingleCore mode.
>>
>> The big advantage here would be that debuging a Solr instance or
>> answering
>> questions becomes really straight forward. Instead of asking "Is
>> there a
>> multicore.xml/solr.xml?" and then depending on the answer asking
>> "What does
>> ./conf/xolrconfig.xml look like?" the only thing you have to know
>> is "What
>> does ./conf/xolrconfig.xml look like?"
>>
>> The possible downsides: More changes to code now before the
>> release; A
>> somewhat awkward Solr Home directory structure when you are using
>> multiple
>> cores (Even if you have different instanceDirs for each core, your
>> main Solr
>> Home directory still needs to contain ./conf/ which needs to
>> contain a
>> solrconfig.xml); And having one file support two radically
>> different types
>> of content.
>>
>> Most installs probably keep all of their instance dirs in Solr
>> Home, so the
>> directory layout of Suggestion#2 doesn't seem too awkward compared to
>> Suggestion#1...
>>
>> solr-home/ (Suggestion#1)
>> solr-home/solr.xml (current multicore.xml)
>> solr-home/instanceDir1/
>> solr-home/instanceDir1/...
>> solr-home/instanceDir2/
>> solr-home/instanceDir2/...
>> solr-home/...
>> ...vs...
>> solr-home/ (Suggestion#2)
>> solr-home/conf/
>> solr-home/conf/solrconfig.xml (current multicore.xml)
>> solr-home/instanceDir1/
>> solr-home/instanceDir1/...
>> solr-home/instanceDir2/
>> solr-home/instanceDir2/...
>> solr-home/...
>>
>> ...But i'm sure opinions vary.
>>
>> What do people think?
>> Is this going to confuse new users who come along, and make
>> troubleshooting
>> as confusing as I suspect, or am I just being paranoid?
>>
>> Even if I am being paranoid: is there any downside to Suggestion #1
>>
>>
>>
>> -Hoss
>>
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
Re: Rename multicore.xml ?
Posted by Yonik Seeley <yo...@apache.org>.
As far as name, I like solr.xml better than multicore.xml
Option #2 is interesting... and might be even more so if files in the
base conf directory could act as defaults (perhaps a future feature).
-Yonik
On Thu, Aug 7, 2008 at 2:51 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> I know I probably should have brought this up a little farther in advance of
> releasing 1.3 (I think i did bring it up back when multicore was first added
> ,but then I kind of forgot about it) but I have some concerns about the name
> of the "multicore.xml" file. If I'm alone, I'll let it go, but if other
> people think I have a point, we should make the change it prior to the
> release.
>
> Main Concern...
>
> From the standpoint of debugging, answering questions, and general
> "Understanding" of a Solr installation the first thing you always have to
> ask with 1.3 is "What is the Solr Home directory?" and the second thing is
> "What does the ./conf/solrconfig.xml file look like?"
>
> As the trunk stands now, the new second question becomes "Is there a
> ./multicore.xml?" ... because if there is, then it doesn't matter what
> ./conf/solrconfig.xml looks like, it's totally ignored 9and you can be
> certain that some confusion like that will pop up as people switch from
> traditional single core to usage to multicore usage, there will be some
> ./conf/solrconfig.xml files lying around).
>
> The question can't even be "Is this instance of Solr using multiple cores?"
> because that's not what really matters, what matters is the multicore.xml
> file. A person might only be using one core, but if multicore.xml exists it
> determines where to look for all of the configs for that core, not
> ./conf/solrconfig.xml.
>
> So far, I see two problems with this:
> 1) The name of the file corresponds with one specific way it can be
> used, but may not be applicable to all usages (namely: you can
> have a multicore.xml file but only use one core)
> 2) The "first" config file checked to determine the application's
> behavior, and what paths will be checked for other config files
> is named after one specific feature of the application.
>
> From a historical perspective, our current setup would be like if the Apache
> HTTPD server had originally used ./conf/httpd.conf as the primary config,
> but when VirtualHost features were added, started saying "If there is a
> ./virtualhost.conf file it will be read first, and it will tell us which
> httpd.conf files to read, even if there is only one VirtualHost."
>
> This seems odd to me, and likely to confuse new users.
> Am I alone in this opinion?
>
> I have two suggested alternatives:
>
> Suggestion #1: Rename multicore.xml something new.
>
> The best suggestion I have is "solr.xml" -- It is a good name to represent
> the "first" config file Solr looks for. If it exists in the Solr Home
> Directory, it will tell us how many cores to run, and what directories to
> use for them. (Someday we might even want to consider allowing a system
> property / JNDI property specify it directly instead of specifying Solr
> Home) and if it doesn't exist we assume a single core whose instanceDir is
> the Solr Home Dir.
>
> This seems pretty straight forward. The only changes we'd *have* to make
> would be some string literals and some documentation (and svn renaming the
> example multicore.xml). But we should also consider changing adding a new
> root XML tag in multicore.xml wrapping the existing <multicore> with a
> <solr> ... that would give us a little more flexibility in the future.
>
>
> Suggestion #2: Change solrconfig.xml parsing to understand <multicore>
>
> This one is a little weird, part of me thinks it's really the best way to
> go, but part of me thinks i's really awkward compared to having a solr.xml.
> The nushell would be that we always look for ./conf/solrconfig.xml first
> and if the root tag is <multicore> we go into MultiCore mode, and if not we
> go into SingleCore mode.
>
> The big advantage here would be that debuging a Solr instance or answering
> questions becomes really straight forward. Instead of asking "Is there a
> multicore.xml/solr.xml?" and then depending on the answer asking "What does
> ./conf/xolrconfig.xml look like?" the only thing you have to know is "What
> does ./conf/xolrconfig.xml look like?"
>
> The possible downsides: More changes to code now before the release; A
> somewhat awkward Solr Home directory structure when you are using multiple
> cores (Even if you have different instanceDirs for each core, your main Solr
> Home directory still needs to contain ./conf/ which needs to contain a
> solrconfig.xml); And having one file support two radically different types
> of content.
>
> Most installs probably keep all of their instance dirs in Solr Home, so the
> directory layout of Suggestion#2 doesn't seem too awkward compared to
> Suggestion#1...
>
> solr-home/ (Suggestion#1)
> solr-home/solr.xml (current multicore.xml)
> solr-home/instanceDir1/
> solr-home/instanceDir1/...
> solr-home/instanceDir2/
> solr-home/instanceDir2/...
> solr-home/...
> ...vs...
> solr-home/ (Suggestion#2)
> solr-home/conf/
> solr-home/conf/solrconfig.xml (current multicore.xml)
> solr-home/instanceDir1/
> solr-home/instanceDir1/...
> solr-home/instanceDir2/
> solr-home/instanceDir2/...
> solr-home/...
>
> ...But i'm sure opinions vary.
>
> What do people think?
> Is this going to confuse new users who come along, and make troubleshooting
> as confusing as I suspect, or am I just being paranoid?
>
> Even if I am being paranoid: is there any downside to Suggestion #1
>
>
>
> -Hoss
>
>
Re: Rename multicore.xml ?
Posted by Ryan McKinley <ry...@gmail.com>.
>
> While we are on the topic.... what about the MultiCore.java class?
> Should it be CoreContainer?
or SolrContainer? or just Solr?
Re: Rename multicore.xml ?
Posted by Chris Hostetter <ho...@fucit.org>.
: While we are on the topic.... what about the MultiCore.java class?
: Should it be CoreContainer? All your same logic applies
I'm less concerned about classnames:
1) they're easier to refactor in the long run
2) they are seen by less people
-Hoss
Re: Rename multicore.xml ?
Posted by Ryan McKinley <ry...@gmail.com>.
>
> Suggestion #1: Rename multicore.xml something new.
>
> The best suggestion I have is "solr.xml"
+1
Hopefully down the line, these xml files will not be how we configure
things. With Spring we could get out of that business.
While we are on the topic.... what about the MultiCore.java class?
Should it be CoreContainer? All your same logic applies
ryan
Re: Rename multicore.xml ?
Posted by Chris Hostetter <ho...@fucit.org>.
: Might also be good to rename Multicore class into the Solr class at the same
: time but I'd like to (re)inject it as @deprecated class MultiCore extends
: Solr...
that sounds fine to me ... but as i mentioned before, i'm not really
concerned about the MultiCore class name for the release, it can be
changed at anytime, and is fairly invisible to most users.
: On the Spring topic, it seems a lot of committers agree this is the way to
: go in the future. Does this mean all the configuration code is throw away?
: Will we have some upwards compatiblity on the XML config/schema files or
I have no idea what a Spring-ified version of Solr will look like, I don't
think anyone has looked into it enough to have any idea.
I *suspect* it will be a major undertaking and look radically different
from Solr today -- both in terms of APIs and in terms of configuration.
But i'm not really worried about what it will look like "then". I'll let
the Spring disciples worry about it (I have not gotten on the Spring bus,
but if enough Solr contributors to get on, and pedal really hard, I have
no objection to being dragged along behind).
My concern is this: I don't know exactly how many more versions of Solr
will be released between now and "then", but I know it will be at least
one (1.3) so i want to make sure the syntax in that version (and however
many others follow in it's footsteps) make sense to both existing and new
users.
-Hoss
Re: Rename multicore.xml ?
Posted by Henrib <hb...@gmail.com>.
> Suggestion #1: Rename multicore.xml something new.
>
> The best suggestion I have is "solr.xml"
+1
Might also be good to rename Multicore class into the Solr class at the same
time but I'd like to (re)inject it as @deprecated class MultiCore extends
Solr...
Since we are deprecating SolrCore.getCore() in 1.3 (no more unnamed core &
al), the easy path is to become 'multi-core' in all cases in 1.4.
On the Spring topic, it seems a lot of committers agree this is the way to
go in the future. Does this mean all the configuration code is throw away?
Will we have some upwards compatiblity on the XML config/schema files or
will Solr 2.0 become a 'lucene-for-spring' ? Isn't there anything we could
do to ease the pain in the mean time or is it worthless ?
Regards
Henrib
--
View this message in context: http://www.nabble.com/Rename-multicore.xml---tp18877268p18881673.html
Sent from the Solr - Dev mailing list archive at Nabble.com.