You're right; it would have to be a system property. Robert
On Aug 17, 2010, at 8/171:40 AM , Igor Drobiazko wrote: > Sorry, the last message was confusing. Forget the statement about > FactoryDefault's and ApplicationDefaults. > > But there is a challenge. Right now the decision whether a service is > reloadable or not is made during binding. At bind time you don't have access > to symbols. > > On Tue, Aug 17, 2010 at 8:22 AM, Igor Drobiazko > <[email protected]>wrote: > >> I would prefer a system property, not a symbol. The "global switch on/off" >> is only for development and you will never override the FactoryDefault's >> value in ApplicationDefaults. >> >> >> On Mon, Aug 16, 2010 at 7:27 PM, 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] >>> >>> >> >> >> -- >> Best regards, >> >> Igor Drobiazko >> http://tapestry5.de >> > > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
