Finding out why liberator comes to a certain result can be tedious.
Instead of sprinkling trace statements over your code, liberator can simply
trace the request execution.
Tracing with liberator.dev/wrap-trace
To enable request tracing wrap the request handler in
wrap-trace accepts to optional arguments
Enabled response header “X-Liberator-Trace”
Add link rel to UI
If enabled, liberator adds for every decision and handler invocation a
response header “X-Liberator-Trace”. This is especially helpful when
debugging with curl or other console tools.
Trace user interface
Sometimes, the full response header is not easily available or you
want to “look back” later. Liberator provides a web resource at
/x-liberator/requests where a list of recent requests can be
found. The trace for a single request can be selected there.
For the trace-ui to be accessible it is mandatory that the wrapped
handler is invoked for trace ui resource. The simplest way to make
this is to add wrap-trace to the stack of ring middleware outside the
Linking to a request’s trace
In any case a link header will be returned with rel=x-liberator-trace.
It points to the request on the trace ui. The current id can also be
retrieved programmatically using (current-trace-url).
Runtime access to the current trace id
The current trace id is bound to liberator.dev/*current-id*.
You can generate a link to the ui console for the current request
and embed a HTML-snippet of a hovering link.
function | description
current-trace-url | generates a URL pointing to the trace ui for the current request
include-trace-panel | generates an HTML snippet with a link to the trace ui
css-url | generates a URL to CSS for the above
Add trace information in your code
The function liberator.core/log! adds entries to liberators
trace log. This can have some advantages over printing to the console,
because the logged statement is available at the correct position in
The entry will show up in the trace and is marked as :trace. You can
use any keyword you want, liberator uses :decision and :handler for
it’s own purposes.
Debugging and testing in the REPL
In clojure, debugging mostly occurs at the REPL, and Liberator makes
this especially easy because every resource is a ring handler function
and can be tested as such:
In the REPL we can test the resource:
Let’s test content negotiation and add some tracing:
If you happen to run the application and have wrapped it in wrap-trace
then the request from the repl are also available at the trace ui.