Why not allow one to assign objects that are annotated with http://www.javaconcurrencyinpractice.com/annotations/doc/net/jcip/annotations/Immutable.html plus all standard java.lang wrappers (Integer ...) in the declaration, but throw exception for the rest? The package that contains that annotation (and a few other marker annotations) is available from the Maven repo (net.jcip:jcip-annotations:1.0), so I guess that adding that dependency to Tapestry is a no-brainer.
BTW: FindBugs understands these annotations as well. Just my 2c. Olle 2008/11/20 Marcelo Lotif <[EMAIL PROTECTED]> > I had exactly the same problem in one of our apps, and was pretty awkward, > one of my object was shared between all users, just like a static field. We > spent as much as 2 days trying to find out where was the problem, and when > we got nothing left to do, we took off the initial assignment and then the > problem disappeared. This was a hint I found when I was searching the > mailing list, but we had no clue if this was related to the problem. After > this, we adapt our apps to initialize the variables at another time > (SetupRender phase or when we are about to enter in a page). > > I think this kind of error report is a good point, and I recommend you to > take this off your pages before you have major problems. =) > > On Thu, Nov 20, 2008 at 3:17 PM, Howard Lewis Ship <[EMAIL PROTECTED]> > wrote: > > > Tapestry has not way to determine if a value is mutable or immutable. > > > > What was happening is that people were assigning mutable values > > (lists, maps, user-defined objects) as the initial value of a > > persistent field. The end result was that these mutable objects were > > being shared between users, as page instances got re-used. > > > > The change forces devs to be aware of this issue and to explicitly > > assign to it at a time when the value can be persisted in the session. > > > > On Wed, Nov 19, 2008 at 11:39 AM, Eric Ma <[EMAIL PROTECTED]> wrote: > > > > > > Why was this restriction introduced in 5.0.16? It completely breaks > our > > > application. If the benefit is marginal, can we roll back to the > > original > > > behavior? Or alternatively, what is a "better" practice under 5.0.16? > > > > > > Thanks, > > > -- > > > View this message in context: > > > http://www.nabble.com/-T5--Persistent-fields-may-not-be-updated-until-after-the-page-has-finished-loading-tp20587662p20587662.html > > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > -- > > Howard M. Lewis Ship > > > > Creator Apache Tapestry and Apache HiveMind > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Atenciosamente, > > Marcelo Lotif > Programador Java e Tapestry > FIEC - Federação das Indústrias do Estado do Ceará > (85) 3477-5910 > -- Olle Hallin Senior Java Developer and Architect [EMAIL PROTECTED] www.crisp.se
