一些Liferay小問題的分析
5.1 Admin這個Portlet中的Server管理權限的分析
如果設置Portal的companyid不是liferay.com，缺省情況下，沒有用戶能夠對admin這個Portlet中的Server部分進行設置。簡單分析一下這部分的代碼，找一個比較好的解決方法。
5.1.1 代碼分析
JSP文件是/portal/portal-web/docroot/html/portlet/admin/server.jsp，其中的關鍵代碼爲
<c:if test="<%= OmniadminUtil.isOmniadmin(user.getUserId()) %>">
也就是通過OmniadminUtil.isOmniadmin進行用戶權限的判斷。
在這段代碼裏面，主要流程爲：
首先判斷userid是否爲空，如果爲空，直接返回false
然後判斷配置文件portal.properties裏面，指定的omniadmin.users 是否有當前用戶。
最後判斷當前用戶是否是系統管理員角色。
5.1.2 解決方法
分析了一下代碼之後，解決方法其實也很簡單。有兩個方案
5.1.2.1 指定管理員
在portal-ext.properties文件中添加或修改內容
omniadmin.users=liferay.com.1,mycompany.com.1
這樣，新站點的第一個用戶將具有管理權限。
5.1.2.2 由系統管理員角色實現
在portal-ext.properties文件中添加或修改內容
omniadmin.users=
這樣，所有的系統管理員角色的用戶都具有相應的權限。
5.2 Liferay的Applet編輯器調用的一個BUG
今天網友邊塵，說到journal中編輯Structure和Template的Applet編輯器部署好像不成功。粗略試了一下，在我的環境中沒有發現這個問題。因爲所用版本不同，我的是4.1.2，他的是4.1.3。開始懷疑是版本的問題。
經過查看源碼，原來是JSP代碼有點問題。
文件portal/portal-web/docroot/html/portlet/journal/edit_template_xsl.jsp的117行，archive="editor-signed.jar"，而實際上這個jar文件不存在，在目錄portal/portal-web/docroot/applets下的相應文件是editor.jar。
後來，網友把JSP代碼進行了簡單修改，editor-signed.jar修改爲editor.jar之後，重新運行就成功了。初步得出結論，是4.1.3不知什麼原因，把文件名搞錯了。
後來我又仔細看了一下4.1.2的代碼，發現也是同樣的問題。那爲什麼我當初沒有發現問題呢？原來是，Structure編輯的JSP代碼是正確的，而Template編輯的JSP代碼有錯誤。而我，正好用到的是Structure的編輯器。
最終的結論單點說：
1、 是Template編輯的JSP頁面有錯誤，修改。
2、 並不是4.1.3纔出現的問題，4.1.2的情況是一樣的。
至於爲什麼代碼裏面是editor-signed.jar。我初步看，應該不是簡單的筆誤的問題。很有可能是以前版本的代碼，用的是這個文件名。而我機器上原來下載的3.6的版本也被我刪掉了，無從驗證。如果有興趣，可以下載一個以前的版本來驗證一下。
5.3 Liferay啓動很慢的一個原因
用了Liferay一段時間，發現啓動的時候比較慢，特別是在出現"Auto deploy scanner started for /home/liferay/deploy"之後。
一開始，以爲就是這個auto deploy導致的問題，嘗試了各種方法去禁止Auto Deploy，但效果都不明顯，基本上沒什麼變化。
今天，在看portal.properties文件內容的時候，無意中找到一點線索。原來是Liferay每次啓動的時候，會自動重建索引；並且是在啓動的同一個線程中完成。缺省配置如下：
# Set the following to true if you want to index your entire library of files on startup.
index.on.startup=true
如果設置Portal的companyid不是liferay.com，缺省情況下，沒有用戶能夠對admin這個Portlet中的Server部分進行設置。簡單分析一下這部分的代碼，找一個比較好的解決方法。
5.1.1 代碼分析
JSP文件是/portal/portal-web/docroot/html/portlet/admin/server.jsp，其中的關鍵代碼爲
<c:if test="<%= OmniadminUtil.isOmniadmin(user.getUserId()) %>">
也就是通過OmniadminUtil.isOmniadmin進行用戶權限的判斷。
在這段代碼裏面，主要流程爲：
首先判斷userid是否爲空，如果爲空，直接返回false
然後判斷配置文件portal.properties裏面，指定的omniadmin.users 是否有當前用戶。
最後判斷當前用戶是否是系統管理員角色。
5.1.2 解決方法
分析了一下代碼之後，解決方法其實也很簡單。有兩個方案
5.1.2.1 指定管理員
在portal-ext.properties文件中添加或修改內容
omniadmin.users=liferay.com.1,mycompany.com.1
這樣，新站點的第一個用戶將具有管理權限。
5.1.2.2 由系統管理員角色實現
在portal-ext.properties文件中添加或修改內容
omniadmin.users=
這樣，所有的系統管理員角色的用戶都具有相應的權限。
5.2 Liferay的Applet編輯器調用的一個BUG
今天網友邊塵，說到journal中編輯Structure和Template的Applet編輯器部署好像不成功。粗略試了一下，在我的環境中沒有發現這個問題。因爲所用版本不同，我的是4.1.2，他的是4.1.3。開始懷疑是版本的問題。
經過查看源碼，原來是JSP代碼有點問題。
文件portal/portal-web/docroot/html/portlet/journal/edit_template_xsl.jsp的117行，archive="editor-signed.jar"，而實際上這個jar文件不存在，在目錄portal/portal-web/docroot/applets下的相應文件是editor.jar。
後來，網友把JSP代碼進行了簡單修改，editor-signed.jar修改爲editor.jar之後，重新運行就成功了。初步得出結論，是4.1.3不知什麼原因，把文件名搞錯了。
後來我又仔細看了一下4.1.2的代碼，發現也是同樣的問題。那爲什麼我當初沒有發現問題呢？原來是，Structure編輯的JSP代碼是正確的，而Template編輯的JSP代碼有錯誤。而我，正好用到的是Structure的編輯器。
最終的結論單點說：
1、 是Template編輯的JSP頁面有錯誤，修改。
2、 並不是4.1.3纔出現的問題，4.1.2的情況是一樣的。
至於爲什麼代碼裏面是editor-signed.jar。我初步看，應該不是簡單的筆誤的問題。很有可能是以前版本的代碼，用的是這個文件名。而我機器上原來下載的3.6的版本也被我刪掉了，無從驗證。如果有興趣，可以下載一個以前的版本來驗證一下。
5.3 Liferay啓動很慢的一個原因
用了Liferay一段時間，發現啓動的時候比較慢，特別是在出現"Auto deploy scanner started for /home/liferay/deploy"之後。
一開始，以爲就是這個auto deploy導致的問題，嘗試了各種方法去禁止Auto Deploy，但效果都不明顯，基本上沒什麼變化。
今天，在看portal.properties文件內容的時候，無意中找到一點線索。原來是Liferay每次啓動的時候，會自動重建索引；並且是在啓動的同一個線程中完成。缺省配置如下：
# Set the following to true if you want to index your entire library of files on startup.
index.on.startup=true
# Set the following to true if you want the indexing on startup to be
# executed on a separate thread to speed up execution.
index.with.thread=false
也就是說，啓動到Auto Deploy之後，需要耗較長時間，就是在進行數據的重新全文檢索。瞭解這個之後，優化的方案也就簡單了。
關掉重建索引 index.on.startup=false
另開線程重建索引 index.with.thread=true
兩種方法，只需在portal-ext.properties文件中添加相應的設置即可。
# executed on a separate thread to speed up execution.
index.with.thread=false
也就是說，啓動到Auto Deploy之後，需要耗較長時間，就是在進行數據的重新全文檢索。瞭解這個之後，優化的方案也就簡單了。
關掉重建索引 index.on.startup=false
另開線程重建索引 index.with.thread=true
兩種方法，只需在portal-ext.properties文件中添加相應的設置即可。