Skip to content

Debugging for non lite apps

amenonsen edited this page Jul 24, 2011 · 9 revisions

Debugging

In order to follow the examples below, create a mojolicious app "test", via

mojolicious generate app test

Several folders will be created, including

/test/log
/test/lib/test # where the controllers are located

Switch to the app folder

cd test

You can now start the Morbo development server

morbo script/test
Server available at http://*:3000

Enter

http://localhost:3000/

in your browser and a "Welcome to the Mojolicious Web Framework!" message should appear on your screen!

Log files

The /test/log folder now contrains a development.log file which provides information on recent requests.

Tue Oct 12 19:25:45 2010 info Mojo::Server::Daemon:341 [1132]: Server listening (http://*:3000)
Tue Oct 12 19:25:50 2010 debug Mojolicious:26 [1132]: Your secret passphrase needs to be changed!!!
Tue Oct 12 19:25:50 2010 debug Mojolicious:159 [1132]: GET /example/welcome (Mozilla/4.0 ...
Tue Oct 12 19:25:50 2010 debug MojoX::Dispatcher::Routes:145 [1132]: Dispatching test::Example->welcome.
Tue Oct 12 19:25:50 2010 debug Mojolicious::Plugin::RequestTimer:35 [1132]: 200 OK (0.037585s, 26.606/s).

For example, you can see that our GET request /example/welcome has been dispatched to the controller class "test::Example" and method "welcome". You can also see that the request took 0.037585s, and that this would allow 26.606 requests per second.

Enter or reload

http://localhost:3000/

again and you will notice that the request time reduces dramatically as all modules have been compiled already.

Now enter

http://localhost:3000/nonexistant

and our log shows that the controller class

test::Nonexistant

does not exist and that a template

"/nonexistant/welcome.html.ep"

could also not be found.

Debugging Routes

When writing your Mojolicious App, you sometimes request a URL that should provide content, but instead deliveres a 404 not found error.

In case that there is no debug message in the log file (e.g. missing template), it's most likely that none of the routes actually matched.

To get a list of routes, just switch to your app folder,

cd test

and enter

perl script/test routes

The output might look like this:

/:controller/:action/:id   (?-xism:^(?:/([^\/\.]+)?)?(?:/([^\/\.]+)?)?(?:/([^\/\.]+)?)?)

Having installed more routes, output might look like this:

/admin/users/new        (?-xism:^/admin/users/new)
/admin/users/:id        (?-xism:^/admin/users/([^\/\.]+))
/admin/users/:id/edit   (?-xism:^/admin/users/([^\/\.]+)/edit)
/admin/users            (?-xism:^/admin/users)
/admin/users            (?-xism:^/admin/users)
/admin/users/:id        (?-xism:^/admin/users/([^\/\.]+))
/admin/users/:id        (?-xism:^/admin/users/([^\/\.]+))

Get log output displayed in your console

In order to get the log messages displayed in your console, just delete the /test/log folder.

So first stop the server via CRTL+C, delete the log folder, start the server again and enter

http://localhost:3000/

and debug log messages should immediately appear in the console window.

STDERR Redirection to an Application's Log

The warn function is a simple and easy way to output errors from anywhere in an application. In many cases, it may be the only option (a library won't have access to the Mojo::Log object $self->app->log). Unfortunately, these error messages won't appear in the Mojo application's log file. In some cases they may entirely disappear (FastCGI)!

Solution: Create a SIG{__WARN__} handle to redirecting warnings to the logger object. This particular implementation wraps the logger in such a way that the caller information is preserved correctly. All warned messages will be properly annotated with their calling information and emitted to the log file at the 'warn' level.

package MyApp;
sub startup {
    my $self = shift;
    $SIG{'__WARN__'} = sub {
        unshift @_, $self->app->log;
        goto $self->app->log->can('warn');
    };
    # Rest of startup...
}
Clone this wiki locally