Re: [Lift] Re: Setting run mode for Lift applications
On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger heiko.seeber...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
On 22 February 2010 09:20, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 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 :-) Ah, OK. I agree if and only you will also enable setting the run mode depending on the beer-level of the deployer ;-) Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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. Cheers, Indrajit On 22/02/10 1:50 PM, Jeppe Nejsum Madsen wrote: On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger heiko.seeber...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
On 22 February 2010 10:52, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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. Looks good! Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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. Cheers, Indrajit On 22/02/10 1:50 PM, Jeppe Nejsum Madsen wrote: On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger heiko.seeber...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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. 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, ) On Mon, Feb 22, 2010 at 7:03 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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. Cheers, Indrajit On 22/02/10 1:50 PM, Jeppe Nejsum Madsen wrote: On Mon, Feb 22, 2010 at 8:48 AM, Heiko Seeberger heiko.seeber...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
On Mon, Feb 22, 2010 at 7:13 PM, David Pollak feeder.of.the.be...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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? 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.the.be...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
On Mon, Feb 22, 2010 at 10:42 AM, Timothy Perrett timo...@getintheloop.euwrote: 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.the.be...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
Sorry David, do you mean you don't like configgy because it can change configurations at runtime? It can only do that if you specifically tell it to. Without registered observers, changes to the .conf file are ignored. Certainly, thats the way it works within all my applications that i've used configgy to date. Cheers, Tim On 22 Feb 2010, at 18:51, David Pollak wrote: On Mon, Feb 22, 2010 at 10:42 AM, Timothy Perrett timo...@getintheloop.eu wrote: 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.the.be...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett timo...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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 On 22 February 2010 08:44, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett timo...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Setting run mode for Lift applications
On Feb 18, 9:14 am, Petr Pudlak petr@gmail.com wrote: 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? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
aw anth...@whitford.com writes: On Feb 18, 9:14 am, Petr Pudlak petr@gmail.com wrote: 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? 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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Setting run mode for Lift applications
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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Setting run mode for Lift applications
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? Cheers, Tim On 20 Feb 2010, at 17:47, Petr Pudlak wrote: 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
