Re: Solr 1.2 released
Hello Yonik, This is great news. Will it be a drop-in replacement for 1.1? I.e., do I need to make any changes other than replacing the jar files? I suppose the index files will still be good. Are 1.2 schema files and config files compatible with those of 1.1? -- Best regards, Jack Thursday, June 7, 2007, 7:32:18 AM, you wrote: Solr 1.2 is now available for download! This is the first release since Solr graduated from the Incubator, and includes many improvements, including CSV/delimited-text data loading, time based auto-commit, faster faceting, negative filters, a spell-check handler, sounds-like word filters, regex text filters, and more flexible plugins. Solr releases can be downloaded from http://www.apache.org/dyn/closer.cgi/lucene/solr/ -Yonik
Re: Solr 1.2 released
On 6/8/07, Jack L [EMAIL PROTECTED] wrote: This is great news. Will it be a drop-in replacement for 1.1? I.e., do I need to make any changes other than replacing the jar files? I suppose the index files will still be good. Are 1.2 schema files and config files compatible with those of 1.1? It should be easy to upgrade. See the release notes (CHANGES.txt)... there is a section on upgrading from 1.1 -Yonik
RE: Solr 1.2 released
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) 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?) I tried putting this jar in the top-level lib and example/solr/lib, but the jar wasn't recognized. Where should I put jars shared by multiple shared apps? BTW, in order to invsetigate this, I inspected the start.conf file inside start.jar and it seems the new start.jar 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.) -kuro
RE: Solr 1.2 released
: 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
