[
https://issues.apache.org/jira/browse/SOLR-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791363#comment-13791363
]
Dawid Weiss commented on SOLR-5323:
-----------------------------------
bq. Hmmm, I agree this is a bug.
Ok, I admit I don't know what is the "right" way to fix this. I also don't
think this issue applies to the clustering contrib only.
There are several <lib/> elements in the example configuration and they all use
relative paths to load additional components. So after you change the relative
folder structure any "example" using these will fail to load, the clustering
component just happens to be loaded eagerly so it triggers a failure sooner.
I've had real life use cases when hard-coded relative paths proved very
confusing so I'd opt for something like Erik mentioned -- making <lib/>
components reference JARs relative to some notion of an "installation" folder.
Ideally, this should also be inferred automatically if it's not given on
command line and if somebody runs Solr from the unpacked default structure. I
can prepare a patch that will try to guess and set "solr.install.dir" based on
the classloader URI leading to one of the core classes (SolrCore, for example).
Once we locate the core JAR we can sniff for ../contrib and ../dist and if
these are present set the install dir in the upper folder.
This is, obviously, a hack. If somebody runs from a WAR file or changes the
default directory structure things will break. I assume if they do so they'll
also be able to change the example's default paths (or override
solr.install.dir explicitly).
I'm also not 100% confident how the above will work in the distributed setting
-- soliciting feedback here.
Anyway, if the above sound all right I will prepare a patch. I don't have any
sensible alternatives other than turning off the clustering component by
default. I would be against this, however, because like I said -- this only
hides the problem, not solves it (the default configuration will still be
"unmovable" from the default directory structure).
> Solr requires -Dsolr.clustering.enabled=false when pointing at example config
> -----------------------------------------------------------------------------
>
> Key: SOLR-5323
> URL: https://issues.apache.org/jira/browse/SOLR-5323
> Project: Solr
> Issue Type: Bug
> Components: contrib - Clustering
> Affects Versions: 4.5
> Environment: vanilla mac
> Reporter: John Berryman
> Assignee: Dawid Weiss
> Fix For: 4.6, 5.0
>
>
> my typical use of Solr is something like this:
> {code}
> cd SOLR_HOME/example
> cp -r solr /myProjectDir/solr_home
> java -jar -Dsolr.solr.home=/myProjectDir/solr_home start.jar
> {code}
> But in solr 4.5.0 this fails to start successfully. I get an error:
> {code}
> org.apache.solr.common.SolrException: Error loading class
> 'solr.clustering.ClusteringComponent'
> {code}
> The reason is because solr.clustering.enabled defaults to true now. I don't
> know why this might be the case.
> you can get around it with
> {code}
> java -jar -Dsolr.solr.home=/myProjectDir/solr_home
> -Dsolr.clustering.enabled=false start.jar
> {code}
> SOLR-4708 is when this became an issue.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
