starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-26 08:05:53 +03:00

[GH-ISSUE #365] Make handlers serializable #125

New issue

Closed

opened 2026-03-04 02:12:23 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 02:12:23 +03:00

Owner

Originally created by @deceze on GitHub (May 12, 2014).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/365

It would be really helpful if handlers would be serializable by default. I'm often injecting loggers as dependencies into objects, and then may cache those objects. Upon retrieving the objects from cache, the logger is typically broken because its resources of course fail serialization/unserialization (e.g. the default StreamHandler).

The fix is easy, in the case of StreamHandler this is all that's needed:

public function __wakeup() {
    $this->close();
}

Rather hacky, but that's all that's required; the rest of the class is already behaving as needed.

Please consider adding proper __sleep/__wakeup compatibility to all handlers by default.

Originally created by @deceze on GitHub (May 12, 2014). Original GitHub issue: https://github.com/Seldaek/monolog/issues/365 It would be really helpful if handlers would be serializable by default. I'm often injecting loggers as dependencies into objects, and then may cache those objects. Upon retrieving the objects from cache, the logger is typically broken because its resources of course fail serialization/unserialization (e.g. the default `StreamHandler`). The fix is easy, in the case of `StreamHandler` this is all that's needed: ``` public function __wakeup() { $this->close(); } ``` Rather hacky, but that's all that's required; the rest of the class is already behaving as needed. Please consider adding proper `__sleep`/`__wakeup` compatibility to all handlers by default.

kerem

2026-03-04 02:12:23 +03:00

closed this issue
added the
Feature
label

kerem commented

2026-03-04 02:12:25 +03:00

Author

Owner

@staabm commented on GitHub (May 12, 2014):

wouldn't it be more apropriate that you exclude the field from serialization and create a new instance after wakeup?

having the stream handler itself serializable doesn't make sense IMO.

@staabm commented on GitHub (May 12, 2014): wouldn't it be more apropriate that you exclude the field from serialization and create a new instance after wakeup? having the stream handler itself serializable doesn't make sense IMO.

kerem commented

2026-03-04 02:12:25 +03:00

Author

Owner

@deceze commented on GitHub (May 12, 2014):

That means I'd have to force the object itself to worry about instantiating and configuring a logger, when right now I'm simply requiring a LoggerInterface in its constructor. I don't want my objects to have to worry about instantiating and configuring a dependency they currently simply receive; I also don't want to have to do this for every single one of my cacheable objects when the solution can neatly be implemented in the logger itself.

@deceze commented on GitHub (May 12, 2014): That means I'd have to force the object itself to worry about instantiating and configuring a logger, when right now I'm simply requiring a `LoggerInterface` in its constructor. I don't want my objects to have to worry about instantiating and configuring a dependency they currently simply receive; I also don't want to have to do this for every single one of my cacheable objects when the solution can neatly be implemented in the logger itself.

kerem commented

2026-03-04 02:12:25 +03:00

Author

Owner

@stof commented on GitHub (May 12, 2014):

@deceze forcing handlers to be serializable is a bad idea IMO, because it restricts too much what can be used to implement it (they can only depend on serializable services).
Thus, if you serialize 2 cacheable objects and unserialize them, you will get 2 new logger instances (with their own file handles open on the same file, which is likely to cause some weird issues).
you should better rethink the way you handle caching (data object should be what you cache, not services, while logging is more expected to be used in service objects)

@stof commented on GitHub (May 12, 2014): @deceze forcing handlers to be serializable is a bad idea IMO, because it restricts too much what can be used to implement it (they can only depend on serializable services). Thus, if you serialize 2 cacheable objects and unserialize them, you will get 2 new logger instances (with their own file handles open on the same file, which is likely to cause some weird issues). you should better rethink the way you handle caching (data object should be what you cache, not services, while logging is more expected to be used in service objects)

kerem commented

2026-03-04 02:12:25 +03:00

Author

Owner

@Seldaek commented on GitHub (May 19, 2014):

I agree that we can't force every handler to be serializable if it's not possible reasonably, for example a stream handler that receives an open stream can not possibly reopen it after wakeup. But I'm fine with adding support for serialization where it's harmless, if you like to send a PR that'd be great.

@Seldaek commented on GitHub (May 19, 2014): I agree that we can't force every handler to be serializable if it's not possible reasonably, for example a stream handler that receives an open stream can not possibly reopen it after wakeup. But I'm fine with adding support for serialization where it's harmless, if you like to send a PR that'd be great.

kerem commented

2026-03-04 02:12:25 +03:00

Author

Owner

@deceze commented on GitHub (May 19, 2014):

Sounds good, I'll look into it when I have a moment. Loggers which can't be serialised should probably complain when somebody attempts to serialise them as well.

@deceze commented on GitHub (May 19, 2014): Sounds good, I'll look into it when I have a moment. Loggers which can't be serialised should probably complain when somebody attempts to serialise them as well.

kerem referenced this issue

2026-03-04 03:03:09 +03:00

[PR #125] [MERGED] Add microsecond precision to CubeHandler log time #948