Static or final fields might be appropriate, as would moving logic out to a service.
The point of deprecating @Retain is that you can no longer trust that objects in component fields will only be visible to one thread at a time. Making the field final at least prevents race conditions related to assigning a value to the field. What's annoying is that if you store an object with mutable state, such as a DateFormat instance, into a field, you will now (in 5.2) begin to see thread safety issues (regardless of whether the field is final or uses @Retain). On Sat, Aug 21, 2010 at 6:15 AM, phoenixwright <cbx...@gmail.com> wrote: > > The type Retain is deprecated,what else can we use,or just use the static > fields? > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/As-the-type-Retain-is-deprecated-what-else-can-we-use-in-tapestry5-2-tp2643223p2643223.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > 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
