lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir
Date Sun, 27 Sep 2009 00:33:15 GMT


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

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:
>             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.

View raw message