nfig, 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
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
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
On Thu, Aug 7, 2008 at 3:39 PM, Grant Ingersoll <[EMAIL PROTECTED]> 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 multicor
>
> 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 th
>
> While we are on the topic what about the MultiCore.java class?
> Should it be CoreContainer?
or SolrContainer? or just Solr?
: 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
: 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.
:
> 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...
: 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 c
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/c
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 h
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 hij
rename multicore.xml solr.xml
-
Key: SOLR-689
URL: https://issues.apache.org/jira/browse/SOLR-689
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
Fix For: 1.3
Per mailing list
n still be done, but are less crucial in my opinion)
Comments? Objections to this being committed?
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
&g
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-689:
--
Description:
Per mailing list discussion (see link below) it seems prudent to rename
multicore.xml to solr.xml
olve file renaming apply
to this patch. care should be taken when applying it to ensure that the
subsequent commit includes both the file history of
"example/multicore/multicore.xml" as well as the changes that were made to it
after it was renamed.
> rename multi
", false );
+ adminPath = cfg.get( "//multicore/@adminPath", null );
+ libDir = cfg.get( "//multicore/@sharedLib", null);
{code}
is that just safer since we may not be at the root?
> rename multicore.xml solr.xml
> -
>
>
it will
still work.
(i suppose we could output a warning if it's not rooted with but for
now i wanted to keep the patch as simple as possible to meet the immediate
goals)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
&g
g at once.
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hoss Ma
s there is
a clear delineation. perhaps?
How about...
{code}
{code}
?
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
>
ture :)
Yes, i like that -- keeping adminPath with makes sense too
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
>
info out to solr.xml and includes
root tag
{code}
writer.write("\n");
writer.write("\n");
{code}
should be:
{code}
writer.write("\n");
writer.write("\n");
{code}
:)
> rename multicore.xml solr.xml
> -
{code}
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project: Solr
> Issue Type: Improvement
>Reporter: Hos
d probably should be, independent
from this patch, but if you attach it here i'll commit as well
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
>
t is to create properties that apply to all cores, but can't
be used elsewhere in the solr.xml, they should be in the tag. we could
have both, or just one depending on the use cases people have identified.
> rename multicore.xml solr.xml
> -
>
>
ot. (Much like having or not to group cores) so
I could prepare a new version of the solr-646 patch (and add a persist test
including properties).
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
>
hen commit
SOLR-689.patch; worry about SOLR-646 and any changes it makes separately)
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SOLR-689
> Project:
[
https://issues.apache.org/jira/browse/SOLR-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-689.
---
Resolution: Fixed
Assignee: Hoss Man
Committed revision 685244.
> rename multicore.xml solr.
e.java config persistence writes info out to solr.xml and
includes root tag
{code}
writer.write("\n");
writer.write("\n");
{code}
should be:
{code}
writer.write("\n");
writer.write("\n");
{code}
:)
> rename multicore.xml solr.xml
> --
can be, and probably should be, independent
from this patch, but if you attach it here i'll commit as well
> rename multicore.xml solr.xml
> -
>
> Key: SOLR-689
> URL: https://issues.apache.org/jira/browse/SO
but i
ment it would be nice to have a persistence test that worked against the trunk
as it is right now, to prove that the behavior doesn't break when the
SOLR-689.patch is applied. (ie: commit a persistence test first, then commit
SOLR-689.patch; worry ab
32 matches
Mail list logo
