Lance J. Andersen wrote:
>
>
> 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.
in theory, they would almost never have to do that. Support and us only
should need that information.
>
> 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).
that's true, it is the best thing to do but unfortunately changing the
way we log, chain and report exceptions would be a far greater
undertaking than the 2 logs.
>
>>>
>>>
>>>>
>>>> Ludo
>>>
>>>
>>