RequestLogger and session invalidation

2009-05-27 Thread Taneli Korri
Hi,

I'm using Wicket 1.3.6 and RequestLogger.getLiveSessions to get the current
sessions in my web application, but I'm experience strange behaviour when
session invalidation occurs.

When the user logs out of the application, the session is invalidated. This
leads to WebApplication.sessionDestroyed to be called, which removes the
session from the RequestLogger.liveSessions Map and everything seems to be
fine.

But the execution continues and eventually RequestCycle.detach gets called,
which leads to RequestLogger.requestTime. And that's where the strangest
thing happens, on line 254 of RequestLogger.java the invalidated session is
created again and added back to the liveSessions Map.

Is this the expected behaviour? Since this ensures that the liveSessions Map
includes all sessions, even the invalidated ones.


And another thing, are there any downsides in keeping RequestLogger on in
production environment? I'm thinking that it might hog a lot of resources,
but is that the case?


Regards,

Taneli Korri


Re: RequestLogger and session invalidation

2009-05-28 Thread Taneli Korri
On Thu, May 28, 2009 at 6:49 AM, Jeremy Thomerson jer...@wickettraining.com
 wrote:

 Please open a JIRA so this doesn't get lost.  I haven't looked, but it
 sounds wrong if it truly recreates an invalidated session in some
 end-of-request logging, even if it doesn't bind the session.  Post the
 link back here.



I found out what's causing the problem, I was using Session.invalidateNow()
which invalidates the session before it's logged. With Session.invalidate()
the problem doesn't exist.


I created a JIRA issue about it:

https://issues.apache.org/jira/browse/WICKET-2291


Regards,

Taneli Korri


Re: RequestLogger and session invalidation

2009-05-29 Thread Taneli Korri
On Thu, May 28, 2009 at 11:24 AM, Johan Compagner jcompag...@gmail.comwrote:

 why are you using invalidateNow?


I was using it for invalidating sessions on logout. But since plain
invalidate() works, and doesn't break RequestLogger, my original problem is
fixed.


Regards,

Taneli Korri


Re: Hide page version query parameters

2011-12-28 Thread Taneli Korri

Allen wrote
 
 Is there a built-in way to hide page version parameters (e.g. ?12) in
 Wicket 1.5?  If not, is it possible to write a custom IRequestMapper that
 does so without screwing up proper request handling?
 
Hi,

Did you find a way to remove the page version parameter?

I'm also trying to figure out how to achieve that in Wicket 1.5. In 1.4 it
was easy since, mounting the page with mountBookmarkablePage was enough.

Regards
Taneli Korri

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Hide-page-version-query-parameters-tp4163099p4240312.html
Sent from the Users forum 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



Re: Hide page version query parameters

2011-12-31 Thread Taneli Korri
On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
 martin.dil...@googlemail.com wrote:
 hi,
 you could try to change your render strategy to redirect to render, that
 would dismiss the page
 parameters version.

 This is not correct.
 The page id is encoded in the url only for stateful pages. Make your
 page stateless and it wont be there.


OK, thanks for the info.

If I remember correctly, in Wicket 1.4 stateful pages had also clean
urls if the page was mounted to a certain path, i.e. the page version
number was stored somewhere behind the scenes. I'm guessing this isn't
possible anymore in Wicket 1.5?

Regards,
Taneli Korri

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Hide page version query parameters

2012-01-01 Thread Taneli Korri
On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org wrote:
 On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
 martin.dil...@googlemail.com wrote:
 hi,
 you could try to change your render strategy to redirect to render, that
 would dismiss the page
 parameters version.

 This is not correct.
 The page id is encoded in the url only for stateful pages. Make your
 page stateless and it wont be there.


 OK, thanks for the info.

 If I remember correctly, in Wicket 1.4 stateful pages had also clean
 urls if the page was mounted to a certain path, i.e. the page version
 number was stored somewhere behind the scenes. I'm guessing this isn't
 possible anymore in Wicket 1.5?

 Everything is possible.
 The new IRequestMapper are easily extensible and you can even use your own 
 one.
 By default this special parameter is set so when the user presses F5
 (Refresh) the page Wicket will deliver the same version of the page.
 Otherwise a new instance will be created without the knowledge of the
 exact version.

 Why do you want to hide this parameter ?


Plain and simple, I like clean urls that can be bookmarked.

Also some of the search engine bots save the crawled urls (with
parameters) and try to access them at a later time. I found this out
when I updated one of my sites and now I'm seeing a lot of 500
Internal error responses in my web server logs.

Regards,
Taneli Korri

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Hide page version query parameters

2012-01-02 Thread Taneli Korri
On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote:
 On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
 martin.dil...@googlemail.com wrote:
 hi,
 you could try to change your render strategy to redirect to render, that
 would dismiss the page
 parameters version.

 This is not correct.
 The page id is encoded in the url only for stateful pages. Make your
 page stateless and it wont be there.


 OK, thanks for the info.

 If I remember correctly, in Wicket 1.4 stateful pages had also clean
 urls if the page was mounted to a certain path, i.e. the page version
 number was stored somewhere behind the scenes. I'm guessing this isn't
 possible anymore in Wicket 1.5?

 Everything is possible.
 The new IRequestMapper are easily extensible and you can even use your own 
 one.
 By default this special parameter is set so when the user presses F5
 (Refresh) the page Wicket will deliver the same version of the page.
 Otherwise a new instance will be created without the knowledge of the
 exact version.

 Why do you want to hide this parameter ?


 Plain and simple, I like clean urls that can be bookmarked.

 The urls with the page id can be bookmarked. If the requested version
 of the page is not available then a new version is created and
 delivered.


Ok, I think I can live with that. :)


 Also some of the search engine bots save the crawled urls (with
 parameters) and try to access them at a later time. I found this out
 when I updated one of my sites and now I'm seeing a lot of 500
 Internal error responses in my web server logs.

 Can you paste the stacktrace of an exception caused by such request ?


I should have been more clear, this case wasn't directly related to
the page version parameter, but to clean urls.

The thing is that I had a few stateful links in the frontpage which
changed the page stylesheet. Now when I have removed the links, I'm
seeing some crawlers still trying to request them.

For example, a get request to
/?0-1.ILinkListener-stylechooser-style1wicket:interface=:1:stylechooser:style2::ILinkListener::
throws this with Wicket 1.5.3:

ERROR org.apache.wicket.DefaultExceptionMapper  - Unexpected error occurred
org.apache.wicket.request.handler.ComponentNotFoundException: Could
not find component 'stylechooser:style1' on page 'class
net.korri.www.page.blog.BlogPage
at 
org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248)
at 
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234)
at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at 
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at 
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
at 
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
at 
org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
at 
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
at 
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381)
at 
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87)
at 
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
at 
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
at 
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
at java.lang.Thread.run(Thread.java:662)

The request was valid earlier, but now since I've changed the site
there's

Re: Hide page version query parameters

2012-01-03 Thread Taneli Korri
On Tue, Jan 3, 2012 at 1:20 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 add the nofollow attribute to such links.


All the links had it from the start. The crawlers from the big
companies (Google, Bing etc) obey it, but some smaller ones do not.

Anyways, I fixed the problem by filtering the bad parameters with
urlrewritefilter. So no more internal server errors.

Regards,
Taneli Korri

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org