mirror of
https://github.com/Seldaek/monolog.git
synced 2026-04-26 08:05:53 +03:00
[GH-ISSUE #255] Better library support/use cases #83
Labels
No labels
Bug
Documentation
Feature
Needs Work
Support
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/monolog#83
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zampettim on GitHub (Oct 25, 2013).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/255
One big issue is that Monolog doesn't really support being used as the logging implementation for libraries and other code that is intended to be primarily used in other applications.
Basically, I should be able to instantiate a Logger instance with just a name (which I understand is technically allowed now), and then at runtime, have a way to specify the handlers and processors that should be applied to that channel, ideally through configuration via a file or API. This is similar to how other logging implementations work, and provides for a high degree of flexibility.
@stof commented on GitHub (Oct 25, 2013):
@zampettim libraries should rely on the PSR-3 to receive a logger IMO, not instantiate their own monolog instance themselves.
@Seldaek commented on GitHub (Oct 25, 2013):
I agree there should be an easier way to instantiate a config (kind of what we have in the Symfony MonologBundle but in monolog itself so you could give it an array of config and get a configured logger back), and perhaps a few pre-made configurations in a very easy to use factory class for common configs. That said I never had time to work on it, and as @stof said I agree this shouldn't be used by libraries but rather apps that aren't built on a framework providing monolog natively.
@sagikazarmark commented on GitHub (Oct 26, 2013):
I was also thinking about something like this. My actual problem was that my framework independent composer package needed config, but every fw have its own config implementation, but non-fw apps do not. So some sort of configuration loader and class autoloader could solve this problem.
I think about it as a config and class autoloader, which can instantiate any class with given params, and probably call an init function, etc. This could run at the beggining or could be run by the developer. The main point is that it is a general interface for getting instantiated objects, which can be used in every context.
Of course writting the wrapper for fws is the best idea some times.
This could be a package independent thing solving a main downside of framework independent coding and giving solution for many packages, not only monolog.
I've already started to think about this, but I did not make any progress. Maybe others also have this problem solved, which could become a general solution.
What do you think? Sorry, if I did not express myself well.
@stof commented on GitHub (Oct 28, 2013):
For the class autoloader, it is not needed IMO. the recommended installation way is composer, which takes care of autoloading.
And for people not wanting to use composer for some reason, they can get a PSR-0 autoloader library (there is a bunch of them on packagist) and configure it. It will not be more work than requiring an autoloader for each library and registering it.
@sagikazarmark commented on GitHub (Oct 28, 2013):
Well, when I say autoloader, I mean "instantiater", but that sounds weird.
Again: I think about it as a general interface for instantiating classes (based on a config file or whatever) when not using a framework.
@stof commented on GitHub (Oct 28, 2013):
@sagikazarmark creating a generic way means reimplementing a component doing the same thing than the configuration layer of a framework. It is out of the scope of monolog. And if it is a separate library, it will simply be considered as yet another framework and so will not solve the issue. We are exactly in this case: http://xkcd.com/927/
@rantonmattei commented on GitHub (Jun 26, 2015):
Just came across this issue. It's been a problem for us at The Orchard since we are big Monolog users. I've worked on a project called monolog-cascade. It is open source as well. This should solve most of your issues. You can configure a bunch of loggers and handlers using a single config file (Yaml or JSON).
First version got ou a few days ago. Try it out and let me know what you think. And feel free to contribute if you like it!
Thanks
@keywan-ghadami-oxid commented on GitHub (Jul 28, 2016):
@rantonmattei i had the same issue but was not aware of your solution so i did nearly the same thing https://github.com/keywan-ghadami-oxid/monolog-configuration. Looking forward to compare implementations.