On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett <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. 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<liftweb%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.
