> 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? > > 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. > > 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 > <[email protected]> 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:[email protected]] > >> Sent: Friday, 19 March 2010 10:53 AM > >> To: [email protected] > >> 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 > >> <[email protected]> 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:[email protected]] > >> >> Sent: Friday, 19 March 2010 9:56 AM > >> >> To: [email protected] > >> >> 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 > >> > <[email protected]> > >> >> 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 > >> > <[email protected]> > >> >> >> 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: [email protected] > >> >> >>> For additional commands, e-mail: [email protected] > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> > >> >> > > >> >> > -- > >> >> > 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: [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] > > > > > > --------------------------------------------------------------------- > > 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]
