I finally found out why the Groovy example "sometimes" fails. Eventually I'm able to reproduce it and what I found out looks to me like we (wicket) are handling sessions not correct. Let me try to explain why I came to that conclusion:
1) Example jWebUnit contains a test which calls the Groovy example and the test is passed successfully 2) Start the examples (index.html; eiher from within eclipse or maven jetty:run-war) and select the Groovy example. Do not select any other example prior to the Groovy example. The Groovy example will work. 3) Stop jetty (or tomcat) and restart it. Now select any of the other examples (e.g. Helloworld) first. Return to the menu and than select the Groovy example. It'll fail. It took some time until I found out, but WicketServlet.doGet() (or more specific HttpSession.getSession(webApplication, servletRequest)) assigns the wrong wicket session to the Groovy request. It assigns the HelloWorld session object and thus the HelloWorld Application to the Groovy request, which of course is wrong. And because HelloWorldApplication does not have the GroovyClassResolver registered, the groovy example fails. Now, why is the wrong Session assigned to the request. To track that down I used HTTPLook, which is a HTTP traffic analyser which intercepts all requests and prints the information (header, content) on a console. It does not modify the request nor the response. Based on the output, the first response after starting the servlet container (jetty) will create a session and the response contains a Cookie-Set JSESSIONID=... header entry. And, as expected, all following browser requests contain that cookie and thus allow the servlet container to select the proper session object. With Wicket the http session contains the wicket session and the wicket session contains the (transient) application. But the very same JSESSIONID value is provided by the browser while selecting the Groovy example (after the Helloworld example) and thus the HelloWorld session and HelloWorld Application are assigned to a Groovy request, which of course is wrong. Why does the browser return the "wrong" session id. Well, from the browser's point of view it is the correct one as it is set with a Path (Path is part of the Cookie) equal to the web app path (e.g. /wicket-examples) and not equals to the servlets path (e.g. /wicket-examples/groovy). This at least is true for default jetty 4.x and 5.x installations (without having modified jetties config). I haven't tested it with tomcat or any other servlet container. Conclusion: based on this information wicket itself must make sure that the servlet's path (taken from http request object) is taken into account to determine the wicket session object. HttpSession.getSession() I think would be right be place to do it I guess. I hope I was able to make clear what the problem is and would appreciate you test it on your envrionments as well and provide me some feedback. Thanks. Some other means to verify it: some example have setStripComponentName with the application object enabled others disabled (default). Depending on which example you select first, it is the first example selected application's settings which are used and not the application settings attached to any of the examples you select afterwards. Juergen ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
