On Thu, Mar 18, 2010 at 6:32 PM, Chris Colman <chr...@stepaheadsoftware.com> wrote: >> that is mostly old seo thinking. some people still prerfer urls like >> >> /blog/entry/2007/my_awesome_blog because it is more readable to the >> client, if they read urls... > > Yes, they probably don't read URLs anyway. > >> as far as the urls indexed you are right, the links wont be broken. >> you can create rewrite rules for all your current mounts but that will >> probably be a pita... > > Does this mean the links won't be broken if I simply change the strategy to > query string and do nothing else or does it mean the links won't be broken if > create rewrite rules for all current mounts?
sorry, i meant they *will* be broken. thus the url rewrite rules... >> maybe we can patch the existing stuff to strip jsessionid before decoding. > > Yes that would be cool. It's only really tomcat that needs to see the > jessionid - after that point in the request lifecycle there's no need to keep > the jsessionid in the URL. all servlet containers do that on first request. if you dont care about browsers with cookies disabled you can tweak tomcat to never append jsessionid to the url, afair there is a setting for that. -igor > >> >> as far as the trailing / - that causes its own problems because it >> throws off relative urls. >> >> -igor >> >> On Thu, Mar 18, 2010 at 5:32 PM, Chris Colman >> <chr...@stepaheadsoftware.com> wrote: >> > Ouch! All the pages are indexed under google with the /name1/value1 >> strategy will this mean the google page links will break if we switch to >> querystringurlcodingstrategy or can wicket handle resolution of both types >> of strategies when it comes to responding to requests? >> > >> > I thought the thinking was that search engines indexed the /name1/value1 >> structure better than the query string ?name1=value1 because they look >> like directories or is that old SEO thinking? >> > >> > Regards, >> > Chris >> > >> > >> >> -----Original Message----- >> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] >> >> Sent: Friday, 19 March 2010 10:53 AM >> >> To: users@wicket.apache.org >> >> Subject: Re: Trailing / on parameter name/value pairs >> >> >> >> i suggest always mounting with querystringurlcodingstrategy unless you >> >> specifically want the folder structure of /name1/value1/name2/value2 >> >> which most of the time you dont. too bad this was made the default, we >> >> cant change it in 1.4 but are fixing it in 1.5 as it causes all kinds >> >> of problems. >> >> >> >> -igor >> >> >> >> On Thu, Mar 18, 2010 at 4:42 PM, Chris Colman >> >> <chr...@stepaheadsoftware.com> wrote: >> >> > I'm using BookmarkablePageLink extensively as it makes it easy to add >> >> > parameter name/value pairs. I end up with URLs like: >> >> > >> >> > www.mysite.com/p1/v1/p2/v2 >> >> > >> >> > Which works fine for most cases but I have a number of >> questions/issues: >> >> > >> >> > My logs show exceptions whereby some browsers (or crawlers) without >> >> > cookies enabled end up requesting URLs with the ;jessionid=... suffix >> >> > which is used when no cookie support is available. >> >> > >> >> > The exception is caused when I try to convert a parameter and the >> >> > session suffix is included in its value eg., >> >> > >> >> > org.apache.wicket.util.string.StringValueConversionException: Unable >> to >> >> > convert '4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC' to a long >> >> > value >> >> > >> >> > The parameter pair was intended to be: >> >> > >> >> > parameter1/4574 i.e. parameter1=4574 >> >> > >> >> > but with the suffix added by tomcat in the absence of cookies it >> became: >> >> > >> >> > parameter1/4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC >> >> > >> >> > i.e. parameter1=4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC >> >> > >> >> > which isn't a valid integer value and so causes an exception. >> >> > >> >> > What can we do about this? Is it possible to force wicket to always >> add >> >> > a trailing / because this would help wicket's parameter parser avoid >> >> > this issue eg., >> >> > >> >> > parameter1/4574/;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC >> >> > >> >> > should work fine I'd imagine. >> >> > >> >> > Another thing about trailing slashes: apparently a trailing slash can >> >> > avoid an redirect. Apparently: >> >> > >> >> > www.mysite.com/p1/v1 will be redirected to >> >> > www.mysite.com/p1/v1/ >> >> > >> >> > If the URL was simply www.mysite.com/p1/v1/ then the redirect is >> >> > avoided. >> >> > >> >> > >> >> > 7%3Bjsessionid%3D3359BBC174E43EF2AE12D7F8FA80FCEC >> >> > >> >> >> -----Original Message----- >> >> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] >> >> >> Sent: Friday, 19 March 2010 9:56 AM >> >> >> To: users@wicket.apache.org >> >> >> Subject: Re: StackOverflowError under serialization leaves pagemap >> >> > locked >> >> >> >> >> >> the fix is in 1.4.x branch and will be part of 1.4.8. >> >> >> >> >> >> in the meantime you can build a fresh snapshot yourself and drop >> that >> >> >> into your application >> >> >> >> >> >> http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x >> >> >> >> >> >> -igor >> >> >> >> >> >> On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker >> >> > <nigel.par...@mazeppa.no> >> >> >> wrote: >> >> >> > >> >> >> > Thank you Johan for your reply. Agree that original problem should >> >> > be >> >> >> fixed. >> >> >> > This is a critical problem for us. We have found out during the >> last >> >> > 24 >> >> >> > hours that some of our pages are retaining a session reference. >> With >> >> >> Ajax >> >> >> > requests this gives a doubling of session size for every request, >> >> > and we >> >> >> now >> >> >> > believe this to be the cause of the StackOverflowErrors. We will >> try >> >> >> this in >> >> >> > production tomorrow. >> >> >> > >> >> >> > We upgraded to to 1.4.7 but still see that the pagemap is locked >> >> > when >> >> >> the >> >> >> > stack overflows. Do you know if the fix to WICKET-2075 is in >> 1.4.7? >> >> >> > >> >> >> > Thanks >> >> >> > Nigel >> >> >> > >> >> >> > >> >> >> > Johan Compagner wrote: >> >> >> >> >> >> >> >> i fixed 2075 so that it should always unlock the pages. >> >> >> >> >> >> >> >> Problem is that you still could get weird errors because that >> page >> >> > is >> >> >> not >> >> >> >> in >> >> >> >> a valid state in the session. >> >> >> >> So if back buttons/page versions are used it could be that that >> >> > doesnt >> >> >> >> work >> >> >> >> >> >> >> >> So what should be fixed is the original problem >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Mar 17, 2010 at 21:03, Nigel Parker >> >> > <nigel.par...@mazeppa.no> >> >> >> >> wrote: >> >> >> >> >> >> >> >>> We are a Wicket shop and for one of our clients have been >> running >> >> > a >> >> >> >>> Wicket application successfully for over 2 years. We are now at >> >> >> >>> version 1.4.0. The traffic on the system is increasing and we >> are >> >> > now >> >> >> >>> seeing an increased frequency of pagemap locking which is >> >> > beginning to >> >> >> >>> be a serious problem for the users. By subclassing >> WebRequestCycle >> >> > we >> >> >> >>> have identified that a StackOverflowError under serialization in >> >> >> >>> RequestCycle.detach() leaves the pagemap locked for the next >> >> > minute. >> >> >> >>> If our analysis is correct this is essentially the problem >> >> > reported as >> >> >> >>> https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately >> >> > we >> >> >> >>> cannot reproduce the problem in our test environment and it >> occurs >> >> >> >>> only in about one in every thousand requests with no apparent >> >> >> >>> consistent pattern about what the user has been doing. Can >> anybody >> >> >> >>> suggest an immediate strategy for further investigations? In >> >> >> >>> particular: >> >> >> >>> >> >> >> >>> - is there a practical way to find out what is causing the >> >> >> >>> serialization problem. The stack trace is no help. We do in many >> >> > cases >> >> >> >>> have large amounts of data in the session, but doubling the >> >> > default >> >> >> >>> stack size leaves the problem frequency unchanged leading us to >> >> >> >>> suspect a logical error rather the sheer amount of data. >> >> >> >>> >> >> >> >>> - by overriding RequestCycle.detach() and catching the >> >> >> >>> StackOverflowError we can get control when the error occurs. Is >> >> > there >> >> >> >>> any way we can persuade Wicket to release the pagemap lock? I >> have >> >> >> >>> looked at the code and this doesn't look straightforward. >> >> >> >>> >> >> >> >>> - can we get Wicket itself to suppress the StackOverflowError so >> >> > that >> >> >> >>> detach() continues and releases the lock? >> >> >> >>> >> >> >> >>> Grateful for any suggestions. >> >> >> >>> >> >> >> >>> Nigel >> >> >> >>> >> >> >> >>> >> >> > --------------------------------------------------------------------- >> >> >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >>> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > -- >> >> >> > View this message in context: >> >> > http://old.nabble.com/StackOverflowError- >> >> >> under-serialization-leaves-pagemap-locked-tp27938028p27950858.html >> >> >> > Sent from the Wicket - User 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 >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
