I've been thinking of a blog post about everything I would do differently in Tapestry if I had perfect foreknowledge. Trust me, it would be different, and simpler in many ways ... and based more heavily on immutability (& controlled mutability) ala Clojure.
Parallel rendering would be nice though not as practical as you'd think ... but it would open the door for things like Hysterix (or other forms of circuit breakers). On Thu, Nov 6, 2014 at 4:37 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 06 Nov 2014 00:58:51 -0200, Alex Kotchnev <akoch...@gmail.com> > wrote: > > Thago & Lance - thanks a lot for your detailed comments and ideas. >> > > ;) > > http://apache-tapestry-mailing-list-archives.1045711. >> n5.nabble.com/Page-instance-variables-and-threads-td5728565.html >> > > In your case, this may be a Scala-Java behavior expectation mismatch. If > you wrote the exact same logic in Java, your closure would be a anonymous > inner class, non-static. This means instances of the closure have an have > an implicit reference to the surrounding object, which is the Tapestry > page, which right now cannot be shared among threads, resulting on what > you're experiencing. So you're not passing just the field value to the > closure: you're passing the whole page object. > > As Lance said, if you created a final variable copying the value of the > field, it would work. Here's an example, but be warned I've never > programmed in Scala: > > class ShowServer { > @PageActivationContext @Property > var sn:String = _ > > def setupRender():Unit = { > val string = sn > val servDetFut = for { > jg <- future { mgr.jarGroupName(string)} > props = mgr.props(string) > pl <- future { mgr.players(string) } > worlds <- future { mgr.listWorlds(string)} > ops <- future { mgr.ops(string) } > wl <- future { mgr.whitelist(string)} > bl <- future { mgr.blacklist(string) } > } yield McServerDetails( > server = mcServer, > jarGroup = jg, > worlds = worlds.toArray, > players = pl.toArray, > ops = ops.toArray, > whiteList = wl.toArray, > blackListed = bl, > props = props > ) > } > > serverDetails = Await.result(servDetFut, 60.seconds) > } > > In terms of being able to pass the state to the child threads, I was >> thinking - is there a way to put this state into InheritableThreadLocals >> (instead of ThreadLocals) so that child threads have access to the thread >> local state. Granted, it seems that with InheritableThreadLocals, if any >> state changes in the child thread it will not propagated to its parent, >> but >> that might be OK. >> > > This seems to be a very good idea. I'm not familiar with > InheritableThreadLocal. What could be the downsides of using it instead of > ThreadLocal? Performance? If yes, what would be the overhead? Anyway, we > could create an annotation to force a page instance to use > InheritableThreadLocal instead of ThreadLocal, which would remain the > default. > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > --------------------------------------------------------------------- > 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 @hlship
