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 marius.dan...@gmail.com 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 feeder.of.the.be...@gmail.com 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.
Re: [Lift] Re: More dynamic Lift
On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu 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
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 kuk...@gmail.com 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 je...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu 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 12:08 PM, Timothy Perrett timo...@getintheloop.eu 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.
[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 je...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu 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
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 Madsenje...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 12:08 PM, Timothy Perrett timo...@getintheloop.eu 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 timo...@getintheloop.eu 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 timo...@getintheloop.eu 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 kuk...@gmail.com 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 je...@ingolfs.dk wrote: On Tue, Mar 9, 2010 at 9:33 AM, Timothy Perrett timo...@getintheloop.eu 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.
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 timo...@getintheloop.euwrote: 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 timo...@getintheloop.eu 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.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: 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
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 Pollakfeeder.of.the.be...@gmail.com 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 timo...@getintheloop.euwrote: 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 timo...@getintheloop.eu 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.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. -- 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 timo...@getintheloop.euwrote: 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.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.
[Lift] Re: More dynamic Lift
I see almost any difference with JRebel On Mar 9, 6:13 pm, David Pollak feeder.of.the.be...@gmail.com 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
Le 09/03/2010 18:35, David Pollak a écrit : On Tue, Mar 9, 2010 at 9:25 AM, Timothy Perrett timo...@getintheloop.eu 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
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.
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 har...@gmail.com To: Lift liftweb@googlegroups.com 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.
Re: [Lift] Re: More dynamic Lift
On Tue, Mar 9, 2010 at 2:42 AM, harryh har...@gmail.com 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.
