Re: Regarding Stack Overflow exception
Can anyone let me know about the entry in *Apache Wicket* /change log/ which talks about serialization error fix? - //Maddy -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Regarding-Stack-Overflow-exception-tp4203930p4288315.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DateTextField Problem
I think this is a bug of a wicket so I have added an extra validation to date component when user clicks on submit button. This is not the best solution but it is worked. Any other solutions? With my best regards. Secil - Wicket-Java -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/DateTextField-Problem-tp4288137p4288349.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Is it possible to set the session?
Hi again, It worked with ..;jsessionid=43423?param1=value1...; But now I want to do the same think when I use setResponsePage(my page). So now I should use the programatically method that you said to override respond method. But now I don't have a link. Do you have idea wich class should I use? Thanks. P.S Sorry for being so insistent but I am quite new in wicket. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4288412.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicketServlet and bean of type [org.apache.wicket.protocol.http.WebApplication] not found
Hi, I have a web application that works on jetty, tomcat, jboss and glassfish but has problems with websphere. I found out that the problem is the use of filters (org.apache.wicket.protocol.http.WicketFilter) so I switched to WicketServlet but now, trying with jetty I have: java.lang.IllegalStateException: bean of type [org.apache.wicket.protocol.http.WebApplication] not found at org.apache.wicket.spring.SpringWebApplicationFactory.createApplication(SpringWebApplicationFactory.java:160) at org.apache.wicket.spring.SpringWebApplicationFactory.createApplication(SpringWebApplicationFactory.java:139) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:308) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) this is the web.xml causing problems with jetty: ... servlet servlet-namewicket.wicket/servlet-name servlet-classorg.apache.wicket.protocol.http.WicketServlet/servlet-class init-param
Re: wicketServlet and bean of type [org.apache.wicket.protocol.http.WebApplication] not found
Either remove init-param param-nameapplicationFactoryClassName/param-name param-valueorg.apache.wicket.spring.SpringWebApplicationFactory/param-value /init-param or add a bean for YourApplication in applicationContext.xml On Thu, Jan 12, 2012 at 10:40 AM, mir m.bo...@siaspa.com wrote: Hi, I have a web application that works on jetty, tomcat, jboss and glassfish but has problems with websphere. I found out that the problem is the use of filters (org.apache.wicket.protocol.http.WicketFilter) so I switched to WicketServlet but now, trying with jetty I have: java.lang.IllegalStateException: bean of type [org.apache.wicket.protocol.http.WebApplication] not found at org.apache.wicket.spring.SpringWebApplicationFactory.createApplication(SpringWebApplicationFactory.java:160) at org.apache.wicket.spring.SpringWebApplicationFactory.createApplication(SpringWebApplicationFactory.java:139) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:308) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at
Re: Javascript resources and jsessionid
Create a ticket please On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I just checked with 1.5.x and for stateless pages all bookmarkable page links do not incur the jsessionid suffix for a non cookie client. Once an Ajax link is added to the page however the jsessionid suffix appears on all links which makes sense as the page is no longer stateless once Ajax gets involved. To summarize: I guess there's two completely separate issues surrounding jsessionid: 1. A jsessionid is added to package resource links, most of which are static don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource. If the user revisits the site after their session has expired then another download of the package resources will occur (because they have a different jsessionid suffix) Possible solution: Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request. 2. To improve SEO search engine crawlers should see only stateless pages so that the jsessionid never appears in any links. Wicket seems to work well in this regard already. The tricky part is to create stateless pages in the first place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicketServlet and bean of type [org.apache.wicket.protocol.http.WebApplication] not found
I added a bean for my application in applicationContext.xml and now I don't see any errors but when I try to access to my first page (a login page) I see a window listing: META-INF/ 0 bytes 2-gen-2012 16.46.08 WEB-INF/0 bytes 11-gen-2012 15.21.18 css/0 bytes 2-gen-2012 16.46.08 img/32768 bytes 2-gen-2012 16.46.16 js/ 4096 bytes 2-gen-2012 16.46.16 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicketServlet-and-bean-of-type-org-apache-wicket-protocol-http-WebApplication-not-found-tp4288252p4288561.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Javascript resources and jsessionid
for packaged resources we should not be adding jsessionid i dont think... -igor On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org wrote: Create a ticket please On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I just checked with 1.5.x and for stateless pages all bookmarkable page links do not incur the jsessionid suffix for a non cookie client. Once an Ajax link is added to the page however the jsessionid suffix appears on all links which makes sense as the page is no longer stateless once Ajax gets involved. To summarize: I guess there's two completely separate issues surrounding jsessionid: 1. A jsessionid is added to package resource links, most of which are static don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource. If the user revisits the site after their session has expired then another download of the package resources will occur (because they have a different jsessionid suffix) Possible solution: Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request. 2. To improve SEO search engine crawlers should see only stateless pages so that the jsessionid never appears in any links. Wicket seems to work well in this regard already. The tricky part is to create stateless pages in the first place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Cancelling form submit in ModalWindow causes validation errors in Form of underlying base page?
Hello everyone, first, sorry for the bad subject. I didn't know how to describe this problem in a short line. I have a page with a form with two AjaxButtons (Add and Delete) and an AjaxFallbackDefaultDataTable. The first button opens a ModalWindow with another form to add new entries to the table. The ModalWindow also has a Cancel button (with setDefaultFormProcessing(false);). which closes the ModalWindow. The page's second button (Delete) should delete entries from the table that have been selected using Check components that are added to each row of the table. If I open the ModalWindow and then click the Cancel button in the ModalWindow I cannot use the Delete button afterwards. I always get to the Delete buttons onError method and in my log I see the following: WARN org.apache.wicket.protocol.http.WebSession.cleanupFeedbackMessages(WebSession.java:135) - Component-targetted feedback message was left unrendered. This could be because you are missing a FeedbackPanel on the page. Message: [FeedbackMessage message = _errormessage_, reporter = orderNumber, level = ERROR] But the FeedbackMessage is from the ModalWindow. How could I solve this so that I can cancel the ModalWindow and still use the Delete button? Thanks in advance, Philip
Serialize form for wicket ajax call
I was trying to understand the wicket serialize method call.
Does it serialize the entire form? Does it serialize fields that are
NOT blank?
I noticed that sometimes post body content only contains the field that
I clicked on and then other times it looks like all of the elements on
the form are submitted.
Somtimes for the same onclick of a radio button:
Example Click1 (clicking on a radio button 'input
onclick=wicketAjaxPost /':
Body Content:
myRadioButton=1234
...
Example Click1 (clicking on the SAME radio button 'input
onclick=wicketAjaxPost /':
Body Content:
myRadioButton=1234
someOtherData=abc
someOtherData2=xyc
... Why would clicking on the same button generate different behavior,
submit different content?
Example wicket ajax post call on a radio button, onclick:
window.scrollTo( 0, 0 );
var wcall=wicketAjaxPost(
[PARM1]
'?wicket:interface=:2:contentPanelContainerIBehaviorListener:0:-1'
[PARM2], wicketSerialize(Wicket.$('id307'))
[PARM3], function() { hideWaitAndShadow( 'mainShadow' )}.bind(this)
[PARM4], function() { hideWaitAndShadow( 'mainShadow' )}.bind(this)
[PARM5], function() {return Wicket.$('id307') != null;}.bind(this));;
showWait();
My intent is to convert some wicketAjaxPost calls to wicketAjaxGet and
then serialize the data in the form and attach it to the URL (as a get
request) and I was trying to understand how the wicketAjaxPost works.
RE: Javascript resources and jsessionid
Yes, I have vague memories of this issue coming up a long time ago in 1.4.x and at the time I thought it was dealt with but maybe there was a problem with its implementation or maybe it regressed somehow. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 13 January 2012 3:15 AM To: users@wicket.apache.org Subject: Re: Javascript resources and jsessionid for packaged resources we should not be adding jsessionid i dont think... -igor On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org wrote: Create a ticket please On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I just checked with 1.5.x and for stateless pages all bookmarkable page links do not incur the jsessionid suffix for a non cookie client. Once an Ajax link is added to the page however the jsessionid suffix appears on all links which makes sense as the page is no longer stateless once Ajax gets involved. To summarize: I guess there's two completely separate issues surrounding jsessionid: 1. A jsessionid is added to package resource links, most of which are static don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource. If the user revisits the site after their session has expired then another download of the package resources will occur (because they have a different jsessionid suffix) Possible solution: Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request. 2. To improve SEO search engine crawlers should see only stateless pages so that the jsessionid never appears in any links. Wicket seems to work well in this regard already. The tricky part is to create stateless pages in the first place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Javascript resources and jsessionid
i remember this being fixed in 1.5 after the resource refactor... -igor On Thu, Jan 12, 2012 at 12:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Yes, I have vague memories of this issue coming up a long time ago in 1.4.x and at the time I thought it was dealt with but maybe there was a problem with its implementation or maybe it regressed somehow. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 13 January 2012 3:15 AM To: users@wicket.apache.org Subject: Re: Javascript resources and jsessionid for packaged resources we should not be adding jsessionid i dont think... -igor On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org wrote: Create a ticket please On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I just checked with 1.5.x and for stateless pages all bookmarkable page links do not incur the jsessionid suffix for a non cookie client. Once an Ajax link is added to the page however the jsessionid suffix appears on all links which makes sense as the page is no longer stateless once Ajax gets involved. To summarize: I guess there's two completely separate issues surrounding jsessionid: 1. A jsessionid is added to package resource links, most of which are static don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource. If the user revisits the site after their session has expired then another download of the package resources will occur (because they have a different jsessionid suffix) Possible solution: Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request. 2. To improve SEO search engine crawlers should see only stateless pages so that the jsessionid never appears in any links. Wicket seems to work well in this regard already. The tricky part is to create stateless pages in the first place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Javascript resources and jsessionid
I ran a quickstart with a very simple standard link and an AJAX link on a page and using yesterday's 1.5-x HEAD. The .js resources included in the head all had the jsessionid suffix on the first hit from the browser. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 13 January 2012 8:13 AM To: users@wicket.apache.org Subject: Re: Javascript resources and jsessionid i remember this being fixed in 1.5 after the resource refactor... -igor On Thu, Jan 12, 2012 at 12:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Yes, I have vague memories of this issue coming up a long time ago in 1.4.x and at the time I thought it was dealt with but maybe there was a problem with its implementation or maybe it regressed somehow. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 13 January 2012 3:15 AM To: users@wicket.apache.org Subject: Re: Javascript resources and jsessionid for packaged resources we should not be adding jsessionid i dont think... -igor On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org wrote: Create a ticket please On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman chr...@stepaheadsoftware.com wrote: I just checked with 1.5.x and for stateless pages all bookmarkable page links do not incur the jsessionid suffix for a non cookie client. Once an Ajax link is added to the page however the jsessionid suffix appears on all links which makes sense as the page is no longer stateless once Ajax gets involved. To summarize: I guess there's two completely separate issues surrounding jsessionid: 1. A jsessionid is added to package resource links, most of which are static don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource. If the user revisits the site after their session has expired then another download of the package resources will occur (because they have a different jsessionid suffix) Possible solution: Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request. 2. To improve SEO search engine crawlers should see only stateless pages so that the jsessionid never appears in any links. Wicket seems to work well in this regard already. The tricky part is to create stateless pages in the first place ;) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Turning off one-pass-render for a single page
I have an application which needs to accept a POST request from an outside server, to confirm payment. I don't want to break the default wicket render strategy (REDIRECT_TO_BUFFER) which is serving to give the users a nicer experience than ONE_PASS_RENDER would, however, the external service is not happy with the 302, and keeps retrying until it gives up. Is there some sensible way that I can tell wicket to use ONE_PASS_RENDER for only the specific page that handles this request? Matt Pennington - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
questions about CheckGroupSelector's behavior?
CheckGroupSelector is very useful to select all/none, but I found there is one condition that the behavior of CheckGroupSelector becomes strange. I'm not sure whether it's a bug or not. When the CheckGroup contains more than two check items, it's fine for any function. But when it contains only one check item, CheckGroupSelector becomes checked status on initial and the one check item is unchecked. I mean,if the CheckGroupSelector is checked, all of the related check items should be all checked as well.(only one check item or more) No matter how many times I press the CheckGroupSelector, it seems malfunctioned to affect the check item, unless I put two or more check items on the list. I have tried org.apache.wicket.examples.compref.CheckGroupPage(in wicket example) and modify the ComponentReferenceApplication.getPersons() to only one person. It's the same behavior as what I mentioned above. The version of my wicket is 1.5.3. Does anyone has comments for this situation?Thanks. Roland. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/questions-about-CheckGroupSelector-s-behavior-tp4291374p4291374.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: questions about CheckGroupSelector's behavior?
WICKET-4279 ? Am 13.01.2012 05:32, schrieb rolandpeng: CheckGroupSelector is very useful to select all/none, but I found there is one condition that the behavior of CheckGroupSelector becomes strange. I'm not sure whether it's a bug or not. When the CheckGroup contains more than two check items, it's fine for any function. But when it contains only one check item, CheckGroupSelector becomes checked status on initial and the one check item is unchecked. I mean,if the CheckGroupSelector is checked, all of the related check items should be all checked as well.(only one check item or more) No matter how many times I press the CheckGroupSelector, it seems malfunctioned to affect the check item, unless I put two or more check items on the list. I have tried org.apache.wicket.examples.compref.CheckGroupPage(in wicket example) and modify the ComponentReferenceApplication.getPersons() to only one person. It's the same behavior as what I mentioned above. The version of my wicket is 1.5.3. Does anyone has comments for this situation?Thanks. Roland. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/questions-about-CheckGroupSelector-s-behavior-tp4291374p4291374.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
