solr源码分析
⑴ java web 怎么用solr
我们下载的Solr包后，进入Solr所在的目录，我们可以看到以下几个目录：build、client、dist、example、lib、site、src。下面分别对其进行介绍。
1) build：该目录是在ant build过程中生成的，其中包含了未被打包成jar或是war的class文件以及一些文档文件。
2) client：该目录包含了特定语言的Solr客户端API，使得使用其他语言的用户能通过HTTP用XML与Solr进行通话。现在该目录里面虽然包含javascript、python、ruby三个子目录，但是到目前为止只包含一部分的ruby的代码，其他语言仍是空的。另外，Solr的Java客户端称为SolrJ，其代码位于src/solrj目录下面。在之后的文章中我会详细介绍Solr客户端的使用。
3) dist：该目录包含build过程中产生的war和jar文件，以及相关的依赖文件。还记得上一篇文章中，我们在build 1.4版本的Solr源代码后需要部署example吗？其实就是将该目录下面的apache-solr-1.4.war部署到Jetty上面去，并重命名为solr.war。
4) example：这个目录实际上是Jetty的安装目录。其中包含了一些样例数据和一些Solr的配置。
其中一些子目录也比较重要，这里也对它们稍作介绍。
l example/etc：该目录包含了Jetty的配置，在这里我们可以将Jetty的默认端口从8983改为80端口。
l 将其中的8983端口换成80端口。注意更改端口后启动Jetty可能会提示你没有权限，你需要使用sudo java -jar start.jar来运行。
l example/multicore：该目录包含了在Solr的multicore中设置的多个home目录。在之后的文章中我会对其进行介绍。
l example/solr：该目录是一个包含了默认配置信息的Solr的home目录。
详见下面的“solr home说明”
l example/webapps：Jetty的webapps目录，该目录通常用来放置Java的Web应用程序。在Solr中，前面提到的solr.war文件就部署在这里。
5) lib：该目录包含了所有Solr的API所依赖的库文件。其中包括Lucene，Apache commons utilities和用来处理XML的Stax库。
6) site：该目录仅仅包含了Solr的官网的网页内容，以及一些教程的PDF文档。
7) src：该目录包含了Solr项目的整个源代码。这里对其各个子目录也做相应的介绍。
l src/java：该目录存放的是Solr使用Java编写的源代码。
l src/scripts：该目录存放的是配置Solr服务器的Unix BashShell脚本，在后面介绍多服务器配置中将会有重要的作用。
l src/solrj：前面提到过该目录存放的是Solr的Java版本的客户端代码。
l src/test：该目录存放的是测试程序的源代码和测试文件。
l src/webapp：该目录存放的是管理Solr的Web页面，包括Servlet和JSP文件，其构成了前面提到的WAR文件。管理Solr的JSP页面在web/admin目录下面，如果你有兴趣折腾Solr可以找到相应的JSP的页面对其进行设置
1.4.2 Solr home说明
所谓的Solr home目录实际上是一个运行的Solr实例所对应的配置和数据（Lucene索引）。在上一篇文章中我提到过在Solr的example/solr目录就是一个Solr用做示例的默认配置home目录。实际上example/multicore也是一个合法的Solr home目录，只不过是用来做mult-core设置的。那么我们来看看example/solr这个目录里面都有些什么。
example/solr目录下主要有以下一些目录和文件：
1) bin：如果你需要对Solr进行更高级的配置，该目录建议用来存放Solr的复制脚本。
2) conf ：该目录下面包含了各种配置文件，下面列出了两个最为重要的配置文件。其余的.txt和.xml文件被这两个文件所引用，如用来对文本进行特殊的处理。
l conf/schema.xml：该文件是索引的schema，包含了域类型的定义以及相关联的analyzer链。
l conf/solrconfig.xml：该文件是Solr的主配置文件。
l conf/xslt：该目录包含了各种XSLT文件，能将Solr的查询响应转换成不同的格式，如：Atom/RSS等。
3) data：包含了Lucene的二进制索引文件。
4) lib：该目录是可选的。用来放置附加的Java JAR文件，Solr在启动时会自动加载该目录下的JAR文件。这就使得用户可以对Solr的发布版本（solr.war）进行扩展。如果你的扩展并不对Solr本身进行修改，那么就可以将你的修改部署到JAR文件中放到这里。
Solr是如何找到运行所需要的home目录的呢？
Solr首先检查名为solr.solr.home的Java系统属性，有几种不同的方式来设置该Java系统属性。一种不管你使用什么样的Java应用服务器或Servlet引擎都通用的方法是在调用Java的命令行中进行设置。所以，你可以在启动Jetty的时候显式地指定Solr的home目录java -Dsolr.solr.home=solr/ -jar start.jar。另一种通用的方法是使用JNDI，将home目录绑定到java:comp/env/solr/home。并向src/webapp/web/WEB-INF/web.xml添加以下一段代码：
1 <env-entry>
2 <env-entry-name>solr/home</env-entry-name>
3 <env-entry-value>solr/</env-entry-value>
4 <env-entry-type>java.lang.String</env-entry-type>
5 </env-entry>
实际上这段XML在web.xml文件中已经存在，你只需要把原来注释掉的xml取消注释，添加你所要指向的home目录即可。因为修改了web.xml文件，所以你需要运行antdist-war来重新打包之后再部署WAR文件。
最后，如果Solr的home目录既没有通过Java系统属性指定也没有通过JNDI指定，那么他将默认指向solr/。
在产品环境中，我们必须设置Solr的home目录而不是让其默认指向solr/。而且应该使用绝对路径，而不是相对路径，因为你有可能从不同的目录下面启动应用服务器。
注：Jetty 是一个开源的servlet容器，它为基于Java的web内容，例如JSP和servlet提供运行环境。Jetty是使用Java语言编写的，它的API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的Java应用提供网络和web连接。
我们先从使用者的角度出发，最先看到的当然是servlet,因为Solr本身是个独立的网络应用程序，需要在Servlet容器中运行来提供服务，所以servlet是用户接触的最外层。我们看看org.apache.solr.servlet包。这个包很简单，只有两个类：SolrServlet和SolrUpdateServlet.我们很容易从类名中猜出这两个类的用途。
SolrServlet类继承HttpServlet类，只有四个方法：
· init()
· destroy()
· doGet()
· doPost()
SolrServlet类中除了普通的Java类对象（包括Servlet相关的）外，有四个Solr本身的类，还有一个Solr本身的异常。其中两个类和一个异常属于org.apache.solr.core包，两个类属于org.apache.solr.request包。属于core包的有：
· Config:
· SolrCore:
属于request包的有：
· SolrQueryResponse:
· QueryResponseWriter:
分析一下这个SolrServlet类。首先servlet会调用init()方法进行初始化：通过Context查找java:comp/env/solr/home来确定Solr的主目录（home），接着调用Config.setInstanceDir(home)方法设置这个实例的目录。然后通过SolrCore.getSolrCore()来获得一个SolrCore实例。destroy()方法将会在Servlet对象销毁时调用，仅仅调用core.close()关闭SolrCore实例。
当用户请求进来时doPost()简单地将任务交给doGet()完成，主要的任务由doGet()完成。分析一下doGet()方法：
1) 使用SolrCore和doGet()参数request生成一个SolrServletRequest对象(注意：这个SolrServletRequest类不是公开类，位于org.apache.solr.servlet包中，继承了SolrQueryRequestBase类，仅仅接受SolrCore和HttpServletRequest对象作为参数)
2) 然后SolrCore执行execute()方法（参数为SolrServletRequest和SolrQueryResponse）
由此可见，真正的处理核心是SolrCore的execute方法
⑵ solr如何实现多语言搜索
ANT_HOME：E:\Work\apache-ant\1.9.1 (这里为你自己解压缩的目录) PATH：%ANT_HOME%\bin （这个设置是为了方便在dos环境下操作）
查看是否安装成功，在命令行窗口中输入命令ant，若出现结果:
说明ant安装成功！因为ant默认运行build.xml文件，这个文件需要我们建立。现在就可以进行build Solr源码了。在命令行窗口中进入到你的Solr源码目录，输入ant会出现当前build.xml使用提示信息。
其它的先不用管它，我们只要针对我们使用的IDE进行build就行了，如果使用eclipse就在命令行输入：ant eclipse.如果使用IntelliJ IDEA 就在命令行输入：ant idea。这样就能进行build了
⑶ solrj的CloudSolrClient源码分析及为什么查询慢
solrj针对solrcloud提供了CloudSolrClient，用于对集群环境solr操作，从一个测试例子，一步步深入，看看CloudSolrClient是如何做查询操作的
1、使用CloudSolrClient发起一个查询请求
2、接着调用CloudSolrClient的request方法
3、CloudSolrClient的request方法中，首先回去获取请求中的collection名字，如果没有，获取默认设置的collcetion，然后调用requestWithRetryOnStaleState方法
4、requestWithRetryOnStaleState方法中，先去连接zk获取solrclound注册在zk上的信息
5、获取zk上的信息，经过处理后，封装到request中，调用sendRequest方法
6、在sendRequest中，会获取每个片的每个replicat的url与注册在zk上的live url做一个交集，得到一个查询url集合，然后创建一个LBHttpSolrClient，请求solrcloud
7、LBHttpSolrClient的request中会在for循环中挨个的轮询上一个步骤中放入的urllist发起http查询请求
在rsp合并结果，并返回
⑷ solr提供的源码怎么打成jar包
1、将解压包中的solr-4.7.1/dist/solr-4.7.1.war复制到tomcat_dir/webapps/目录，并命名为solr.war。 2、将solr-4.7.1/example/lib/ext/目录下的jar文件复制到tomcat/lib目录下，将solr-4.7.1/example/resources/下的log4j.properties文件复制到...
⑸ solr和elasticsearch对比，有啥差别吗
从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。
单机对比
1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。
2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回
3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个Field，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒
4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒
5. 使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730 条记录，约合2577条/秒
6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，第一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms
查询及排序的指令：
{
"query": {
"query_string": {
"query": "*999*"
}
},
"sort": [
{
"TIME_UP": {
"order": "asc"
}
}
]
}
7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730 条记录，约合3965条/秒
8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G
单机对比2
在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。
1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G
2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回
3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。
4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回
5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。
6. 结论：es的查询效率也可以很高，只是我们还不会用。
7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。
备注：
1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。
2. 改回缺省的内存配置，导入速度仍然慢。
3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别
4. 在10G配置的情况下，检索速度也差别不大。
5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？
集群对比：
采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。
1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。
2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）
3. 查询性能：
*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒
*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒
SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s
SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s
4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：
机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &
其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &
但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。
结论
1. 导入性能，es更强
2. 查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升
3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。
⑹ solr组件的角色有哪些
Solr它是一种开放源码的、基于 Lucene Java 的搜索服务器，易于加入到 Web 应用程序中。
二、Solr 提供了层面搜索(就是统计)、命中醒目显示并且支持多种输出格式（包括XML/XSLT 和JSON等格式）。它易于安装和配置，而且附带了一个基于 HTTP 的
管理界面。Solr已经在众多大型的网站中使用，较为成熟和稳定。
三、Solr 包装并扩展了 Lucene，所以Solr的基本上沿用了Lucene的相关术语。更重要的是，Solr 创建的索引与 Lucene 搜索引擎库完全兼容。
四、通过对Solr 进行适当的配置，某些情况下可能需要进行编码，Solr 可以阅读和使用构建到其他 Lucene 应用程序中的索引。
五、此外，很多 Lucene 工具（如Nutch、 Luke）也可以使用Solr 创建的索引。可以使用 Solr 的表现优异的基本搜索功能，也可以对它进行扩展从而满足企业的需要。
solr的优点
通过上面Solr的简介，可知solr的优点包括以下几个方面：
①高级的全文搜索功能；
②专为高通量的网络流量进行的优化；
③基于开放接口（XML和HTTP）的标准；
④综合的HTML管理界面；
⑤可伸缩性－能够有效地复制到另外一个Solr搜索服务器；
⑥使用XML配置达到灵活性和适配性；
⑦可扩展的插件体系。
solr VS Lucene！？
在比较solr和Lucene之前，要知道什么是Lucene，那么首先就来回顾Lucene是个什么东东？
Lucene是一个基于Java的全文信息检索工具包，它不是一个完整的搜索应用程序，而是为你的应用程序提供索引和搜索功能。Lucene 目前是 Apache Jakarta(雅加达) 家族中的一个开源项目。也是目前最为流行的基于Java开源全文检索工具包。目前已经有很多应用程序的搜索功能是基于 Lucene ，比如Eclipse 帮助系统的搜 索功能。Lucene能够为文本类型的数据建立索引，所以你只要把你要索引的数据格式转化的文本格式，Lucene 就能对你的文档进行索引和搜索。
那么，solr和它相比，是”输“了？还是“赢”了呢？
其实，Solr与Lucene 并不是竞争对立关系，恰恰相反Solr 依存于Lucene，因为Solr底层的核心技术是使用Lucene 来实现的，Solr和Lucene的本质区别有以下三点：搜索服务器，企业级和管理。Lucene本质上是搜索库，不是独立的应用程序，而Solr是。Lucene专注于搜索底层的建设，而Solr专注于企业应用。Lucene不负责支撑搜索服务所必须的管理，而Solr负责。所以说，一句话概括 Solr: Solr是Lucene面向企业搜索应用的扩展。
下面是solr和 lucene的架构图：
这个图很繁琐，看不懂，大家不要灰心，在后面的代码里你就能够了解了这个图所讲的。
不难看出，绿色的就是lucene的模块，而蓝色的就是solr扩展了lucene。从图上可以看出以下几点：
a. 一个真正的拥有动态字段(Dynamic Field)和唯一键(Unique Key)的数据模式(Data Schema)
b. 对Lucene查询语言的强大扩展！
c. 支持对结果进行动态的分组和过滤
d. 高级的，可配置的文本分析
e. 高度可配置和可扩展的缓存机制
f. 性能优化
g. 支持通过XML进行外部配置
h. 拥有一个管理界面
i. 可监控的日志
j. 支持高速增量式更新(Fast incremental Updates)和快照发布(Snapshot Distribution)
说到这，solr的简介就到此结束了，相信大家也对solr有了初步的了解，下面开始介绍一下solr的常用属性有哪些？
solr的使用属性及配置文件
Document 包括一个或多个 Field。Field 包括名称、内容以及告诉 Solr 如何处理内容的元数据。
例如，Field可以包含字符串、数字、布尔值或者日期，也可以包含你想添加的任何类型，只需用在solr的配置文件中进行相应的配置即可。Field可以使用大量的选项来描述，这些
选项告诉 Solr 在索引和搜索期间如何处理内容。
现在，查看以下图片 中列出的重要属性的子集：
在这就先提一下solr的重要文件之一，就是schema.xml的配置文件。
（一） schema.xml
schema.xml这个配置文件可以在你下载solr包的安装解压目录的\solr\example\solr\collection1\conf中找到，它就是solr模式关联的文件。
打开这个配置文件，你会发现有详细的注释。模式组织主要分为三个重要配置：
一、Fieldtype
Fieldtype：就是属性类型的意思，像int，String，Boolean种类型，而在此配置文件中，FieldType就有这种定义属性的功能，看下面的图片：
图片上有我们熟悉的int，String，boolean，那么，后面的配置，是什么呢？那么我们就来介绍一下后面的参数：
二、Field
Field：是添加到索引文件中出现的属性名称，而声明类型就需要用到上面的type，如图所示：
ps：①field: 固定的字段设置；②dynamicField: 动态的字段设置,用于后期自定义字段,*号通配符.例如: test_i就是int类型的动态字段。
还有一个特殊的字段Field,一般用于检索时用的字段这样就只对这一个字段进行索引分词就行了Field的dest字段如果有多个source一定要设置
⑺ Lucene 或者 solr 有什么不一样分别何时使用
Lucene是一个开放源代码的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎.
Solr是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http G Solr et操作提出查找请求，并得到XML格式的返回结果；
Solr和Lucene的本质区别有以下三点：搜索服务器，企业级和管理。Lucene本质上是搜索库，不是独立的应用程序，而Solr是。Lucene专注于搜索底层的建设，而Solr专注于企业应用。Lucene不负责支撑搜索服务所必须的管理，而Solr负责。所以说，一句话概括Solr: Solr是Lucene面向企业搜索应用的扩展
⑻ 为什么使用solr-solr与Lucene比较及solr 的结构分析
为什么使用solr-solr与Lucene比较及solr 的结构分析
solr可以对多个core进行综合管理，并接受请求选择特定的一个或者多个core执行相关任务。下面来回答什么是solr的core。
core从文件结构的角度来看的话，主要包括一份索引（也可能还包括拼写检查的索引）、一堆配置文件。最主要的配置文件是：solrconfig.xml和schema.xml。solrconfig.xml从整体上对core进行了配置，例如索引的存放路径、字段的最大长度（maxFiedlLength）、写锁的超时时间（writeLockTimeout）、锁类型（lockType）、是否压缩索引（useCompoundFile）、内存索引缓冲区大小（ramBufferSizeMB）、合并因子（mergeFactor）、删除策略、自动提交策略、缓存设置等，它好比是一份组装机器人的说明书，里面详细描述了各个部件（handler）的参数。
⑼ jsp与solr结合实现网站搜索，怎么弄
Solr是使用Ant进行管理的源码, Ant是一种基于Java的build工具。理论上来说，它有些类似于Maven 或者是 C中的make。下载后解压出来后，进行环境变量设置。
ANT_HOME：E:\Work\apache-ant\1.9.1 (这里为你自己解压缩的目录) PATH：%ANT_HOME%\bin （这个设置是为了方便在dos环境下操作）
查看是否安装成功，在命令行窗口中输入命令ant，若出现结果:
说明ant安装成功！因为ant默认运行build.xml文件，这个文件需要我们建立。现在就可以进行build Solr源码了。在命令行窗口中进入到你的Solr源码目录，输入ant会出现当前build.xml使用提示信息。
其它的先不用管它，我们只要针对我们使用的IDE进行build就行了，如果使用eclipse就在命令行输入：ant eclipse.如果使用IntelliJ IDEA 就在命令行输入：ant idea。这样就能进行build了。
黑窗口里提示这个。。。
失败。。。为什么呢，最后我发现是因为下载的ant中少了一个jar就是这apache-ivy（下载地址：http://ant.apache.org/ivy/）这东东名子真怪 ivy是ant管理jar依赖关系的。当第一次bulid时ivy会自动把build中的缺少的依赖进行下载。网速慢的第一次build要好久的。。。
下载一个jar就行把jar放到ant的lib下（E:\Work\apache-ant\1.9.1\lib）这样再次运行ant 就会成功了。到现在才可以进行Solr的代码调试。
4.4配置并运行Solr代码
不管用什么IDE首选都要设置Solr Home在IDE的JVM参数设置VM arguments写入 -Dsolr.solr.home=solr/example/solr一般就行了.不行也可以使用绝对路径.
solr使用StartSolrJetty文件作为入口文件进行调试代码,在这里可以设置服务器使用的端口和solr的webapps目录.一般都不用设置,默认的就可以进行调试.Solr Home也能可在代码中设置一样好用. System.setProperty("solr.solr.home", "E:\\Work\\solr-4.2.0-src-idea\\solr\\example\\solr");
目前是使用自带的一个example作为solr配置的根目录，如果你有其他的solr配置目录，设置之即可。点击run即可，debug也是一样可以用了。没有别的问题就应该能运行了.注意servlet 容器使用的端口,如查提示:
FAILED [email protected]:8983: java.net.BindException: Address already in use: JVM_Bind 就说明当前端口占用中.改一下就可以了.如果没有报错启动成功后就可以在浏览器中输入地址: http://localhost:8983/solr/ 就可以看到如下界面
到这里Solr就成功配置并运行了.要是想跟代码调试在启动时在这个方法里点断点就可以Initializer的initialize()方法如果想从浏览器中找断点调试就要到SolrDispatchFilter的doFilter方法中点断点了.
注：IE9在兼容模式下有bug，必须设置为非兼容模式。
5.Solr基础
因为 Solr 包装并扩展了Lucene，所以它们使用很多相同的术语。更重要的是，Solr 创建的索引与 Lucene 搜索引擎库完全兼容。通过对 Solr 进行适当的配置，某些情况下可能需要进行编码，Solr 可以阅读和使用构建到其他 Lucene 应用程序中的索引。在 Solr 和 Lucene 中，使用一个或多个 Document 来构建索引。Document 包括一个或多个 Field。Field 包括名称、内容以及告诉 Solr 如何处理内容的元数据。