Juan Hernandez has posted comments on this change. Change subject: core: Add engine-java-launcher script ......................................................................
Patch Set 4: > I think we should not distinguish between dev and prod, but have > configuration of product with file locations. The main reason for this distinguishing is trying to make the introduction of the script as smooth as possible for developers, so only new environment variable (ENGINE_ENVIRONMENT) is required. Right now the only effect of this variable is to change how .jar files are looked up, but it could also be used to activate other typical development settings, like enabling remote debugging, increase log levels, etc. > Usually I am for putting /etc/ovirt-engine/env.sh or something similar with > environment variables of the location of javalib, pythonlib etc... This is more or less what we are doing with /etc/sysconfig/ovirt-engine, only that it is not a shell script, but a plain configuration file easy to read by python, sh or Java programs (this last is the most important point in my opinion, I want Java programs to be able to read this file). > This can be overridden by environment variable so that dev users may have > their own env.sh with custom locations. In the service script (which is kind of the older, wiser and stronger brother of engine-java-launcher) we read that file and then launch the service with some of the variables (not all) converted to environment variables. We could do something here, and let the existing environment variables override them, but only in development environments. > It is good to have this in sh format as it may be used by other utilities, > and python wrappers can easily use the environment. The /etc/sysconfig/ovirt-engine file is also easy to consume, for any kind of program. > If we do this right, we can also install product at /usr/local/ without any > issue, and we can do side-by-side installation of two instances. That sounds great, lets go for it! > I am not sure the /etc/sysconfig/ovirt-engine location is good for none > service files. We already have /etc/ovirt-engine. Or more precisely I don't > understand for what used. I have to admit my Fedora bias here. This /etc/sysconfig directory is where you usually put service configuration in Fedora, I mean, configuration for the service start/stop program. What we have there at the moment is service configuration. So I thought this could be a good place. I am not against putting it somewhere else. > Can you please explain (my java knowledge may be weak), we you do the fuzzy > search and not just use wildcards? For example ovirt-engine*.jar. Because different systems use different names for .jar files. Some use apache-commons-codec.jar, some use commons-codec.jar, some use libcommons-codec.jar, some commons/codec-1.3.jar, so on. Even we use different names for our own jars in different locations: engine-bll.jar in some places, but just bll.jar in other places. So the fuzzy search is a must. Either we do the fuzzy search or we have different scripts for different environments. I prefer the fuzzy search. All that said, what is most important from my point of view is to have a wrapper that hides the details of how the java tools are invoked. The details of how that internally works are secondary. -- To view, visit http://gerrit.ovirt.org/5129 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6eed7495f8d380656ef413596d7848618e395c96 Gerrit-PatchSet: 4 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Juan Hernandez <juan.hernan...@redhat.com> Gerrit-Reviewer: Alex Lourie <alou...@redhat.com> Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com> Gerrit-Reviewer: Barak Azulay <bazu...@redhat.com> Gerrit-Reviewer: Juan Hernandez <juan.hernan...@redhat.com> Gerrit-Reviewer: Ofer Schreiber <oschr...@redhat.com> Gerrit-Reviewer: Roy Golan <rgo...@redhat.com> Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com> _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
