You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Stefan Renz <s....@efonds.com> on 2014/04/02 15:25:36 UTC
Error handling in IResource implementations?
Hi,
I'm currently at loss: what would be the correct way signalling that a
IResource implementation encountered an error?
Here's the case:
I have a custom AbstractResource implementation that grabs an object
from a WebService. Getting information about the object (metadata and
ID) is one call, actually getting the content stream by ID is another.
In
org.apache.wicket.request.resource.AbstractResource#newResourceResponse
I get the metadata, and set the response properties accordingly (time of
last modification, content type, etc.).
Then, in the anonymous
org.apache.wicket.request.resource.AbstractResource.WriteCallback#writeData()
I make the call to retrieve the content. And here's the problem:
What can I do at this stage to inform the user a problem occured, i.e.
by forwarding to an error page (using IExceptionMapper)? Here, the
metadata is still present (database), whereas the file content
(filesystem) is gone for whatever reason.
Thanks for your help,
bye
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Error handling in IResource implementations?
Posted by Stefan Renz <s....@efonds.com>.
Hi,
Martin Grigorov wrote:
> Hi,
>
> I think moving the second WS call out of #writeData() would be the simpler
> solution.
This works as expected, and is pretty straigthforward, so I'll stick
with this suggestion rather than choosing the second option below.
The solution then looks like this: get the metadata, set the response
attributes (such an content type, disposition, last modification
timestamp) from it. Then, fetch the binary data into a
ByteArrayOutputStream. If no exception, set a WriteCallback
implementation on the response, which copies the content of the
ByteArrayOutputStream to the response's output stream. In case of an
exception, set a corresponding error code on the response and set no
write callback.
>
> The other solution that I see is to
> override org.apache.wicket.request.resource.AbstractResource#flushResponseAfterHeaders()
> with an empty impl and throw
> org.apache.wicket.request.http.flow.AbortWithHttpErrorCodeException when
> there is an error in #writeData().
> The same is to use
> RequestCycle.get().scheduleRequestHandlerAfterCurrent(...)
The solution above seems to be simpler and more straightforward, so I'll
skip this suggestions.
>
>
> Martin Grigorov
> Wicket Training and Consulting
>
Thanks, Martin.
Bye
Stefan
>
> On Thu, Apr 3, 2014 at 10:41 AM, Stefan Renz <s....@efonds.com> wrote:
>
>> Hi Martin,
>>
>> yes, I figured that, and some errors (such as can't find metadata) I
>> handle accordingly. However, I get the actual binary content in my
>> #writeData()-implementation, and this is where I don't know how to
>> handle errors.
>>
>> I guess I could get the content beforehand and treat errors like above,
>> if there is no clean way of reporting errors inside #writeData()...
>>
>> Thanks, Martin.
>> Bye
>> Stefan
>>
>>
>> Martin Grigorov wrote:
>>> Hi,
>>>
>>> It is not mandatory to make the second call to the WS in #writeData().
>>> You can make it earlier, as with the metadata.
>>> This way you can use response#setError() if needed.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>>
>>>
>>> On Wed, Apr 2, 2014 at 3:25 PM, Stefan Renz <s....@efonds.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm currently at loss: what would be the correct way signalling that a
>>>> IResource implementation encountered an error?
>>>>
>>>> Here's the case:
>>>>
>>>> I have a custom AbstractResource implementation that grabs an object
>>>> from a WebService. Getting information about the object (metadata and
>>>> ID) is one call, actually getting the content stream by ID is another.
>>>>
>>>> In
>>>> org.apache.wicket.request.resource.AbstractResource#newResourceResponse
>>>> I get the metadata, and set the response properties accordingly (time of
>>>> last modification, content type, etc.).
>>>>
>>>> Then, in the anonymous
>>>>
>>>>
>> org.apache.wicket.request.resource.AbstractResource.WriteCallback#writeData()
>>>> I make the call to retrieve the content. And here's the problem:
>>>>
>>>> What can I do at this stage to inform the user a problem occured, i.e.
>>>> by forwarding to an error page (using IExceptionMapper)? Here, the
>>>> metadata is still present (database), whereas the file content
>>>> (filesystem) is gone for whatever reason.
>>>>
>>>> Thanks for your help,
>>>> bye
>>>> Stefan
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>> --
>> im Auftrag der eFonds Solutions AG, +49-89-579494-3417
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
--
im Auftrag der eFonds Solutions AG, +49-89-579494-3417
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Error handling in IResource implementations?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I think moving the second WS call out of #writeData() would be the simpler
solution.
The other solution that I see is to
override org.apache.wicket.request.resource.AbstractResource#flushResponseAfterHeaders()
with an empty impl and throw
org.apache.wicket.request.http.flow.AbortWithHttpErrorCodeException when
there is an error in #writeData().
The same is to use
RequestCycle.get().scheduleRequestHandlerAfterCurrent(...)
Martin Grigorov
Wicket Training and Consulting
On Thu, Apr 3, 2014 at 10:41 AM, Stefan Renz <s....@efonds.com> wrote:
> Hi Martin,
>
> yes, I figured that, and some errors (such as can't find metadata) I
> handle accordingly. However, I get the actual binary content in my
> #writeData()-implementation, and this is where I don't know how to
> handle errors.
>
> I guess I could get the content beforehand and treat errors like above,
> if there is no clean way of reporting errors inside #writeData()...
>
> Thanks, Martin.
> Bye
> Stefan
>
>
> Martin Grigorov wrote:
> > Hi,
> >
> > It is not mandatory to make the second call to the WS in #writeData().
> > You can make it earlier, as with the metadata.
> > This way you can use response#setError() if needed.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> >
> >
> > On Wed, Apr 2, 2014 at 3:25 PM, Stefan Renz <s....@efonds.com> wrote:
> >
> >> Hi,
> >>
> >> I'm currently at loss: what would be the correct way signalling that a
> >> IResource implementation encountered an error?
> >>
> >> Here's the case:
> >>
> >> I have a custom AbstractResource implementation that grabs an object
> >> from a WebService. Getting information about the object (metadata and
> >> ID) is one call, actually getting the content stream by ID is another.
> >>
> >> In
> >> org.apache.wicket.request.resource.AbstractResource#newResourceResponse
> >> I get the metadata, and set the response properties accordingly (time of
> >> last modification, content type, etc.).
> >>
> >> Then, in the anonymous
> >>
> >>
> org.apache.wicket.request.resource.AbstractResource.WriteCallback#writeData()
> >> I make the call to retrieve the content. And here's the problem:
> >>
> >> What can I do at this stage to inform the user a problem occured, i.e.
> >> by forwarding to an error page (using IExceptionMapper)? Here, the
> >> metadata is still present (database), whereas the file content
> >> (filesystem) is gone for whatever reason.
> >>
> >> Thanks for your help,
> >> bye
> >> Stefan
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> --
> im Auftrag der eFonds Solutions AG, +49-89-579494-3417
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Error handling in IResource implementations?
Posted by Stefan Renz <s....@efonds.com>.
Hi Martin,
yes, I figured that, and some errors (such as can't find metadata) I
handle accordingly. However, I get the actual binary content in my
#writeData()-implementation, and this is where I don't know how to
handle errors.
I guess I could get the content beforehand and treat errors like above,
if there is no clean way of reporting errors inside #writeData()...
Thanks, Martin.
Bye
Stefan
Martin Grigorov wrote:
> Hi,
>
> It is not mandatory to make the second call to the WS in #writeData().
> You can make it earlier, as with the metadata.
> This way you can use response#setError() if needed.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Apr 2, 2014 at 3:25 PM, Stefan Renz <s....@efonds.com> wrote:
>
>> Hi,
>>
>> I'm currently at loss: what would be the correct way signalling that a
>> IResource implementation encountered an error?
>>
>> Here's the case:
>>
>> I have a custom AbstractResource implementation that grabs an object
>> from a WebService. Getting information about the object (metadata and
>> ID) is one call, actually getting the content stream by ID is another.
>>
>> In
>> org.apache.wicket.request.resource.AbstractResource#newResourceResponse
>> I get the metadata, and set the response properties accordingly (time of
>> last modification, content type, etc.).
>>
>> Then, in the anonymous
>>
>> org.apache.wicket.request.resource.AbstractResource.WriteCallback#writeData()
>> I make the call to retrieve the content. And here's the problem:
>>
>> What can I do at this stage to inform the user a problem occured, i.e.
>> by forwarding to an error page (using IExceptionMapper)? Here, the
>> metadata is still present (database), whereas the file content
>> (filesystem) is gone for whatever reason.
>>
>> Thanks for your help,
>> bye
>> Stefan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
--
im Auftrag der eFonds Solutions AG, +49-89-579494-3417
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Error handling in IResource implementations?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
It is not mandatory to make the second call to the WS in #writeData().
You can make it earlier, as with the metadata.
This way you can use response#setError() if needed.
Martin Grigorov
Wicket Training and Consulting
On Wed, Apr 2, 2014 at 3:25 PM, Stefan Renz <s....@efonds.com> wrote:
> Hi,
>
> I'm currently at loss: what would be the correct way signalling that a
> IResource implementation encountered an error?
>
> Here's the case:
>
> I have a custom AbstractResource implementation that grabs an object
> from a WebService. Getting information about the object (metadata and
> ID) is one call, actually getting the content stream by ID is another.
>
> In
> org.apache.wicket.request.resource.AbstractResource#newResourceResponse
> I get the metadata, and set the response properties accordingly (time of
> last modification, content type, etc.).
>
> Then, in the anonymous
>
> org.apache.wicket.request.resource.AbstractResource.WriteCallback#writeData()
> I make the call to retrieve the content. And here's the problem:
>
> What can I do at this stage to inform the user a problem occured, i.e.
> by forwarding to an error page (using IExceptionMapper)? Here, the
> metadata is still present (database), whereas the file content
> (filesystem) is gone for whatever reason.
>
> Thanks for your help,
> bye
> Stefan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>