Jerome Dochez wrote:
> Lance J. Andersen wrote:
>
>>
>>
>> Ludovic Champenois wrote:
>>
>>> Jerome Dochez wrote:
>>>
>>>> Thanks Lloyd, This would be a good start.
>>>>
>>>> However I think this is not enough. I have to agree with the Cay
>>>> Horstman that seeing a stack trace is not very friendly and has
>>>> very little added value to the developer (unless generated by the
>>>> developer code which we can detect in all cases).
>>>>
>>>> I remember Ludo already complaining (...:)...) about that in 8.1
>>>> and Ken Saks pointed out that it was an important debugging tool
>>>> for us when developer forward issues or application server
>>>> potential bugs. I agree this is a valid concern.
>>>>
>>>> So I am wondering if we should not change our logging strategy to
>>>> log exceptions in a separate file (exceptions.log). In the
>>>> server.log, we should only see the exception.getMessage() with a ID
>>>> that could be used to cross reference in the exceptions.log. That
>>>> way, usual developers would not have to dig through exceptions logs
>>>> in the server.log to get an idea of what went wrong. When
>>>> necessary, we can use the exceptions.log when debugging problems.
>>>>
>>>> KenS, Jan, Ludo (impact on Netbeans ?), others... feedback ?
>>>>
>>>> Jerome
>>>>
>>>
>>> I like the idea of a dual log file, one for the normal user, and one
>>> for getting the extra stack trace(s), when needed (which by the way
>>> might still not be enough, given my experience on previous log files
>>> where sometimes, even the module owner or module guru cannot not
>>> figure out what's going on without asking further questions to
>>> customers :-))
>>> The perf impact is not a big deal since it happens only we we have
>>> runtime error.
>>> A little impact on netbeans, but as well as admin gui log viewer and
>>> log rotation strategy (do we rotate the 2 files at the same time?)
>>> No big deal I guess...
>>
>>
>> Why not just set a property or a verbosity level so that you only see
>> the the stackTrace when you want to? having another log file to have
>> to roll over and adminstrate (for the appserver administrator) seems
>> possibly more work than the potential bang for the buck?
>
> the issue with the property is that it is an after the facts
> operation. When you run your app, have an exception. then you would
> need to change the verbosity level, and then try to reproduce the
> problem, this may not be possible or difficult. Some folks may not
> even know how to change the verbosity level of our logging, and I have
> to say that without Netbeans, it's not that easy...
I know and I thought about that before i sent the email. There are
tradeoffs to consider and unless you always assume that the user is
examining the log files through some type of gui based tool, having to
open multiple files and search is a bit of a drag as well.
I think the real issue is to be as precise in the initial error that is
generated and avoid displaying bloat in the primary log file (even if
you do go to a multiple log scenario).
>>
>>
>>>
>>> Ludo
>>
>>
>