Well, if you provide a product for someone else you need to clearly separate between files you ship and files the user is allowed to modify.
We want to keep the setenv empty so the user can adjust things there and we don't have to worry during upgrades (at least not that much to worry, of course certain variables might no longer be used or their values become counter productive...). Now if WE ship already data within setenv and the user adds his own stuff there, we have an issue during upgrades if we need to change "our part" of the script. We need to figure out what it is that we changed vs. what the user changed so we don't "overwrite" or remove the users settings. Hence the idea to modify the base scripts to additionally detect a JVM inside KARAF_HOME and prefer that one if present. Greetings -Sascha- Am 31.10.2016 um 14:05 schrieb Jean-Baptiste Onofré: > Ah, I understand now. > > It was also the purpose of the bin/setenv to be able to override Karaf > defined location (like the Java). > > I'm not against to use $KARAF_HOME/java folder as JAVA_HOME if it's > provided, but I don't see a huge value compared to define it in bin/setenv. > > Regards > JB > > On 10/31/2016 02:02 PM, Sascha Vogt wrote: >> @Achim / @JB: >> >> Sorry for the misunderstanding. I didn't mean to ship a binary >> distribution with a JVM embedded, I meant to modify the scripts so that >> Karaf by default prefers a JVM if (and only if) one is present in a >> certain directory within KARAF_HOME. >> >> In case none is there, just follow the same search order like at the >> moment (ie. first look for a JAVA_HOME env var and if that is missing >> search for a java binary in the path). >> >> That would be enough for users to package a JVM without needing to >> modify the setenv scripts... >> >> Greetings >> -Sascha- >> >> Am 31.10.2016 um 13:49 schrieb Jean-Baptiste Onofré: >>> Hi Sascha, >>> >>> An "embedded" distribution of Karaf with JVM is a good idea. It sounds a >>> bit like a docker image ;) >>> >>> However, unfortunately, I'm not sure it would be possible to provide >>> such distribution directly at Karaf due to legal constraint. >>> >>> We can provide a script (like a dockerfiles I created) to let users >>> create their own custom distro. >>> >>> Regards >>> JB >>> >>> On 10/31/2016 01:33 PM, Sascha Vogt wrote: >>>> Hi all, >>>> >>>> we're workig on a Karaf based product and have the requirement to use >>>> the JVM we ship with the product. We thought that might also be >>>> interesting to others, so we wanted to share our proposal / current >>>> implementation (and are also willing to provide the required patches). >>>> >>>> Main idea is to modify the start scripts (including the service >>>> wrappers?) to prefer a JVM inside the KARAF_HOME directory (ie. >>>> runtime/jvm64, or just plain jvm in KARAF_HOME). Whenever such a >>>> directory is present it is prefered over a JAVA_HOME env var or >>>> whatever >>>> else is in the path. >>>> >>>> Reason to also prefer it over JAVA_HOME is because if you run alongside >>>> other Java applications on a server, JAVA_HOME might already be set for >>>> other applications and the admin cannot change it. >>>> >>>> At the moment we have implemented the above via custom setenv >>>> scripts we >>>> ship which then sets JAVA_HOME to KARAF_HOME/runtime/jvm64. When >>>> "wrapper:install" is called, this JAVA_HOME is taken to the wrapper >>>> properties. >>>> >>>> We spoke with the Instana[1] people as their agent is also Karaf based >>>> and they were interested in it as well, so we know at least one other >>>> Karaf user who would welcome that :) >>>> >>>> Anyway, any feeback is welcome. Also of course the name of the >>>> directory(ies) can be discussed. >>>> >>>> Greetings >>>> -Sascha- >>>> >>>> [1]https://www.instana.com/ >>>> >>> >> >
