Re: Tomcat class reloading and the development cycle
The class reloading feture in T5 is a great productivity gain, for a T4 project I myself created an hibernateSessionFactory implementation that resides in tomcat's class loader so I don't need to wait for hibernate to initialize. this was small improvement but not near to desired speedup. Question for Howard: With the current expirience with reloading page classes, what is a possibility for any of the commiters to implement a similar feature back to T4 ? is it: Hard, possible or impossible to implement ? Davor Hrg On 5/15/07, Inge Solvoll [EMAIL PROTECTED] wrote: Thanks anyway, Matt! I've done some experimenting, what actually works (most of the time) is to recompile a class without structural changes. If you change a method name or parameter, you have to reload the application. Some people say Jetty have better performance and better support for configuring the class reloading you want, does anyone here have experience with that? On 5/14/07, Matt Larson [EMAIL PROTECTED] wrote: Inge, You are right--this is much improved in Tap 5. However, as far as I understand (asked Howard about it at JavaOne) this works by using some custom classloader functionality that handles reloading specific Tapestry packages for your pages and components. The code checks for changes on some specified interval and reloads the changed classes. In Howard's demo at JavaOne all changes looked basically instantaneous. I'm sorry that's not really any help--just know that there's some special code to make this happen in Tap 5 that Tap 4 doesn't have. I have exactly the same problem with Tap 4 in Tomcat, and it is a huge pain due especially to hibernate intialization. A fast machine makes it less painful, but that's about it... Maybe others have suggestions for Tap 4. Matt Inge Solvoll wrote: Hi I would like to shorten the time spent from changing a class file to actually seeing the change in the browser. My problem now is that if I set my Tomcat application to reloadable, it reloads all servlets (including struts, tapestry and more) when I change a class file. This takes at least 5-10 secs. Then on the first page access to tapestry, it spends another 5 secs (at least) initializing tapestry, hivemind, tacos and so on. How can I avoid this reloading and still get tomcat to pick up the newest version of my class files? I've seen Howard's demos of Tapestry 5, where he hits reload in the browser 1 sec after a class change, and it loads in the browser within the same second. How can I achieve this on my system? I've seen people referring to the following hack on an application with reloadable=false, but I'm thinking there has to be a simpler way? - Delete the class file - Access the page, tomcat throws an exception because of missing class - Compile the class - Reload the page, tomcat picks up the new class file I suppose this is more of a Tomcat question than a Tapestry question, but it's heavily affecting the productivity of tapestry developers... Regards Inge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Tomcat class reloading and the development cycle
It would be very nice if you could provide this session factory implementation for us! Mit lieben Grüßen aus dem eWerk | Holger Stolzenberg | Softwareentwickler | | Geschäftsführer: | Frank Richter, Erik Wende, Hendrik Schubert | | eWerk IT GmbH | Markt 16 | Leipzig 04109 | http://www.ewerk.com | HRB 9065, AG Leipzig | Hauptniederlassung Leipzig | | fon +49.341.4 26 49-0 | fax +49.341.4 26 49-88 | mailto:[EMAIL PROTECTED] | | Support: | fon 0700 CALLME24 (0700 22556324) | fax 0700 CALLME24 (0700 22556324) | | Auskünfte und Angebote per Mail | sind freibleibend und unverbindlich. -Ursprüngliche Nachricht- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 15. Mai 2007 11:33 An: Tapestry users Betreff: Re: Tomcat class reloading and the development cycle The class reloading feture in T5 is a great productivity gain, for a T4 project I myself created an hibernateSessionFactory implementation that resides in tomcat's class loader so I don't need to wait for hibernate to initialize. this was small improvement but not near to desired speedup. Question for Howard: With the current expirience with reloading page classes, what is a possibility for any of the commiters to implement a similar feature back to T4 ? is it: Hard, possible or impossible to implement ? Davor Hrg On 5/15/07, Inge Solvoll [EMAIL PROTECTED] wrote: Thanks anyway, Matt! I've done some experimenting, what actually works (most of the time) is to recompile a class without structural changes. If you change a method name or parameter, you have to reload the application. Some people say Jetty have better performance and better support for configuring the class reloading you want, does anyone here have experience with that? On 5/14/07, Matt Larson [EMAIL PROTECTED] wrote: Inge, You are right--this is much improved in Tap 5. However, as far as I understand (asked Howard about it at JavaOne) this works by using some custom classloader functionality that handles reloading specific Tapestry packages for your pages and components. The code checks for changes on some specified interval and reloads the changed classes. In Howard's demo at JavaOne all changes looked basically instantaneous. I'm sorry that's not really any help--just know that there's some special code to make this happen in Tap 5 that Tap 4 doesn't have. I have exactly the same problem with Tap 4 in Tomcat, and it is a huge pain due especially to hibernate intialization. A fast machine makes it less painful, but that's about it... Maybe others have suggestions for Tap 4. Matt Inge Solvoll wrote: Hi I would like to shorten the time spent from changing a class file to actually seeing the change in the browser. My problem now is that if I set my Tomcat application to reloadable, it reloads all servlets (including struts, tapestry and more) when I change a class file. This takes at least 5-10 secs. Then on the first page access to tapestry, it spends another 5 secs (at least) initializing tapestry, hivemind, tacos and so on. How can I avoid this reloading and still get tomcat to pick up the newest version of my class files? I've seen Howard's demos of Tapestry 5, where he hits reload in the browser 1 sec after a class change, and it loads in the browser within the same second. How can I achieve this on my system? I've seen people referring to the following hack on an application with reloadable=false, but I'm thinking there has to be a simpler way? - Delete the class file - Access the page, tomcat throws an exception because of missing class - Compile the class - Reload the page, tomcat picks up the new class file I suppose this is more of a Tomcat question than a Tapestry question, but it's heavily affecting the productivity of tapestry developers... Regards Inge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat class reloading and the development cycle
I posted a comment decribing the general approach half a year ago on user list. here's the text ... here is something I haven't seen on the mailing list, and it speeds up Hibernate Actualy it saves SessionFactory in a static variable which has lifecycle of the tomcat server instaead the lifecycle of my web app. The trick is in the class loader (which Howard reminded mi of in his blog on T5 dynamic reload) my hibernate initializatio code is moved into a separate lib which is put in tomcat common class loader, so when I reload my webapp, the SessionFactory stays in a static field in a class which is out of the webapp's classloader. I moved most of the libraries to tomcat common for this to work, separated all my data classes and hibernate.cfg.xml into a separate jar, excluded these classes and config from deployment in my web app. It works like a charm, but my app is small nad hibernate startup is 2 secs, and comparing to tapestry startup almost neglectible, but since I've headr people say their hibernate starts for 5-8 secs or so I thought this could help ease their pain. . of course for this to work you must reload the application instead of restarting tomcat I'll try to find the mentioned source and post a more detailed example on how to do it On 5/15/07, Holger Stolzenberg [EMAIL PROTECTED] wrote: It would be very nice if you could provide this session factory implementation for us! Mit lieben Grüßen aus dem eWerk | Holger Stolzenberg | Softwareentwickler | | Geschäftsführer: | Frank Richter, Erik Wende, Hendrik Schubert | | eWerk IT GmbH | Markt 16 | Leipzig 04109 | http://www.ewerk.com | HRB 9065, AG Leipzig | Hauptniederlassung Leipzig | | fon +49.341.4 26 49-0 | fax +49.341.4 26 49-88 | mailto:[EMAIL PROTECTED] | | Support: | fon 0700 CALLME24 (0700 22556324) | fax 0700 CALLME24 (0700 22556324) | | Auskünfte und Angebote per Mail | sind freibleibend und unverbindlich. -Ursprüngliche Nachricht- Von: Davor Hrg [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 15. Mai 2007 11:33 An: Tapestry users Betreff: Re: Tomcat class reloading and the development cycle The class reloading feture in T5 is a great productivity gain, for a T4 project I myself created an hibernateSessionFactory implementation that resides in tomcat's class loader so I don't need to wait for hibernate to initialize. this was small improvement but not near to desired speedup. Question for Howard: With the current expirience with reloading page classes, what is a possibility for any of the commiters to implement a similar feature back to T4 ? is it: Hard, possible or impossible to implement ? Davor Hrg On 5/15/07, Inge Solvoll [EMAIL PROTECTED] wrote: Thanks anyway, Matt! I've done some experimenting, what actually works (most of the time) is to recompile a class without structural changes. If you change a method name or parameter, you have to reload the application. Some people say Jetty have better performance and better support for configuring the class reloading you want, does anyone here have experience with that? On 5/14/07, Matt Larson [EMAIL PROTECTED] wrote: Inge, You are right--this is much improved in Tap 5. However, as far as I understand (asked Howard about it at JavaOne) this works by using some custom classloader functionality that handles reloading specific Tapestry packages for your pages and components. The code checks for changes on some specified interval and reloads the changed classes. In Howard's demo at JavaOne all changes looked basically instantaneous. I'm sorry that's not really any help--just know that there's some special code to make this happen in Tap 5 that Tap 4 doesn't have. I have exactly the same problem with Tap 4 in Tomcat, and it is a huge pain due especially to hibernate intialization. A fast machine makes it less painful, but that's about it... Maybe others have suggestions for Tap 4. Matt Inge Solvoll wrote: Hi I would like to shorten the time spent from changing a class file to actually seeing the change in the browser. My problem now is that if I set my Tomcat application to reloadable, it reloads all servlets (including struts, tapestry and more) when I change a class file. This takes at least 5-10 secs. Then on the first page access to tapestry, it spends another 5 secs (at least) initializing tapestry, hivemind, tacos and so on. How can I avoid this reloading and still get tomcat to pick up the newest version of my class files? I've seen Howard's demos of Tapestry 5, where he hits reload in the browser 1 sec after a class change, and it loads in the browser within the same second. How can I achieve this on my system? I've seen people referring to the following hack on an application with reloadable=false, but I'm
Re: Tomcat class reloading and the development cycle
Inge, You are right--this is much improved in Tap 5. However, as far as I understand (asked Howard about it at JavaOne) this works by using some custom classloader functionality that handles reloading specific Tapestry packages for your pages and components. The code checks for changes on some specified interval and reloads the changed classes. In Howard's demo at JavaOne all changes looked basically instantaneous. I'm sorry that's not really any help--just know that there's some special code to make this happen in Tap 5 that Tap 4 doesn't have. I have exactly the same problem with Tap 4 in Tomcat, and it is a huge pain due especially to hibernate intialization. A fast machine makes it less painful, but that's about it... Maybe others have suggestions for Tap 4. Matt Inge Solvoll wrote: Hi I would like to shorten the time spent from changing a class file to actually seeing the change in the browser. My problem now is that if I set my Tomcat application to reloadable, it reloads all servlets (including struts, tapestry and more) when I change a class file. This takes at least 5-10 secs. Then on the first page access to tapestry, it spends another 5 secs (at least) initializing tapestry, hivemind, tacos and so on. How can I avoid this reloading and still get tomcat to pick up the newest version of my class files? I've seen Howard's demos of Tapestry 5, where he hits reload in the browser 1 sec after a class change, and it loads in the browser within the same second. How can I achieve this on my system? I've seen people referring to the following hack on an application with reloadable=false, but I'm thinking there has to be a simpler way? - Delete the class file - Access the page, tomcat throws an exception because of missing class - Compile the class - Reload the page, tomcat picks up the new class file I suppose this is more of a Tomcat question than a Tapestry question, but it's heavily affecting the productivity of tapestry developers... Regards Inge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat class reloading and the development cycle
Hi I would like to shorten the time spent from changing a class file to actually seeing the change in the browser. My problem now is that if I set my Tomcat application to reloadable, it reloads all servlets (including struts, tapestry and more) when I change a class file. This takes at least 5-10 secs. Then on the first page access to tapestry, it spends another 5 secs (at least) initializing tapestry, hivemind, tacos and so on. How can I avoid this reloading and still get tomcat to pick up the newest version of my class files? I've seen Howard's demos of Tapestry 5, where he hits reload in the browser 1 sec after a class change, and it loads in the browser within the same second. How can I achieve this on my system? I've seen people referring to the following hack on an application with reloadable=false, but I'm thinking there has to be a simpler way? - Delete the class file - Access the page, tomcat throws an exception because of missing class - Compile the class - Reload the page, tomcat picks up the new class file I suppose this is more of a Tomcat question than a Tapestry question, but it's heavily affecting the productivity of tapestry developers... Regards Inge
