> 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
> <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

Reply via email to