We should be using an AtomicLong to generate the values instead; that would ensure no duplications.
On Fri, Sep 30, 2011 at 3:56 AM, Christian Zulehner <[email protected]> wrote: > Hi, > > after changing to nanos, the problem still occured, although not very > often... > So I changed it locally to use Apache's RandomUtils.nextLong() instead of > System.nanoTime(). > > Anyone had the same problems or a better idea how to solve this? > Although I think it's not a 100% safe implementation (duplicate > randomvalues still possible), this seems to work for me at the moment. > Or am I barking up the wrong tree (looking at PartialMarkupRendererFilter) > ? > > > > > regards > > Christian Zulehner > Im Auftrag der Porsche Informatik GmbH > > > > > > > Von: Christian Zulehner <[email protected]> > An: [email protected] > Datum: 28.09.2011 13:06 > Betreff: Bug/Improvement in JavascriptSupport > PartialMarkupRendererFilter : millis vs. nanos > > > > Hi all, > > we ran into problems having more than one progressiv display on one page, > as some elements appeared to have the same (generated) id. > After investigation, we found out, that the code in > PartialMarkupRendererFilter javascriptSupport uses System. > currentTimeMillis(), which is obviously not sufficient. > We now use System.nanoTime() and this seems to work for us. (Quick fix is > to override the original tapestry contribution in your own module). > > Haven't found a Jira issue for that, but I think this really needs a > change. > > > > Mit freundlichen Grüßen > > Christian Zulehner > Im Auftrag der Porsche Informatik GmbH > -- 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: [email protected] For additional commands, e-mail: [email protected]
