isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian K <harvestmoon...@gmail.com>
Subject Re: We'd like to remove "isis.deploymentType" ... any objections?
Date Thu, 01 Nov 2018 20:31:51 GMT
My experience with environment variables setting java system properties to
affect the application's behavior comes from Tomcat and JBoss.  Their
startup scripts set the java system properties of the java runtime from the
environment variables *if* they are set.  The java system properties
override any other default configured in the application from code or
property files.  To me, it doesn't make sense to ignore a property given
explicitly on the command line in favor of an environment variable.

Also, I found this discussion[1] that referred to the java docs [2].  The
place for preferring environment variables, according to the java docs, is
if you are spawning a new process that does not have access to the java
system properties.

[1]
https://stackoverflow.com/questions/14026558/when-to-use-environment-variables-vs-system-properties
[2]
https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#EnvironmentVSSystemProperties




On Wed, Oct 31, 2018 at 8:00 AM Jayesh Prajapati <jayeshecs@gmail.com>
wrote:

> Hi Andi,
>
> My thoughts are towards jvm system properties because you need environment
> variable in case DOCKER only, which can be easily managed internally by
> framework.
>
> I think, if we follow below for settings/option in framework then it will
> work for all use cases
>
> First Layer -> Default values for settings at code level
> Second Layer -> Framework properties file that can override First Layer
> Third Layer -> system property which can override First and Second layers
> Last Layer -> Configuration at database level that can override all layers
> (Applicable to specific settings that are used after application has
> started)
>
> For DOCKER, it should be possible to supply desired value as ENVIRONMENT
> variable, however, internally image will supply relevant value in the form
> of system property using -D jvm option.
>
> I see the logic in framework as below ...
> ... 1) if jvm property 'isis.deploymentType' is set then use value of this
> as deployment type literal
> ... 2) else check if IsisConfiguration has value of isis.deploymentType
> then use it as deployment type literal
> ... 2) else check if environment variable ' DEPLOYMENT_TYPE' is available
> and use its value as deployment type literal
> ... 3) else make use of ''PRODUCTION" as  deployment type literal
> (DEFAULT)
> ... 4) Based on this  deployment type literal  lookup correct
> DeploymentType
>
> My vote is -> As much possible try and avoid use of DEPLOYMENT_TYPE
>
> Thanks,
> Jayesh
>
> On Wed, Oct 31, 2018 at 2:28 PM Andi Huber <ahuber@apache.org> wrote:
>
> > I think, this is an excellent opportunity for us to find out, what we
> want
> > to be ‘best practice’ and therefore can safely recommend to our users.
> >
> > System-environment-variables do have one advantage over any other, they
> > are immutable for any operating system process that wants to read them.
> > (Hence I’m an advocate for having only this option.)
> >
> > Here would be my suggestion ...
> >
> > 1) Command-line
> >
> > For the command-line, in general simply prefix your command with ‘set
> > PROTOTYPING=true|false’:
> >
> > set PROTOTYPING=true ; mvn jetty:run
> >
> > 2) IDE
> >
> > Eclipse and (I believe others likewise) allow for ‘Run Configurations’ to
> > be setup with system-environment-variables. That applies to the launching
> > of processes or test-runners from within the IDE.
> >
> > 3) Docker
> >
> > Docker allows for Docker images to be ‘primed’ with
> > system-environment-variables using this entry in the image build file
> > (Dockerfile):
> >
> > ENV PROTOTYPING true
> >
> > But this value can be overwritten, when you actually create your Docker
> > container:
> >
> > docker run -ePROTOTYPING=true|false my-image
> >
> > ---
> >
> > Question is, are these options flexible enough, to serve all use-cases?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 2018/10/30 17:21:27, Dan Haywood <dan@haywood-associates.co.uk>
> wrote:
> > > Hi Andi / all,
> > >
> > > I was thinking a little more about this.
> > >
> > > For those of us who *are* on Docker, using the ENV keyword in the
> > > Dockerfile [1] isn't really appropriate, because it shouldn't be
> > necessary
> > > to rebuild the image when moving from dev (prototyping=true) to prod
> > > (prototyping=false).
> > >
> > > That said, if using Docker without a swarm then docker run allows the
> > > environment variable to be specified in the command line (-e option),
> > which
> > > is a good alternative.
> > >
> > > Or, if using Docker with a swarm, then the environment can be specified
> > in
> > > the stack file (one stack file per environment), which also seems okay
> > [3].
> > >
> > > So far, then, I'm still in agreement that there's no need for
> > > isis.deploymentType to be a configuration property.
> > >
> > > But, building on Brian's slight confusion, it occurs to me that it
> might
> > be
> > > useful to also support for prototyping mode to be read as a system
> > > property.  For backwards compatibility, I suggest that the system
> > property
> > > is named "isis.deploymentType".  Therefore one could use:
> > >
> > > mvn -Disis.deploymentType=PROTOTYPING jetty:run
> > >
> > > or, if using org.apache.isis.WebServer main class in an IDE, then
> > similarly
> > > invoke that with a system property (easily specified in the IDE run
> > dialog).
> > >
> > > ~~
> > > So, in conclusion, what I'm suggesting is that we do remove support for
> > > reading isis.deploymentType as a config property, but support reading
> > both
> > > isis.deploymentType as a system property, and PROTOTYPING as an
> > environment
> > > variable.
> > >
> > > Thoughts?
> > > Dan
> > >
> > >
> > >
> > > [1] https://docs.docker.com/engine/reference/builder/#env
> > > [2]
> > https://docs.docker.com/v1.7/reference/run/#env-environment-variables
> > > [3] https://docs.docker.com/compose/environment-variables/
> > >
> > > On Mon, 29 Oct 2018 at 19:29, Brian K <harvestmoon299@gmail.com>
> wrote:
> > >
> > > > Thanks for clarifying!  My concern is that flexibility would be lost
> > if you
> > > > remove a configuration path.  I thought the common practice was to
> > have the
> > > > java system property be what drives the application's behavior, and
> > that
> > > > property is loaded from the environment if it isn't set explicitly at
> > the
> > > > command line.  The web.xml file can reference the java property with
> > syntax
> > > > like <param-value>${prototyping}</param-value>
> > > >
> > > > An interesting (some would use another word) puzzle would evolve when
> > > > one developer runs a packaged war file and gets the prototyping menu
> > > > while another developer who runs it can't get that prototyping menu
> to
> > > > display until he figures out he must set an environment
> > > > variable to see it.
> > > >
> > > > -Brian
> > > >
> > > >
> > > > On Sun, Oct 28, 2018, 10:02 PM Andi Huber <ahuber@apache.org> wrote:
> > > >
> > > > > Hi Brian,
> > > > >
> > > > > not sure if I understand all your questions, but to clarify:
> > > > >
> > > > > In our context PROTOTYPING=true is a system environment variable
> > [1][2]
> > > > > for which the running operating system accounts responsible. You
> can
> > set
> > > > > such environment variables in multiple ways and note, this does not
> > > > require
> > > > > Docker!
> > > > >
> > > > > Also note: mvn -Dkey=value does not set an environment variable
> (this
> > > > does
> > > > > set a system property, which is specific to the Java runtime)
> > > > >
> > > > > Does this answer your questions and concerns?
> > > > >
> > > > > [1]
> > > > >
> > > >
> >
> https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getenv-java.lang.String-
> > > > > [2] https://en.wikipedia.org/wiki/Environment_variable
> > > > >
> > > > > On 2018/10/29 04:41:40, Brian K <harvestmoon299@gmail.com>
wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Two points to consider:
> > > > > >
> > > > > > Being new to this platform,  it was very useful to see the
> > prototyping
> > > > > menu
> > > > > > when prototyping with 'mvn jetty:run'.  This change would require
> > 'mvn
> > > > > > -DPROTOTYPING=true jetty:run' ?  Would jetty console stop
> > functioning
> > > > > with
> > > > > > a simple launch with this change?
> > > > > >
> > > > > > Please don't assume Docker is available.  My lan uses the same
> > netmask
> > > > > that
> > > > > > Docker uses, making it hard to make use of this tool.
> > > > > >
> > > > > > -Brian
> > > > > >
> > > > > >
> > > > > > On Sun, Oct 28, 2018, 12:27 PM Stephen Cameron <
> > > > > steve.cameron.62@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > No problem
> > > > > > >
> > > > > > > On Mon, Oct 29, 2018 at 2:47 AM Jayesh Prajapati <
> > > > jayeshecs@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > No problem from my side.
> > > > > > > >
> > > > > > > > @Anisha ... Do you see any problem?
> > > > > > > >
> > > > > > > > On Sun, Oct 28, 2018, 16:28 Patrick Pliessnig <
> > p.pliessnig@gmx.net
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > No problem
> > > > > > > > >
> > > > > > > > > Am 28.10.2018 um 10:29 schrieb Andi Huber:
> > > > > > > > > > Hello everyone!
> > > > > > > > > >
> > > > > > > > > > Dan and I discussed [1], whether we should
remove the
> > config
> > > > > option
> > > > > > > > > 'isis.deploymentType'.
> > > > > > > > > >
> > > > > > > > > > Remember, we are having this, in order for
developers to
> > > > decide,
> > > > > > > > whether
> > > > > > > > > an Apache Isis App should be deployed in PROTOTYPING
mode
> or
> > not
> > > > > > > > > (PRODUCTION).
> > > > > > > > > >
> > > > > > > > > > In the advent of Docker, we had to introduce
support for
> a
> > > > system
> > > > > > > > > environment variable (PROTOTYPING), that serves
the exact
> > same
> > > > > purpose.
> > > > > > > > > >
> > > > > > > > > > Now, instead of having to support 2 possible
ways to
> > configure
> > > > > the
> > > > > > > > > deployment type, we would like to discontinue
the first
> one.
> > This
> > > > > > > > relieves
> > > > > > > > > us from the burden of having to decide, which
one has
> > precedence
> > > > > over
> > > > > > > the
> > > > > > > > > other, and also having to document this somewhere.
As a
> > positive
> > > > > > > > > side-effect, developers are not encouraged to
provide
> > different
> > > > war
> > > > > > > files
> > > > > > > > > for different deployment scenarios.
> > > > > > > > > >
> > > > > > > > > > So we are asking you, do you have any strong
objections
> > > > regarding
> > > > > > > this
> > > > > > > > > move?
> > > > > > > > > >
> > > > > > > > > > Cheers Andi!
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> >
> https://github.com/apache/isis/commit/4ea76029e097e3e8b94f5602ca430dfcd6ee9dac
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message