Re: Tapestry 5.2 bug?
I am using PipedInputStream and PipedOutputStream to convert a large OutputStream to StreamResponse, that needs a new thread. For me, there is no problem with the new approach, just want framework which is already very great to be perfect. Yunhua On Mon, Sep 27, 2010 at 4:57 PM, Howard Lewis Ship wrote: > True, there are some leaky abstractions related to the new approach; > there was a different set in the 5.1 version of the page lifecycle. > > I've never felt the need to start up a thread from the middle of a > page. I'm curious what your use case is, and whether it wouldn't be > better handled > using ThreadPools (for starters) and perhaps a JMS solution. I'm > having some great luck using ActiveMQ right now, so split long > synchronous work into small asynchronous work. > > On Mon, Sep 27, 2010 at 1:37 PM, Yunhua Sang wrote: >> Hi Thiago, >> >> Thanks for your response. Yes, the code looks not nice, however, there >> is nothing wrong with it. I knew there was a refactoring of changing >> pool to singleton recently, so I was able to come up with a workaround >> quickly, but for a Tapestry newbie, he/she might not know what's going >> on, then will spend a lot of time to figour out. >> >> Yunhua >> >> On Mon, Sep 27, 2010 at 4:13 PM, Thiago H. de Paula Figueiredo >> wrote: >>> On Mon, 27 Sep 2010 16:47:38 -0300, Yunhua Sang >>> wrote: >>> Hi everyone, >>> >>> Hi! >>> The field is always null when printing it out within run method; a workaround is to define a local variable then access this variable in new thread.I am wondering whether it's an expected behaviour or not. >>> >>> It's expected behavior after Tapestry does not uses a page pool anymore. >>> Even before the change this would be very bad programming, as it would uses >>> fields from an object that is pooled for threads. >>> >>> Instead of relying in an anonymous class, create a normal one and pass all >>> the info it needs in its constructor. >>> >>> -- >>> 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: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> - >> 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 > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 5.2 bug?
True, there are some leaky abstractions related to the new approach; there was a different set in the 5.1 version of the page lifecycle. I've never felt the need to start up a thread from the middle of a page. I'm curious what your use case is, and whether it wouldn't be better handled using ThreadPools (for starters) and perhaps a JMS solution. I'm having some great luck using ActiveMQ right now, so split long synchronous work into small asynchronous work. On Mon, Sep 27, 2010 at 1:37 PM, Yunhua Sang wrote: > Hi Thiago, > > Thanks for your response. Yes, the code looks not nice, however, there > is nothing wrong with it. I knew there was a refactoring of changing > pool to singleton recently, so I was able to come up with a workaround > quickly, but for a Tapestry newbie, he/she might not know what's going > on, then will spend a lot of time to figour out. > > Yunhua > > On Mon, Sep 27, 2010 at 4:13 PM, Thiago H. de Paula Figueiredo > wrote: >> On Mon, 27 Sep 2010 16:47:38 -0300, Yunhua Sang >> wrote: >> >>> Hi everyone, >> >> Hi! >> >>> The field is always null when printing it out within run method; a >>> workaround is to define a local variable then access this variable in >>> new thread.I am wondering whether it's an expected behaviour or not. >> >> It's expected behavior after Tapestry does not uses a page pool anymore. >> Even before the change this would be very bad programming, as it would uses >> fields from an object that is pooled for threads. >> >> Instead of relying in an anonymous class, create a normal one and pass all >> the info it needs in its constructor. >> >> -- >> 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: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > - > 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
Re: Tapestry 5.2 bug?
Hi Thiago, Thanks for your response. Yes, the code looks not nice, however, there is nothing wrong with it. I knew there was a refactoring of changing pool to singleton recently, so I was able to come up with a workaround quickly, but for a Tapestry newbie, he/she might not know what's going on, then will spend a lot of time to figour out. Yunhua On Mon, Sep 27, 2010 at 4:13 PM, Thiago H. de Paula Figueiredo wrote: > On Mon, 27 Sep 2010 16:47:38 -0300, Yunhua Sang > wrote: > >> Hi everyone, > > Hi! > >> The field is always null when printing it out within run method; a >> workaround is to define a local variable then access this variable in >> new thread.I am wondering whether it's an expected behaviour or not. > > It's expected behavior after Tapestry does not uses a page pool anymore. > Even before the change this would be very bad programming, as it would uses > fields from an object that is pooled for threads. > > Instead of relying in an anonymous class, create a normal one and pass all > the info it needs in its constructor. > > -- > 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: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry 5.2 bug?
On Mon, 27 Sep 2010 16:47:38 -0300, Yunhua Sang wrote: Hi everyone, Hi! The field is always null when printing it out within run method; a workaround is to define a local variable then access this variable in new thread.I am wondering whether it's an expected behaviour or not. It's expected behavior after Tapestry does not uses a page pool anymore. Even before the change this would be very bad programming, as it would uses fields from an object that is pooled for threads. Instead of relying in an anonymous class, create a normal one and pass all the info it needs in its constructor. -- 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: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
