Packaging solr for Debian: using debian-supplied lucene-*.jar
Hi all, I'm working on packaging Solr for Debian. The package will install Solr as a Tomcat 5.5 webapp. I got the package working, but I would like the package to use the Debian-supplied lucene and xpp3 .jar files, which with Debian are installed under /usr/share/java. It is Debian policy not to unnecessarily duplicate .jars on the same system. I've tried the following approaches without success: - putting full paths to the .jars in META-INF/MANIFEST.MF - symlinking the .jars in /usr/share/java to /usr/share/solr/WEB-INF/lib - symlinking the .jars in /usr/share/java to /usr/share/tomcat5.5/shared/lib Does anyone know how to get Tomcat to use the .jars under /usr/share/java for the solr webapp? If you're interested: SVN repository (read-only): http://svn.vanbest.org/svn/solr Websvn: http://svn.vanbest.org/websvn/listing.php?repname=solr Private Debian repository: http://www.vanbest.org/debian/ Thanks for any help, Jan-Pascal signature.asc Description: OpenPGP digital signature
distributed search
Hello all, Is there distributed support in Solr search engine? For example install solr instance on different server and have them load balanced. Anyway, any suggestion/experience about Solr distributed search topic is appreciated. Regards, David
Re: distributed search
David - It depends on what "distributed" means in your question. If you're looking for high availability, that can be accomplished through typical load balancing schemes for the servlet container that's running solr. Solr helps out in this respect with a replication scheme using rsync that keeps the indexes updated on all load-balanced nodes. If you're looking for support for bigger indexes that don't fit inside one solr instance (multiple solr instances = one search index), it's presently not available (as far as I know.) Work has progressed in the area of federated search (http://wiki.apache.org/solr/FederatedSearch). There are many challenges to accomplishing this; the wiki outlines where progress has been made. -- j On 6/3/07, David Xiao <[EMAIL PROTECTED]> wrote: Hello all, Is there distributed support in Solr search engine? For example install solr instance on different server and have them load balanced. Anyway, any suggestion/experience about Solr distributed search topic is appreciated. Regards, David
Re: Packaging solr for Debian: using debian-supplied lucene-*.jar
: as a Tomcat 5.5 webapp. I got the package working, but I would like the : package to use the Debian-supplied lucene and xpp3 .jar files, which : with Debian are installed under /usr/share/java. It is Debian policy not : to unnecessarily duplicate .jars on the same system. : : I've tried the following approaches without success: 1) can you define "without success"? what was the observed behavior? 2) i'm vaguely familiar with debian policy on "no redundency" but i'm not sure it relaly applies here ... the published releases of Solr only include one jar: the solr.jar (which contains solr source code for use in compiling plugins). other jars are bundled into the solr.war which should be considered a single "binary" entity ... much like a C app might link in a bunch of independently compiled object files. attempting to "extract" those jars from the solr.war and reuse other jars installed by other packages is like trying to unlink that C program and make it use shared object files instead --- it's a pretty big leap. 3) Some of the jars Solr inlcudes in it's war are not the officially released version of third party software. We frequently use development versions (varefully noting which version in our README) when we feel they are stable enough and provide important features. For this reason, you may find it hard to achieve your goal in a forward maintainable manner no matter what. -Hoss
Re: Packaging solr for Debian: using debian-supplied lucene-*.jar
: 2) i'm vaguely familiar with debian policy on "no redundency" but i'm not : sure it relaly applies here ... the published releases of Solr only : include one jar: the solr.jar (which contains solr source code for use in whoops ... my bad, i forgot we do actually include all of the other jars in the "lib" directory of the release ball for users compiling plugins, but they aren't used by a running instance of solr.war (it has copies of them embedded in it) and can easily be excluded from a downstream package. all of my other comments are still very applicable however.. : compiling plugins). other jars are bundled into the solr.war which should : be considered a single "binary" entity ... much like a C app might link in : a bunch of independently compiled object files. attempting to : "extract" those jars from the solr.war and reuse other jars installed by : other packages is like trying to unlink that C program and make it use : shared object files instead --- it's a pretty big leap. : : 3) Some of the jars Solr inlcudes in it's war are not the officially : released version of third party software. We frequently use development : versions (varefully noting which version in our README) when we feel they : are stable enough and provide important features. For this reason, you : may find it hard to achieve your goal in a forward maintainable manner no : matter what. -Hoss
welcome solr1.2
thks Solr Committers -- regards jl
can't start solr by tomcat
solr 1.3dev 2007-06-04(svn) tomcat log show me error information: solr 1.3dev 2007-06-04 org.apache.solr.core.SolrException: Unknown fieldtype 'string' i find it only use in shema.xml i modifiy it and now start is ok property required means? i not find it in comment. -- regards jl
Re: can't start solr by tomcat
i modifiy it and now start is ok property required means? i not find it in comment. "required" means that the field *must* be specified when you add it to the index. If it isn't there, you will get an error. If you upgrade or work from trunk, make sure to read CHANGES.txt carefully -- when 1.2 is officially released (soon I swear!) this will be made very clear. ryan
Re: can't start solr by tomcat
thks,ryan, i find "required" in changes.txt 2007/6/4, Ryan McKinley < [EMAIL PROTECTED]>: > > i modifiy it and now start is ok > >> >> > > property required means? > i not find it in comment. > "required" means that the field *must* be specified when you add it to the index. If it isn't there, you will get an error. If you upgrade or work from trunk, make sure to read CHANGES.txt carefully -- when 1.2 is officially released (soon I swear!) this will be made very clear. ryan -- regards jl
