On 2005-01-24 19:39:06 Richard Sitze wrote:
>1. It's not indiscriminate logging. That's why we call it tracing, and >that's why the logging impls [such as Log4J] allow us to turn it on/off. > >2. The fact of the matter is that in many corporate operational >environments, production-level [that's *not* development] systems are >guarded carefully. Installing additional components [debuggers], never >MIND running them, is not an option. When one fails to duplicate a >problem in a development environment, customers *expect* us to be able to >glean information from productions system that can demonstrate the >problems.
I was not suggesting the use of debuggers at all, not one bit. When you attempt to log everything, then logging can be abstractly viewed as a persistent debugger.
>3. Are your pokes/jabs at me for being an IBM employee necessary? I've >spent 2/5 of my career at IBM. When I exceed 1/2, you come on back and >I'll listen to you more seriously.
No jabs at you personally. I am an ex-IBM employee. Some of the IBM products we struggled with at the time generated so much log output that I still vividly recall the frustration. The lesson from that experience:
Too much logging can as bad as the absence of logging.
>My goal is to be an advocate of the technologies and techniques I see that
>can benefit the community. I *will* argue for what I believe to be in the
>best interest of the development community. And when the decisions are
>made, I will support them. That's the stance I take with my employer:
>defending open-source decisions that I may not agree with.
>
>That I am tainted by my experience, environment, etc., is a fact of life..
>and part of the process. It's the strength of open source development.
>It's why we have developers from many backgrounds make up our community.
>Why do you want to make that a negative?
Having personally experienced the negative effects of the approach advocated by IBM, I am trying to warn to community. However, you and IBM have every right to advocate your point of view. I sincerely apologize if my comments came across as disparaging IBM or you personally, that was not my intention.
>I claim that entry/exit at class/method is reasonable.. along with other
>best-practices I've described in other notes.
>
>It's easily identifiable, it's convenient, it's easy to automate [AspectJ
>or other tooling], and more importantly it's *useful*. Should it stop
>there? No. Is it a reasonable, and easily understood, starting point for
>instrumenting code with logging? Yes.
You can go overboard with logging. Method entry/exit logs happens to be convenient and easy way of generating tons of garbage. :-)
>I've personally been in situations where the errors could not be >duplicated "in the lab". Differences in hardware, and in the particular >case in my mind, even to the extent of different revisions of firmware on >otherwise similar systems introduce variable that are not always easily >comprehended.
Instead of instrument every copy of your application, you can instrument a special version to identify the problem on that special environment. Once the problem is identified, you move on. There is no need to pollute every copy of your application.
While I agree with everything that you have said about "indiscriminate logging," I think you are missing Richard's point here. In some environments, this sort of ad hoc change is not allowed or cannot be executed quickly enough to help resolve a production problem. The relevant information simply needs to be available in the logs.
I agree with you that entry/exit logging and other forms of "automatic" instrumentation can create more problems than they solve. The challenge is to get the right info into the logs without, as you put it, "polluting" them with junk that strains the infrastructure and makes it hard to find the relevant info. Sadly, success here depends much less on what the logging framework provides than what the developer is thinking when deciding when and what to log.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
