Re: comet implementation issue
yes, you are right thread.sleep does not look like the right approach, it does not scale either. thanks - Original Message From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Tue, 25 May, 2010 6:41:08 AM Subject: Re: comet implementation issue On Mon, 24 May 2010 21:45:16 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: This behavior is not limited to the reverse ajax call but it is seen with all the pages. It is as if the polling for page change stops with the reverse ajax call. Can a Thread.sleep(...) in a dispatcher cause the page change polling to stop? I'm not sure, but that's possible. Instead of using Thread.sleep(), which has the potential of causing a deadlock, try using wait() and notifyAll() instead. --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: comet implementation issue
Thanks for the inputs Peter. I had done some research on the ill effects of reverse AJAX but the advantages of having the feature outweighed its disadvantage. My idea of Jetty was that of a light weight embeddable HTTP server which can be used for unit testing or in situations where high load is not expected. Are you suggesting that jetty can be used for some heavy lifting? regards, Rajesh - Original Message From: p.stavrini...@albourne.com p.stavrini...@albourne.com To: Tapestry users users@tapestry.apache.org Sent: Tue, 25 May, 2010 1:27:43 PM Subject: Re: comet implementation issue Using a dispatcher may prevent the pool becoming exhausted, but that just shifts the real problem elsewhere... DWR's long poling technique places a huge load on web servers, it is a pretty nasty hack on the HTTP protocol, which is not really a Tapestry problem as such. long poling won't play nice with many web servers, some browsers, but especially not proxies (i.e.: Apache in front of Tomcat), if you do use it then you should expect the unexpected and do loads of testing. I recommend you try Jetty if you are not already, as it handles reverse AJAX better than other web servers, Jetty 6 supports continuations, which will reduce traffic and prevent the page pool becoming exhausted... it is the most robust and reliable solution available for HTTP keep alives (to the best of my knowledge anyway). I tested DWR for a while, and whilst I was impressed, the extra load, latency and some of the reliability issues were too much of a trade off to use for my production environment. regards, Peter - Original Message - From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Tuesday, 25 May, 2010 04:11:08 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: comet implementation issue On Mon, 24 May 2010 21:45:16 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: This behavior is not limited to the reverse ajax call but it is seen with all the pages. It is as if the polling for page change stops with the reverse ajax call. Can a Thread.sleep(...) in a dispatcher cause the page change polling to stop? I'm not sure, but that's possible. Instead of using Thread.sleep(), which has the potential of causing a deadlock, try using wait() and notifyAll() instead. -- 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 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: comet implementation issue
For information, I think Jetty is powering Google App Engine. See: http://jetty.codehaus.org/jetty/ http://jetty.codehaus.org/jetty/ On Sat, May 29, 2010 at 8:59 AM, rajesh sukumaran rajeshs_...@yahoo.co.inwrote: Thanks for the inputs Peter. I had done some research on the ill effects of reverse AJAX but the advantages of having the feature outweighed its disadvantage. My idea of Jetty was that of a light weight embeddable HTTP server which can be used for unit testing or in situations where high load is not expected. Are you suggesting that jetty can be used for some heavy lifting? regards, Rajesh - Original Message From: p.stavrini...@albourne.com p.stavrini...@albourne.com To: Tapestry users users@tapestry.apache.org Sent: Tue, 25 May, 2010 1:27:43 PM Subject: Re: comet implementation issue Using a dispatcher may prevent the pool becoming exhausted, but that just shifts the real problem elsewhere... DWR's long poling technique places a huge load on web servers, it is a pretty nasty hack on the HTTP protocol, which is not really a Tapestry problem as such. long poling won't play nice with many web servers, some browsers, but especially not proxies (i.e.: Apache in front of Tomcat), if you do use it then you should expect the unexpected and do loads of testing. I recommend you try Jetty if you are not already, as it handles reverse AJAX better than other web servers, Jetty 6 supports continuations, which will reduce traffic and prevent the page pool becoming exhausted... it is the most robust and reliable solution available for HTTP keep alives (to the best of my knowledge anyway). I tested DWR for a while, and whilst I was impressed, the extra load, latency and some of the reliability issues were too much of a trade off to use for my production environment. regards, Peter - Original Message - From: Thiago H. de Paula Figueiredo thiag...@gmail.com To: Tapestry users users@tapestry.apache.org Sent: Tuesday, 25 May, 2010 04:11:08 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: comet implementation issue On Mon, 24 May 2010 21:45:16 -0300, rajesh sukumaran rajeshs_...@yahoo.co.in wrote: This behavior is not limited to the reverse ajax call but it is seen with all the pages. It is as if the polling for page change stops with the reverse ajax call. Can a Thread.sleep(...) in a dispatcher cause the page change polling to stop? I'm not sure, but that's possible. Instead of using Thread.sleep(), which has the potential of causing a deadlock, try using wait() and notifyAll() instead. -- 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 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Coercion error in onActivate
Dear Tapestry Users, I hope someone can help me with that issue, it's bugging me for a while now and I may not be able to see the obvious. In an edit page I am taking the user id as argument, but when calling the url with proper value /user/edit/2 I am getting an exception: Caused by: java.lang.IllegalArgumentException: Exception in method de.matchpatch.pages.user.UserEdit.onActivate(long) (at UserEdit.java:25), parameter #1: Coercion of layout to type java.lang.Long (via String -- Long) failed: For input string: layout I found a mail from Uli Staerk (http://osdir.com/ml/users-tapestry-apache/2009-01/msg00170.html) where he figured it was due to a hardcoded CSS file, but that's not the case here (using @IncludeStylesheet annotation). But I do use a Template (based on YAML) in a layout component. My UserEdit.tml looks like this: t:layout title=matchpatch User xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd; xmlns:p=tapestry:parameter t:beaneditform object=user/ /t:layout I hope someone has got a hint for me. If more code is required, please let me know. Thanks in advance Daniel
Re: comet implementation issue
On Sat, 29 May 2010 07:24:59 -0300, Robin Komiwes robin.komi...@gmail.com wrote: For information, I think Jetty is powering Google App Engine. See: http://jetty.codehaus.org/jetty/ GAE does use Jetty. By the way, Jetty is an Eclipse project now: http://www.eclipse.org/jetty/ -- 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
Re: Coercion error in onActivate
On Sat, 29 May 2010 10:58:55 -0300, Daniel Henze dhe...@googlemail.com
wrote:
Dear Tapestry Users,
Hi!
I found a mail from Uli Staerk
(http://osdir.com/ml/users-tapestry-apache/2009-01/msg00170.html) where
he figured it was due to a hardcoded CSS file, but that's not the case
here (using @IncludeStylesheet annotation). But I do use a Template
(based on YAML) in a layout component.
The overall problem is using relative paths, not hard-coding references to
files such as JavaScript, CSS and images. You can use ${context:xxx}
without any problems.
Check the generated HTML and look for relative paths. ;)
--
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
Coercion error in onActivate
Dear Tapestry Users, I hope someone can help me with that issue, it's bugging me for a while now and I may not be able to see the obvious. In an edit page I am taking the user id as argument, but when calling the url with proper value /user/edit/2 I am getting an exception: Caused by: java.lang.IllegalArgumentException: Exception in method de.matchpatch.pages.user.UserEdit.onActivate(long) (at UserEdit.java:25), parameter #1: Coercion of layout to type java.lang.Long (via String -- Long) failed: For input string: layout I found a mail from Uli Staerk (http://osdir.com/ml/users-tapestry-apache/2009-01/msg00170.html) where he figured it was due to a hardcoded CSS file, but that's not the case here (using @IncludeStylesheet annotation). But I do use a Template (based on YAML) in a layout component. My UserEdit.tml looks like this: t:layout title=matchpatch User xmlns:t=http://tapestry.apache.org/schema/tapestry_5_1_0.xsd; xmlns:p=tapestry:parameter t:beaneditform object=user/ /t:layout I hope someone has got an idea for me. If more code is required, please let me know. Thanks in advance Daniel - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Coercion error in onActivate
Thanks Thiago, thanks a lot, you pointed me into the right direction. I
did eliminate everything from the layout and that worked well. So I'll
be going through and try to find the erroneous part.
Cheers
Daniel
Am 29.05.2010 16:24, schrieb Thiago H. de Paula Figueiredo:
On Sat, 29 May 2010 10:58:55 -0300, Daniel Henze
dhe...@googlemail.com wrote:
Dear Tapestry Users,
Hi!
I found a mail from Uli Staerk
(http://osdir.com/ml/users-tapestry-apache/2009-01/msg00170.html)
where he figured it was due to a hardcoded CSS file, but that's not
the case here (using @IncludeStylesheet annotation). But I do use a
Template (based on YAML) in a layout component.
The overall problem is using relative paths, not hard-coding
references to files such as JavaScript, CSS and images. You can use
${context:xxx} without any problems.
Check the generated HTML and look for relative paths. ;)
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: RenderSupport Scope
On Sat, 29 May 2010 23:18:28 -0300, Pablo dos Reis pablodosr...@gmail.com wrote: When I inject javaScript using renderSupport not is possible access the methods created in the class through a js file. Hi, Pablo! I'm not sure what you're talking about, but remember that any JavaScript code added through RenderSupport.addScript() ends up in a script tag in the end of the body. Avoid overriding methods in this case: just generate the minimum amount of code needed and let the heavy lifting for .js files. ;) -- 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
Re: RenderSupport Scope
Hi Thiago, When the Tapestry creates the script. It puts the script inside a other method. Tapestry.onDOMLoaded() in this case. So when I try call it method using a js the method created by RenderSupport is not visible for js. I resolved the following writer.element(script, language, JavaScript); writer.write(script); writer.end(); Then ran!! But maybe is not the better way. I had to use RenderSupport because in js I don't know the element's id for implements a method that return the component value. 2010/5/29 Thiago H. de Paula Figueiredo thiag...@gmail.com On Sat, 29 May 2010 23:18:28 -0300, Pablo dos Reis pablodosr...@gmail.com wrote: When I inject javaScript using renderSupport not is possible access the methods created in the class through a js file. Hi, Pablo! I'm not sure what you're talking about, but remember that any JavaScript code added through RenderSupport.addScript() ends up in a script tag in the end of the body. Avoid overriding methods in this case: just generate the minimum amount of code needed and let the heavy lifting for .js files. ;) -- 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 -- Pablo Henrique dos Reis
