Issue Details (XML | Word | Printable)

Key: TUSCANY-1974
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: ant elder
Reporter: Jean-Sebastien Delfino
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Tuscany

Chat webapp sample misses chat messages

Created: 13/Jan/08 04:25 AM   Updated: 02/Apr/08 08:40 AM
Return to search
Component/s: Java SCA Samples
Affects Version/s: Java-SCA-1.1
Fix Version/s: Java-SCA-1.2

Time Tracking:
Not Specified

Environment:
Tuscany 1.1 RC1
RHEL5
IBM JDK 1.5
Tested Firefox 2.0.0.11 and 3.0 beta2

Resolution Date: 02/Apr/08 08:40 AM


 Description  « Hide
To reproduce the issue:
Deploy the Chat webapp to Tomcat and open it in Firefox
enter nickname: test1, text: 1
nothing is logged, the message seems to be lost
enter text: 2, then 2 is logged

Another weird issue:
open another window
enter nickname: test2, text: a
again 'a' is lost
enter text b, this time b is logged

Go back to the first window
enter several text messages
they are logged in the first window but none of them is logged in the second window

The chat application does not seem to really work.


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Simon Laws added a comment - 14/Jan/08 03:27 PM
I tried the sample on Geronimo and see a similar effect. With browsers A and B the sequence seems to be that B doesn't get messages from A until B sends a message itself. The same is true when B send messages, i.e. A must send a message in order to see B's messages.

ant elder added a comment - 14/Jan/08 03:56 PM
I think this is the issue mentioned on the mailing list where DWR has switched from comet/reverse ajax mode to use piggy backing so clients don't receive messages until they make a request themselves. I shall go investigate why...

ant elder added a comment - 04/Feb/08 03:51 PM
test

ant elder added a comment - 10/Mar/08 11:29 AM
As a quick test i tried debugging through the current trunk code and comparing it to debugging through the same from the 1.0.1 Tuscany release code. That was setting break points in various methods in the tuscany-binding-dwr code and seeing what happens differently in trunk compared with 1.0.1. I start up tomcat, open two browser windows to http://localhost:8080/sample-chat-webapp/ then enter a name/text in one chat window. The main differenece is in org.apache.tuscany.sca.binding.dwr.invoke the line

Collection sessions = wctx.getScriptSessionsByPage(currentPage);

returns no sessions with the trunk code and two sessions (one for each open browser window) with the 1.0.1 code.

So the question is why aren't the sessions being found correctly any more?
 

ant elder added a comment - 10/Mar/08 12:32 PM
Another very useful tool for debugging this is TCPMON from the Apache WS project - http://ws.apache.org/commons/tcpmon/download.cgi

You can use that to view the messages sent between the browser client and tomcat server. Start up TCPMON, click on Admin , enter 8089 for the listen port and change the Listener target port to 8080 and click add. Now on the browser change the URL used to run the sample to use the port 8089 eg http://localhost:8089/sample-chat-webapp/, TCPMON should then show all the HTTP messages like GET/ and POST/. Comparing the message differences from the Tuscany 1.0.1 and current trunk code may give a good indication of what the problem may be.

ant elder added a comment - 13/Mar/08 06:22 PM
fyi, the change in r636817 fixes an issue related to this problem. The remaining problem here is that Tuscany is getting the context path and servlet path incorrect so the urls used by the scaDomain.js script are incorrect.

Luciano Resende added a comment - 13/Mar/08 06:42 PM
Is it possible to try implementation.widget here ?

ant elder added a comment - 28/Mar/08 08:13 AM
The following two changes fix this problem for me. The problem is caused by a bug in WebAppRequestDispatcher including the webapp context path in its servletPath, this change strips out the context path so the WebAppRequestDispatcher servlet path really is just the servlet path.

I'm just adding the fix to the jira as this late in the 1.2 release I'm a bit worried there may be samples that have come to rely on the old behaviour and i don't have time to test them all sorry.

Index: modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
===================================================================
--- modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java (revision 639228)
+++ modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java (working copy)
@@ -185,7 +185,7 @@
             if (servletPath.endsWith("*")) {
                 servletPath = servletPath.substring(0, servletPath.length() - 1);
                 if (suri.startsWith(servletPath)) {
- return new WebAppRequestDispatcher(entry.getKey(), entry.getValue());
+ return new WebAppRequestDispatcher(entry.getKey().substring(contextPath.length()), entry.getValue());
                 } else {
                     if ((suri + "/").startsWith(servletPath)) {
                         return new WebAppRequestDispatcher(entry.getKey(), entry.getValue());

C:\Tuscany\SVN\LATEST>svn diff modules\binding-dwr\src\main\java\org\apache\tuscany\sca\binding\dwr\DWRServlet.java
Index: modules/binding-dwr/src/main/java/org/apache/tuscany/sca/binding/dwr/DWRServlet.java
===================================================================
--- modules/binding-dwr/src/main/java/org/apache/tuscany/sca/binding/dwr/DWRServlet.java (revision 639228)
+++ modules/binding-dwr/src/main/java/org/apache/tuscany/sca/binding/dwr/DWRServlet.java (working copy)
@@ -146,7 +146,7 @@
         // Use the DWR remoter to generate the JavaScipt function for each SCA service
         Remoter remoter = (Remoter)getContainer().getBean(Remoter.class.getName());

- String path = request.getServletPath();
+ String path = request.getContextPath() + request.getServletPath();

         for (String serviceName : services.keySet()) {
             String serviceScript = remoter.generateInterfaceScript(serviceName, path);

ant elder added a comment - 02/Apr/08 08:40 AM
Fixed in r643023