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
On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe sven@stfx.eu 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,
On 25 Nov 2019, at 16:50, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe sven@stfx.eu 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: marianopeck@gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck Blog: https://marianopeck.wordpress.com/ _______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Mon, Nov 25, 2019 at 12:59 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 25 Nov 2019, at 16:50, Mariano Martinez Peck marianopeck@gmail.com
wrote:
On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe sven@stfx.eu
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,
On Mon, Nov 25, 2019 at 5:09 PM Mariano Martinez Peck marianopeck@gmail.com 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
Isn’t that just `self requestContext request` ?
Johan
On 25 Nov 2019, at 16:50, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Mon, Nov 25, 2019 at 12:39 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> 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: marianopeck@gmail.com mailto:marianopeck@gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/ Blog: https://marianopeck.wordpress.com/ https://marianopeck.wordpress.com/_______________________________________________ seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Mon, Nov 25, 2019 at 1:19 PM Johan Brichau johan@inceptive.be 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
On 25 Nov 2019, at 17:28, Esteban Maringolo emaringolo@gmail.com wrote:
On Mon, Nov 25, 2019 at 1:19 PM Johan Brichau johan@inceptive.be 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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside@lists.squeakfoundation.org