Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@rabidaudio
Copy link
Contributor

Since @justinpawela you were so quick in helping me out, I figured I'd share my solution from #11. This adds a new file endpoint that functions the same as LXRotatingFileEndpoint with two differences:

  • The file can be rotated manually, either with .rotate() or with a posted notification to LXFileEndpointCauseRotationNotification
  • Providing a non-positive maxFileSizeKiB will cause it to never rotate based on file size, so that it is only rotated manually

I totally understand if you don't want to support another endpoint, and I'm quite happy to use my fork if you decide not to mainline it.

@justinpawela
Copy link
Contributor

Hi @rabidaudio
Thanks for your PR!

I appreciate your contribution and your ideas in general about improving Rotating File Endpoints.

I want to look at this further. To that end, I have created a new branch and merged your changes into it.
https://github.com/logkit/logkit/tree/manual-rotating-endpoint

In specific I'd like to give some thought as to whether these changes can be merged into the standard LXRotatingFileEndpoint instead of creating a separate class. They are so close to each other.

And from a broader perspective, I've been thinking about whether there is a better way to structure the File Endpoint family in general. There are some things I'm not happy with.

I'm going to leave this open for now, in case you have further thoughts, which I welcome.

@justinpawela
Copy link
Contributor

Hi @rabidaudio,

Yesterday I integrated your PR into LogKit's master branch, with a few changes. After your updates to LXRotatingFileEndpoint's structure, it was pretty straightforward to merge LXManuallyRotatingFileEndpoint into it. Here's what changed:

  • LXRotatingFileEndpoint now accepts nil as a max file size. If nil is supplied, the Endpoint will never rotate automatically -- only when manually triggered.
  • I did not include the Notification that triggers a rotation, and instead just included the public rotate() method. It seemed too weak an association for an Endpoint instance to listen for any "please rotate now" notification, instead of a message aimed specifically at that instance. What if a dev had two different rotating Endpoints in their configuration? It seems safer to use a specific instance's rotate() method (if less convenient -- see below).

I welcome further thoughts on these changes.

However, not all is lost if one is tied to the "please rotate now" notification flow. It would be very easy to subclass the LXRotatingFileEndpoint and get that back with very little code. Something like:

let LXFileEndpointRequestRotationNotification: String = "info.logkit.endpoint.fileEndpoint.requestRotation"

class NoteRotatingFileEndpoint: LXRotatingFileEndpoint {

    deinit { NSNotificationCenter.defaultCenter().removeObserver(self) }

    convenience init?(numberOfFiles: UInt = 5, minimumPriorityLevel: LXPriorityLevel = .All, dateFormatter: LXDateFormatter = LXDateFormatter.standardFormatter(), entryFormatter: LXEntryFormatter = LXEntryFormatter.standardFormatter(), listenForNoteFrom sender: AnyObject? = nil) {
        self.init(numberOfFiles: numberOfFiles, maxFileSizeKiB: nil, minimumPriorityLevel: minimumPriorityLevel, dateFormatter: dateFormatter, entryFormatter: entryFormatter)
        NSNotificationCenter.defaultCenter().addObserverForName(LXFileEndpointRequestRotationNotification, object: sender, queue: nil, usingBlock: { [unowned self] _ in self.rotate() })
    }
}

@rabidaudio
Copy link
Contributor Author

Sounds good. Your thoughts on the rotate notification make a lot of sense. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants