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]
