About error handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

About error handling

Sven Van Caekenberghe-2
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
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Mariano Martinez Peck


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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Sven Van Caekenberghe-2


> 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
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Mariano Martinez Peck


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

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Johan Brichau-2
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
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Esteban A. Maringolo
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
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Sven Van Caekenberghe-2


> 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
Reply | Threaded
Open this post in threaded view
|

Re: About error handling

Philippe Marschall
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