我的環境中有很少的激活碼包。在只有一個包中,start()方法沒有被調用。基本上它沒有被激活。這個軟件包唯一的變化就是使用「DynamicImport-Package:」。 刪除此標記解決了start()沒有被調用的問題,但這是不可能的,因爲在我的場景中所有的包都不是預先知道的。OSGI Bundle的start()方法沒有被調用
有人可以幫助我,因爲我很堅持這一點。 我無法弄清楚什麼是問題以及他們兩個是如何相關的。
我的環境中有很少的激活碼包。在只有一個包中,start()方法沒有被調用。基本上它沒有被激活。這個軟件包唯一的變化就是使用「DynamicImport-Package:」。 刪除此標記解決了start()沒有被調用的問題,但這是不可能的,因爲在我的場景中所有的包都不是預先知道的。OSGI Bundle的start()方法沒有被調用
有人可以幫助我,因爲我很堅持這一點。 我無法弄清楚什麼是問題以及他們兩個是如何相關的。
他們沒有關係。刪除DynamicImport-Package
將不會影響您的包是否啓動,因此必須進行其他操作。你真的在任何地方打電話給捆綁的Bundle.start()
方法嗎?
順便說一句,使用DynamicImport-Package
是一個非常糟糕的主意。幾乎可以肯定有更好的方法來解決您認爲通過使用DI-P解決的任何問題。
當使用DynamicImport-Package特別是*時,無法控制包的來源。所以如果兩個軟件包導出相同的軟件包,你會遇到很大的問題。
例如我有一個pax考試的問題,它使用這個* import作爲測試包,在那裏有兩個版本的包javax.inject。由於調用測試的軟件包看到了不同版本的軟件包,服務導入不起作用。
因此,在您的示例中,可能有兩個版本的BundleActivator所在的包org.osgi.framework。 你安裝org.osgi.core api包嗎?如果是,那麼刪除它。只有框架應該提供這些包。它可能會導致框架無法使用激活器類的效果。
擺脫動態導入最終:) – LokeshJoshi
似乎是這樣。不確定這個問題,但我們最終擺脫了動態導入,問題得到解決。 – LokeshJoshi