Setting run mode for Lift applications
Petr Pudlak
I've written my first application using Lift and now I'm deploying it
into a production. I find it inconvenient that the run mode is
specified as a JVM system property.
First, sometimes JVM system properties are inaccessible, for example
when deploying to a hosted servlet container.
Second, it's impossible to run different lift applications with
different run modes in a single
servlet container.
Generally, I believe that a *Java web application shouldn't be
configured by JVM system properties*. I suggest that the run mode
should be configured by a servlet context initialization parameter,
called for example "lift.run.mode". Or, for maximum flexibility, both
alternatives should be provided.
With best regards,
Petr
PS: Lift is a really great framework for writing web applications!
Thanks for developing it.
aw
> Hi all,
>
> I've written my first application using Lift and now I'm deploying it
> into a production. I find it inconvenient that the run mode is
> specified as a JVM system property.
>
> First, sometimes JVM system properties are inaccessible, for example
> when deploying to a hosted servlet container.
>
> Second, it's impossible to run different lift applications with
> different run modes in a single
> servlet container.
I have sympathy for your first point, but am suspicious about the
second point. I generally don't recommend running applications in
different "modes"/environments on a single servlet container because
you run the risk that a destabilizing factor in Dev or QA could impact
a Production system, for example. A dev servlet container instance
that hosted just dev instances, for example, would make sense, but
these would share the same run.mode.
> Generally, I believe that a *Java web application shouldn't be
> configured by JVM system properties*. I suggest that the run mode
> should be configured by a servlet context initialization parameter,
> called for example "lift.run.mode". Or, for maximum flexibility, both
> alternatives should be provided.
Servlet context initialization parameters break down because the
servlet configuration is baked into the artifact, yet the goal is to
run the same artifact across several environments. (Sure, there are
things like the global web.xml, but if you can't access system
properties, I don't see how you will change the global web.xml.)
Any other ideas?
Jeppe Nejsum Madsen
Some servlet containers (eg Jetty, Tomcat) allow a context to override
servlet context initialization parameters externally from the war...
I'm not sure if this is too late in the boot cycle, but one simple
solution would be to have a LiftRules.calculateRunMode
/Jeppe
Petr Pudlak
On 20 ún, 16:03, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
> aw <anth...@whitford.com> writes:
> > On Feb 18, 9:14 am, Petr Pudlak <petr....@gmail.com> wrote:
> >> Second, it's impossible to run different lift applications with
> >> different run modes in a single
> >> servlet container.
>
> > I have sympathy for your first point, but am suspicious about the
> > second point. I generally don't recommend running applications in
> > different "modes"/environments on a single servlet container because
> > you run the risk that a destabilizing factor in Dev or QA could impact
> > a Production system, for example. A dev servlet container instance
> > that hosted just dev instances, for example, would make sense, but
> > these would share the same run.mode.
Well, I must admit you're right. But still it would be nice to have
the freedom to decide.
>
> >> Generally, I believe that a *Java web application shouldn't be
> >> configured by JVM system properties*. I suggest that the run mode
> >> should be configured by a servlet context initialization parameter,
> >> called for example "lift.run.mode". Or, for maximum flexibility, both
> >> alternatives should be provided.
>
> > Servlet context initialization parameters break down because the
> > servlet configuration is baked into the artifact, yet the goal is to
> > run the same artifact across several environments. (Sure, there are
> > things like the global web.xml, but if you can't access system
> > properties, I don't see how you will change the global web.xml.)
>
> > Any other ideas?
>
> Some servlet containers (eg Jetty, Tomcat) allow a context to override
> servlet context initialization parameters externally from the war...
Yes, this is what I meant. Tomcat, for example, allows to alter
servlet context initialization parameters in a deployment descriptor
[1]. This is how I imagine it should work. The deployer of an
application can choose the run mode independently of the developer
(packager), but the settings affects just the single application, not
the whole JVM.
[1] http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Context
Parameters
> I'm not sure if this is too late in the boot cycle, but one simple
> solution would be to have a LiftRules.calculateRunMode
If I understand it correctly, you suggest to have a function-type
field that could be set in the Boot class and which would be called to
calculate the run mode. That would be nice, a developer would be able
to choose whatever means (s)he would prefer.
Another possibility would be to add another method to the Boot class,
which would calculate the run mode. It would be less nice than the
previous solution, but it could be called before the 'boot' method, if
that would be required.
Petr
Timothy Perrett
Jeppe: Are you willing to investigate this / take the lead?
Cheers, Tim
Jeppe Nejsum Madsen
<tim...@getintheloop.eu> wrote:
> The former is a lift idiom that we use for everything configurable... Lets look into doing that.
>
> Jeppe: Are you willing to investigate this / take the lead?
Yes. I've created
https://www.assembla.com/spaces/liftweb/tickets/362-make-runmode-configurable-in-liftrules
/Jeppe
Heiko Seeberger
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Heiko Seeberger
Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Jeppe Nejsum Madsen
<heiko.s...@googlemail.com> wrote:
> Folks,
> I really do not understand the value of setting the run mode statically via
> code in LiftRules. The run mode should be set externally, right? In order to
> use the same artifact (WAR) on a dev or a prod server.
> Heiko
Agreed. This was more so that people could change how "externally" is
defined, ie in a hosted env you can't change system properties.
The default would still be the current lookup in system properties,
but you could change this to look at servlet params, hostname, day of
month etc :-)
/Jeppe
Heiko Seeberger
The default would still be the current lookup in system properties,
but you could change this to look at servlet params, hostname, day of
month etc :-)
Indrajit Raychaudhuri
consider that at all? That would have served the purpose for Petr.
So the calcRunMode could roughly have something like:
customRunMode or context.initParam("run.mode") or
Box.!!(System.getProperty("run.mode"))
with provision for having customRunMode customized heartily.
Cheers, Indrajit
Heiko Seeberger
Given that setting initParams is the usual webapp idiom, should we not consider that at all? That would have served the purpose for Petr.
customRunMode or context.initParam("run.mode") or Box.!!(System.getProperty("run.mode"))
with provision for having customRunMode customized heartily.
Indrajit Raychaudhuri
On 22/02/10 3:22 PM, Indrajit Raychaudhuri wrote:
> Given that setting initParams is the usual webapp idiom, should we not
> consider that at all? That would have served the purpose for Petr.
>
> So the calcRunMode could roughly have something like:
>
> customRunMode or context.initParam("run.mode") or
> Box.!!(System.getProperty("run.mode"))
>
> with provision for having customRunMode customized heartily.
On second thought, the order probably should be other way round.
Box.!!(System.getProperty("run.mode")) or context.initParam("run.mode")
or customRunMode
-Drun.mode=... is more transient (and suitable for fast mode switching
during development) than static definition in the code and thus to be
tried first.
David Pollak
WebKit depends on util. Props (where the runmode is defined) is in util, so there would be a circular reference if LiftRules was used to calculate the runmode.
Further, util can be used outside of the context of WebKit/Boot. We want to encourage that.
So, creating a "mode calculation function" that's consulted during the evaluation of the run mode in props makes sense. But this function has to be set super duper uper mooper early in the app initialization cycle because the run mode is calculated in order to figure out which property file to load and this is done the first time a property is accessed.
Put another way, if we do a "calculation function", it's going to be the first thing that needs to be set in Boot. Then there's going to be confusion.
It might be just as easy for the OP to write a mock filter that's initialized before the Lift filter which does System.setProperty("run.mode", ....)
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Jeppe Nejsum Madsen
<feeder.of...@gmail.com> wrote:
> I've closed Jeppe's ticket. Why?
>
> WebKit depends on util. Props (where the runmode is defined) is in util, so
> there would be a circular reference if LiftRules was used to calculate the
> runmode.
>
> Further, util can be used outside of the context of WebKit/Boot. We want to
> encourage that.
Fair point. I keep forgetting about those other uses :-)
/Jeppe
Timothy Perrett
Anyone got any thoughts on this?
Cheers, Tim
David Pollak
Whilst we are talking about Props, I wouldn't mind seeing a level of abstraction on Props so that it can load stuff from things other than .props files. For instance, Im using configgy more and more these days as its much more preferable to properties files for app configuration.
Anyone got any thoughts on this?
I'd love to see a more flexible file format for properties as well as support for merging a "secret" set of properties (e.g., ones that contain passwords that you don't want to put into source control) during property file parsing.
The thing I'm not keen on with Configgy is the ability to change configurations during runtime.
Cheers, Tim
On 22 Feb 2010, at 18:34, Jeppe Nejsum Madsen wrote:
> On Mon, Feb 22, 2010 at 7:13 PM, David Pollak
> <feeder.of...@gmail.com> wrote:
>> I've closed Jeppe's ticket. Why?
>>
>> WebKit depends on util. Props (where the runmode is defined) is in util, so
>> there would be a circular reference if LiftRules was used to calculate the
>> runmode.
>>
>> Further, util can be used outside of the context of WebKit/Boot. We want to
>> encourage that.
>
> Fair point. I keep forgetting about those other uses :-)
>
> /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.