Re: [Lift] Re: More dynamic Lift
Le 09/03/2010 18:35, David Pollak a écrit : On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett mailto:timo...@getintheloop.eu>> wrote: Wow, I wish I had 5 machines ;-) lol. Thats an interesting outlook and an explanatory rationale. Can you explain the implementation? Perhaps I can be persuaded. Right now, i'm not convinced about hampering development mode in this way. Basically, Boot will be run and then LiftRules will be snapshot. Then the function in the dynamic block is run. This gives us the baseline LiftRules. Tapestry 5 has such a functionnality build-in (JRebel wasn't around at the time when T5 was built, so there was no alternatives - and JRebel is not free for Java application) The user view is here: http://tapestry.apache.org/tapestry5.1/guide/reload.html I think that the implementation is somewhat like what you described (a classloader that can be dismissed used for class that could be reload) with some more logic to handle when reloads happen I'm not sure into what extends the comparison may be followed (T5 internal is quite different than Lift, there is pools of already instantiated component/pages waiting to be assembled for a request. See[0] for the component instantiation logic) Basically, there is a resquest filter[1] that look for time elapsed since last reload, and a update listener hub[2] is said to say to each of its registered resources to check for update[3]. Resources know how to check for update depending of their type (template resource, class[5], etc). If it is inspiring... The corresponding code is here, for last release: [0] http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.7/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ComponentInstantiatorSourceImpl.java?view=markup [1] Tapestry request filter: http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.7/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/CheckForUpdatesFilter.java?view=markup [2] Update Listener Hub: http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.7/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/UpdateListenerHubImpl.java?view=markup [4] Update listener: http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.7/tapestry-core/src/main/java/org/apache/tapestry5/services/UpdateListener.java?view=markup [5] Page (checkForUpdate): http://svn.apache.org/viewvc/tapestry/tapestry5/tags/releases/5.1.0.7/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/PagePoolImpl.java?view=markup -- Francois ARMAND http://fanf42.blogspot.com -- 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: More dynamic Lift
I see almost any difference with JRebel On Mar 9, 6:13 pm, David Pollak wrote: > My development cycle has never worked well with JRebel. > > First, I've got so many machines I do development on (5, 3 of which get > wiped each time Ubuntu releases a new version), getting all of those > machines set up with JRebel is something of a pain. Further, having JRebel > run in some cases is *very bad* (e.g., any compilation takes 10x longer with > JRebel). > > So, when I do use JRebel, it is generally a bad experience for me. This is > based on the way I code. First, I use a whole lot of for comprehensions in > my code. The problem with for comprehensions is that they create a bunch of > anonymous inner classes that are named based on the order they appear in the > code. This means that the classes for a given thing change and that leads > to incompatible class change issues. Further, I write a lot of code in > traits that I mix into lots of different classes. This also leads to less > than optimal results in JRebel (more incompatible class change issues.) The > JRebel folks and Martin have worked to address the former issue, have not > completely eliminated it. > > There's a further issue... JRebel doesn't work automatically with Lift. > Technically, it's costless, but you have to register it with ZeroTurnaround, > etc. This means you start using JRebel after you've made a commitment to > Lift rather than during the early stages of using Lift. > > So, based on our recent discussion about onboarding, some discussions Jeppe > and I have been having, and my non-JRebel-friendly development style, I > thought that there might be a way to address all of these issues at once. -- 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: More dynamic Lift
On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett wrote: > Wow, I wish I had 5 machines ;-) lol. > > Thats an interesting outlook and an explanatory rationale. Can you explain > the implementation? Perhaps I can be persuaded. Right now, i'm not convinced > about hampering development mode in this way. > Basically, Boot will be run and then LiftRules will be snapshot. Then the function in the dynamic block is run. This gives us the baseline LiftRules. For each request, we roll LiftRules back to the snapshot, create a new class loader, reload the function passed to the dynamic block and run that in the scope of the new classloader, then proceed to service the request. This means that all the classes referenced by the request are reloaded (although the excluded classes in model, etc. will be loaded by the servlet scope classloader rather than our per-request classloader). I can structure things such that if you don't use the dynamic block, you will see the same behavior as we have now. I can also structure things that will allow a "less dynamic" block that allows for SiteMap updates without causing the whole machinery to get invoked. So, what you'd see is: - Existing code would work exactly the way it works now - Any code that used the dynamic block in Boot would cause the new dynamic mechanism to be invoked (this would be the default for new projects, but well commented to suggest alternatives) - There would be a "less dynamic" mode for SiteMap and other LiftRules changes (this would be run on each request against the snapshotted LiftRules, but there would not be a new classloader). In this mode, you'd only be able to serve 1 request at once. Now, we could wait until 2.8 is the default... with package objects, we could define LiftRules in the package objects to be differently visible to each request (a la RequestVars). > > Cheers, Tim > > On 9 Mar 2010, at 17:13, David Pollak wrote: > > > So, based on our recent discussion about onboarding, some discussions > Jeppe and I have been having, and my non-JRebel-friendly development style, > I thought that there might be a way to address all of these issues at once. > > -- > 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.
Re: [Lift] Re: More dynamic Lift
Why is compilation running with JRebel? Also, how critical is JRebel to people getting their feet wet? When I was new to Lift, I used the default setting in the POM that caused a jetty hot redeploy when class files were updated. (Possibly earlier on I restarted jetty manually.) While that meant sitemap would be updated, after a number of restarts it would run out of PermGen memory. I only started using JRebel later. The best of both worlds would be JRebel + manual hot redeploy, which it sounds like is possible with SBT, which Lift plans to switch to. - David Pollak wrote: My development cycle has never worked well with JRebel. First, I've got so many machines I do development on (5, 3 of which get wiped each time Ubuntu releases a new version), getting all of those machines set up with JRebel is something of a pain. Further, having JRebel run in some cases is *very bad* (e.g., any compilation takes 10x longer with JRebel). So, when I do use JRebel, it is generally a bad experience for me. This is based on the way I code. First, I use a whole lot of for comprehensions in my code. The problem with for comprehensions is that they create a bunch of anonymous inner classes that are named based on the order they appear in the code. This means that the classes for a given thing change and that leads to incompatible class change issues. Further, I write a lot of code in traits that I mix into lots of different classes. This also leads to less than optimal results in JRebel (more incompatible class change issues.) The JRebel folks and Martin have worked to address the former issue, have not completely eliminated it. There's a further issue... JRebel doesn't work automatically with Lift. Technically, it's costless, but you have to register it with ZeroTurnaround, etc. This means you start using JRebel after you've made a commitment to Lift rather than during the early stages of using Lift. So, based on our recent discussion about onboarding, some discussions Jeppe and I have been having, and my non-JRebel-friendly development style, I thought that there might be a way to address all of these issues at once. On Tue, Mar 9, 2010 at 6:48 AM, Timothy Perrett wrote: > No it doesn't work for sitemap... as thats loaded at boot only ;-) My point > was that it can still be a good experience without JR for our users. > > Interesting what you were saying about your dev style... i'm usually the > other way around and implement sitemap last as I see it as a concrete > setting of my content. > > Cheers, Tim > > > On 9 Mar 2010, at 11:20, Jeppe Nejsum Madsen wrote: > > > On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett > > wrote: > >> BTW, with SBT, don't forget you can do: > >> > >> jetty-run > >> (make changes to your code) > >> prepare-webapp > >> > >> That will redeploy chnaged files / classses to the running jetty > instance so > >> development with SBT can still be slick without javarebel :-) > > > > But still this doesn't address the problem (I think?) of changing > > things in Boot. Maybe I code differently from everybody else, but when > > iterating new features, I always end up making lots of changes to > > Sitemap. And afaik everyone of those changes requires a restart > > > > For the rest I agree JRebel fits quite nicely (it does have it's > > problems as David points 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. > > > > > > -- > 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: More dynamic Lift
Wow, I wish I had 5 machines ;-) lol. Thats an interesting outlook and an explanatory rationale. Can you explain the implementation? Perhaps I can be persuaded. Right now, i'm not convinced about hampering development mode in this way. Cheers, Tim On 9 Mar 2010, at 17:13, David Pollak wrote: > So, based on our recent discussion about onboarding, some discussions Jeppe > and I have been having, and my non-JRebel-friendly development style, I > thought that there might be a way to address all of these issues at once. -- 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: More dynamic Lift
My development cycle has never worked well with JRebel. First, I've got so many machines I do development on (5, 3 of which get wiped each time Ubuntu releases a new version), getting all of those machines set up with JRebel is something of a pain. Further, having JRebel run in some cases is *very bad* (e.g., any compilation takes 10x longer with JRebel). So, when I do use JRebel, it is generally a bad experience for me. This is based on the way I code. First, I use a whole lot of for comprehensions in my code. The problem with for comprehensions is that they create a bunch of anonymous inner classes that are named based on the order they appear in the code. This means that the classes for a given thing change and that leads to incompatible class change issues. Further, I write a lot of code in traits that I mix into lots of different classes. This also leads to less than optimal results in JRebel (more incompatible class change issues.) The JRebel folks and Martin have worked to address the former issue, have not completely eliminated it. There's a further issue... JRebel doesn't work automatically with Lift. Technically, it's costless, but you have to register it with ZeroTurnaround, etc. This means you start using JRebel after you've made a commitment to Lift rather than during the early stages of using Lift. So, based on our recent discussion about onboarding, some discussions Jeppe and I have been having, and my non-JRebel-friendly development style, I thought that there might be a way to address all of these issues at once. On Tue, Mar 9, 2010 at 6:48 AM, Timothy Perrett wrote: > No it doesn't work for sitemap... as thats loaded at boot only ;-) My point > was that it can still be a good experience without JR for our users. > > Interesting what you were saying about your dev style... i'm usually the > other way around and implement sitemap last as I see it as a concrete > setting of my content. > > Cheers, Tim > > > On 9 Mar 2010, at 11:20, Jeppe Nejsum Madsen wrote: > > > On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett > > wrote: > >> BTW, with SBT, don't forget you can do: > >> > >> jetty-run > >> (make changes to your code) > >> prepare-webapp > >> > >> That will redeploy chnaged files / classses to the running jetty > instance so > >> development with SBT can still be slick without javarebel :-) > > > > But still this doesn't address the problem (I think?) of changing > > things in Boot. Maybe I code differently from everybody else, but when > > iterating new features, I always end up making lots of changes to > > Sitemap. And afaik everyone of those changes requires a restart > > > > For the rest I agree JRebel fits quite nicely (it does have it's > > problems as David points 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. > > > > > > -- > 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.
Re: [Lift] Re: More dynamic Lift
If the sitemap could be specified as a function JRebel could reload it. One approach is along the lines that setSiteMap could be passed a function e.g. ()=>List[Menu]. In production mode the return value may or may not be cached. Another approach is to have an optional method in Boot called say buildSiteMap. If it's not defined you can build it imperatively in def boot. Or you can define buildSiteMap. In development mode it would be called on every page load. In production mode it could either be called once, or it could be called every time. Personally I see value in a dynamic, functional sitemap even in production, but it may impact performance (or not). - Jeppe Nejsum Madsen wrote: On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett wrote: > BTW, with SBT, don't forget you can do: > > jetty-run > (make changes to your code) > prepare-webapp > > That will redeploy chnaged files / classses to the running jetty instance so > development with SBT can still be slick without javarebel :-) But still this doesn't address the problem (I think?) of changing things in Boot. Maybe I code differently from everybody else, but when iterating new features, I always end up making lots of changes to Sitemap. And afaik everyone of those changes requires a restart For the rest I agree JRebel fits quite nicely (it does have it's problems as David points 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. -- 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: More dynamic Lift
No it doesn't work for sitemap... as thats loaded at boot only ;-) My point was that it can still be a good experience without JR for our users. Interesting what you were saying about your dev style... i'm usually the other way around and implement sitemap last as I see it as a concrete setting of my content. Cheers, Tim On 9 Mar 2010, at 11:20, Jeppe Nejsum Madsen wrote: > On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett > wrote: >> BTW, with SBT, don't forget you can do: >> >> jetty-run >> (make changes to your code) >> prepare-webapp >> >> That will redeploy chnaged files / classses to the running jetty instance so >> development with SBT can still be slick without javarebel :-) > > But still this doesn't address the problem (I think?) of changing > things in Boot. Maybe I code differently from everybody else, but when > iterating new features, I always end up making lots of changes to > Sitemap. And afaik everyone of those changes requires a restart > > For the rest I agree JRebel fits quite nicely (it does have it's > problems as David points 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. > > -- 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: More dynamic Lift
On Mar 9, 1:08 pm, Timothy Perrett wrote: > BTW, with SBT, don't forget you can do: > > jetty-run > (make changes to your code) > prepare-webapp > > That will redeploy chnaged files / classses to the running jetty > instance so development with SBT can still be slick without > javarebel :-) > > Lift is really elegant - some how, this approach feels pretty ugly. I > haven't looked at it, but no doubt it's using some classloader trickery? Of course this is why one can get into cast failures as ProtectionDomain may change. I haven't seen Dave's code so he can provide more details of what he did. > > Cheers, Tim > > Sent from my iPhone > > On 9 Mar 2010, at 10:45, Lukasz Kuczera wrote: > > > > > But on the other hand it happens not too often. I'm personally very > > very happy with current productiveness using Lift + Jetty + JRebel. > > But what happens when Zeroturnaround will turn back to Scala ? It is > > quite possible that Scala will go mainstream. It might be viable > > solution then. > > > Simple solution would be putting Menu building just before page > > rendering in "development" mode. But i can live perfectly without that > > as well (using JRebel). > > > On Mar 9, 9:37 am, Jeppe Nejsum Madsen wrote: > >> On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett > >> wrote: > >>> I'm afraid I agree with Marius... I'm just not sure on the benefit > >>> here over > >>> JRebel? > > >> My main pain point was changes to Sitemap. JRebel doesn't help you > >> here as it's fixed once Lift is booted... > >> /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 > > athttp://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] Re: More dynamic Lift
But on the other hand it happens not too often. I'm personally very very happy with current productiveness using Lift + Jetty + JRebel. But what happens when Zeroturnaround will turn back to Scala ? It is quite possible that Scala will go mainstream. It might be viable solution then. Simple solution would be putting Menu building just before page rendering in "development" mode. But i can live perfectly without that as well (using JRebel). On Mar 9, 9:37 am, Jeppe Nejsum Madsen wrote: > On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett > wrote: > > I'm afraid I agree with Marius... I'm just not sure on the benefit here over > > JRebel? > > My main pain point was changes to Sitemap. JRebel doesn't help you > here as it's fixed once Lift is booted... > /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: More dynamic Lift
On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett wrote: > BTW, with SBT, don't forget you can do: > > jetty-run > (make changes to your code) > prepare-webapp > > That will redeploy chnaged files / classses to the running jetty instance so > development with SBT can still be slick without javarebel :-) But still this doesn't address the problem (I think?) of changing things in Boot. Maybe I code differently from everybody else, but when iterating new features, I always end up making lots of changes to Sitemap. And afaik everyone of those changes requires a restart For the rest I agree JRebel fits quite nicely (it does have it's problems as David points 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.
Re: [Lift] Re: More dynamic Lift
BTW, with SBT, don't forget you can do: jetty-run (make changes to your code) prepare-webapp That will redeploy chnaged files / classses to the running jetty instance so development with SBT can still be slick without javarebel :-) Lift is really elegant - some how, this approach feels pretty ugly. I haven't looked at it, but no doubt it's using some classloader trickery? Cheers, Tim Sent from my iPhone On 9 Mar 2010, at 10:45, Lukasz Kuczera wrote: But on the other hand it happens not too often. I'm personally very very happy with current productiveness using Lift + Jetty + JRebel. But what happens when Zeroturnaround will turn back to Scala ? It is quite possible that Scala will go mainstream. It might be viable solution then. Simple solution would be putting Menu building just before page rendering in "development" mode. But i can live perfectly without that as well (using JRebel). On Mar 9, 9:37 am, Jeppe Nejsum Madsen wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett wrote: I'm afraid I agree with Marius... I'm just not sure on the benefit here over JRebel? My main pain point was changes to Sitemap. JRebel doesn't help you here as it's fixed once Lift is booted... /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: More dynamic Lift
On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett wrote: > I'm afraid I agree with Marius... I'm just not sure on the benefit here over > JRebel? My main pain point was changes to Sitemap. JRebel doesn't help you here as it's fixed once Lift is booted... /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: More dynamic Lift
I'm afraid I agree with Marius... I'm just not sure on the benefit here over JRebel? Cheers, Tim Sent from my iPhone On 9 Mar 2010, at 08:05, Marius wrote: I'm having seconds thoughts about this. Development mode can mean slightly different things depending on the nature of the application. The things you enlisted are for me only PROS for not including this feature. Sorry but personally I don't see much value in this approach ... but this doesn't mean other people wont. Yes JavaRebel is not perfect but it does its job quite good and it is really helpful in most cases. On Mar 9, 2:51 am, David Pollak wrote: Folks, I spent today "cracking the code" on how to implement a more dynamic Lift development cycle. Specifically, I figured out how to support (during development mode) having changes in compiled code reflected in the running application. The change to your Lift app will be a change in how you do things in Boot.scala. Basically, anything that could change between page loads will be wrapped as such in Boot: LiftRules.dynamicDevelopmentMode(List("com.liftcode.model", "com.liftcode.lib"))(() => { LiftRules.dispatch.append {...} LiftRules.setSiteMap() }) The list is a list of packages to exclude from the dynamic reloading. Because schemification isn't going to happen on every page reload, it's best not to reload the models. The dynamic mode will impose the following limitations: - Lift will only service one request at once in development mode - Page loads in development mode will be 10x-50x slower than in non-development mode - Comet objects will not change once they've been instantiated - There will cases where classes created in one classloader are not recognized as the same class for casting and/or pattern matching purposes if the classes are created across calls - There may be problems related to running out of PermGen space because each page reload will cause all the applications classes to be reloaded... and this may happen faster than the classes are GCed. With those limitations, do you guys thing the feature would be valuable? Should it be part of development mode or should there be another demarcation of the dynamic reload mode? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://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.
[Lift] Re: More dynamic Lift
I'm having seconds thoughts about this. Development mode can mean slightly different things depending on the nature of the application. The things you enlisted are for me only PROS for not including this feature. Sorry but personally I don't see much value in this approach ... but this doesn't mean other people wont. Yes JavaRebel is not perfect but it does its job quite good and it is really helpful in most cases. On Mar 9, 2:51 am, David Pollak wrote: > Folks, > > I spent today "cracking the code" on how to implement a more dynamic Lift > development cycle. Specifically, I figured out how to support (during > development mode) having changes in compiled code reflected in the running > application. The change to your Lift app will be a change in how you do > things in Boot.scala. Basically, anything that could change between page > loads will be wrapped as such in Boot: > > LiftRules.dynamicDevelopmentMode(List("com.liftcode.model", > "com.liftcode.lib"))(() => { > LiftRules.dispatch.append {...} > > LiftRules.setSiteMap() > > }) > > The list is a list of packages to exclude from the dynamic reloading. > Because schemification isn't going to happen on every page reload, it's best > not to reload the models. > > The dynamic mode will impose the following limitations: > > - Lift will only service one request at once in development mode > - Page loads in development mode will be 10x-50x slower than in > non-development mode > - Comet objects will not change once they've been instantiated > - There will cases where classes created in one classloader are not > recognized as the same class for casting and/or pattern matching purposes > if > the classes are created across calls > - There may be problems related to running out of PermGen space because > each page reload will cause all the applications classes to be reloaded... > and this may happen faster than the classes are GCed. > > With those limitations, do you guys thing the feature would be valuable? > Should it be part of development mode or should there be another demarcation > of the dynamic reload mode? > > Thanks, > > David > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://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: More dynamic Lift
On Tue, Mar 9, 2010 at 2:42 AM, harryh wrote: > What's the advantage of this sort of setup over using JavaRebel? Sitemap and other things set in boot doesn't really change even if the class is reloaded by JRebel /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: More dynamic Lift
It's less sensitive to inner class name changes and supports changing interfaces. Connected by MOTOBLUR™ on T-Mobile -Original message- From: harryh To: Lift Sent: Tue, Mar 9, 2010 01:42:10 GMT+00:00 Subject: [Lift] Re: More dynamic Lift What's the advantage of this sort of setup over using JavaRebel? -harryh -- 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] Re: More dynamic Lift
What's the advantage of this sort of setup over using JavaRebel? -harryh -- 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.