I see your point, but as you will provide your own distribution, you can
always override the default scripts with your definition and let the
user with bin/setenv.
My point is that what you are proposing make sense but very specific to
your use case.
You can create a Jira with such improvement, we will see what the others
think about that.
Regards
JB
On 10/31/2016 02:14 PM, Sascha Vogt wrote:
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/
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
