For the synchronization issue see WICKET-3740.
jsessionid in resource urls (.css, .js, ...) is removed in current trunk
About the meta for robots I think it is a good addition to the newly
introduced (today) AbstractErrorPage from which all error pages should
extend.
Please file a RFE.
On Fri, Jun 3, 2011 at 6:00 PM, Jim Pinkham <pinkh...@gmail.com> wrote:
> I mentioned a few weeks ago I had some page locking issues.
>
> I turned on logging and overrode the PageAccessSynchronizer to log and
> swallow the page lock exception (it still has the timeout wait, so
> it's not totally disabled), but of course it hasn't happened since, so
> I still haven't found the root cause other than some heavier usage
> (1500 page loads/day is busy for me - go ahead, laugh ;)
>
> ... but now I just noticed my search results in Google are showing
> these Internal Error page in search results!
>
> Yikes - Bad news!
>
> So, my band-aid fix is this:
>
> protected final class MyInternalErrorPage extends InternalErrorPage {
> private static final long serialVersionUID = 1L;
>
> @Override
> public void renderHead(IHeaderResponse response) {
> response.renderString("<META NAME=\"ROBOTS\" CONTENT=\"NONE\"
> />");
> }
> }
>
> and in my application init():
>
> getApplicationSettings().setInternalErrorPage(MyInternalErrorPage.class);
>
> I'm thinking this might be a good default for this page?
>
> Of course we don't want internal errors in the first place, but if
> they do happen (to a robot), no reason to literally advertise the
> fact, right? Seems like a drag on the brand name to some degree..
>
> On a side note, does anyone know how to tell google to get rid of a
> cached search result like this, or am I stuck waiting for the next
> robot to come along?
>
> To see what I mean, google for "Together Auction" (2nd result, crawled
> May 21, still here June 3):
>
> Catalog - Internal Error
>
> Internal error. Return to home page.
> togetherauction.com/firstuu/catalog - Cached
>
>
> OK, back to the page locking issues - the only unusual thing I'm doing
> is that I have my app deployed at my domain root with suffixes for
> each of my clients so they each appear to have their own version of
> the web app served from a common ROOT.war. So my URLs are like this:
>
> mydonamin.com/clientname/restOfURL. This is done via a
> ClientFirstRootRequestMapper extends AbstractComponentMapper
> (source if anyone is interested: http://pastebin.com/Zxp561JK )
>
> For some reason, this was working great in 1.5 M3 but since I've
> upgraded to RC3, I'm seeing ;jsessionid= on all my URLs now - not sure
> if that is related.
>
> I mention the RequestMapper because I wonder if this might result in
> two different clients using same page class with instance keys that
> might not be unique and thus have locking conflict from that ?
>
> Thanks for any insights any of you wiser wicket ones might have to share.
>
> -- Jim.
>
> TogetherAuction.com
>
> ---------------------------------------------------------------------
> 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
