[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759969#action_12759969
]
Hoss Man commented on SOLR-1449:
--------------------------------
bq. Is this an issue which users have reported? in my experience with Solr
mailing list, I am yet to see a request where users wish to add arbitrary
directories to classpath
I don't really feel like searching through the archives at the moment, but it
has come up -- i don't know if anyone has explicitly requested the ability to
add arbitrary directories, but there have certainly been discussions about the
annoyance of needing to copy and/or symlink jars.
If nothing else: I'm a user, and i'm requesting it.
bq. How important is this feature to be in 1.4?
As i said in my first comment i don't know.
It would be nice to have, but i certainly don't think it's a blocker ... even
with the testing i've done, and even with the new tests i added to the patch,
and even though the behavior for existing ./lib users hasn't been changed, i
still wouldn't consider committing unless other people try it out and gave it a
thumbs up.
bq. Users in general have a lot of problems with classloading. Even with the
current support with one lib directory I have seen so many users having trouble
with classloading . This can only add to that confusion
I don't really see how this will make confusion about classloading any worse.
most problems i can think of where people have classloader difficulty in solr
stem from not understanding where they are suppose to copy their jars -- they
tend to get confused about which "lib" directory, particularly with example/lib
containing the jetty jars. Allowing people to put the jar any where they want
and point at it by name in the config file should _reduce_ confusion.
Besides which: they're still free to create a ./lib dir and copy jars -- that
still works, no configuration needed.
I agree that the original patch (with the order in the config mattering) would
have been confusing for people, but with the more recent patches where all jars
are in the same classloader i can't imagine any situation where this will cause
more problems/confusion then forcing people to make a lib dir.
bq. I am sure most of the users will be happy with the minimal solr. The rest
of them will happily download the whole thing however big it is.
I *REALLY* don't want to argue the merrits of this issue as if it's purpose was
to decrease the size of the distribution -- it was _not_ the purpose, it's just
a possible additional benefit -- but i *HAVE* to disagree with you on this ...
most users may only _need_ a minimal solr, but we should not passively
discourage people from finding features that can make them happier by making
those features more complex to get (via an alternate larger download).
Adding this feature, and using it to reduce the size of the _current_ examples
may not reduce the size of the _current_ distribution enough to be worth
worrying about, that's fine. But i'm trying to thing longer term: there have
been multiple threads discussing the goal of adding *many* more example
directories demonstrating cool use cases of solr via interesting permutations
of features (DIH, clustering, solr cell, velocity, etc...). This patch (or
something like it) is going to be necessary before we can do anything like that.
> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---------------------------------------------------------------------------
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was
> a way to configure a core to load plugins from specific jars (or "classes"
> style directories) by path w/o needing to copy them to the "./lib" dir in
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the
> situation of the Solr Release artifacts, where we wind up making numerous
> copies of jars to support multiple example directories (you can't have
> reliable symlinks in zip files)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
