I had same problem when I made my own features.xml with DOSGi. When I make a line break after <version> tag inside <feature> tag, the karaf booting correctly, but after restart I got the same Number Format exception. After I fixed this line break in features.xml the problem didn't came up again. I think that the deploy mechanism resolves trimming white spaces in version tag, but the cache is stores the original (whitespaced) version, and after restart the version parser cannot read it correctly. I haven't time to check the root of the problem, because the correct features.xml formatting resolves this problem for me).
Regards, Robert 2014-04-01 14:46 GMT+02:00 Matthieu Vincent <[email protected]>: > No problem. > > Don't hesitate if you need any other information. > I'll tell you if I find anything else on this subject > > Mat > > > 2014-04-01 14:37 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > > Thanks for the details. >> >> I will try to reproduce and investigate what it's done by the Felix >> Framework. >> >> Regards >> JB >> >> >> On 04/01/2014 02:33 PM, Matthieu Vincent wrote: >> >>> So, i've shutdown my karaf, switch back to felix and run "./karaf.bat >>> clean" >>> >>> Then, I install my feature : feature:install siti-libs (definition >>> attached) >>> >>> And here is the bundle.info <http://bundle.info> generated for one of >>> >>> the dependencies : >>> >>> 103 >>> mvn:commons-codec/commons-codec/1.7 >>> 32 >>> 70 >>> 1396355110248 >>> 0 >>> >>> After restart, only few libraries are still installed : >>> karaf@karaf-root()> list >>> START LEVEL 100 , List Threshold: 50 >>> ID | State | Lvl | Version | Name >>> ------------------------------------------------------ >>> 97 | Active | 70 | 11 | com.oracle.ojdbc >>> 101 | Active | 70 | 2.3.0 | Commons IO >>> 107 | Installed | 70 | 1.6.1 | SLF4J Log4J Binding >>> 123 | Active | 70 | 0 | wrap_mvn_asm_asm_3.1 >>> 128 | Active | 70 | 2.6 | Commons Lang >>> >>> >>> Note that some of dependencies had been Osgified with bundlor (but >>> worked normally on Karaf 2.3.3) >>> >>> Mat >>> >>> >>> >>> 2014-04-01 14:21 GMT+02:00 Jean-Baptiste Onofré <[email protected] >>> <mailto:[email protected]>>: >>> >>> >>> Hi Matthieu, >>> >>> no problem to use Equinox instead of Felix. >>> >>> But your use case is interesting. >>> Do you mind to share your feature or at least the bundles installed >>> and corrupted ? >>> I only focused on the kill "issue" on Felix, but yours look >>> interesting. >>> >>> Are you sure that the bundle cache is corrupted *before* CTRL-D ? >>> Maybe CTRL-D doesn't perform a clean shutdown (it should do a stop >>> on bundle 0 aka the framework, maybe the hook is not called >>> correctly) ? >>> >>> Thanks, >>> Regards >>> JB >>> >>> On 04/01/2014 02:17 PM, Matthieu Vincent wrote: >>> >>> No, the bundle.info <http://bundle.info> <http://bundle.info> >>> >>> file in incorrect after >>> >>> installing feature (Karaf still running). >>> I exit Karaf with ctrl+D and restart it normally when error >>> appears, no >>> kill in my case >>> >>> I've tried to switch to equinox and it seems to fix the problem ! >>> >>> Are there any potential side effects to switch to equinox ? >>> >>> Mat >>> >>> >>> 2014-04-01 14:11 GMT+02:00 Jean-Baptiste Onofré <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>: >>> >>> >>> >>> Hi Matthieu, >>> >>> I guess that you killed Karaf process right ? >>> Or did you restart "cleanly" (and how ?) ? >>> >>> We saw an issue with Felix Framework when killing the JVM: >>> the >>> bundle cache gets corrupted. >>> Equinox looks more stable about this. >>> >>> Regards >>> JB >>> >>> >>> On 04/01/2014 02:01 PM, Matthieu Vincent wrote: >>> >>> Hello >>> >>> After installing a custom feature in Karaf 3.0 >>> successfully, if I >>> restart karaf instance, I got the following error : >>> >>> ERROR: Error reloading cached bundle, removing it: >>> D:\Siti-1.3.0\server\karaf-____siti\data\cache\bundle99 >>> (java.lang.____NumberFormatException: For input >>> string: " >>> ") >>> java.lang.____NumberFormatException: For input string: >>> " " >>> at >>> >>> java.lang.____NumberFormatException.____forInputString(____ >>> NumberFormatException.java:65) >>> at >>> java.lang.Integer.parseInt(____Integer.java:481) >>> at >>> java.lang.Integer.parseInt(____Integer.java:527) >>> at >>> >>> org.apache.felix.framework.____cache.BundleArchive.____ >>> readBundleInfo(BundleArchive.____java:959) >>> at >>> >>> org.apache.felix.framework.____cache.BundleArchive.<init>(__ >>> __BundleArchive.java:182) >>> at >>> >>> org.apache.felix.framework.____cache.BundleCache. >>> getArchives(____BundleCache.java:247) >>> at >>> org.apache.felix.framework.____Felix.init(Felix.java:705) >>> at >>> org.apache.karaf.main.Main.____launch(Main.java:238) >>> at >>> org.apache.karaf.main.Main.____main(Main.java:172) >>> >>> >>> >>> It appears that in the bundle.info <http://bundle.info> >>> <http://bundle.info> >>> <http://bundle.info> file generated >>> >>> in data/cache, there is an empty line : >>> >>> 135 >>> mvn:com.xxx.xxx/xxx-commands/____1.3.0-SNAPSHOT >>> >>> >>> 32 >>> 80 >>> 1396353616390 >>> 0 >>> >>> >>> If I try to deploy the same bundle directly in deploy >>> directory, the >>> bundle.info <http://bundle.info> <http://bundle.info> >>> <http://bundle.info> file is >>> >>> modified and correct. >>> >>> >>> Any idea ? >>> >>> Thanks again >>> Matthieu >>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >>> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> >>> -- >>> Jean-Baptiste Onofré >>> [email protected] <mailto:[email protected]> >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
