Re: Problems with Autocomplete in 6.11.0
Done: WICKET-5382 Greetings Jan -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Problems-with-Autocomplete-in-6-11-0-tp4661600p4661637.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: Form Reset Problems
Well that's the thing, a reset back to defaults makes sense since that's how
most apps behave. Wiping out the defaults and emptying out the form fields
is a bit strange to call via a "Reset" button, maybe "New" button? As Martin
described it makes sense but might be confusing to the user unless you're
explicit in the UI.
The last time I had to touch on the form field's input VS its model was to
audit the user input as Hibernate's Envers didn't fit our services (which
touched on too many entities at once and was harder to present in the UI to
the system admin).
~ Thank you,
Paul Bors
-Original Message-
From: Richard W. Adams [mailto:rwada...@up.com]
Sent: Monday, September 30, 2013 10:52 AM
To: users@wicket.apache.org
Subject: RE: Form Reset Problems
Our use case is probably more complex than most. We have a form that does a
lot Ajax field updates that appear to break the reset function on some
browsers. That's why resorted to doing the reset via Ajax.
From: Paul Bors
To:
Date: 09/30/2013 09:41 AM
Subject:RE: Form Reset Problems
I'll like to hear more about Richard's use-case as to me using Ajax to
perform a form reset that could be done by the browser is a bit of an
overkill. Unless some sort of a user workflow through the app happens in
stages for which I would recommend using a Wizard.
~ Thank you,
Paul Bors
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, September 30, 2013 9:57 AM
To: users@wicket.apache.org
Subject: Re: Form Reset Problems
Hi,
I'm going to write a blog article about Form component's input vs. model.
I've been asked few times about this last two weeks by colleagues of mine.
It would be good to have it in the official guide though (
https://issues.apache.org/jira/browse/WICKET-5321).
To reset a form you should:
1) use a button with default processing == false, to prevent form validation
(or just AjaxLink)
2) call form.clearInput()
3) and to set the "default" model for each form component. Each application
should know what "default" means for its form components.
On Mon, Sep 30, 2013 at 3:46 PM, Richard W. Adams wrote:
> We're having trouble making our form reset button work. It's defined
> thusly:
>
> AjaxButton button = new AjaxButton("reset-button"); ...
>
> _
>
> Here's our reset code, executed when the button is clicked. The main
> form seems to re-render OK, but a FormComponentPanel that is part of
> the form does not. I see a lot of discussion on Wicket form resets on
> the Web, but most is several years old. Is there an "officially"
> endorsed pattern or example for doing Ajax form resets?
> _
>
> public void onReset(final AjaxRequestTarget target) {
>
> final Component.IVisitor> visitor = new
> Component.IVisitor>() {
>
> @Override public Object component(final
> FormComponent
> formComponent) {
>
> if (formComponent.getDefaultModel() != null) {
> // Must have a model for the component
> final Object currentValue =
> formComponent.getDefaultModelObject(); // Save model value
> formComponent.clearInput(); // Clear
> out formComponent.setDefaultModelObject(currentValue); // Add the
> value
back
> }
> if (target != null) {
> target.addComponent(formComponent);
> }
> return Component.IVisitor.CONTINUE_TRAVERSAL;
> }
> };
> visitChildren(FormComponent.class, visitor);
> }
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
> others, and any forwarding of this email or its contents, without the
> express permission of the sender is strictly prohibited by law. If
> you are not the intended recipient, please contact the sender
> immediately, delete the e-mail and destroy all copies.
> **
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use,
review, disclosure, copying, distribution or reliance by others, and any
forwarding of this email or its contents, without the express permission of
the sender is strictly prohibited by law. If you are not the intended
recipient, please contact the sender immediately, delete the e-mail and
destroy all copies.
**
-
To unsubscribe, e-mail: users-unsubscr..
RE: Form Reset Problems
Our use case is probably more complex than most. We have a form that does
a lot Ajax field updates that appear to break the reset function on some
browsers. That's why resorted to doing the reset via Ajax.
From: Paul Bors
To:
Date: 09/30/2013 09:41 AM
Subject:RE: Form Reset Problems
I'll like to hear more about Richard's use-case as to me using Ajax to
perform a form reset that could be done by the browser is a bit of an
overkill. Unless some sort of a user workflow through the app happens in
stages for which I would recommend using a Wizard.
~ Thank you,
Paul Bors
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, September 30, 2013 9:57 AM
To: users@wicket.apache.org
Subject: Re: Form Reset Problems
Hi,
I'm going to write a blog article about Form component's input vs. model.
I've been asked few times about this last two weeks by colleagues of mine.
It would be good to have it in the official guide though (
https://issues.apache.org/jira/browse/WICKET-5321).
To reset a form you should:
1) use a button with default processing == false, to prevent form
validation (or just AjaxLink)
2) call form.clearInput()
3) and to set the "default" model for each form component. Each
application should know what "default" means for its form components.
On Mon, Sep 30, 2013 at 3:46 PM, Richard W. Adams wrote:
> We're having trouble making our form reset button work. It's defined
> thusly:
>
> AjaxButton button = new AjaxButton("reset-button"); ...
>
> _
>
> Here's our reset code, executed when the button is clicked. The main
> form seems to re-render OK, but a FormComponentPanel that is part of
> the form does not. I see a lot of discussion on Wicket form resets on
> the Web, but most is several years old. Is there an "officially"
> endorsed pattern or example for doing Ajax form resets?
> _
>
> public void onReset(final AjaxRequestTarget target) {
>
> final Component.IVisitor> visitor = new
> Component.IVisitor>() {
>
> @Override public Object component(final
> FormComponent
> formComponent) {
>
> if (formComponent.getDefaultModel() != null) {
> // Must have a model for the component
> final Object currentValue =
> formComponent.getDefaultModelObject(); // Save model value
> formComponent.clearInput(); //
> Clear out
> formComponent.setDefaultModelObject(currentValue); // Add the value
back
> }
> if (target != null) {
> target.addComponent(formComponent);
> }
> return Component.IVisitor.CONTINUE_TRAVERSAL;
> }
> };
> visitChildren(FormComponent.class, visitor);
> }
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended
recipient.
> Any use, review, disclosure, copying, distribution or reliance by
> others, and any forwarding of this email or its contents, without the
> express permission of the sender is strictly prohibited by law. If
> you are not the intended recipient, please contact the sender
> immediately, delete the e-mail and destroy all copies.
> **
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use, review,
disclosure, copying, distribution or reliance by others, and any forwarding of
this email or its contents, without the express permission of the sender is
strictly prohibited by law. If you are not the intended recipient, please
contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: Form Reset Problems
Imagine wizard workflow.
Browser reset will reset to the value the page has been loaded with.
Server-side reset will reset to whatever the application defines as default
value.
On Mon, Sep 30, 2013 at 4:40 PM, Paul Bors wrote:
> I'll like to hear more about Richard's use-case as to me using Ajax to
> perform a form reset that could be done by the browser is a bit of an
> overkill. Unless some sort of a user workflow through the app happens in
> stages for which I would recommend using a Wizard.
>
> ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Monday, September 30, 2013 9:57 AM
> To: users@wicket.apache.org
> Subject: Re: Form Reset Problems
>
> Hi,
>
> I'm going to write a blog article about Form component's input vs. model.
> I've been asked few times about this last two weeks by colleagues of mine.
> It would be good to have it in the official guide though (
> https://issues.apache.org/jira/browse/WICKET-5321).
>
> To reset a form you should:
> 1) use a button with default processing == false, to prevent form
> validation (or just AjaxLink)
> 2) call form.clearInput()
> 3) and to set the "default" model for each form component. Each
> application should know what "default" means for its form components.
>
>
> On Mon, Sep 30, 2013 at 3:46 PM, Richard W. Adams wrote:
>
> > We're having trouble making our form reset button work. It's defined
> > thusly:
> >
> > AjaxButton button = new AjaxButton("reset-button"); ...
> >
> > _
> >
> > Here's our reset code, executed when the button is clicked. The main
> > form seems to re-render OK, but a FormComponentPanel that is part of
> > the form does not. I see a lot of discussion on Wicket form resets on
> > the Web, but most is several years old. Is there an "officially"
> > endorsed pattern or example for doing Ajax form resets?
> > _
> >
> > public void onReset(final AjaxRequestTarget target) {
> >
> > final Component.IVisitor> visitor = new
> > Component.IVisitor>() {
> >
> > @Override public Object component(final
> > FormComponent
> > formComponent) {
> >
> > if (formComponent.getDefaultModel() != null) {
> > // Must have a model for the component
> > final Object currentValue =
> > formComponent.getDefaultModelObject(); // Save model value
> > formComponent.clearInput();
> //
> > Clear out
> > formComponent.setDefaultModelObject(currentValue); // Add the value back
> > }
> > if (target != null) {
> > target.addComponent(formComponent);
> > }
> > return Component.IVisitor.CONTINUE_TRAVERSAL;
> > }
> > };
> > visitChildren(FormComponent.class, visitor);
>
>
> > }
> >
> >
> > **
> >
> > This email and any attachments may contain information that is
> > confidential and/or privileged for the sole use of the intended
> recipient.
> > Any use, review, disclosure, copying, distribution or reliance by
> > others, and any forwarding of this email or its contents, without the
> > express permission of the sender is strictly prohibited by law. If
> > you are not the intended recipient, please contact the sender
> > immediately, delete the e-mail and destroy all copies.
> > **
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
RE: Form Reset Problems
I'll like to hear more about Richard's use-case as to me using Ajax to perform
a form reset that could be done by the browser is a bit of an overkill. Unless
some sort of a user workflow through the app happens in stages for which I
would recommend using a Wizard.
~ Thank you,
Paul Bors
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Monday, September 30, 2013 9:57 AM
To: users@wicket.apache.org
Subject: Re: Form Reset Problems
Hi,
I'm going to write a blog article about Form component's input vs. model.
I've been asked few times about this last two weeks by colleagues of mine.
It would be good to have it in the official guide though (
https://issues.apache.org/jira/browse/WICKET-5321).
To reset a form you should:
1) use a button with default processing == false, to prevent form validation
(or just AjaxLink)
2) call form.clearInput()
3) and to set the "default" model for each form component. Each application
should know what "default" means for its form components.
On Mon, Sep 30, 2013 at 3:46 PM, Richard W. Adams wrote:
> We're having trouble making our form reset button work. It's defined
> thusly:
>
> AjaxButton button = new AjaxButton("reset-button"); ...
>
> _
>
> Here's our reset code, executed when the button is clicked. The main
> form seems to re-render OK, but a FormComponentPanel that is part of
> the form does not. I see a lot of discussion on Wicket form resets on
> the Web, but most is several years old. Is there an "officially"
> endorsed pattern or example for doing Ajax form resets?
> _
>
> public void onReset(final AjaxRequestTarget target) {
>
> final Component.IVisitor> visitor = new
> Component.IVisitor>() {
>
> @Override public Object component(final
> FormComponent
> formComponent) {
>
> if (formComponent.getDefaultModel() != null) {
> // Must have a model for the component
> final Object currentValue =
> formComponent.getDefaultModelObject(); // Save model value
> formComponent.clearInput(); //
> Clear out
> formComponent.setDefaultModelObject(currentValue); // Add the value back
> }
> if (target != null) {
> target.addComponent(formComponent);
> }
> return Component.IVisitor.CONTINUE_TRAVERSAL;
> }
> };
> visitChildren(FormComponent.class, visitor);
> }
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
> Any use, review, disclosure, copying, distribution or reliance by
> others, and any forwarding of this email or its contents, without the
> express permission of the sender is strictly prohibited by law. If
> you are not the intended recipient, please contact the sender
> immediately, delete the e-mail and destroy all copies.
> **
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
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 Page Expired exceptions in Wicket 6.10.0 (GlassFish v3
and v4)
https://issues.apache.org/jira/browse/WICKET-5380
On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov wrote:
> 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();
> httpRequest.getSession().setMaxInactiveInterval(10);
>
> and the session expires according to the web container's configurations.
> Jetty's Scavenger thread runs every 30 secs by default, so the session
> is invalidated between 1-30 secs after its expiration time.
> Tomcat and GF seems to do this every 60 secs by default.
>
> I'll create a ticket and commit the change.
>
>
> On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote:
>
>> 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, Martin Grigorov
>> wrote:
>>
>>> 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();
>>> old=doPutOrRemove(name,value);
>>> }
>>>
>>> if (value==null || !value.equals(old)) // <
>>> {
>>> if (old!=null)
>>> unbindValue(name,old);
>>>
>>> Since SessionEntry doesn't override #equals() the check is by reference.
>>> Thus no notification.
>>>
>>>
>>>
>>> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov
>>> wrote:
>>>
I'll test this and let you know.
On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 =
> (WebRequest)RequestCycle.get().getRequest();
> HttpServletRequest httpRequest =
> (HttpServletRequest)webRequest.getContainerRequest();
> httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
>
> I set the session duration to 1 min and tried it with the new
> implementation for the getSessionEntry(), waited for a good 2-3
> mins and the session is never invalidated any longer as if it's no longer
> touched.
> My breakpoint on SessionEntry.valueUnbound() is not called either,
> unless explicitly through the Logout button which calls
> o.a.w.protocol.http.WebSession.get().invalidateNow();
>
> This is what makes me think that going off the HttpSessionListener
> might be better.
>
> ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Saturday, September 28, 2013 3:44 AM
> To: users@wicket.apache.org
> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
> (GlassFish v3 and v4)
>
> 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 touched for some predefined time
> then the web container invalidates it automatically.
>
>
> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
>
> > 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 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 exceptions in Wicket 6.10.0
> >> (GlassFish
Re: AjaxSelfUpdatingTimerBehavior does not stop itself properly after certain time
doProcessTarget() is your own method and AFAIS it is called only if not
expired.
@Override
protected final void onPostProcessTarget(AjaxRequestTarget target) {
if (expired.get()) {
stop(target);
return;
}
doProcessTarget(target);
}
Wicket knows nothing about this method, so it cannot call it.
On Mon, Sep 30, 2013 at 3:52 PM, Behrooz Nobakht wrote:
> Thanks for the hint. The part that "delete
> Wicket.TimerHandles[‘instance103’]" should be in the response, helped us
> find the issue.
>
> However, there is a more general discussion as this cannot be called a bug.
> Why after the last time “shouldTrigger” is called and then
> “stop(AjaxRequestTargte)”, there will be still another call to
> “doProcessTarget()”?
>
> This made us to use two flags to manage time-wise expiration of the
> behavior.
>
> Thanks,
>
>
> On Mon, Sep 30, 2013 at 2:23 PM, Martin Grigorov >wrote:
>
> > Hi,
> >
> > Put a breakpoint in #onPostProcessTarget() and make sure that
> stop(target)
> > is invoked.
> > Then check the Ajax response for this request and verify that it has
> > something like:
> > delete Wicket.TimerHandles['instance103']
> > and that there is no another setTimeout() call in the
> elements
> > in the response.
> >
> > As last resort create a quickstart app and attach it to a ticket so we
> can
> > debug it and fix it if there is a problem.
> >
> >
> > On Mon, Sep 30, 2013 at 2:12 PM, Behrooz Nobakht
> wrote:
> >
> > > Hello,
> > >
> > > I have a custom AjaxSelfUpdatingTimerBehavior as follows:
> > >
> > > public class LimitedAjaxSelfUpdatingTimerBehavior extends
> > > AjaxSelfUpdatingTimerBehavior {
> > > private static final long serialVersionUID = 1L;
> > >
> > > public static final long MAX_IDLE_TIME =
> > > TimeUnit.SECONDS.toMillis(120);
> > >
> > > private final Logger logger = LoggerFactory.getLogger(getClass());
> > >
> > > private final AtomicLong createdTime = new
> > > AtomicLong(System.currentTimeMillis());
> > >
> > > private final AtomicBoolean expired = new AtomicBoolean(false);
> > >
> > > public LimitedAjaxSelfUpdatingTimerBehavior() {
> > > this(Duration.milliseconds(MAX_IDLE_TIME));
> > > }
> > >
> > > protected LimitedAjaxSelfUpdatingTimerBehavior(Duration
> > > updateInterval) {
> > > super(updateInterval);
> > > }
> > >
> > > @Override
> > > protected final void onPostProcessTarget(AjaxRequestTarget target)
> {
> > > if (expired.get()) {
> > > stop(target);
> > > return;
> > > }
> > > doProcessTarget(target);
> > > }
> > >
> > > @Override
> > > protected boolean shouldTrigger() {
> > > long idle = System.currentTimeMillis() - createdTime.get();
> > > expired.compareAndSet(false, idle > MAX_IDLE_TIME);
> > > if (expired.get()) {
> > > logger.warn("A message");
> > >
> > > // find the AJAX request and stop it
> > > AjaxRequestTarget target =
> > > RequestCycle.get().find(AjaxRequestTarget.class);
> > > stop(target);
> > > }
> > > return !expired.get();
> > > }
> > >
> > > /**
> > > * @param target
> > > */
> > > protected void doProcessTarget(AjaxRequestTarget target) {
> > > }
> > > }
> > >
> > > I use this behavior on a set of my components in a Wicket page,
> however,
> > > after the default timeout passes, I can still see in the browser debug
> > > console XHR requests such as:
> > >
> > >
> > >
> >
> http://localhost:8081/w/wicket/page?1-1.IBehaviorListener.0-serviceInstances-0-serviceInstanceServerInstances-content-servers-0-server-instances-0-instance&_=1380542862344
> > >
> > > And the response to such XHR looks like:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > which shows that the behavior has *not* been stopped for the component.
> > >
> > > What am I missing or doing in a wrong way?
> > >
> > > Thanks for the help!— Behrooz Nobakht
> > >
> >
>
>
>
> --
> -- Behrooz Nobakht
>
Re: Form Reset Problems
Hi,
I'm going to write a blog article about Form component's input vs. model.
I've been asked few times about this last two weeks by colleagues of mine.
It would be good to have it in the official guide though (
https://issues.apache.org/jira/browse/WICKET-5321).
To reset a form you should:
1) use a button with default processing == false, to prevent form
validation (or just AjaxLink)
2) call form.clearInput()
3) and to set the "default" model for each form component. Each
application should know what "default" means for its form components.
On Mon, Sep 30, 2013 at 3:46 PM, Richard W. Adams wrote:
> We're having trouble making our form reset button work. It's defined
> thusly:
>
> AjaxButton button = new AjaxButton("reset-button");
> ...
>
> _
>
> Here's our reset code, executed when the button is clicked. The main form
> seems to re-render OK, but a
> FormComponentPanel that is part of the form does not. I see a lot of
> discussion on Wicket form resets on the Web, but most is several years
> old. Is there an "officially" endorsed pattern or example for doing Ajax
> form resets?
> _
>
> public void onReset(final AjaxRequestTarget target) {
>
> final Component.IVisitor> visitor = new
> Component.IVisitor>() {
>
> @Override public Object component(final FormComponent
> formComponent) {
>
> if (formComponent.getDefaultModel() != null) {
> // Must have a model for the component
> final Object currentValue =
> formComponent.getDefaultModelObject(); // Save model value
> formComponent.clearInput(); //
> Clear out
> formComponent.setDefaultModelObject(currentValue); // Add the value back
> }
> if (target != null) {
> target.addComponent(formComponent);
> }
> return Component.IVisitor.CONTINUE_TRAVERSAL;
> }
> };
> visitChildren(FormComponent.class, visitor);
> }
>
>
> **
>
> This email and any attachments may contain information that is
> confidential and/or privileged for the sole use of the intended recipient.
> Any use, review, disclosure, copying, distribution or reliance by others,
> and any forwarding of this email or its contents, without the express
> permission of the sender is strictly prohibited by law. If you are not the
> intended recipient, please contact the sender immediately, delete the
> e-mail and destroy all copies.
> **
>
Re: AjaxSelfUpdatingTimerBehavior does not stop itself properly after certain time
Thanks for the hint. The part that "delete
Wicket.TimerHandles[‘instance103’]" should be in the response, helped us
find the issue.
However, there is a more general discussion as this cannot be called a bug.
Why after the last time “shouldTrigger” is called and then
“stop(AjaxRequestTargte)”, there will be still another call to
“doProcessTarget()”?
This made us to use two flags to manage time-wise expiration of the
behavior.
Thanks,
On Mon, Sep 30, 2013 at 2:23 PM, Martin Grigorov wrote:
> Hi,
>
> Put a breakpoint in #onPostProcessTarget() and make sure that stop(target)
> is invoked.
> Then check the Ajax response for this request and verify that it has
> something like:
> delete Wicket.TimerHandles['instance103']
> and that there is no another setTimeout() call in the elements
> in the response.
>
> As last resort create a quickstart app and attach it to a ticket so we can
> debug it and fix it if there is a problem.
>
>
> On Mon, Sep 30, 2013 at 2:12 PM, Behrooz Nobakht wrote:
>
> > Hello,
> >
> > I have a custom AjaxSelfUpdatingTimerBehavior as follows:
> >
> > public class LimitedAjaxSelfUpdatingTimerBehavior extends
> > AjaxSelfUpdatingTimerBehavior {
> > private static final long serialVersionUID = 1L;
> >
> > public static final long MAX_IDLE_TIME =
> > TimeUnit.SECONDS.toMillis(120);
> >
> > private final Logger logger = LoggerFactory.getLogger(getClass());
> >
> > private final AtomicLong createdTime = new
> > AtomicLong(System.currentTimeMillis());
> >
> > private final AtomicBoolean expired = new AtomicBoolean(false);
> >
> > public LimitedAjaxSelfUpdatingTimerBehavior() {
> > this(Duration.milliseconds(MAX_IDLE_TIME));
> > }
> >
> > protected LimitedAjaxSelfUpdatingTimerBehavior(Duration
> > updateInterval) {
> > super(updateInterval);
> > }
> >
> > @Override
> > protected final void onPostProcessTarget(AjaxRequestTarget target) {
> > if (expired.get()) {
> > stop(target);
> > return;
> > }
> > doProcessTarget(target);
> > }
> >
> > @Override
> > protected boolean shouldTrigger() {
> > long idle = System.currentTimeMillis() - createdTime.get();
> > expired.compareAndSet(false, idle > MAX_IDLE_TIME);
> > if (expired.get()) {
> > logger.warn("A message");
> >
> > // find the AJAX request and stop it
> > AjaxRequestTarget target =
> > RequestCycle.get().find(AjaxRequestTarget.class);
> > stop(target);
> > }
> > return !expired.get();
> > }
> >
> > /**
> > * @param target
> > */
> > protected void doProcessTarget(AjaxRequestTarget target) {
> > }
> > }
> >
> > I use this behavior on a set of my components in a Wicket page, however,
> > after the default timeout passes, I can still see in the browser debug
> > console XHR requests such as:
> >
> >
> >
> http://localhost:8081/w/wicket/page?1-1.IBehaviorListener.0-serviceInstances-0-serviceInstanceServerInstances-content-servers-0-server-instances-0-instance&_=1380542862344
> >
> > And the response to such XHR looks like:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > which shows that the behavior has *not* been stopped for the component.
> >
> > What am I missing or doing in a wrong way?
> >
> > Thanks for the help!— Behrooz Nobakht
> >
>
--
-- Behrooz Nobakht
Form Reset Problems
We're having trouble making our form reset button work. It's defined
thusly:
AjaxButton button = new AjaxButton("reset-button");
...
_
Here's our reset code, executed when the button is clicked. The main form
seems to re-render OK, but a
FormComponentPanel that is part of the form does not. I see a lot of
discussion on Wicket form resets on the Web, but most is several years
old. Is there an "officially" endorsed pattern or example for doing Ajax
form resets?
_
public void onReset(final AjaxRequestTarget target) {
final Component.IVisitor> visitor = new
Component.IVisitor>() {
@Override public Object component(final FormComponent
formComponent) {
if (formComponent.getDefaultModel() != null) {
// Must have a model for the component
final Object currentValue =
formComponent.getDefaultModelObject(); // Save model value
formComponent.clearInput(); //
Clear out
formComponent.setDefaultModelObject(currentValue); // Add the value back
}
if (target != null) {
target.addComponent(formComponent);
}
return Component.IVisitor.CONTINUE_TRAVERSAL;
}
};
visitChildren(FormComponent.class, visitor);
}
**
This email and any attachments may contain information that is confidential
and/or privileged for the sole use of the intended recipient. Any use, review,
disclosure, copying, distribution or reliance by others, and any forwarding of
this email or its contents, without the express permission of the sender is
strictly prohibited by law. If you are not the intended recipient, please
contact the sender immediately, delete the e-mail and destroy all copies.
**
Re: AjaxSelfUpdatingTimerBehavior does not stop itself properly after certain time
Hi,
Put a breakpoint in #onPostProcessTarget() and make sure that stop(target)
is invoked.
Then check the Ajax response for this request and verify that it has
something like:
delete Wicket.TimerHandles['instance103']
and that there is no another setTimeout() call in the elements
in the response.
As last resort create a quickstart app and attach it to a ticket so we can
debug it and fix it if there is a problem.
On Mon, Sep 30, 2013 at 2:12 PM, Behrooz Nobakht wrote:
> Hello,
>
> I have a custom AjaxSelfUpdatingTimerBehavior as follows:
>
> public class LimitedAjaxSelfUpdatingTimerBehavior extends
> AjaxSelfUpdatingTimerBehavior {
> private static final long serialVersionUID = 1L;
>
> public static final long MAX_IDLE_TIME =
> TimeUnit.SECONDS.toMillis(120);
>
> private final Logger logger = LoggerFactory.getLogger(getClass());
>
> private final AtomicLong createdTime = new
> AtomicLong(System.currentTimeMillis());
>
> private final AtomicBoolean expired = new AtomicBoolean(false);
>
> public LimitedAjaxSelfUpdatingTimerBehavior() {
> this(Duration.milliseconds(MAX_IDLE_TIME));
> }
>
> protected LimitedAjaxSelfUpdatingTimerBehavior(Duration
> updateInterval) {
> super(updateInterval);
> }
>
> @Override
> protected final void onPostProcessTarget(AjaxRequestTarget target) {
> if (expired.get()) {
> stop(target);
> return;
> }
> doProcessTarget(target);
> }
>
> @Override
> protected boolean shouldTrigger() {
> long idle = System.currentTimeMillis() - createdTime.get();
> expired.compareAndSet(false, idle > MAX_IDLE_TIME);
> if (expired.get()) {
> logger.warn("A message");
>
> // find the AJAX request and stop it
> AjaxRequestTarget target =
> RequestCycle.get().find(AjaxRequestTarget.class);
> stop(target);
> }
> return !expired.get();
> }
>
> /**
> * @param target
> */
> protected void doProcessTarget(AjaxRequestTarget target) {
> }
> }
>
> I use this behavior on a set of my components in a Wicket page, however,
> after the default timeout passes, I can still see in the browser debug
> console XHR requests such as:
>
>
> http://localhost:8081/w/wicket/page?1-1.IBehaviorListener.0-serviceInstances-0-serviceInstanceServerInstances-content-servers-0-server-instances-0-instance&_=1380542862344
>
> And the response to such XHR looks like:
>
>
>
>
>
>
>
>
>
> which shows that the behavior has *not* been stopped for the component.
>
> What am I missing or doing in a wrong way?
>
> Thanks for the help!— Behrooz Nobakht
>
AjaxSelfUpdatingTimerBehavior does not stop itself properly after certain time
Hello,
I have a custom AjaxSelfUpdatingTimerBehavior as follows:
public class LimitedAjaxSelfUpdatingTimerBehavior extends
AjaxSelfUpdatingTimerBehavior {
private static final long serialVersionUID = 1L;
public static final long MAX_IDLE_TIME = TimeUnit.SECONDS.toMillis(120);
private final Logger logger = LoggerFactory.getLogger(getClass());
private final AtomicLong createdTime = new
AtomicLong(System.currentTimeMillis());
private final AtomicBoolean expired = new AtomicBoolean(false);
public LimitedAjaxSelfUpdatingTimerBehavior() {
this(Duration.milliseconds(MAX_IDLE_TIME));
}
protected LimitedAjaxSelfUpdatingTimerBehavior(Duration updateInterval) {
super(updateInterval);
}
@Override
protected final void onPostProcessTarget(AjaxRequestTarget target) {
if (expired.get()) {
stop(target);
return;
}
doProcessTarget(target);
}
@Override
protected boolean shouldTrigger() {
long idle = System.currentTimeMillis() - createdTime.get();
expired.compareAndSet(false, idle > MAX_IDLE_TIME);
if (expired.get()) {
logger.warn("A message");
// find the AJAX request and stop it
AjaxRequestTarget target =
RequestCycle.get().find(AjaxRequestTarget.class);
stop(target);
}
return !expired.get();
}
/**
* @param target
*/
protected void doProcessTarget(AjaxRequestTarget target) {
}
}
I use this behavior on a set of my components in a Wicket page, however,
after the default timeout passes, I can still see in the browser debug
console XHR requests such as:
http://localhost:8081/w/wicket/page?1-1.IBehaviorListener.0-serviceInstances-0-serviceInstanceServerInstances-content-servers-0-server-instances-0-instance&_=1380542862344
And the response to such XHR looks like:
which shows that the behavior has *not* been stopped for the component.
What am I missing or doing in a wrong way?
Thanks for the help!— Behrooz Nobakht
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
https://issues.apache.org/jira/browse/WICKET-5380
On Mon, Sep 30, 2013 at 12:32 PM, Martin Grigorov wrote:
> 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();
> httpRequest.getSession().setMaxInactiveInterval(10);
>
> and the session expires according to the web container's configurations.
> Jetty's Scavenger thread runs every 30 secs by default, so the session is
> invalidated between 1-30 secs after its expiration time.
> Tomcat and GF seems to do this every 60 secs by default.
>
> I'll create a ticket and commit the change.
>
>
> On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote:
>
>> 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, Martin Grigorov
>> wrote:
>>
>>> 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();
>>> old=doPutOrRemove(name,value);
>>> }
>>>
>>> if (value==null || !value.equals(old)) // <
>>> {
>>> if (old!=null)
>>> unbindValue(name,old);
>>>
>>> Since SessionEntry doesn't override #equals() the check is by reference.
>>> Thus no notification.
>>>
>>>
>>>
>>> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov
>>> wrote:
>>>
I'll test this and let you know.
On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 = (WebRequest)RequestCycle.get().getRequest();
> HttpServletRequest httpRequest =
> (HttpServletRequest)webRequest.getContainerRequest();
> httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
>
> I set the session duration to 1 min and tried it with the new
> implementation for the getSessionEntry(), waited for a good 2-3 mins and
> the session is never invalidated any longer as if it's no longer touched.
> My breakpoint on SessionEntry.valueUnbound() is not called either, unless
> explicitly through the Logout button which calls
> o.a.w.protocol.http.WebSession.get().invalidateNow();
>
> This is what makes me think that going off the HttpSessionListener
> might be better.
>
> ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Saturday, September 28, 2013 3:44 AM
> To: users@wicket.apache.org
> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
> (GlassFish v3 and v4)
>
> 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 touched for some predefined time then the web container invalidates
> it automatically.
>
>
> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
>
> > 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 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 exceptions in Wicket 6.10.0
> >> (GlassFish
> >> v3 and v4)
> >>
> >> 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 HttpSes
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
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();
httpRequest.getSession().setMaxInactiveInterval(10);
and the session expires according to the web container's configurations.
Jetty's Scavenger thread runs every 30 secs by default, so the session is
invalidated between 1-30 secs after its expiration time.
Tomcat and GF seems to do this every 60 secs by default.
I'll create a ticket and commit the change.
On Mon, Sep 30, 2013 at 11:55 AM, Martin Grigorov wrote:
> 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, Martin Grigorov wrote:
>
>> 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();
>> old=doPutOrRemove(name,value);
>> }
>>
>> if (value==null || !value.equals(old)) // <
>> {
>> if (old!=null)
>> unbindValue(name,old);
>>
>> Since SessionEntry doesn't override #equals() the check is by reference.
>> Thus no notification.
>>
>>
>>
>> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov
>> wrote:
>>
>>> I'll test this and let you know.
>>>
>>>
>>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 = (WebRequest)RequestCycle.get().getRequest();
HttpServletRequest httpRequest =
(HttpServletRequest)webRequest.getContainerRequest();
httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
I set the session duration to 1 min and tried it with the new
implementation for the getSessionEntry(), waited for a good 2-3 mins and
the session is never invalidated any longer as if it's no longer touched.
My breakpoint on SessionEntry.valueUnbound() is not called either, unless
explicitly through the Logout button which calls
o.a.w.protocol.http.WebSession.get().invalidateNow();
This is what makes me think that going off the HttpSessionListener
might be better.
~ Thank you,
Paul Bors
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Saturday, September 28, 2013 3:44 AM
To: users@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
(GlassFish v3 and v4)
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 touched for some predefined time then the web container invalidates
it automatically.
On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
> 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 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 exceptions in Wicket 6.10.0
>> (GlassFish
>> v3 and v4)
>>
>> 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 HttpSessionListener instead
>> is cleaner.
>>
>> ~ Thank you,
>>Paul Bors
>>
>> -Original Message-
>> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>> Sent: Friday, September 27, 2013 4:09 PM
>> To: users@wicket
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
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, Martin Grigorov wrote:
> 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();
> old=doPutOrRemove(name,value);
> }
>
> if (value==null || !value.equals(old)) // <
> {
> if (old!=null)
> unbindValue(name,old);
>
> Since SessionEntry doesn't override #equals() the check is by reference.
> Thus no notification.
>
>
>
> On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov wrote:
>
>> I'll test this and let you know.
>>
>>
>> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 = (WebRequest)RequestCycle.get().getRequest();
>>> HttpServletRequest httpRequest =
>>> (HttpServletRequest)webRequest.getContainerRequest();
>>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
>>>
>>> I set the session duration to 1 min and tried it with the new
>>> implementation for the getSessionEntry(), waited for a good 2-3 mins and
>>> the session is never invalidated any longer as if it's no longer touched.
>>> My breakpoint on SessionEntry.valueUnbound() is not called either, unless
>>> explicitly through the Logout button which calls
>>> o.a.w.protocol.http.WebSession.get().invalidateNow();
>>>
>>> This is what makes me think that going off the HttpSessionListener might
>>> be better.
>>>
>>> ~ Thank you,
>>> Paul Bors
>>>
>>> -Original Message-
>>> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>>> Sent: Saturday, September 28, 2013 3:44 AM
>>> To: users@wicket.apache.org
>>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
>>> (GlassFish v3 and v4)
>>>
>>> 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 touched for some predefined time then the web container invalidates
>>> it automatically.
>>>
>>>
>>> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
>>>
>>> > 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 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 exceptions in Wicket 6.10.0
>>> >> (GlassFish
>>> >> v3 and v4)
>>> >>
>>> >> 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 HttpSessionListener instead
>>> >> is cleaner.
>>> >>
>>> >> ~ Thank you,
>>> >>Paul Bors
>>> >>
>>> >> -Original Message-
>>> >> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>>> >> Sent: Friday, September 27, 2013 4:09 PM
>>> >> To: users@wicket.apache.org
>>> >> Cc: d...@wicket.apache.org
>>> >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
>>> >> (GlassFish
>>> >> v3 and v4)
>>> >>
>>> >> 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
>>> >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName());
>>> >> if (entry == null && create)
>>> >> {
>>> >> bind();
>>> >> entry = new SessionEntry(applicationName, getSessionId()); } if
>>> >> (entry != null) { synchronized (entry) {
>>> >> setSessionAttribute(**getA
Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
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();
old=doPutOrRemove(name,value);
}
if (value==null || !value.equals(old)) // <
{
if (old!=null)
unbindValue(name,old);
Since SessionEntry doesn't override #equals() the check is by reference.
Thus no notification.
On Mon, Sep 30, 2013 at 11:32 AM, Martin Grigorov wrote:
> I'll test this and let you know.
>
>
> On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 = (WebRequest)RequestCycle.get().getRequest();
>> HttpServletRequest httpRequest =
>> (HttpServletRequest)webRequest.getContainerRequest();
>> httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
>>
>> I set the session duration to 1 min and tried it with the new
>> implementation for the getSessionEntry(), waited for a good 2-3 mins and
>> the session is never invalidated any longer as if it's no longer touched.
>> My breakpoint on SessionEntry.valueUnbound() is not called either, unless
>> explicitly through the Logout button which calls
>> o.a.w.protocol.http.WebSession.get().invalidateNow();
>>
>> This is what makes me think that going off the HttpSessionListener might
>> be better.
>>
>> ~ Thank you,
>> Paul Bors
>>
>> -Original Message-
>> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>> Sent: Saturday, September 28, 2013 3:44 AM
>> To: users@wicket.apache.org
>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish
>> v3 and v4)
>>
>> 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 touched for some predefined time then the web container invalidates
>> it automatically.
>>
>>
>> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
>>
>> > 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 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 exceptions in Wicket 6.10.0
>> >> (GlassFish
>> >> v3 and v4)
>> >>
>> >> 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 HttpSessionListener instead
>> >> is cleaner.
>> >>
>> >> ~ Thank you,
>> >>Paul Bors
>> >>
>> >> -Original Message-
>> >> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>> >> Sent: Friday, September 27, 2013 4:09 PM
>> >> To: users@wicket.apache.org
>> >> Cc: d...@wicket.apache.org
>> >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
>> >> (GlassFish
>> >> v3 and v4)
>> >>
>> >> 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
>> >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName());
>> >> if (entry == null && create)
>> >> {
>> >> bind();
>> >> entry = new SessionEntry(applicationName, getSessionId()); } if
>> >> (entry != null) { synchronized (entry) {
>> >> setSessionAttribute(**getAttributeName(),
>> >> entry); } } return entry; }
>> >>
>> >> I think the correct code should be:
>> >>
>> >> private SessionEntry getSessionEntry(boolean create) { SessionEntry
>> >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName());
>> >> if (entry == null && create)
>> >> {
>> >> bind();
>> >> entry = new SessionEntry(applicationName, getSessionId());
>> >> setSessionAttribute(**getAttributeName(), entry); } return entry; }
>> >> I.e. set the Sessio
Re: AjaxFormChoiceComponentUpdatingBehavior with onchange event
thx : wicket is so amazing - Duto -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormChoiceComponentUpdatingBehavior-with-onchange-event-tp4661614p4661618.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: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)
I'll test this and let you know.
On Sat, Sep 28, 2013 at 10:37 PM, Paul Bors 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 = (WebRequest)RequestCycle.get().getRequest();
> HttpServletRequest httpRequest =
> (HttpServletRequest)webRequest.getContainerRequest();
> httpRequest.getSession().setMaxInactiveInterval(sessionDuration);
>
> I set the session duration to 1 min and tried it with the new
> implementation for the getSessionEntry(), waited for a good 2-3 mins and
> the session is never invalidated any longer as if it's no longer touched.
> My breakpoint on SessionEntry.valueUnbound() is not called either, unless
> explicitly through the Logout button which calls
> o.a.w.protocol.http.WebSession.get().invalidateNow();
>
> This is what makes me think that going off the HttpSessionListener might
> be better.
>
> ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Saturday, September 28, 2013 3:44 AM
> To: users@wicket.apache.org
> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish
> v3 and v4)
>
> 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 touched for some predefined time then the web container invalidates
> it automatically.
>
>
> On Sat, Sep 28, 2013 at 8:48 AM, Sven Meier wrote:
>
> > 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 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 exceptions in Wicket 6.10.0
> >> (GlassFish
> >> v3 and v4)
> >>
> >> 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 HttpSessionListener instead
> >> is cleaner.
> >>
> >> ~ Thank you,
> >>Paul Bors
> >>
> >> -Original Message-
> >> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> >> Sent: Friday, September 27, 2013 4:09 PM
> >> To: users@wicket.apache.org
> >> Cc: d...@wicket.apache.org
> >> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
> >> (GlassFish
> >> v3 and v4)
> >>
> >> 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
> >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName());
> >> if (entry == null && create)
> >> {
> >> bind();
> >> entry = new SessionEntry(applicationName, getSessionId()); } if
> >> (entry != null) { synchronized (entry) {
> >> setSessionAttribute(**getAttributeName(),
> >> entry); } } return entry; }
> >>
> >> I think the correct code should be:
> >>
> >> private SessionEntry getSessionEntry(boolean create) { SessionEntry
> >> entry = (SessionEntry)**getSessionAttribute(**getAttributeName());
> >> if (entry == null && create)
> >> {
> >> bind();
> >> entry = new SessionEntry(applicationName, getSessionId());
> >> setSessionAttribute(**getAttributeName(), entry); } return entry; }
> >> I.e. set the SessionEntry as an attribute in the http session only
> >> when it is created.
> >>
> >> Because with the current code we call
> >> "setSessionAttribute(**getAttributeName(), entry);" even with already
> >> existing entries and this leads to notifications to
> >> HttpSessionBindingListener - new value is bound, old value is removed.
> >>
> >> I guess Tomcat and Jetty optimize this by doing identity check.
> >>
> >> Another solution would be SessionEntry to implement
> >> HttpSessionListener instead and check the sessionId of the unbound
> >> session against its own one and clean the data store if they are equal.
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors wrote:
> >>
> >> Created
> >> https://java.net/jira/browse/
Re: AjaxFormChoiceComponentUpdatingBehavior with onchange event
Hi,
Try with
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes)
super.updateAjaxAttributes(attributes);
attributes.setEventNames("change");
}
On Mon, Sep 30, 2013 at 10:13 AM, Olivier Dutrieux <
olivier.dutri...@pasteur.fr> wrote:
> Hello all,
>
> Is there a way where I can use AjaxFormChoiceComponentUpdatingBehavior with
> the onchange event (javascript) rather tha onclick ?
>
> Because I need only ajax when the group radio change, because with the
> onclick event, every time I click on the same radio button, the ajax event
> is fire.
>
> maybe it's not the right way ...
>
> thx advance for your reply
>
> Duto
>
>
>
> -
> Duto
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/AjaxFormChoiceComponentUpdatingBehavior-with-onchange-event-tp4661614.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
>
>
AjaxFormChoiceComponentUpdatingBehavior with onchange event
Hello all, Is there a way where I can use AjaxFormChoiceComponentUpdatingBehavior with the onchange event (javascript) rather tha onclick ? Because I need only ajax when the group radio change, because with the onclick event, every time I click on the same radio button, the ajax event is fire. maybe it's not the right way ... thx advance for your reply Duto - Duto -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxFormChoiceComponentUpdatingBehavior-with-onchange-event-tp4661614.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
