Agreed. A global flag defaulted to false is a good compromise which ensures
backward compatibility.

On Mon, Aug 16, 2010 at 7:40 PM, Kalle Korhonen
<[email protected]>wrote:

> I suggested the global flag and enableReloading() in my first post on
> this thread, but also noted that it might cause even more confusion as
> more configuration options typically do. Let's remember that this is a
> development-time feature only so the outcry regarding backwards
> compatibility is somewhat unwarranted. A global service reloading flag
> that by default is false would probably be a good enough compromise -
> if you want the feature you need to deal with the requirements it
> imposes.
>
> Kalle
>
>
> On Mon, Aug 16, 2010 at 10:27 AM, Robert Zeigler <[email protected]>
> wrote:
> > I love live service implementation reloading, and I would hate to have to
> explicitly enable it for every service I create. I'm in favor of the "global
> on/off switch" as proposed by, eg, Michal Gruca.  I'm not sure if it would
> be feasible to have a global "off" and then an enableReloading() call for
> specific services, but, at the very least, having it be "off"="everything
> off", and "on" = retain current behavior (on except for services with
> preventReloading()) should be imminently doable. It may even be best to turn
> off live service reloading by default (in tapestry's
> contributeFactoryDefaults) so that you have the same behavior as before
> T5.2, and then you can turn on the reloading at your leisure.  That way,
> upgrade = painless, but it's still easy to globally turn on the feature (for
> people like me who love it and don't have any access issues :).
> >
> > Robert
> >
> > On Aug 16, 2010, at 8/169:22 AM , Thiago H. de Paula Figueiredo wrote:
> >
> >> On Mon, 16 Aug 2010 03:48:32 -0300, Igor Drobiazko <
> [email protected]> wrote:
> >>
> >>> So, what is the consensus on fixing the issue?
> >>
> >> +1 for live reloading of a given service live needing an explicit action
> from the Tapestry user (i.e. enableReloading()).
> >>
> >> As it is now, Tapestry-IoC is breaking backward compatibility in a
> serious way.
> >>
> >> --
> >> 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: [email protected]
> >> For additional commands, e-mail: [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de

Reply via email to