I use Monolog 1.10 as logging tool.
Along with the date and loglevel I need to persist class and method names from which logging method has been called. Seems that I need to configure formatter. But I could not find any examples for such case.
How do I do this?
Monolog has Introspection Processor. We need just add it to our logger or handler - and all needed information will be logged
https://github.com/Seldaek/monolog/blob/master/src/Monolog/Processor/IntrospectionProcessor.php
Related
I have a service defined in services.yaml that has a calls entry since I don't want to specify my dependencies in it's constructor so I use setters.
Now I am trying to point the security.firewalls.main.guard.authenticators.0 configuration entry to it, but if I try to reference it like this: '#App\Service\Authentication\Guard' I get The service "security.authentication.provider.guard.main" has a dependency on a non-existent service "#App\Service\Authentication\Guard".
If I specify just the name of the class as per Symfony's docs: App\Service\Authentication\Guard then there's no exception and the guard works, however the calls section of my definition is completely ignored and thus my setters don't work.
My best guess would be that the security module uses it's own service locator that's somehow disconnected and ignores definitions in services.yaml, which is probably why you won't find examples of the above config entry using simple service names rather than canonical class names.
I am trying to implement a custom Symfony bundle and inside my service I need to pass the global symfony logger that I defined in my Symfony App and it is an instance of Psr\Log\LoggerInterface. The problem is that when I am configuring my services with the ContainerBuilder the logger service is not yet initialised.
In my bundle service I am passing the Logger like this:
public function __construct(LoggerInterface $logger, $argument1, $argument2);
The two arguments are being delivered from the packages/my_custom_bundle_config.yaml file. However I can't pass the App's Logger as a parameter even in the above config file.
Any help or any comments will be much appreciated.
Thank you.
There are three things you need to do:
Create a compiler pass. You can search for them in the documentation. Basically, they allow you to modify the container just before it is compiled, when all definitions and aliases have been registered.
Is really good practice in your configuration class to define a service id for the logger, in case your users want to use a different implementation. In your extension class, you should pass that reference as an argument.
Usually all bundles that rely on psr interfaces register an alias of it to a default implementation. They are usually called logger.default or something similar. You can search in monolog bundle extension class for the definitions they use or use the interface, that will have an alias.
I'm trying to set up a testing suite for my Symfony 3 app, and I'm wondering what the correct method for setting up the test database is. I've found this article, but it doesn't actually explain how to add fixtures programmatically.
Also, it appears their example sets up the test database for every test.
Is there a way to setup a test database which is automatically loaded with fixtures when phpunit is run? The official documentation is kind of sparse
Symfony has different environments you can operate in. By default those are prod(production), dev(developement) and test. Although it may not be exactly what you want, you can configure different config, paramaters, routes and so on for each environment. Read the official documentation for more info but yeah, you can setup your parameters.yml file for test mode which could have a different database configured there.
https://symfony.com/doc/current/configuration/environments.html
If you extend your TestCases from KernelTestCase or WebTestCase, basically extend from \PHPUnit_Framework_TestCase you have methods like setUpBeforeClass() or setUp() which are run by PhpUnit before your test/test cases is/are executed.
Use this to e.g. create your fixtures, load your SQL file or whatever and however you might require your prerequisites for your tests.
I'm trying to build a specific error "stack" for my applications. I have a small module system in place, and I want to be able to add the error handlers from the module to the current error stack. However, there are some error handlers that I want to be checked before the module error handlers, but those need registered before the module error handlers, in case there is in error in the module's bootstrapping process.
The stack I'm going for looks like:
Logging Error handlers
Alert Error handlers (firing off emails to developers if necessary)
Module error handlers
Application error handlers
Default fallbacks
When the application starts, the logging, alert, and default fallbacks are placed on the stack immediately. I want to be able to stub the application error handlers in next, and then the module error handlers once the module is determined and loaded. As far as I can see, error handlers can only be placed on the top or bottom of the stack; not inserted in the middle.
Is there a way to insert into the error handler? If not, is there a way to register a different error handling class (one extended from the built-in one)?
In the interest of time, I managed to come up with a solution that works. It's not what I was really looking for, but I'll share it in case anyone else needs to do something like this.
My approach was to extend the Illuminate\Foundation\Application and override the registerExceptionProvider() method to register my own ExceptionServiceProvider. This provider extends from Illuminate\Exception\ExceptionServiceProvider and overrides the registerHandler() method. In there, I register my Handler in the same manner the original provider registers the default handler.
I added insert* versions of each of the error methods provided by the default Application and an insertError method to the Handler that does the actual insert into the error handler stack. Lastly, I altered the start.php file to create my Application instead of the default one.
As I mentioned, I don't really like this approach; I feel it's more heavy lifting that what should have to be done. It seems like Laravel should have a better way to extend the actual error handler, or at least an interface to order the error handlers being registered more precisely.
I'm quite new to laravel 4, and I want to log to files inside storage/logs when a user attempt to connect to my application.
I have added inside routes.php this:
Event::listen('auth.attempt', function() {
echo 'attempting to logging in';
});
I know that Laravel 4 includes monolog which is a PHP logging framework , but I dont know if it's the easiest way to log here.
I can declare a filter that I add to the before of my route, but this solution isn't very elegant.
Go with monolog, it is widely used and a great library. It can be configured in many different ways and implements the PSR-3 logging interface. See http://laravel.com/docs/errors#logging and http://github.com/Seldaek/monolog‎.
Most simple logging command:
Log::info('This is some useful information.');
If you want to directly interface with monolog:
$monolog = Log::getMonolog();
By using the standard laravel facade for monolog it will automatically log it into a new file with the current date.
Regarding your initial query about the easiest method, I feel compelled to say this is the easiest one.