Alon Bar-Lev 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.
Right.
But development environment may be more than one entity.
So what I suggest is to have something like:
---
OVIRT_VARS="${OVIRT_VARS:/etc/ovirt-engine/ovirt.vars}"
if [ -f "${OVIRT_VARS}" ]; do
. "${OVIRT_VARS}"
else
die "Cannot locate variables '${OVIRT_VARS}'"
fi
---
Then you can put more than one variable or setting.
You can have multiple profiles for developers.
export OVIRT_VARS=~/ovirt-remote-debugging.vars
<do whatever>
> > 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).
I don't think there is a problem for python, java to read a file of the syntax:
---
export KEY="VALUE"
---
I usually source this file to environment at wrapper script so java does not
need to access the file as it can access the environment.
<snip>
> > 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.
As far as I know the /etc/sysconfig is for services, utilities and daemon
configuration should be located at different place.
> > 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.
Right.
Idea...
We can have
/usr/share/ovirt-engine/javalib/classpath1
/usr/share/ovirt-engine/javalib/classpath2
/usr/share/ovirt-engine/javalib/classpath3
Each classpathX is for a group of utilities which shares the same classpath.
These classpathes will be set with symlinks to actual distro specific jars at
packaging/installation.
Then it will be easy to use for example: '-cp
/usr/share/ovirt-engine/javalib/classpath2/*'.
No need to search for anything.
Alon.
--
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
