I'll test this and let you know.
On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors p...@bors.ws wrote:
Sorry for the delay, it's the weekend :)
In our webapp we let the system administrator control the user session
timeout which we set it via the Login page as:
WebRequest webRequest =
Jetty 8.1.13 checks for equality of the old and the new values:
org.eclipse.jetty.server.session.AbstractSession#setAttribute
public void setAttribute(String name, Object value)
{
Object old=null;
synchronized (this)
{
checkValid();
Tomcat 7.x makes identity check:
org.apache.catalina.session.StandardSession#setAttribute
// Call the valueUnbound() method if necessary
if (notify (unbound != null) (unbound != value)
(unbound instanceof HttpSessionBindingListener)) {
On Mon, Sep 30, 2013 at 11:49 AM,
Applying only the first change that I suggested works on all - Jetty 8,
Tomcat 7 and Glassfish 4.
I've used:
WebRequest webRequest = (WebRequest) RequestCycle.get().getRequest();
HttpServletRequest httpRequest =
(HttpServletRequest)webRequest.getContainerRequest();
https://issues.apache.org/jira/browse/WICKET-5380
On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov mgrigo...@apache.orgwrote:
Applying only the first change that I suggested works on all - Jetty 8,
Tomcat 7 and Glassfish 4.
I've used:
WebRequest webRequest = (WebRequest)
Yes, the 60 secs default on GF threw me off over the weekend when I rushed my
tests.
Is working fine, thanks Martin!
~ Paul
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, September 30, 2013 6:43 AM
To: users@wicket.apache.org
Subject: Re: Bunch of
Martin's explanation fits the reported stacktrace nicely.
We should definitely change getSessionEntry() as proposed. I don't see
an advantage in using an HttpSessionListener though.
@Paul: What is broken now?
Sven
On 09/28/2013 12:15 AM, Paul Bors wrote:
I take that back, the new
I think both suggestions should be applied.
The intentions are more clear, IMO.
But let's wait Paul to explain what problem he faced. I don't expect
problems with session timeouts because this is managed by the web
container. If there is request then the session is touched. If the session
is not
Sorry for the delay, it's the weekend :)
In our webapp we let the system administrator control the user session timeout
which we set it via the Login page as:
WebRequest webRequest = (WebRequest)RequestCycle.get().getRequest();
HttpServletRequest httpRequest =
The closest I came to finding any ticket in GF's queue was:
https://java.net/jira/browse/GLASSFISH-4373 Remove http session attributes
only after invoking HttpSessionListener.sessionDestroyed()
Which was closed with some defensive comment about how GF does obey the servlet
specs and ...
Now
Created https://java.net/jira/browse/GLASSFISH-20828
HttpSessionBindingListener.valueUnbound() is always called right after
valueBound() with a null HttpSessionBindingEvent.getValue()
Let's see what becomes of this...
-
~ Thank you,
p...@bors.ws
--
View this message in context:
Reading your ticket against GF I think GF behaves correctly. But I wonder
why Tomcat/Jetty don't do this.
So here is what happens:
org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create)
{
SessionEntry
I tested with the proposed
o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new
implementation and it's working fine in GlassFish v3.1.2.2
I'll withdraw my GLASSFISH-20828 bug.
Should I open a new Wicket ticket instead?
I do think the second suggestion of using
I take that back, the new implementation breaks the session timeout.
~ Thank you,
Paul Bors
-Original Message-
From: Paul Bors [mailto:p...@bors.ws]
Sent: Friday, September 27, 2013 5:51 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: RE: Bunch of Page Expired
14 matches
Mail list logo
