Smalltalk › Gemtalk › GLASS

Issue 191: getting object log continuation for rest api calls

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

NorbertHartl

Issue 191: getting object log continuation for rest api calls

I saw this one has been fixed. Unfortunately it does not work in my case. To be honest I'm totally confused about the possible setup alternatives. There are a lot of error handlers, adaptors and places where things can be configured.

I have done everything that is mentioned in the Issue 190 comments (preparing exceptionfilter and having the newest packages). But I can't get something in the object log. And I wasn't able to get any debugger either. I tried to start a fcgi instance from the gemtools but a raised exception didn't give me a debugger in gemtools. Could you please give a short recipe about what have to be set exactly to be able to get a continuation in the object log when the execption is raised inside a request handler or request filter?

thanks,

Norbert

Dale Henrichs

Re: Issue 191: getting object log continuation for rest api calls

On 02/09/2011 10:40 AM, Norbert Hartl wrote:
> I saw this one has been fixed. Unfortunately it does not work in my
> case. To be honest I'm totally confused about the possible setup
> alternatives. There are a lot of error handlers, adaptors and places
> where things can be configured.

Yes, and I don't have all of this memorized either....

>
> I have done everything that is mentioned in the Issue 190 comments
> (preparing exceptionfilter and having the newest packages). But I
> can't get something in the object log. And I wasn't able to get any
> debugger either. I tried to start a fcgi instance from the gemtools
> but a raised exception didn't give me a debugger in gemtools. Could
> you please give a short recipe about what have to be set exactly to
> be able to get a continuation in the object log when the execption is
> raised inside a request handler or request filter?

If you are not getting a debugger when you run the server in gemtools,
then I am suspicious that there must be an exception handler somewhere
that is masking the error or something similar....

So I'm inclined to find out why that is happening and we can do that by
setting a number of breakpoints to track down who might be handling the
error. If you run:

WABasicDevelopment setBreakPoints.

before running:

WAFastCGIAdaptor startOn: 9001.

You'll set breakpoints in all of the usual suspects for error handlers
outside the seaside framework ... all of the places that end up handling
internal errors ...

The error that you generate should be trapped by one of these
breakpoints and you'll have the stack in a debugger and we can look at
the stack and see why the Issue191 instructions don't work...

Dale

NorbertHartl

Re: Issue 191: getting object log continuation for rest api calls

Dale,

On 09.02.2011, at 20:25, Dale Henrichs wrote:

> On 02/09/2011 10:40 AM, Norbert Hartl wrote:
>> I saw this one has been fixed. Unfortunately it does not work in my
>> case. To be honest I'm totally confused about the possible setup
>> alternatives. There are a lot of error handlers, adaptors and places
>> where things can be configured.
>
> Yes, and I don't have all of this memorized either....
>
>>
>> I have done everything that is mentioned in the Issue 190 comments
>> (preparing exceptionfilter and having the newest packages). But I
>> can't get something in the object log. And I wasn't able to get any
>> debugger either. I tried to start a fcgi instance from the gemtools
>> but a raised exception didn't give me a debugger in gemtools. Could
>> you please give a short recipe about what have to be set exactly to
>> be able to get a continuation in the object log when the execption is
>> raised inside a request handler or request filter?
>
> If you are not getting a debugger when you run the server in gemtools, then I am suspicious that there must be an exception handler somewhere that is masking the error or something similar....
>
> So I'm inclined to find out why that is happening and we can do that by setting a number of breakpoints to track down who might be handling the error. If you run:
>
> WABasicDevelopment setBreakPoints.
>
> before running:
>
> WAFastCGIAdaptor startOn: 9001.
>
> You'll set breakpoints in all of the usual suspects for error handlers outside the seaside framework ... all of the places that end up handling internal errors ...
>
> The error that you generate should be trapped by one of these breakpoints and you'll have the stack in a debugger and we can look at the stack and see why the Issue191 instructions don't work...
>

I seem to have it working now but I don't know what I do different :) Anyway now I have in the initialize of my rest handlerr

initialize
| filter |
super initialize.
filter := WAExceptionFilter new.
filter configuration addParent: WAAdmin applicationExceptionHandlingDefaults.
(WAAdmin register: self at: 'rest-api')
addFilterFirst: filter;
addFilter: (WAAuthenticationFilter new
realm: 'rest test fest';
yourself)

and in the start script of the stone I've put

run
WAAdmin applicationExceptionHandlingDefaults
at: #exceptionHandler
put: WAGemStoneProductionErrorHandler.
%

I thought I have done this before, too. But maybe everything was just to confusing for me. Thanks for the help.

Norbert