• <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">  
•     <lst name="defaults">  
•       <str name="config">C:\solr-tomcat\solr\db\conf\db-data-config.xml</str>  
•     </lst>  
•   </requestHandler>  
  

• <dataConfig>  
•         <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/tuitui" user="root" password="mysql"/>  
•     <document name="shop">  
•             <entity name="tuitui_shop" pk="shopId" query="select * from tuitui_shop">  
•             <field column="shopid" name="shopId" />  
•             <field column="shopName" name="shopName" />  
•             <field column="shopUrl" name="shopUrl" />  
•             <field column="keyword" name="keyword" />  
•             <field column="synopsis" name="synopsis" />  
•             <field column="province" name="province" />  
•             <field column="city" name="city" />  
•             <field column="domain" name="domain" />  
•             <field column="address" name="address" />  
•             <field column="coordinate" name="coordinate" />  
•             <field column="shopSspn" name="shopSspn" />  
•             <field column="phone" name="phone" />  
•             <field column="createTime" name="createTime" />  
•         </entity>  
•     </document>  
• </dataConfig>  
  

名為HttpSolrServer，我是找了半天才發現，大家以后可以注意。

     部署前準備:

• Solr 必須運行在Java1.5 或更高版本的Java 虛擬機中，運行標準Solr 服務只需要安裝JRE 即可。
• Solr 4.0 :  http://www.apache.org/dyn/closer.cgi/lucene/solr/4.0.0
• 本文以Tomcat7.0  進行演示。
  

Solr 4.0 目錄:

        這里是我的部署方式，Tomcat安裝好之后把apache-solr-4.0.0\example\webapps下的solr.war文件拷貝到Tomcat下的

Tomcat7.0\webapps目錄下，然后啟動Tomcat 報錯不用管，solr.war會自動解壓，之后打開Tomcat7.0\webapps\solr\WEB-

INF\web.xml，把下面代碼復制進去放到后面：

            其中  E:\SolrHome  是存放solr配置文件等，修改為自己文件的位置，為了看著更清晰直觀，你可以這樣放:

            E:\Tomcat7.0

            E:\apache-solr-4.0.0

            E:\SolrHome

            現在可以重新啟動Tomcat了，沒有報錯，通過這個地址進入Solr4.0頁面:http://localhost:8080/solr

            如果進入以上界面說明成功了，沒有成功的話頁面會有ERROR提示。

            如圖：左側core0,core1等是solr 4.0中的示例，core0和core1位于apache-solr-4.0.0\example\multicore所有文件都下拷貝

到E:\SoleHome下，core0和core1可以理解為兩個庫，都是獨立的，用來存放索引以及生成這些索引文件所需要的配置文件，solrtest是我測試建立的目錄，如圖：

        沒添加一個庫都需要在solr.xml里面進行配置，這個比較簡單

        每個目錄下包含兩個文件夾conf和data，data下有兩個文件夾index和tlog，index是存放生成的索引文件，tlog存放log，

conf下是必要的配置文件schema.xml和solrconfig.xml，可以參考官方或者core里面的配置文件：

        solrconfig.xml我還不是很懂，在這里就不講了，但是必須配置（好像是必須配）：

        之后在exampledocs目錄下手動創建一個solr1.xml文件：

         跟schema.xml中的字段對應，好了現在可以提交數據了，這里在window命令窗口提交數據，把E:\apache-solr-

4.0.0\example\exampledocs下的post.jar復制到 E:\SolrHome\exampledocs下

        打開命令窗口CD 到E:\SolrHome\exampledocs下使用命令，Tomcat不要忘了開：

java -Durl=http://localhost:8080/solr/solrtest/update -Ddata=files -jar post.jar solr1.xml

如圖成功的添加的索引，看下E:\SolrHome\solrtest\data\index下的文件：

        進入solr頁面：

        點擊Executu Query查詢，右側生成了地址可以打開查看，到此結束。

 Debug視圖

認識debug視圖，紅色部分框為線程堆棧視圖，黃色部分框為表達式、斷點、變量視圖，藍色部分為代碼視圖。

 線程堆棧視圖

分別介紹一下這幾個按鈕的含義：

1.表示當前實現繼續運行直到下一個斷點，快捷鍵為F8。

2.表示打斷整個進程

3.表示進入當前方法，快捷鍵為F5。

4.表示運行下一行代碼，快捷鍵為F6。

5.表示退出當前方法，返回到調用層，快捷鍵為F7。

6.表示當前線程的堆棧，從中可以看出在運行哪些代碼，并且整個調用過程，以及代碼行號

變量視圖

1.為變量名視圖，顯示當前代碼行中所有可以訪問的實例變量和局部變量

2.顯示所有的變量值

3.可以通過該窗口來改變變量值

斷點視圖

1.顯示所有斷點

2. 將當前窗口1中選中的端口失效，再次點擊啟用。

3.異常斷點

表達式視圖

表達式視圖：表達式視圖是Debug過程中較為常用的一個視圖，可以對自己的感興趣的一些變量進行觀察，也可以增加一些自己的表達式，也可以查看一行代碼的運行結果。

1.表達式

2. 點擊此可以新增一個表達式

代碼視圖

代碼視圖：用來顯示具體的代碼。其中綠色部分是指當前將要執行的代碼

場景一：小明辛苦了兩天終于將自己的負責的任務完成了，第二天轉測后，測試找到了小明說，小明的程序有bug，可以是小明經過仔細調試，發現本地沒有任何問題，但是測試的環境上確實有問題，所以小明遇到了難題，測試的環境linux，又不能上去linux去debug，小明這個時候想要是Linux也可以debug就好了.

遠程debug

遠程debug：遠程debug顧名思義，能夠將遠程操作系統上的任何java進行debug，但是有前提是本地需要有同步的代碼。

1.遠程debug的步驟是在遠程操作系統上啟動java進程時增加特殊的

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=$DEBUG_PORT,server=y,suspend=n

2.在Eclipse中新建一個Remote Java Application

遠程debug

1.打開Debug Configurations視圖

2.右擊Remote Java Application，

New

3.選擇源碼工程

4.輸入遠程IP和端口，端口即服務

端的$DEBUG_PORT,點擊OK。

場 景一：小明寫了一個任務執行者，該執行者不間斷的執行一些任務，在現網上運行了一段時間后，發現有概率的出現一些故障，發現運行一段時間后，該任務者異常 退出了，退出的因為是空指針，可以小明想要在本地debug，不知道斷點打在哪里，該問題是概率事件，不一定會出現，所以小明debug幾遍下來后，頭暈 眼花，連代碼都看不清楚了，小明想要是能有個斷點每當出現空指針異常的時候就停下來讓他發現問題，那該多好呀。

異常斷點

異常斷點：在定位問題的過程中，常常會遇到斷點無法打到合適的位置，以至于和問題的觸發點千差萬別，所以這個時候不妨試試異常斷點，顧名思義，異常斷點是指拋出某種異常后自動掛起的斷點。

點擊紅色部位，增加一個異常斷點

輸入想要定位的異常類型，例如NullPointerException，這樣系統中拋出任何NullPointerException異常后，都會掛起當前線程，給你機會去定位問題。

場景一：小明寫了一個巨大的循環，在調測代碼時，小明發現每當循環到第100000次的時候，就是出現問題，沒有達到自己的預期，于是小明在循環里打了個斷點，想看看到底怎么回事，可小明萬萬沒有想到，想要到達100000次循環是多么的困難，小明這個時候已經開始浮想聯翩，如果能有這樣的斷點：

             If 循環次數== 100000，線程停下來

條件斷點

如右圖，循環1000次，如果想要在循環到500

次的時候停下來，可以創建一個條件斷點，右

擊斷點懸著Breakpoint Properties。

選中Enable Condition

在空白處，添加你自己的條件，如果條件返回true，線程會被掛起，如果為false，則忽略該異常

Hit Count為該斷點經過多少次后，正式掛起線程，如果設置為500，則表達前499次，經過該斷點都不會停下，當第500次，該斷點會掛起當前線程。

表達式

表達式可以查看一些在當前代碼中沒有的命令行，方便定位問題。

場景一：小明最近遇到一個難題，在調用一個第三方插件時總是會有問題，小明懷疑是第三方插件的bug，但小明沒有找到源碼不能進行debug，小明該怎么辦呢？

Debug定位第三方插件的問題

1.使用反編譯工具將代碼反編譯

2.將反編譯后的源碼進行過濾

3.修復源碼編譯錯誤

4.進行debug

Debug一些經驗

1.盡量減少debug，少用debug，優秀的程序員總是花80%的時間來思考如何解決問題，20%的時間來動手完成代碼，而糟糕的程序員總是用20%的時間去寫代碼，80%的時間去調試代碼，動手之前盡量想好如何去做，并且已經為你自己的思路做了充分的實驗。

2.盡可能的提高debug的效率，設置合適的斷點，使用快捷鍵。

3.debug的F6快捷鍵經常用到，它與金山詞霸的快捷鍵沖突，所以在debug的時候最好將金山詞霸關掉。

4.debug的表達式是可執行代碼，將會對代碼結果產生永久性影響，在調試時注意，經常將不用的表達式清除掉。

多站點共享Session常見的作法有：

• 使用.net自動的狀態服務（Asp.net State Service）;
• 使用.net的Session數據庫；
• 使用Memcached。
• 使用Cookie方式實現多個站點間的共享（這種方式只限于幾個站點都在同一域名的情況下）； 

這里我們就 演練一下 以數據庫的形來存儲Session，來實現多站點共享Session。 

首先我們 建好一下站點，如下圖: 

Default.aspx 

其中 有二個Button  ，SetSession 主要是用于給一個 Session 賦值（如：Session["ShareValue"] = “abcd”

） ，

GetSession 主要就是獲得 一個 Session 值。

具體代碼如下:

 代碼部分就這么多就行了…

下面就是要配置一下 Web.config了 ， 其實主要就是在 <system.web>

 這個節點中 增加 machineKey 及 sessionState 這兩個節點，

1.增加machineKey 主要作用是：

“按照MSDN的標準說法：“對密鑰進行配置，以便將其用于對 Forms 身份驗證 Cookie 數據和視圖狀態數據進行加密和解密，并將其用于對進程外會話狀態標識進行驗證。”也就是說Asp.Net的很多加密，都是依賴于machineKey里面 的值，例如Forms 身份驗證 Cookie、ViewState的加密。默認情況下，Asp.Net的配置是自己動態生成，如果單臺服務器當然沒問題，但是如果多臺服務器負載均 衡，machineKey還采用動態生成的方式，每臺服務器上的machinekey值不一致，就導致加密出來的結果也不一致，不能共享驗證和 ViewState，所以對于多臺服務器負載均衡的情況，一定要在每臺站點配置相同的machineKey。“ ，具體可以查一下其它資料。

2.增加 sessionState 主要是讓 Session 保存在數據庫中。 

具體配置如下：

數據庫配置：

使用aspnet_regsql.exe工具

ASP.NET 2.0版本后微軟提供了aspnet_regsql.exe工具可以方便的配置Session數據庫.該工具位于 Web 服務器上的"系統根目錄\Microsoft.NET\Framework\版本號"文件夾中.

使用舉例:

表示數據庫實例名稱. 可以用"."表示本機.

-U和-P參數:

表示用戶名和密碼.

-E參數:

可以再-U –P 與 -E中選擇一組. –E表示以當前系統用戶通過windows身份驗證登錄數據庫, -U -P則是使用SqlServer用戶登錄數據庫.

-ssadd / –ssremove 參數:

-ssadd表示是添加Session數據庫, -ssremove表示移除Session數據庫.

sstype 參數說明:

我的設置是：aspnet_regsql.exe -S . - E -d AWBUISession -ssadd -sstype c 

好了。基本的 我們就已經搞定了。。

我們把 其中一個 服務器中的 defaut.aspx 中 “服務器 1” 改成 “服務器 2” ，這樣做的主要目地是 做一下 區別！ 

具體如下：

兩個網站的 URL分別是：

 server 1：127.0.0.1:8081;

server 2：127.0.0.1:8080;   

OK。下面我們就是 配置 Nignx了。

做如上的 設置：

OK。  nginx  這樣配置 就算OK 了。 我們啟動一下 nginx ..

在瀏覽器中 輸入我們 在 nginx 中配置的 URL 如：127.0.0.1：8090

重啟一下各站點。再在瀏覽一下網站點 “SetSession”, 再點：“GetSession” 這樣 我們就看到 服務器2 給出了我們 剛才在 服務器 1 中設置 的會話值了。

Apache Shiro 架構

ApacheShiro的設計目標是使程序的安全變得簡單直觀而易于實現，shiro的核心設計參照大多數用戶對安全的思考模式--如何對某人（或某事）在與程序交互的環境中的進行安全控制。

程序設計通常都以用戶為基礎，換句話說，你經常以用戶可以（或者應該）如何與軟件交互為基礎來設計用戶接口或者服務API，例如，你可能說，“如果當前與我程序交互的用戶已經登錄了，我將展示一個按鈕給他，他可以點擊去查看自己的賬戶住處，如果他們沒有登錄，我將顯示一個注冊按鈕。”

這個陳述例子指出我們開發程序很大程度上是為了滿足用戶的需求，即使“用戶（User）”是另外一個軟件系統而并非一個人，你仍然要寫代碼對當前與你軟件交互的誰（或者什么）的動作進行回應。

shiro從它的設計中表現了這種理念，為了與軟件開發者的直覺相配合，Apache Shiro在幾乎所有程序中保留了直觀和易用的特性。

概覽

在概念層，shiro架構包含三個主要的理念：Subject,SecurityManager和Realm。下面的圖展示了這些組件如何相互作用，我們將在下面依次對其進行描述。

subject:就像我們在上一章示例中提到的那樣，subject本質上是當前運行用戶特定的'view'，而單詞“user”經常暗指一個人，subject可以是一個人，但也可以是第三方服務、守護進程帳戶、時鐘守護任務或者其它--當前和軟件交互的任何事件。

subject實例都和（也需要）一個SecurityManager綁定，當你和一個subject進行交互，這些交互動作被轉換成SecurityManager下subject特定的交互動作。

SecurityManager:SecurityManager是Shiro架構的核心，配合內部安全組件共同組成安全傘。然而，一旦一個程序配置好了SecurityManager和它的內部對象，SecurityManager通常獨自留下來，程序開發人員幾乎花費的所有時間都集中在Subjet API上。

我們將在以后詳細討論SecurityManager，但當你和一個Subject互動時了解它是很重要的。任何Subject的安全操作中SecurityManager是幕后真正的舉重者，這在上面的圖表中可以反映出來。

Realms：Reamls是Shiro和你的程序安全數據之間的“橋”或者“連接”，它用來實際和安全相關的數據如用戶執行身份認證（登錄）的帳號和授權（訪問控制）進行交互，shiro從一個或多個程序配置的Realm中查找這些東西。

Realm本質上是一個特定的安全DAO：它封裝與數據源連接的細節，得到shiro所需的相關的數據。在配置shiro的時候，你必須指定至少一個Realm來實現認證（authentication）和/或授權（authorization）。SecurityManager可以配置多個復雜的Realm，但是至少有一個是需要的。

Shiro提供out-of-the-box Realms來連接安全數據源（或叫地址）如LDAP、JDBC、文件配置如INI和屬性文件等，如果已有的Realm不能滿足你的需求你也可以開發自己的Realm實現。

和其它內部組件一樣，ShiroSecurityManager管理如何使用Realms獲取Subject實例所代表的安全和身份信息。

詳細架構

下面的圖表展示了Shiro的核心架構思想，下面有簡單的解釋。

Subject (org.apache.shiro.subject.Subject)

正在與軟件交互的一個特定的實體“view”（用戶、第三方服務、時鐘守護任務等）。

SecurityManager(org.apache.shiro.mgt.SecurityManager)

如同上面提到的，SecurityManager 是Shiro的核心，它基本上就是一把“傘”用來協調它管理的組件使之平穩地一起工作，它也管理著Shiro中每一個程序用戶的視圖，所以它知道每個用戶如何執行安全操作。

Authenticator(org.apache.shiro.authc.Authenticator)

Authenticator是一個組件，負責執行和反饋用戶的認證（登錄），如果一個用戶嘗試登錄，Authenticator就開始執行。Authenticator知道如何協調一個或多個保存有相關用戶/帳號信息的Realm，從這些Realm中獲取這些數據來驗證用戶的身份以確保用戶確實是其表述的那個人。

Authentication Strategy(org.apache.shiro.authc.pam.AuthenticationStrategy)

如果配置了多個Realm，AuthenticationStrategy將會協調Realm確定在一個身份驗證成功或失敗的條件（例如，如果在一個方面驗證成功了但其他失敗了，這次嘗試是成功的嗎？是不是需要所有方面的驗證都成功？還是只需要第一個？）

Authorizer(org.apache.shiro.authz.Authorizer)

Authorizer是負責程序中用戶訪問控制的組件，它是最終判斷一個用戶是否允許做某件事的途徑，像Authenticator一樣，Authorizer也知道如何通過協調多種后臺數據源來訪問角色和權限信息，Authorizer利用這些信息來準確判斷一個用戶是否可以執行給定的動作。

SessionManager(org.apache.shiro.session.mgt.SessionManager)

SessionManager知道如何創建并管理用戶Session生命周期而在所有環境中為用戶提供一個強有力的Session體驗。這在安全框架領域是獨一無二--Shiro具備管理在任何環境下管理用戶Session的能力，即使沒有Web/Servlet或者EJB容器。默認情況下，Shiro將使用現有的session（如Servlet Container），但如果環境中沒有，比如在一個獨立的程序或非web環境中，它將使用它自己建立的session提供相同的作用，sessionDAO用來使用任何數據源使session持久化。

SessionDAO(org.apache.shiro.session.mgt.eis.SessionDAO)

SessionDAO代表SessionManager執行Session持久（CRUD）動作，它允許任何存儲的數據掛接到session管理基礎上。

CacheManager(org.apache.shiro.cache.CacheManager)

CacheManager創建并管理其它shiro組件的catch實例生命周期，因為shiro要訪問許多后端數據源來實現認證、授權和session管理，caching已經成為提升性能的一流的框架特征，任何一個現在開源的和/或企業級的caching產品都可以插入到shiro中實現一個快速而有效的用戶體驗。

Cryptography (org.apache.shiro.crypto.*)

Cryptography在安全框架中是一個自然的附加產物，shiro的crypto包包含了易用且易懂的加密方式，Hashes（亦即digests）和不同的編碼實現。該包里所有的類都亦于理解和使用，曾經用過Java自身的加密支持的人都知道那是一個具有挑戰性的工作，而shiro的加密API簡化了java復雜的工作方式，將加密變得易用。

Realms (org.apache.shiro.realm.Realm)

如同上面提到的，Realm是shiro和你的應用程序安全數據之間的“橋”或“連接”，當實際要與安全相關的數據進行交互如用戶執行身份認證（登錄）和授權驗證（訪問控制）時，shiro從程序配置的一個或多個Realm中查找這些數據，你需要配置多少個Realm便可配置多少個Realm（通常一個數據源一個），shiro將會在認證和授權中協調它們。

SecurityManager

因為shiro API鼓勵以Subject為中心的開發方式，大部分開發人員將很少會和SecurityManager直接交互（盡管框架開發人員也許發現它非常有用），盡管如此，知道SecurityManager如何工作，特別是當在一個程序中進行配置的時候，是非常重要的。

設計

如前所述，程序中SecurityManager執行操作并且管理所有程序用戶的狀態，在shiro基礎的SecurityManager實現中，包含以下內容：

認證（Authentication）

授權（Authorization）

會話管理（Session Management）

緩存管理（Cache Management）

Realm協調（Realm coordination）

事件傳導（Event propagation ）

"RememberMe" 服務（"Remember Me" Services）

建立Subject(Subject creation)

退出登錄（Logout）

及其它。

但這些功能都在一個單獨的組件中管理，并且，當所有功能集中在一個類中實現是靈活和可定制是非常困難的。

為了實現配置的簡單、靈活、可插拔，shiro在設計時實現了高模塊化--盡管模塊化，SecurityManager（包括它的繼承類）并沒有做到，相反地，SecurityManager實現更像一個輕量級的‘容器（container）’，代表幾乎所有嵌套/封裝組件的行為，這種‘封裝（wrapper）’設計在上面的架構圖表中已有反映。

當組件執行邏輯的時候，SecurityManager知道如何以及何時去協調組件做出正確的動作。

SecurityManager和JavaBean兼容，這允許你（或者配置途徑）通過標準的JavaBean訪問/設置方法（get*/set*）很容易地定制插件，這意味著shiro模塊可以根據用戶行為轉化成簡易的配置。

簡易的配置

因為適合JavaBean，任何支持Javabean配置的組件都有非常簡單的途徑配置SecurityManager，如Spring、Guice、JBoss,等等。

我們將在下一節討論配置（Configuration ）

為文檔加把手

我們希望這篇文檔可以幫助你使用Apache Shiro進行工作，社區一直在不斷地完善和擴展文檔，如果你希望幫助shiro項目，請在你認為需要的地方考慮更正、擴展或添加文檔，你提供的任何點滴幫助都將擴充社區并且提升Shiro。

提供你的文檔的最簡單的途徑是將它發送到用戶論壇（http://shiro-user.582556.n2.nabble.com/）或郵件列表（http://shiro.apache.org/mailing-lists.html）

 原文地址：http://shiro.apache.org/architecture.html