I think I've got this working now although it took quite a bit of experimenting.
In the past, the current directory was the directory where the wrapper executable was run from (the bin directory). But now it seems to be one step up (where you unpack the Karaf distribution). I used to have: set.default.KARAF_HOME=.. set.default.KARAF_BASE=.. But now I have: set.default.KARAF_HOME=. set.default.KARAF_BASE=%KARAF_HOME% But this doesn't seem to be the case when it comes to the wrapper properties. I used to have: wrapper.java.command=%JAVA_HOME%/bin/java wrapper.java.mainclass=org.apache.karaf.wrapper.internal.service.Main wrapper.java.classpath.1=%KARAF_BASE%/lib/boot/*.jar wrapper.java.classpath.2=%KARAF_BASE%/lib/wrapper/*.jar wrapper.java.library.path.1=%KARAF_BASE%/lib/wrapper/ But I now have: wrapper.working.dir=.. wrapper.java.command=%JAVA_HOME%/bin/java wrapper.java.mainclass=org.apache.karaf.wrapper.internal.service.Main wrapper.java.classpath.1=./lib/boot/*.jar wrapper.java.classpath.2=./lib/jdk9plus/*.jar wrapper.java.classpath.3=./lib/wrapper/*.jar wrapper.java.library.path.1=./lib/wrapper/ I guess the reason for this is the parameter "wrapper.working.dir". I had forgotten that we used to comment it out but now I didn't. I think this is the main source of confusion for me. Also, I had problems getting the wrapper's log file to the correct place - it always ended up in the root directory and was called wrapper.log even if I tried calling it something else. It turned out that the problem is that if the directory of the wrapper's log file does not exist then it defaults to wrapper.log in the root. As I often delete the data directory when testing, the data/log directory did not exist and the default was used. All well now, /Bengt Den tors 17 dec. 2020 kl 17:46 skrev Bengt Rodehav <[email protected]>: > Just a thought... > > The wrapper sets the current directory to the folder where its executable > resides. But what current directory does Karaf have? If the two don't agree > with this but they both parse the KARAF_HOME and KARAF_BASE variables then > it becomes impossible to use relative paths. > > /Bengt > > Den tors 17 dec. 2020 kl 17:33 skrev Bengt Rodehav <[email protected]>: > >> Hello JB, >> >> I've tested and experimented more about this issue. First I replaced the >> wrapper bundled int Karaf 4.3.0 with the one bundled in Karaf 4.0.7. I get >> the same result so the problem is probably not with the wrapper itself. >> >> Next, I replaced all the *use* of variables KARAF_HOME and KARAF_BASE >> with the hard coded absolute paths. But it still doesn't work. I get: >> >> INFO | jvm 1 | 2020/12/17 17:10:20 | Could not create framework: >> java.lang.NumberFormatException: null >> INFO | jvm 1 | 2020/12/17 17:10:20 | >> java.lang.NumberFormatException: null >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> java.base/java.lang.Integer.parseInt(Integer.java:614) >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> java.base/java.lang.Integer.parseInt(Integer.java:770) >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> org.apache.karaf.main.ConfigProperties.<init>(ConfigProperties.java:251) >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> org.apache.karaf.main.Main.launch(Main.java:262) >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> org.apache.karaf.wrapper.internal.service.Main.start(Main.java:55) >> INFO | jvm 1 | 2020/12/17 17:10:20 | at >> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) >> >> Note that I still had KARAF_HOME and KARAF_BASE set to ".." but I didn't >> *use* those variables anywhere so it's not the wrapper that has problems >> but some part of Karaf seems to read those variables (are they environment >> variables?) and cannot handle that the paths are relative. >> >> /Bengt >> >> Den tors 17 dec. 2020 kl 13:54 skrev Bengt Rodehav <[email protected]>: >> >>> I am using openjdk15 on Windows 7 and Windows 10 in case that could >>> affect this issue. >>> >>> /Bengt >>> >>> Den tors 17 dec. 2020 kl 08:51 skrev Bengt Rodehav <[email protected]>: >>> >>>> Thanks JB - I appreciate it. >>>> >>>> /Bengt >>>> >>>> Den tors 17 dec. 2020 kl 06:08 skrev Jean-Baptiste Onofre < >>>> [email protected]>: >>>> >>>>> Hi, >>>>> >>>>> There were lot of changes between 4.0.x and 4.3.x. I don’t remember >>>>> changes about the service wrapper. >>>>> >>>>> Let me reproduce and do a git bisect to identify the change. >>>>> >>>>> I will keep you posted. >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> > Le 16 déc. 2020 à 16:16, Bengt Rodehav <[email protected]> a écrit : >>>>> > >>>>> > I am upgrading from Karaf 4.0.7 to 4.3.0 and have run into problems >>>>> starting Karaf as a service. >>>>> > >>>>> > We want to be able to unpack our Karaf based application anywhere so >>>>> we need to avoid absolute paths everywhere. In the past, our >>>>> karaf-wrapper.conf has contained the following lines: >>>>> > >>>>> > set.default.KARAF_HOME=.. >>>>> > set.default.KARAF_BASE=.. >>>>> > set.default.KARAF_DATA=../data >>>>> > set.default.KARAF_ETC=../etc >>>>> > >>>>> > This has worked fine since the Wrapper always sets the directory in >>>>> which karaf-wrapper.exe resides as the working directory. Therefore, since >>>>> karaf-wrapper.exe resides in the %KARAF_HOME%/bin directory, ".." takes us >>>>> back to %KARAF_HOME%. >>>>> > >>>>> > However, this does not seem to work in Karaf 4.3.0. I have tried >>>>> several relative paths but I cannot figure out what directory ".." seems >>>>> to >>>>> point to in Karaf 4.3.0. >>>>> > >>>>> > Has anything related to this been changed from Karaf 4.0.7 to Karaf >>>>> 4.3.0? >>>>> >>>>>
