For backward compatibility reasons it should be enableReloading() and not preventReloading(). Otherwise the most apps will suffer from this issue. Do you remember our promise? Making new features (that can break my app) configurable and disabling them per default is a good practise.
On Thu, Aug 12, 2010 at 1:01 AM, Robert Zeigler <robe...@scazdl.org> wrote: > Does: > binder.bind(Interface.class, Implementation.class).preventReloading(); > > not do the trick? > > It's already disabled for services that use buildXXX since Tapestry won't > know the implementation class of the service. > > Robert > > On Aug 11, 2010, at 8/115:40 PM , Thiago H. de Paula Figueiredo wrote: > > > On Wed, 11 Aug 2010 19:18:42 -0300, Igor Drobiazko < > igor.drobia...@gmail.com> wrote: > > > >> But you would recreate only those services that you need right now. All > >> other "heavy" services are created later on demand. > > > > These heavy service methods could be invoked by the recreated services, > but I agree with you too. > > > > By the way, I couldn't find any way of disabling the services live > reloading. Is there any? If not, it would be nice to have one. > > > > -- > > Thiago H. de Paula Figueiredo > > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, > and instructor > > Owner, Ars Machina Tecnologia da Informação Ltda. > > http://www.arsmachina.com.br > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Best regards, Igor Drobiazko http://tapestry5.de
