reload application.properties
Martin
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
David Pollak
--
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
> 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 philosophy....when 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
David Pollak
> The Props.get stuff is frozen the first time its accessed. This is aAnd I agree very much in this philosophy....when we're talking
> 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.
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 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.
Naftoli Gugenheim
Would changing setSiteMap (if that's what it's called) to take a call by name be a bad idea?
-------------------------------------
David Pollak<feeder.of...@gmail.com> wrote:
> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
Jeppe Nejsum Madsen
[...]
>> 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.
>> - 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!
How do you envision this working? Just calling Boot again from a JRebel plugin?
> 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
David Pollak
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.
That would be awesome!
>> - 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.
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.
Not sure. SiteMap is the main culprit imo. I'll try to keep an eye out
> What other things need changing? Maybe the LiftRules stuff can be
> more dynamic at runtime.
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 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.
Jeppe Nejsum Madsen
[...]
>> > 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