• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Log4Cocoa
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Log4Cocoa


  • Subject: Re: Log4Cocoa
  • From: Timothy Reaves <email@hidden>
  • Date: Sat, 24 Jan 2009 11:53:49 -0500


On Jan 23, 2009, at 3:33 PM, Joel Norvell wrote:

This doesn't answer the original question, but I believe it is pertinent to this thread.

It is also possible to log from within Xcode, something I hadn't realized until I saw the video of an excellent talk Joar Wingfors gave at a Silicon Valley Cocoaheads.

Joel

http://video.google.com/videoplay?docid=3598467380866353869

http://theocacao.com/downloads/DebuggingWithXcode.pdf




Thanks for the links. Logging for development debugging is only one small use case for logging though. And the people using Apple's log service only see one additional use case, which is for logging on the developers machine. But these two use cases aren't that important to software that is sold for use. If a developer (individual or team) has software that they have to support, and users report defects, that is where things like NSLog & ASL fail, and a true logging framework is needed.

When trying to figure out a customers issue, you can have them manually open the system log file and search for specific info. You also can't have the app always logging debug level detail, as this not only consumes large amounts of disk space and impacts performance greatly, but is almost useless to the developer (I've seen apps produce logs in the gigabyte size).

Frameworks like Log4Cocoa are a means of doing just about anything you want with logging. In production software, it's valuable because it allows a compiled application to change it'[s logging behavior with either a restart (if using a config file), or by a few settings in the a preferences window and no need to restart. The app then can produce a log file with very detailed logging around the suspected classes/ subsystems that are of interest, while leaving the rest of the system only logging at an error level (for example). The app can then even send that log file to he developer automatically, or the user can compress it an e-mail it. These kinds of things are not possible with NSLog or ASL, without building a log framework around them.

If the software you are writing is for in-house use, or your own use, then perhaps NSLog & ASL are what's best for you. And perhaps for most Mac software that is the case. But there are development projects out there that simply need more.
_______________________________________________


Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Log4Cocoa (From: Joel Norvell <email@hidden>)

  • Prev by Date: Re: Targetting Tiger
  • Next by Date: Re: Forcing allocation of a subclass
  • Previous by thread: Re: Log4Cocoa
  • Next by thread: [WORKAROUND] Re: Cursor updates - bug or programmer ignorance?
  • Index(es):
    • Date
    • Thread