Here is what I was able to gather XCGLogger currently does * Different log levels for different types of logs (errors/debug/warning) * Rolling file logger so the number of files on a disk don’t get huge and the size of the logs stays small * Separate files for different types of logs. Sync/Browser/Keychahin
If I'm missing any other functionality we expect please let me know. I think Cocoalumberjack is the best solution + Swift / Carthage support + Well supported and very widely used + Very extensible + Supports rolling file logging out of the box - Not written completely in swift - documentation for swift is sparse ClearnRoomLogger + Written completely in swift - Not as widely used. We might start discovering bugs once we implement it - Developer community is smaller - documentation sparse - Harder to separate log levels into different files There are some slight differences between XCGLogger and CocoaLumberJack. In XCGLogger we create multiple instances of the logger for different types of logs (Browser/Sync/Keychain) etc. But in LumberJack we only have ONE logger instance and many different Log levels. So creating an error for Sync would require it being its own log level. There would be a SyncError,BrowserError and a regular Error. Let me know what you guys think and we can move from there. I'm fine with replacing the logging myself. (Might have to bust out the regex) Obligatory http://xkcd.com/208/ On Wed, Apr 13, 2016 at 9:08 AM, Farhan Patel <fpa...@mozilla.com> wrote: > I can look into both the libraries and share my findings here. I dont > think I have enough context yet to make the call on which one to switch to > so I will leave that up to the rest of the team. > > On Tue, Apr 12, 2016 at 10:42 AM, Stefan Arentz <sare...@mozilla.com> > wrote: > >> >> > On Apr 12, 2016, at 10:35 AM, Farhan Patel <fpa...@mozilla.com> wrote: >> > >> > I agree with Emily replacing our logging with a new framework might >> introduce its own set of problems. >> >> But the underlying problems with XCGLogger are more difficult to fix: it >> uses NSFileHandle#write to write to its log files. And NSFileHandle#write >> has not been properly wrapped by Apple with Swift compatible exception >> handling. On top of that, NSFileHandle is documented to raise exceptions if >> the file handle goes bad. For whatever reason, and as a result we crash. >> >> XCGLogger is faulty by design. We crash when it cannot log. >> >> I think we should still swap it out with a logging framework that better >> handles these failures. Or maybe better, does not depend on NSFileHandle at >> all and instead for example uses iOS’ ASL library to do logging. >> >> I think it may be worth it to look at the code of the two suggested >> alternatives and see if they are more robust. >> >> S. >> >> >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
