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 <harvestmoon...@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 <ahu...@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 <harvestmoon...@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...@gmail.com>
> > > wrote:
> > >
> > > > No problem
> > > >
> > > > On Mon, Oct 29, 2018 at 2:47 AM Jayesh Prajapati <
> jayesh...@gmail.com>
> > > > wrote:
> > > >
> > > > > No problem from my side.
> > > > >
> > > > > @Anisha ... Do you see any problem?
> > > > >
> > > > > On Sun, Oct 28, 2018, 16:28 Patrick Pliessnig <p.pliess...@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
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to