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...
my point was more that it was a bad default for us to choose, we shouldve stuck with the query string. the current strategy still has its applications 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... maybe we can patch the existing stuff to strip jsessionid before decoding. 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
