Yes, I like the idea of your "stakeholder" seeing you build and change the app live. The reloading stuff dates back to 2006; it's just a matter of dealing with Java ClassLoader objects ... customizing how they load classes and monitoring .class files for changes. When a .class file changes, Tapestry throws away the ClassLoader and creates a new one; it may have to reload dozens or more classes and reconstruct large numbers of objects, but Tapestry and Java are fast, so you don't notice.
There's some Leaky Abstractions (you really have to be careful about what classes are stored in what packages) but in the context of Tapestry most would agree that it works well ... and it's impossible to go back. On Mon, Jan 2, 2012 at 8:37 AM, Christian Grobmeier <grobme...@gmail.com> wrote: > Hello folks > > recently a Customer asked me to do some stuff with Tapestry. Being a > Struts user for a good while and trying out many other frameworks, > Tapestry impressed me lots. One of the things which made me eyes pop > out of their holes is the automatic class reloading you guys have > implemented. It is amazing! > > Now I am wondering how this is done... any pointers here? > > Thanks > Christian > > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
