Karaf教程第2部分使用Configuration Admin服务
原文地址? http://blog.csdn.net/wusandi/article/details/78172920
????
? 在Karaf教程的第1部分，我們學習了如何使用maven和blueprint提供和使用pojo服務，如何使用http服務發布servlet。
????在第2部分，我們集中精力關注OSGi bundle的配置。不像servlet容器，OSGi容器包含一個非常好的配置規范：來自企業級規范的Config Admin服務。在本教程中，我們將在純OSGi和blueprint中使用Config Admin服務，學習如何在bundle中自動部署配置文件。
????這個教程的練習可以在github上找到：https://github.com/cschneider/Karaf-Tutorial/tree/master/configadmin。
2.1 Configuration?Admin服務規范
我們首先快速概覽一下Configuration Admin服務規范。對于我們來說，主要有兩個接口可以使用：
1、ConfigurationAdmin：允許獲取和改變配置。這個服務由Config Admin服務實現提供。
2、ManagedService：允許對配置改變產生影響。必須實現這個接口，并將它注冊給要被通知的服務。
????所以，基本上在Config Admin服務中的配置是一個字典，這個字典包含了屬性和他們的值。字典由持久性標識PID標識。PID就是一個簡單的字符串，它唯一標識了配置。
2.2 如何處理配置？
????雖然你可以使用ConfigurationAdmin.getConfiguration接口獲取配置，但是我不推薦你這么做。OSGi是動態的，所以有可能發生bundle在Config Admin服務之前啟動或者Config Admin服務還沒有讀取這個bundle的配置。所以有時候你獲取的配置可能為null。
????所以，推薦的方式是使用ManagedService，并對更新做出反應。如果你的bundle沒有配置無法啟動，那么在收到第一個更新時創建一個要被配置的pojo類是個好主意。
2.3 介紹要被配置的非常簡單的類
????由于我們想要實現一個整潔風格的配置，那么要被配置的類應該是純pojo。雖然可以簡單的實現ManagedService接口，直接使用Dictionary，但這將使你依賴于OSGi和當前的Config Admin規范。所以，替代做法是我們使用一個具有title熟悉的簡單的bean類。另外，我增加了一個刷新方法，當配置發生改變的時候來調用刷新方法。
[java]?view plaincopy
所以我們的目標就是當配置發生改變時，配置title，然后調用refresh方法。我們將在純OSGi和blueprint中做這件事。
2.4 練習一下：使用純OSGi接口處理配置
????本教程的第1個練習演示如何只用OSGi接口使用Config Admin服務。雖然這可能不是你以后使用的方式，但這種方式可以幫助你理解更深層次的東西。
????你可以在子目錄configapp中找到實現：(https://github.com/cschneider/Karaf-Tutorial/tree/master/configadmin/configapp)。
????所以首先我們需要一個pom文件用于maven構建。你最好從configapp示例程序的pom文件開始。如果你新建了新的工程，你必須是使用maven-bundle-plugin插件使你的工程成為一個bundle，你需要添加兩個依賴：
[html]?view plaincopy?
????第一個依賴用于獲取config admin服務接口，第二個依賴用于創建Activator，它包含基本的OSGi接口。
????現在，我們關心如何更新MyApp類。下面這個類解決了這個問題。我們實現了ManagedService接口，來與Config Admin服務交互。所以無論什么時候，配置發生改變，我們的方法都會被調用。第一件事是檢查是否為null，當config被移除時這是有可能發生的。這時我們可以停止MyApp，但為了簡單起見，我們只是忽略它。下一步是創建MyApp類。通常你可能會在Activator中實例化它，但是你不得不處理空配置，這是我們不希望的。最后是簡單地用從config中獲取的值調用setter方法，在所有的設置完成后再調用refresh方法。
[java]?view plaincopy
????當然，這還是什么事情都沒做。最后一步就是在Activator.start方法中注冊ConfigUpdater。我們簡單地使用registerService方法，就像每一個其他的服務一樣。唯一特殊的地方是你必須設置SERVICE_PID為config pid，這樣Config Admin服務就知道你想要監視的配置了。
[java]?view plaincopy
2.5 運行這個簡單的示例
?用mvn install命令構建這個工程
?啟動一個全新的karaf實例
?將configapp.jar從target目錄復制到Karaf的deploy目錄
????現在我們注意到似乎沒有發生任何事情。在Karaf控制臺調用list，你會看到這個bundle確實已經啟動了，但是它沒有任何輸出，因為它還沒有配置。我們仍然需要創建配置文件，并設置title。
?復制已有的文件/configadmin-features/src/main/resources/ConfigApp.cfg到Karaf的/etc目錄
????這里重要的部分是文件名必須是<pid>.cfg。這樣config admin服務才能找到它。
????現在fileinstall bundle會在etc目錄檢測到新的文件。由于文件結尾是.cfg，它認為這是一個config admin資源，創建或更新由文件名確定的pid的Config Admin服務配置。
所以現在在Karaf控制臺你應該能看到下面的打印。這個打印顯示了配置改變被正確地檢測和轉發。如果你現在用編輯器改變了這個文件并保存，那么這個變化也會被傳播。
?
2.6 使用Karaf config命令探究配置
在Karaf控制臺鍵入如下命令：
?
在其他的配置中，你應該找到上面的配置"ConfigApp"。這個配置顯示它從哪兒加載的，pid，當然還有在文件中設置的所有屬性。
我們也可以改變這個配置：
?
我們看到這個修改直接傳播到了我們的bundle。如果你看看etc下面的配置文件，你會發現這個改變已經持久化到了這個文件。所以如果我們重啟了Karaf，修改還是生效的。
2.7 使用Blueprint配置
????在純OSGi環境中處理了Config Admin服務之后，現在我們將看一看如何在Blueprint中實現同樣的功能。幸運地是，這是相當容易，就Blueprint為我們做的大多數的工作一樣。
????我們僅僅定義了一個cm:property-placeholder元素。這個處理文件的屬性占位符的功能很相似，但是這里是處理Config Admin服務。我們需要提供一個配置的PID和更新策略。更新策略我們選擇“reload”。這意味著在配置改變之后，blueprint上下文會被重新加載或反射改變。我們也設置了默認的屬性，當配置的PID找不到或者屬性不存在的時候，就會使用這些默認值。
????集成我們的bean類通常是一個簡單的bean定義。在這個類中我們定義了title熟悉，分配一個占位符，這個占位符會使用config admin服務進行解析。唯一特別的是初始化方法。這個給了我們機會以便對配置改變之后做出反應，就像純OSGi示例中一樣。
對于bluenprint來說，我們不需要任何maven的依賴，因為我們的Java代碼是純Java bean。只要將Blueprint上下文放在OSGI-INF/blueprint目錄中并且blueprint extender加載了，那么blueprint上下文就被會簡單地激活。由于As blueprint總是在Karaf中被加載，所以我們什么都不需要做。
[html]?view plaincopy2.8 Deploying config files
在我們成功地使用了Config Admin服務之后，剩下要做的唯一一件事就是部署帶默認配置的bundle。這可以使用Karaf feature文件實現。我們定義一個feature，帶有它需要的bundle，簡單地添加一個configfile元素。這使得Karaf部署給定的文件到Karaf安裝位置的etc目錄。如果這個文件已經存在，那么它不會被覆蓋。
[html]?view plaincopy
這樣，最后一個問題是如何將配置部署到maven，讓configfileonfig元素能夠找到它。這好像屬于Karaf中的the build-helper-maven-plugin的特性。請參見pom文件了解使用細節。
?
2.9 Summing it up and a look into the future
????在本教程中，我們學習了如何使用Config Admin服務以及如何在純OSGi和blueprint中使用該服務。我們也看到了如何構建和部署我們的工程。
????雖然這已經很有用了，但在我看來，有一點點小問題。第一個問題是configfile似乎看起來與config admin不一致。實際上，Karaf不使用config admin服務部署文件。所以我想要看到的是已經存在的config元素不僅僅是為了寫入配置，而且還用于持久化。幸運地是，我的同事Jean Baptiste正在研究這個問題。參見https://issues.apache.org/jira/browse/KARAF-888。
????另一個問題是對于企業級環境，需要具有附加特性的config admin服務。一件是要可能在整個服務器網絡中進行配置，具有配置的中心源和友好的UI。另一件事是你不僅想要部署默認的配置，而且要部署管理員真正想要為系統進行的配置。所以，我想你能夠定義一個部署計劃，不僅要安裝bundle和feature，還需要配置的改變。如果這個正確的完成，將允許部署、配置改變的良好檢查，也允許管理員一旦在出錯的情況下回滾配置的變化。我希望我們可以在下一個Talend ESB EE發布版中提供這樣的計劃。
總結
以上是生活随笔為你收集整理的Karaf教程第2部分使用Configuration Admin服务的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小李子日记。
- 下一篇： Prometheus 实战于源码分析之s