: I noticed there is no example/ext
: directory or jars that was found there
: in 1.1 (commons-el.jar, commons-logging.jar,
: jasper-*.jar, mx4j-*.jar)
the example/ext directory was an entirly Jetty based artifact. when we
upgraded the Jetty used in the example setup, Jetty no longer had an ext
directory, so it was removed.
: I have a jar that my Solr plugin depends on.
: This jar contains a class that needs to be
: loaded only once per container because
: it is a JNI library. For that reason, it
: cannot be placed in a per-webapp lib
: directory. (I am assuming placing the jars
: in example/solr/lib is same as placing them
: in each web app's WEB-INF/lib, from the
: class loading point of view. Am I right?)
not exactly, i custom classloader is constructed for the ${solr.home}/lib
directory, but it is a child loader of the Servlet Context loader, so you
are probably right about it being a poor place to put a JNI library.
: Where should I put jars shared by multiple
: shared apps?
that really depends on your servlet container. The scaled down Jetty
instance provided is purely an *example* so that people who want to try
solr can do so without needing to download, install, and understand the
configuration of a servlet container. If you want to use Jetty 6, then
you should read the Jetty docs to learn more about loading classes in the
system classloader. Alternately if you liked Jetty 5 (which is what was
used in the Solr 1.1 example) you can use it ... but people really
shouldn't count on the servlet container provided to power the example
behaving consistent as new versions of Solr come out -- it might switch to
tomcat in the next version, it all depneds on which was is simpler,
smaller, easier to setup for the example, etc...
: is expecting to find ant.jar in this
: fixed location:
: /usr/share/java/
:
: Is this intended? (I don't know why jetty
: needs ant anyway.)
i really can't say ... it's purely a Jetty thing. We make no
modifications to Jetty's start.jar
-Hoss
