You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Nick Pratt <nb...@gmail.com> on 2015/01/12 20:46:44 UTC
Handling errors in dynamic Resource generation
I have an AbstractResource modelled after section 15.9 in the Wicket Guide:
http://wicket.apache.org/guide/guide/resources.html
What is the correct way to handle errors (such as expected dynamic data not
available) during the writeCallback?
The specific line in the example is: output.output(getFeed(), writer);
While I throw a WicketRuntimeException during the writeCallback and the
server aborts the request and logs the error, the client sits waiting for
the download. Worse still, after the client times out (Chrome on OS X), the
downloads bar displays what looks like a successfully downloaded valid file
with no indication of error, and while it does have some data in it (in my
case around 4800 bytes) its not valid (Im a little puzzled about the ~4800
bytes or so). Ideally I'd like to give the user a notification that the
download failed.
If I try and get the data before the writecallback, and then set the
ErrorCode on the ResourceResponse when the data is not available, the user
is redirected to an unstyled Jetty served error screen which we don't want
to see - we'd rather signal that the download failed and keep the user on
the same page. Is this possible with ResourceLink/AbstractResource or do
we have to use an alternative method to make this work more elegantly?
Re: Handling errors in dynamic Resource generation
Posted by Martin Grigorov <mg...@apache.org>.
I've done something similar before:
- pass the page id to the resource
- if there is an error then use the page id to lookup the page from the
stores
- if you send the request to the resource with Ajax
-- create a new AjaxRequestHandler and schedule it after the current
- if this is normal (non-Ajax) request
-- just do RequestCycle.get().setResponsePage(page)
- either do page.error(...) or broadcast a special event (with the ARH when
in Ajax) so a more specific component may report the error
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Jan 12, 2015 at 10:22 PM, Nick Pratt <nb...@gmail.com> wrote:
> Thanks Martin. How would this work though - from the callstack, I see
> newResourceResponse() invoked, followed by flushResponseAfterHeaders(), and
> then the writeData() callback invocation. So setting a flag in the
> writeData callback occurs too late. If I try and load the data outside the
> writeCallback, catch the error and then reset the headers there, the user
> gets redirected to the standard Wicket error/exception page.
>
> What does the browser need to receive in order to notify the user that a
> download failed (but keep them on the same page)?
>
>
> We cant (dont want to) ensure that all linked resources are physically
> available on disk (or on S3) since that would just kill page loading. We
> have a set of links that should be present, and barring any network issues
> or disk issues, they would ordinarily be available.
>
>
>
> On Mon, Jan 12, 2015 at 3:12 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > Override #flushResponseAfterHeaders() (see
> >
> >
> https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L673
> > )
> > so that you are able to reset the response if an error occurs while
> writing
> > the body.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, Jan 12, 2015 at 8:46 PM, Nick Pratt <nb...@gmail.com> wrote:
> >
> > > I have an AbstractResource modelled after section 15.9 in the Wicket
> > Guide:
> > > http://wicket.apache.org/guide/guide/resources.html
> > >
> > > What is the correct way to handle errors (such as expected dynamic data
> > not
> > > available) during the writeCallback?
> > >
> > > The specific line in the example is: output.output(getFeed(), writer);
> > >
> > >
> > > While I throw a WicketRuntimeException during the writeCallback and the
> > > server aborts the request and logs the error, the client sits waiting
> for
> > > the download. Worse still, after the client times out (Chrome on OS X),
> > the
> > > downloads bar displays what looks like a successfully downloaded valid
> > file
> > > with no indication of error, and while it does have some data in it (in
> > my
> > > case around 4800 bytes) its not valid (Im a little puzzled about the
> > ~4800
> > > bytes or so). Ideally I'd like to give the user a notification that the
> > > download failed.
> > >
> > > If I try and get the data before the writecallback, and then set the
> > > ErrorCode on the ResourceResponse when the data is not available, the
> > user
> > > is redirected to an unstyled Jetty served error screen which we don't
> > want
> > > to see - we'd rather signal that the download failed and keep the user
> on
> > > the same page. Is this possible with ResourceLink/AbstractResource or
> do
> > > we have to use an alternative method to make this work more elegantly?
> > >
> >
>
Re: Handling errors in dynamic Resource generation
Posted by Nick Pratt <nb...@gmail.com>.
Thanks Martin. How would this work though - from the callstack, I see
newResourceResponse() invoked, followed by flushResponseAfterHeaders(), and
then the writeData() callback invocation. So setting a flag in the
writeData callback occurs too late. If I try and load the data outside the
writeCallback, catch the error and then reset the headers there, the user
gets redirected to the standard Wicket error/exception page.
What does the browser need to receive in order to notify the user that a
download failed (but keep them on the same page)?
We cant (dont want to) ensure that all linked resources are physically
available on disk (or on S3) since that would just kill page loading. We
have a set of links that should be present, and barring any network issues
or disk issues, they would ordinarily be available.
On Mon, Jan 12, 2015 at 3:12 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> Override #flushResponseAfterHeaders() (see
>
> https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L673
> )
> so that you are able to reset the response if an error occurs while writing
> the body.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Jan 12, 2015 at 8:46 PM, Nick Pratt <nb...@gmail.com> wrote:
>
> > I have an AbstractResource modelled after section 15.9 in the Wicket
> Guide:
> > http://wicket.apache.org/guide/guide/resources.html
> >
> > What is the correct way to handle errors (such as expected dynamic data
> not
> > available) during the writeCallback?
> >
> > The specific line in the example is: output.output(getFeed(), writer);
> >
> >
> > While I throw a WicketRuntimeException during the writeCallback and the
> > server aborts the request and logs the error, the client sits waiting for
> > the download. Worse still, after the client times out (Chrome on OS X),
> the
> > downloads bar displays what looks like a successfully downloaded valid
> file
> > with no indication of error, and while it does have some data in it (in
> my
> > case around 4800 bytes) its not valid (Im a little puzzled about the
> ~4800
> > bytes or so). Ideally I'd like to give the user a notification that the
> > download failed.
> >
> > If I try and get the data before the writecallback, and then set the
> > ErrorCode on the ResourceResponse when the data is not available, the
> user
> > is redirected to an unstyled Jetty served error screen which we don't
> want
> > to see - we'd rather signal that the download failed and keep the user on
> > the same page. Is this possible with ResourceLink/AbstractResource or do
> > we have to use an alternative method to make this work more elegantly?
> >
>
Re: Handling errors in dynamic Resource generation
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Override #flushResponseAfterHeaders() (see
https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L673)
so that you are able to reset the response if an error occurs while writing
the body.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Jan 12, 2015 at 8:46 PM, Nick Pratt <nb...@gmail.com> wrote:
> I have an AbstractResource modelled after section 15.9 in the Wicket Guide:
> http://wicket.apache.org/guide/guide/resources.html
>
> What is the correct way to handle errors (such as expected dynamic data not
> available) during the writeCallback?
>
> The specific line in the example is: output.output(getFeed(), writer);
>
>
> While I throw a WicketRuntimeException during the writeCallback and the
> server aborts the request and logs the error, the client sits waiting for
> the download. Worse still, after the client times out (Chrome on OS X), the
> downloads bar displays what looks like a successfully downloaded valid file
> with no indication of error, and while it does have some data in it (in my
> case around 4800 bytes) its not valid (Im a little puzzled about the ~4800
> bytes or so). Ideally I'd like to give the user a notification that the
> download failed.
>
> If I try and get the data before the writecallback, and then set the
> ErrorCode on the ResourceResponse when the data is not available, the user
> is redirected to an unstyled Jetty served error screen which we don't want
> to see - we'd rather signal that the download failed and keep the user on
> the same page. Is this possible with ResourceLink/AbstractResource or do
> we have to use an alternative method to make this work more elegantly?
>