Cocoalumberjack: Using CocoaLumberJackSwift without includes and module specific debug level

[diederich]

Not an issue, but I wasn't sure where else to post it. Feel free to close :-)

--

@ole just implemented something interesting for one of our modules over at @cocologics:

The idea is to have a Logging.swift file per module. This overwrites the default logging command like DDLogError and forwards them to CocoaLumberjack. The advantage:

• no need to CocoaLumberjackSwift imports in all files
• easy customising of the log level per module

-> https://gist.github.com/diederich/6b6becf75719886d1ec2e4d67a38c28d

If this is interesting, maybe we could put it in the wiki/sample?

[sushichop]

Thanks for your proposal.
I am not sure, but may documentation be suitable for the explanation?

Then, just a short discussion.
I have another similar way, CocoaLumberjackObjCWrapper.swift that is also very similar with CocoaLumberjack.swift.

Using this wrapper, you only need to use import CocoaLumberjack at any time.
And you do not need to useimport CocoaLumberjackSwift whether with CocoaPods or Carthage.
I often use it in Swift based project as same as Objective-C based one.

I think that proposal, suggestion, discussion and etc. are always welcomed, because here is GitHub.
Thanks for your proposal and feel free to discuss each other!😄

[lolgear]

@diederich @sushichop
I suppose that this feature can be extended further. It could provide logs filtering per module.

[diederich]

@lolgear - absolutely! I think that's a great idea. LogLevel/Filtering, maybe something with the os_log stuff? (which I still haven't looked into properly, but it's moving higher and higher on the todo list :-))

[lolgear]

@diederich I would like to bring this implementation to ObjectiveC also. Heh, I don't have time (but I have motivation) for rewriting hundreds of DDLog statements :)
So, default filtering per framework would be nice.

But there is one statement.
Suppose, that you would like to filter some logs from the module. In ObjectiveC you could filter messages by Object-Prefix in case of global namespace. For that you just add filter in your app and be lucky. Who do you do this in swift? Setting global something is not what you are looking for.
Maybe the real problem is the shared-nature of CocoaLumberjack setup?

However, two features would be nice.
First, add bundle-lookup for filtering ( each class has its bundle even in ObjectiveC ).
Second, add filtering.swift default file ( but here we must consider configuration and settings of the instance inside ).

[diederich]

Hey @lolgear,

I think what I had in mind for this (and I was only thinking swift TBH), was to just drop in the linked Logging.swift file, and in the best case this should be it. No rewriting of log statements, just drop&play :-)

So the log level per module can be configured in here:
https://gist.github.com/diederich/6b6becf75719886d1ec2e4d67a38c28d#file-logging-swift-L20

And I think we can also hook into the "subsystem" support of os_log by using the contexts provided in Lumberjack.
I think by passing the "context" along into the os_log methods here:
https://github.com/CocoaLumberjack/CocoaLumberjack/blob/master/Classes/DDOSLogger.m#L59
we might already get some nice support. The subsystems in os_log seems to be Strings instead of the Ints that the context has, but maybe proving the DDOSLogger class with something that can map those ints to strings solves that?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions.

[bpoplauschi]

Guys, let's decide on the actions to take here. @ole's idea is very nice, but can we add it somewhere?
@CocoaLumberjack/collaborators

[diederich]

I'm basically using this approach in all my projects now. Copy the file into a framework which uses CocoaLumberjack and I don't need includes anymore. I haven't done any further investigation about log-levels / scopes per module though...

[bpoplauschi]

Then maybe just adding a documentation entry about it?

[lolgear]

@bpoplauschi
I am not sure this "the idea" should be added.

The main feature is "wrapping" all calls of external library by exploiting Swift target-namespace.
The best point is to create LoggingService which could handle some events from application lifecycle.

However, this discussion can last long, so, I suggest you to navigate to another issue about CocoaLumberjack lifecycle.
The main question is why CocoaLumberjack has invocations of objc/runtime and why it can't handle stuff in more "user safe" mode without shared and class methods?

[diederich]

Thanks for you comment @lolgear. I think the main feature of this is:

• not having to include CocoaLumberjack in each source file, but only have this file once per module.
• allow for module wide configurations of logging / prefix / log-level etc

I haven't looked into the second part at all until now, but the first is so convenient I'm using this 'pattern' now in most of my frameworks.

I agree that an issue is probably not the right thing for this content. Let's close this for now. I'll report back once I looked more into this besides the convenience of includes.