Smalltalk › Frameworks & Tools › Seaside › Seaside General

About error handling

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Sven Van Caekenberghe-2

About error handling

Hi,

I have my own WAHtmlHaltAndErrorHandler subclass that overrides #handleDefault: to log the error in various ways as well as email it. I also include some custom session information for context.

However, I would also like to print all details of the original HTTP request (WARequest) to better map it to upstream requests, but I can't find how to access that. Any ideas ?

Thx,

Sven

PS: I am using ZnZincServerAdaptor on Pharo 7
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: About error handling

On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe <[hidden email]> wrote:

Hi,

I have my own WAHtmlHaltAndErrorHandler subclass that overrides #handleDefault: to log the error in various ways as well as email it. I also include some custom session information for context.

However, I would also like to print all details of the original HTTP request (WARequest) to better map it to upstream requests, but I can't find how to access that. Any ideas ?

Hi Sven,

I think I did not understand your question...but...just in case, can't you do a "WACurrentRequestContext value" inside the #ha ndleDefault: and get the WARequest? Then you can print whatever you want...

Best,

Mariano Martinez Peck

Email: [hidden email]

Twitter: @MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sven Van Caekenberghe-2

Re: About error handling

> On 25 Nov 2019, at 16:50, Mariano Martinez Peck <[hidden email]> wrote:
>
>
>
> On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe <[hidden email]> wrote:
> Hi,
>
> I have my own WAHtmlHaltAndErrorHandler subclass that overrides #handleDefault: to log the error in various ways as well as email it. I also include some custom session information for context.
>
> However, I would also like to print all details of the original HTTP request (WARequest) to better map it to upstream requests, but I can't find how to access that. Any ideas ?
>
>
> Hi Sven,
>
> I think I did not understand your question...but...just in case, can't you do a "WACurrentRequestContext value" inside the #ha ndleDefault: and get the WARequest? Then you can print whatever you want...

Ah yes, now that you told me it is obvious. Thx.

> Best,
>
> --
> Mariano Martinez Peck
> Email: [hidden email]
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck
> Blog: https://marianopeck.wordpress.com/
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: About error handling

On Mon, Nov 25, 2019 at 12:59 PM Sven Van Caekenberghe <[hidden email]> wrote:

> On 25 Nov 2019, at 16:50, Mariano Martinez Peck <[hidden email]> wrote:
>
>
>
> On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe <[hidden email]> wrote:
> Hi,
>
> I have my own WAHtmlHaltAndErrorHandler subclass that overrides #handleDefault: to log the error in various ways as well as email it. I also include some custom session information for context.
>
> However, I would also like to print all details of the original HTTP request (WARequest) to better map it to upstream requests, but I can't find how to access that. Any ideas ?
>
>
> Hi Sven,
>
> I think I did not understand your question...but...just in case, can't you do a "WACurrentRequestContext value" inside the #ha ndleDefault: and get the WARequest? Then you can print whatever you want...

Ah yes, now that you told me it is obvious. Thx.

My pleasure :)

BTW, in the VA Smalltalk version of Seaside, in response to a customer need, I adapted our Seaside adaptor to store the native request (SST in our case, Zinc in yours) in the request context. That way, it was very easy to add logging and be able to map from Seaside requests to native requests. Looks like long ago it was like that: https://github.com/SeasideSt/Seaside/issues/305 but not any longer.

What I did was something like this:

!WASstRequestConverter publicMethods !

contextFor: aNativeRequest
"Answer a request context for aNativeRequest."

^(super contextFor: aNativeRequest)
propertyAt: #nativeRequest put: aNativeRequest;
yourself! !

Let me know if you want more details and I can share everything you want.

Best,

Mariano Martinez Peck

Email: [hidden email]

Twitter: @MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: About error handling

In reply to this post by Mariano Martinez Peck

Isn’t that just `self requestContext request` ?

Johan

On 25 Nov 2019, at 16:50, Mariano Martinez Peck <[hidden email]> wrote:

On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe <[hidden email]> wrote:
Hi,

I have my own WAHtmlHaltAndErrorHandler subclass that overrides #handleDefault: to log the error in various ways as well as email it. I also include some custom session information for context.

However, I would also like to print all details of the original HTTP request (WARequest) to better map it to upstream requests, but I can't find how to access that. Any ideas ?

Hi Sven,

I think I did not understand your question...but...just in case, can't you do a "WACurrentRequestContext value" inside the #ha ndleDefault: and get the WARequest? Then you can print whatever you want...

Best,

--
Mariano Martinez Peck
Email: [hidden email]
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck
Blog: https://marianopeck.wordpress.com/
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Esteban A. Maringolo

Re: About error handling

On Mon, Nov 25, 2019 at 1:19 PM Johan Brichau <[hidden email]> wrote:
>
> Isn’t that just `self requestContext request` ?

Yes, it is the same, with the added fact that the WAErrorHandler has
the request context as an instvar instead of resolving it via a
dynamic variable.

Regards!

Esteban A. Maringolo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sven Van Caekenberghe-2

Re: About error handling

> On 25 Nov 2019, at 17:28, Esteban Maringolo <[hidden email]> wrote:
>
> On Mon, Nov 25, 2019 at 1:19 PM Johan Brichau <[hidden email]> wrote:
>>
>> Isn’t that just `self requestContext request` ?

Yes ;-)

> Yes, it is the same, with the added fact that the WAErrorHandler has
> the request context as an instvar instead of resolving it via a
> dynamic variable.

There is also the interesting #dontDestroy ...

> Regards!
>
> Esteban A. Maringolo
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall

Re: About error handling

In reply to this post by Mariano Martinez Peck

On Mon, Nov 25, 2019 at 5:09 PM Mariano Martinez Peck
<[hidden email]> wrote:
> BTW, in the VA Smalltalk version of Seaside, in response to a customer need, I adapted our Seaside adaptor to store the native request (SST in our case, Zinc in yours) in the request context. That way, it was very easy to add logging and be able to map from Seaside requests to native requests. Looks like long ago it was like that: https://github.com/SeasideSt/Seaside/issues/305 but not any longer.

I had the same need for the Seaside Servlet Bridge, I wonder whether
we should bring the method back.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside