Re: AJAX slower than full page update
Yes, but we have many other things on the page. But why is it so slow? Is Wicket using some js functions that is extra slow in IE? If you google for IE javascript performance there are some recommendations, like here: http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx IE + JavaScript Performance Recommendations - Part 1 Have anyone looked at this issue before? BR Niels igor.vaynberg wrote: if the table is the only expensive component on your page then there is really no advantage to using ajax since you are adding all the overhead of javascript processing without saving anything. -igor On Tue, Jun 3, 2008 at 3:57 AM, Niels Bo [EMAIL PROTECTED] wrote: Hi I have observed that using AJAX to update of large content of a page is much slower than updating the full page withou AJAX. For example AJAX sorting a big DataTable (10x25) can be much slower that without AJAX, and I often see Client parsetime of more than a second in IE. FireFox seems to be faster, so I am hoping that is is possible to optimize the Wicket AJAX Javascript. Is this somthing that you Wicket developers will look into? Best Regards Niels -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17620961.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17653337.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX slower than full page update
hmm..ok, then it must be something in my application... And is was. My table contains lots of small icons, that are not really cached in development mode. The time shown as client parsetime then includes the time to call the server maybe 50 times to check if all the icons are up to date, and switching to deployment mode made a very big difference. So thanks for the help! Niels igor.vaynberg wrote: honestly i havent noticed any slow performance on ie... -igor On Wed, Jun 4, 2008 at 11:25 AM, Niels Bo [EMAIL PROTECTED] wrote: Yes, but we have many other things on the page. But why is it so slow? Is Wicket using some js functions that is extra slow in IE? If you google for IE javascript performance there are some recommendations, like here: http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx IE + JavaScript Performance Recommendations - Part 1 Have anyone looked at this issue before? BR Niels igor.vaynberg wrote: if the table is the only expensive component on your page then there is really no advantage to using ajax since you are adding all the overhead of javascript processing without saving anything. -igor On Tue, Jun 3, 2008 at 3:57 AM, Niels Bo [EMAIL PROTECTED] wrote: Hi I have observed that using AJAX to update of large content of a page is much slower than updating the full page withou AJAX. For example AJAX sorting a big DataTable (10x25) can be much slower that without AJAX, and I often see Client parsetime of more than a second in IE. FireFox seems to be faster, so I am hoping that is is possible to optimize the Wicket AJAX Javascript. Is this somthing that you Wicket developers will look into? Best Regards Niels -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17620961.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17653337.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17655546.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AJAX slower than full page update
Hi I have observed that using AJAX to update of large content of a page is much slower than updating the full page withou AJAX. For example AJAX sorting a big DataTable (10x25) can be much slower that without AJAX, and I often see Client parsetime of more than a second in IE. FireFox seems to be faster, so I am hoping that is is possible to optimize the Wicket AJAX Javascript. Is this somthing that you Wicket developers will look into? Best Regards Niels -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17620961.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
Yes, it seems to be an error in Wicket. Johan says it should be fixed it in the latest shapshot version, but I have not tried it yet. But I will probably keep the workaround code as an extra protection. Niels Gwyn wrote: Anything new on this issue? /Gwyn On Wed, Apr 9, 2008 at 5:55 PM, Niels Bo [EMAIL PROTECTED] wrote: ok, I can put a try-catch(Throwable t) around the service() and log that together with the request-url. But since it is a production server, I am not able to get it deployed until tomorrow evening, and right now we are doing ok with the workaround. Niels Johan Compagner wrote: if there was an error before that that should then be logged just before you log that there is a wrong state The way you do it now is in reverse the wrong state was already set in X number of request back so when you log it, You can;'t really tie it to a a specific request that did go wrong. If you log it later after the service method. Then you know that it did happen for that request And most likely there should be some error before that.. Because i dont see another way how it would be possible when the normal flow without exceptions would happen. johan On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo [EMAIL PROTECTED] wrote: Hi How can I check/log if there are error for that thread? Niels Johan Compagner wrote: could you change that method that it checks this after the fact? and then see if there is an error for that thread before? for example also log the url call so that we can see what kind of request did let one thread local be there? Which one is it by the way? is it app, session or request cycle? i just checked our code and we have finally blocks pretty much every where in WicketFilter.doGet and in RequestCycle.steps And i have no idea how those can be jumped over. johan -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16590574.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16656648.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
Yes, I can do that.
It is both Application and Session at the same time.
RequestCycle I have never seen it happen for.
Niels
Johan Compagner wrote:
could you change that method that it checks this after the fact?
and then see if there is an error for that thread before? for example also
log the url call so that we can see
what kind of request did let one thread local be there?
Which one is it by the way?
is it app, session or request cycle?
i just checked our code and we have finally blocks pretty much every where
in WicketFilter.doGet
and in RequestCycle.steps
And i have no idea how those can be jumped over.
johan
On Wed, Apr 9, 2008 at 12:22 PM, Niels Bo [EMAIL PROTECTED]
wrote:
We have kind of the same problem.
It looks like Application and Session are not always cleared from the
request thread, and to test this I have just deployed a subclassed
WicketServlet with these checks (and also as a workaround):
protected void service(HttpServletRequest req, HttpServletResponse
resp)
throws ServletException, IOException {
if(Application.exists()) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
Application on Thread);
Application.unset();
}
if(Session.exists()) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
Session on Thread);
Session.unset();
}
if(RequestCycle.get() != null) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
RequestCycle on Thread);
RequestCycle.get().detach();
}
super.service(req, resp); // call WicketServlet
}
Our logs show that it actually happens that both Application and Session
are
already attached to the thread before the request is processed.
I have only seen it once or twice in our development environment, but it
happens a few times every hour on the production server.
Niels
--
View this message in context:
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16583880.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585336.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
Hi How can I check/log if there are error for that thread? Niels Johan Compagner wrote: could you change that method that it checks this after the fact? and then see if there is an error for that thread before? for example also log the url call so that we can see what kind of request did let one thread local be there? Which one is it by the way? is it app, session or request cycle? i just checked our code and we have finally blocks pretty much every where in WicketFilter.doGet and in RequestCycle.steps And i have no idea how those can be jumped over. johan -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
ok, I can put a try-catch(Throwable t) around the service() and log that together with the request-url. But since it is a production server, I am not able to get it deployed until tomorrow evening, and right now we are doing ok with the workaround. Niels Johan Compagner wrote: if there was an error before that that should then be logged just before you log that there is a wrong state The way you do it now is in reverse the wrong state was already set in X number of request back so when you log it, You can;'t really tie it to a a specific request that did go wrong. If you log it later after the service method. Then you know that it did happen for that request And most likely there should be some error before that.. Because i dont see another way how it would be possible when the normal flow without exceptions would happen. johan On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo [EMAIL PROTECTED] wrote: Hi How can I check/log if there are error for that thread? Niels Johan Compagner wrote: could you change that method that it checks this after the fact? and then see if there is an error for that thread before? for example also log the url call so that we can see what kind of request did let one thread local be there? Which one is it by the way? is it app, session or request cycle? i just checked our code and we have finally blocks pretty much every where in WicketFilter.doGet and in RequestCycle.steps And i have no idea how those can be jumped over. johan -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16590574.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AutoCompleteTextField type mismatch in line 227
Hi I just swithed from 1.3.2 to 1.3.3 and that resultet in a javascript error type mismatch in line 227, wich is this line in wicket-autocomplete.js: menu.style.zIndex=index==auto?index:Number(index)+1; Only in IE (6.0) - firefox works fine. Does anyone else see this problem? Niels -- View this message in context: http://www.nabble.com/AutoCompleteTextField-%22type-mismatch%22-in-line-227-tp16560166p16560166.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple Wicket Servlets in same web application
We are not doing any stress load. Just a few normal users and there is absolutly no load on the server. Besides this problem everything works. I can also see the problem late in the evening, when I am the only user on the server. We are not using filters but the WicketServlets and they are defined like normal: servlet servlet-namePubApplicationServlet/servlet-name servlet-classorg.apache.wicket.protocol.http.WicketServlet/servlet-class init-param param-nameapplicationClassName/param-name param-valueoet.applications.pub.PubApplication/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-namePubApplicationServlet/servlet-name url-pattern/pub/*/url-pattern /servlet-mapping and the other application in the same way, with just different application class and url pattern. Niels Nino.Martinez wrote: I guess you have tried using something like Jmeter to simulate a stressing environment? It could be a lot of stuff that clutters it up, like database acesss etc... How does your filter mapping look like? -regards Nino Niels Bo wrote: Hi We have two WicketServlets/Applications in the same web application(war) and that has worked fine until we deployed on the big production server (Weblogic 10). What we see now is that the homepage from application A is sometime showing up as response to request on urls that belong to the application B! It is not a redirection. It is really the response that does not match the url requested, and we have it logged and documented with Fiddler. It looks just as if Application A is stuck to a worker thread (in its ThreadLocal current), but looking at the wicket source we cant see how that should happen. This right now happens for maybe 10% of the requests on the production server, while have only been able to recreate it once a day on a development server, so that makes it difficult to debug. Any suggestions where and how to look for the error? Is there a place where we can add an extra check to catch if the Application is stuck on a worker thread? Niels -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Multiple-Wicket-Servlets-in-same-web-application-tp16419432p16443888.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple Wicket Servlets in same web application
Hi We have two WicketServlets/Applications in the same web application(war) and that has worked fine until we deployed on the big production server (Weblogic 10). What we see now is that the homepage from application A is sometime showing up as response to request on urls that belong to the application B! It is not a redirection. It is really the response that does not match the url requested, and we have it logged and documented with Fiddler. It looks just as if Application A is stuck to a worker thread (in its ThreadLocal current), but looking at the wicket source we cant see how that should happen. This right now happens for maybe 10% of the requests on the production server, while have only been able to recreate it once a day on a development server, so that makes it difficult to debug. Any suggestions where and how to look for the error? Is there a place where we can add an extra check to catch if the Application is stuck on a worker thread? Niels -- View this message in context: http://www.nabble.com/Multiple-Wicket-Servlets-in-same-web-application-tp16419432p16419432.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with opening inline PDF file due to ;charset=UTF-8 in content type
Hi After upgrading from wicket 1.2.6 to 1.3 we got a problem with opening PDF files inline in a browser window. At least for some browser versions and/or PDF readers, it now opens the PDF file in a separate window instead of inline. The difference is that in Wicket 1.3 ;charset=UTF-8 is always appended to the content type. If ResourceState::getContentType() returns application/pdf, this is what I see in a HTTP debugger: Wicket 1.2.6: Content-Type: application/pdf Wicket 1.3.1: Content-Type: application/pdf; charset=UTF-8 The ;charset=UTF-8 is appended in ResourceStreamRequestTarget, and I can't see a way to override it. Any suggestions how to fix this? Niels -- View this message in context: http://www.nabble.com/Problem-with-opening-inline-PDF-file-due-to-%22-charset%3DUTF-8%22-in-content-type-tp15757124p15757124.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AJAX mouseover popup
Hi I am looking for some wicket code or a component that can show mouseover popups loaded by AJAX. Exactly as can be seen on this page http://www.mathertel.de/AJAXEngine/S03_AJAXControls/AJAXPopUpDemo.aspx http://www.mathertel.de/AJAXEngine/S03_AJAXControls/AJAXPopUpDemo.aspx Many thanks if someone can help. Niels -- View this message in context: http://www.nabble.com/AJAX-mouseover-popup-tp15312817p15312817.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE7, loose.dtd, and the default Wicket error pages
I see the same in IE6 after updating from 1.3.0-rc1 to 1.3.0-rc2. I belive it it caused by the license comment placed before the DOCTYPE tag in the page markup. See: https://issues.apache.org/jira/browse/WICKET-1241 https://issues.apache.org/jira/browse/WICKET-1241 Niels Kirk Israel-2 wrote: So IE7 seems to choke on the default Wicket error pages (such as time out) because it doesn't like the --s inside of http://www.w3.org/TR/html4/loose.dtd Our work around was to override the pages on a case per case basis: getApplicationSettings().setPageExpiredErrorPage(TimeoutPage.class); I don't know if there's fingerpointing of IE7 vs w3.org about this. Being a pragmatic developer with street roots, I greatly dislike a decent error page with a link to the front of the site being replaced with an ugly can't parse the XML page, so I was wondering who will bend first, IE7, w3.org, or Wicket? And is there another more generalized solution to this problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/IE7%2C-loose.dtd%2C-and-the-default-Wicket-error-pages-tp14461685p14481357.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session.bind() in newSession()
No, I don't really need the bind() anyway! I was tracking a problem where the several Session was created with just my local browser, but it was caused by myself alternating between Jetty and Weblogic without closing the browser. There were then two session cookies (but different path), so WebLogic was unable to overwrite the jsessionid from Jetty. Niels -- View this message in context: http://www.nabble.com/Session.bind%28%29-in-newSession%28%29-tf4831304.html#a13844577 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket behind a front-end proxy
Hi Murat! If you are running behind a WebSeal proxy, just configure the junction as transparent and deploy your application with the same context-root as the junction name. Then you can run like: myserver1.xxx.com:80/myapp1 - localhost:8080/myapp1 The transparent setting means that the proxy will not try to parse the html and try to fix any server-relative url contained in you pages. Best Regards Niels Bo Murat Yücel-2 wrote: It seems like wicket doesnt support it, because there is no workaround on the link that Frank Bille send. There is only information about that this is a problem. /Murat 2007/11/9, Johan Compagner [EMAIL PROTECTED]: so we dont support this currently? myserver1.xxx.com:80 - localhost:8080/myapp1 myserver2.xxx.com:80 - localhost:8080/myapp2 johan On Nov 9, 2007 1:35 PM, Frank Bille [EMAIL PROTECTED] wrote: Read this again: http://cwiki.apache.org/WICKET/wicket-behind-a-front-end-proxy.html#Wicketbehindafront-endproxy-Whythisdoesn%2527talwayswork Frank On Nov 9, 2007 1:26 PM, Murat Yücel [EMAIL PROTECTED] wrote: Hi Frank I have substituted my projectname with wicket. Below is the conf for the proxy part. VirtualHost * ServerAdmin [EMAIL PROTECTED] ServerName www.wicket.com ServerAlias wicket.com ProxyRequests off ProxyPreserveHost On RewriteEngine On # Indexes + Directory Root. DirectoryIndex index.html DocumentRoot /var/wicket.com # Logfiles ErrorLog /var/log/apache2/wicket-error.log CustomLog /var/log/apache2/wicket-access.log combined ProxyPass / http://127.0.0.1:8080/wicket/ ProxyPassReverse / http://127.0.0.1:8080/wicket/ ProxyPreserveHost On /VirtualHost 2007/11/9, Frank Bille [EMAIL PROTECTED]: Sounds weird. Can you show me your apache conf for the proxy? Frank On Nov 9, 2007 12:44 PM, Murat Yücel [EMAIL PROTECTED] wrote: Hi Frank I have changed the /app/* to /* but it doesnt change the urls. They are still wrong. For example i enter the following url: www.wicket.com The url is transformed to www.wicket.com/wicket/?wicket:bookmarkablePage=%3Acom.wicket.LoginPage If i remove the the wicket part from the url then i can see the login page. But if i click on a link then the wicket part is appended again. /Murat 2007/11/9, Frank Bille [EMAIL PROTECTED]: First of all, you don't need /app/* anylonger. just /*. I'm running behind proxy as well and it works well. Are you sure you haven't run into this problem: http://cwiki.apache.org/WICKET/wicket-behind-a-front-end-proxy.html#Wicketbehindafront-endproxy-Whythisdoesn%2527talwayswork Frank On Nov 9, 2007 11:56 AM, Murat Yücel [EMAIL PROTECTED] wrote: Hi All I have looked at this article: http://cwiki.apache.org/WICKET/wicket-behind-a-front-end-proxy.html and it seems like the problem should be gone in wicket 1.3 but it isnt. I still get 404 errors. There is a warning on the wiki page: Don't use setContextPath with Wicket 1.3. I am not setting the context path. Instead i am using filter-mapping. Is this the same thing? filter-mapping filter-namewicket/filter-name !-- The app is needed for ajax (this is a known limitation/bug in wicket) -- url-pattern/app/*/url-pattern /filter-mapping Do you have a workaround for this issue or am i doing something wrong? I am currently running 1.3-beta4. Kind regards /Murat Yücel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Wicket-behind-a-front-end-proxy-tf4776982.html#a13821932 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Session.bind() in newSession()
Hi I am setting locale and a userid to my custom Session in the application.newSession() method (the information comes from a front end proxy), and this works fine under Jetty, but I get this nullpointer exception under WebLogic. Is that the wrong place to call bind()? java.lang.NullPointerException at org.apache.wicket.Session.bind(Session.java:392) at oet.applications.branch.BranchApplication.newSession(BranchApplication.java:87) at org.apache.wicket.Session.findOrCreate(Session.java:225) at org.apache.wicket.protocol.http.WicketFilter.getLastModified(WicketFilter.java:894) at org.apache.wicket.protocol.http.WicketServlet.getLastModified(WicketServlet.java:210) at javax.servlet.http.HttpServlet.service(HttpServlet.java:736) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170) Using 1.3.0-rc1, Session.java:392 contains RequestCycle.get().getRequest() Niels -- View this message in context: http://www.nabble.com/Session.bind%28%29-in-newSession%28%29-tf4831304.html#a13822138 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
