Re: [Lift] reload application.properties
On Tue, Mar 2, 2010 at 12:48 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: David Pollak feeder.of.the.be...@gmail.com writes: [...] 1) Change the menu structure? Restart server Yes. This is a problem. 2) Change the menu text? Restart server (yes I use properties for text and yes I need an app in different languages, see other thread :-) This is a problem as well. 3) Change something in a mapped field? Restart server This is unavoidable. If the model changes, you have to re-sync to the RDBMS and this requires a restart. In practice, how often do you change your model? Depends on what you mean by model. If you mean adding/changing fields at the db level, requiring restart is not a big problem. But when using mapper, this is not the only thing that lives in the model. Hiding showing fields, render format, the validations etc. I just tried again, and some stuff does seem to be working. It may have been a JRebel issue. I'll try to keep an eye on this and see if there are some specific things that doesn't change dynamically. 4) Change a field label? Restart server With JRebel, the change to a field label should be reflected immediately. I swear I tried this before writing :-) But you're right, it does seem to work (unless you get the label from properties :-) [...] It would be really nice for some of this to be picked up automatically when running in development mode. I still remember some time ago when I did a project in PHP. I don't like the PHP language very much, but you can't really beat the instant gratification of a code change: Just reload the page! The problem is two-fold: (1) Lift is stateful and trying to morph the state based on change to logic is non-trivial and (2) the amount of logic you can get into a line of PHP vs. a line of Scala is 2-3 orders of magnitude different. Agreed, and I'm not looking to get a seamless incorporation of dynamic changes. But not having to do the restart/relogin cycle in the most frequent scenarios would be nice. I think some of these issues could be solved easily, some will require more work and some may be impossible. - Reloading properties if the file has changed should be easy. What do you keep in your properties file? I keep database connection info and service endpoints (e.g., Amazon S3 urls and passwords). Changing this stuff should require an app restart. Agreed. What do you keep in your properties files that can change at runtime? Translated strings. You keep your translated strings in the files accessed by net.liftweb.util.Props? I haven't done any Lift localization, but I think that's the wrong place for them. If the current implementation of the localization stuff isn't reloading the localization files on change during dev mode, that's a defect (or an enhancement) and deserves a ticket. - Rebooting lift on the fly may not be easy, but perhaps some things could be made reloadable (sitemap?). If you then write a JRebel plugin (not a hard task) that triggers the reload when a class change is detected, you will be one step closer to RAD nirvana. SiteMap is an easy case. If you'd be so kind as to open a ticket and assign it to me, I'll make SiteMap morphable in development mode. That would be awesome! https://www.assembla.com/spaces/liftweb/tickets/385-make-sitemap-dynamic-when-running-in-development-mode How do you envision this working? Just calling Boot again from a JRebel plugin? I'm not going to call Boot again, but I have a bunch of ideas of an efficient mechanism for recalculating stuff on a request-by-request basis in dev mode, but only once in production mode. What other things need changing? Maybe the LiftRules stuff can be more dynamic at runtime. Not sure. SiteMap is the main culprit imo. I'll try to keep an eye out for others /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] reload application.properties
David Pollak feeder.of.the.be...@gmail.com writes: [...] What do you keep in your properties files that can change at runtime? Translated strings. You keep your translated strings in the files accessed by net.liftweb.util.Props? I haven't done any Lift localization, but I think that's the wrong place for them. Ahh I see we've been talking past each other then. I was talking about properties in the general sense (as read by e.g. S.?()), not about net.liftweb.util.Props which I agree is not important for dynamic reload. If the current implementation of the localization stuff isn't reloading the localization files on change during dev mode, that's a defect (or an enhancement) and deserves a ticket. Good to see we're on the same page after all. I'm pretty sure they're not being reloaded, but will double check and file a ticket if needed. [...] I'm not going to call Boot again, but I have a bunch of ideas of an efficient mechanism for recalculating stuff on a request-by-request basis in dev mode, but only once in production mode. But it will still require something that picks up the changed/reloaded class files from somewhere? I look forward to try it out. /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] reload application.properties
Hi is there any way to reload application.properties file after boot.scala finishes? I would like to do dynamic localization of properties on my site, without need to stop/start application. Mayby there is much better way to accomplish it. I would really appreciate any help. best regards, Martin -- 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] reload application.properties
The Props.get stuff is frozen the first time its accessed. This is a philosophical issue for me. The properties should be fixed at start-up time. If there are things to vary, build an administrative interface or some other thingy (e.g., a separate HTTP listener) that allows you to manipulate the mutable configuration. On Mon, Mar 1, 2010 at 4:57 AM, Martin marcin.szla...@gmail.com wrote: Hi is there any way to reload application.properties file after boot.scala finishes? I would like to do dynamic localization of properties on my site, without need to stop/start application. Mayby there is much better way to accomplish it. I would really appreciate any help. best regards, Martin -- 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] reload application.properties
David Pollak feeder.of.the.be...@gmail.com writes: The Props.get stuff is frozen the first time its accessed. This is a philosophical issue for me. The properties should be fixed at start-up time. If there are things to vary, build an administrative interface or some other thingy (e.g., a separate HTTP listener) that allows you to manipulate the mutable configuration. And I agree very much in this philosophywhen we're talking production. I'm interested if you feel the same way about this during development? If so, stop reading as the rest will just be a rant, if not read on :-) I think the static nature of some of Lift's internals is one of the greatest productivity killers when it comes to rapidly start up with a new app where you quickly iterate different ideas (or even do many small changes in an existing app). 1) Change the menu structure? Restart server 2) Change the menu text? Restart server (yes I use properties for text and yes I need an app in different languages, see other thread :-) 3) Change something in a mapped field? Restart server 4) Change a field label? Restart server Using JRebel doesn't really help in these scenarios as the values are fixed at start-up. There are probably others, but these are the ones I can recall. Perhaps I'm being hit harder than others since 1) We need different languages and 2) You need to be logged in to see the app. Or perhaps I just don't develop in an efficient way who knows? It would be really nice for some of this to be picked up automatically when running in development mode. I still remember some time ago when I did a project in PHP. I don't like the PHP language very much, but you can't really beat the instant gratification of a code change: Just reload the page! I think some of these issues could be solved easily, some will require more work and some may be impossible. - Reloading properties if the file has changed should be easy. - Rebooting lift on the fly may not be easy, but perhaps some things could be made reloadable (sitemap?). If you then write a JRebel plugin (not a hard task) that triggers the reload when a class change is detected, you will be one step closer to RAD nirvana. I'm interested to hear if others have the same pain points as me (if not, I don't see this changing soon :-) and if there are some ideas how to remedy this (either by changing Lift or changing my development process :-) /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] reload application.properties
On Mon, Mar 1, 2010 at 12:30 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: David Pollak feeder.of.the.be...@gmail.com writes: The Props.get stuff is frozen the first time its accessed. This is a philosophical issue for me. The properties should be fixed at start-up time. If there are things to vary, build an administrative interface or some other thingy (e.g., a separate HTTP listener) that allows you to manipulate the mutable configuration. And I agree very much in this philosophywhen we're talking production. I'm interested if you feel the same way about this during development? If so, stop reading as the rest will just be a rant, if not read on :-) I think the static nature of some of Lift's internals is one of the greatest productivity killers when it comes to rapidly start up with a new app where you quickly iterate different ideas (or even do many small changes in an existing app). 1) Change the menu structure? Restart server Yes. This is a problem. 2) Change the menu text? Restart server (yes I use properties for text and yes I need an app in different languages, see other thread :-) This is a problem as well. 3) Change something in a mapped field? Restart server This is unavoidable. If the model changes, you have to re-sync to the RDBMS and this requires a restart. In practice, how often do you change your model? 4) Change a field label? Restart server With JRebel, the change to a field label should be reflected immediately. Using JRebel doesn't really help in these scenarios as the values are fixed at start-up. There are probably others, but these are the ones I can recall. Perhaps I'm being hit harder than others since 1) We need different languages and 2) You need to be logged in to see the app. Or perhaps I just don't develop in an efficient way who knows? It would be really nice for some of this to be picked up automatically when running in development mode. I still remember some time ago when I did a project in PHP. I don't like the PHP language very much, but you can't really beat the instant gratification of a code change: Just reload the page! The problem is two-fold: (1) Lift is stateful and trying to morph the state based on change to logic is non-trivial and (2) the amount of logic you can get into a line of PHP vs. a line of Scala is 2-3 orders of magnitude different. I think some of these issues could be solved easily, some will require more work and some may be impossible. - Reloading properties if the file has changed should be easy. What do you keep in your properties file? I keep database connection info and service endpoints (e.g., Amazon S3 urls and passwords). Changing this stuff should require an app restart. What do you keep in your properties files that can change at runtime? - Rebooting lift on the fly may not be easy, but perhaps some things could be made reloadable (sitemap?). If you then write a JRebel plugin (not a hard task) that triggers the reload when a class change is detected, you will be one step closer to RAD nirvana. SiteMap is an easy case. If you'd be so kind as to open a ticket and assign it to me, I'll make SiteMap morphable in development mode. What other things need changing? Maybe the LiftRules stuff can be more dynamic at runtime. I'm interested to hear if others have the same pain points as me (if not, I don't see this changing soon :-) and if there are some ideas how to remedy this (either by changing Lift or changing my development process :-) /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] reload application.properties
Is a dynamic menu not advantageous for production apps (e.g., a CMS)? Would changing setSiteMap (if that's what it's called) to take a call by name be a bad idea? - David Pollakfeeder.of.the.be...@gmail.com wrote: On Mon, Mar 1, 2010 at 12:30 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: David Pollak feeder.of.the.be...@gmail.com writes: The Props.get stuff is frozen the first time its accessed. This is a philosophical issue for me. The properties should be fixed at start-up time. If there are things to vary, build an administrative interface or some other thingy (e.g., a separate HTTP listener) that allows you to manipulate the mutable configuration. And I agree very much in this philosophywhen we're talking production. I'm interested if you feel the same way about this during development? If so, stop reading as the rest will just be a rant, if not read on :-) I think the static nature of some of Lift's internals is one of the greatest productivity killers when it comes to rapidly start up with a new app where you quickly iterate different ideas (or even do many small changes in an existing app). 1) Change the menu structure? Restart server Yes. This is a problem. 2) Change the menu text? Restart server (yes I use properties for text and yes I need an app in different languages, see other thread :-) This is a problem as well. 3) Change something in a mapped field? Restart server This is unavoidable. If the model changes, you have to re-sync to the RDBMS and this requires a restart. In practice, how often do you change your model? 4) Change a field label? Restart server With JRebel, the change to a field label should be reflected immediately. Using JRebel doesn't really help in these scenarios as the values are fixed at start-up. There are probably others, but these are the ones I can recall. Perhaps I'm being hit harder than others since 1) We need different languages and 2) You need to be logged in to see the app. Or perhaps I just don't develop in an efficient way who knows? It would be really nice for some of this to be picked up automatically when running in development mode. I still remember some time ago when I did a project in PHP. I don't like the PHP language very much, but you can't really beat the instant gratification of a code change: Just reload the page! The problem is two-fold: (1) Lift is stateful and trying to morph the state based on change to logic is non-trivial and (2) the amount of logic you can get into a line of PHP vs. a line of Scala is 2-3 orders of magnitude different. I think some of these issues could be solved easily, some will require more work and some may be impossible. - Reloading properties if the file has changed should be easy. What do you keep in your properties file? I keep database connection info and service endpoints (e.g., Amazon S3 urls and passwords). Changing this stuff should require an app restart. What do you keep in your properties files that can change at runtime? - Rebooting lift on the fly may not be easy, but perhaps some things could be made reloadable (sitemap?). If you then write a JRebel plugin (not a hard task) that triggers the reload when a class change is detected, you will be one step closer to RAD nirvana. SiteMap is an easy case. If you'd be so kind as to open a ticket and assign it to me, I'll make SiteMap morphable in development mode. What other things need changing? Maybe the LiftRules stuff can be more dynamic at runtime. I'm interested to hear if others have the same pain points as me (if not, I don't see this changing soon :-) and if there are some ideas how to remedy this (either by changing Lift or changing my development process :-) /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. -- 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
