This is a blanket issue to refactor this middleware to be more efficient, more rusty, and use better conventions.

In particular this middleware unnecessarily uses String and Vec in many places, which leads to unnecessary clones of data and is likely to be pretty slow.

#97 added support for iron 0.5.x, but this hasn't been released yet. Could this be released soon?

When using the logging middleware, all requests fail with the following log messages:

2016-03-28T21:44:08+07:00 ERROR iron::iron - Error handling:
Request {
    url: Url { scheme: "http", host: Domain("localhost"), port: 3000, path: ["12345"], username: None, password: None, query: None, fragment: None }
    method: Get
    remote_addr: V6([::1]:59540)
    local_addr: V6([::1]:3000)
}
Error was: Error { repr: Custom(Custom { kind: Other, error: NotSupported }) }

The NotSupported seems to come from term indicating that the used terminal doesn't support the requested term capabilities.

The relevant source code used:

let mut chain = Chain::new(router);

let (logger_before, logger_after) = Logger::new(None);
chain.link_before(logger_before);
chain.link_after(logger_after);

Chaning the format string to not use colors solves the problem.

Rust: rustc 1.9.0-nightly (d5a91e695 2016-03-26)
Iron: 0.3.0
Logger: 0.0.3
OS: Windows 7 SP 1
Shell: zsh
Env: msys2
I also used ConEmu, if that's relevant.

See other repos for an example.

[dependencies]
iron = "0.4.0"
router = "0.2.0"
logger = "0.1.0"

extern crate iron;
extern crate router;
extern crate logger;

use iron::prelude::*;
use iron::status;
use router::Router;
use logger::Logger;

fn handler(req: &mut Request) -> IronResult<Response> {
    Ok(Response::with((status::Ok, "Hello world!")))
}

fn main() {

    let mut router = Router::new();
    router.get("/", handler);
    router.get("/:query", handler);

    let mut chain = Chain::new(router);

    let (logger_before, logger_after) = Logger::new(None);
    chain.link_before(logger_before);
    chain.link_after(logger_after);

    Iron::new(chain).http("localhost:3000").unwrap();

}

I got a 500 server error if I link logger to chain.

It would be great to get the a new version of logger up on crates.io now that it's building again.

This seems like a debugging tool. Should it be used when Rust is not in a debugging mode?

What about using debug! instead of println! to only print when we are trying to debug?

Then again, this might not be helpful, as a user wants this data, but it would be nice if they could turn it on and off through an environment variable instead of having to recompile their code.

Useful for when the request occurred at with respect to some timezone.

With the switch to log crate, we need to update README (and maybe some other places) to inform users on how to set it up.

adding:

[dependencies.logger]

git = "https://github.com/iron/logger.git"

to my cargo.toml, and running this code:

extern crate iron;
extern crate router;
extern crate logger;

use iron::prelude::*;
use iron::status;
use router::Router;
use logger::Logger;

fn main() {
    let (logger_before, logger_after) = Logger::new(None);

    let mut router = Router::new();
    router.get("/", handler);
    router.get("/generate", generate_handler);

    let mut chain = Chain::new(router);
    chain.link_before(logger_before);
    chain.link_after(logger_after);

    Iron::new(chain).http("localhost:3000").unwrap();
}

fn handler(_: &mut Request) -> IronResult<Response> {
    Ok(Response::with((status::Ok, "OK")))
}

fn generate_handler(_: &mut Request) -> IronResult<Response> {
    Ok(Response::with((status::Ok)))
}

produces the following error:

src/main.rs:22:11: 22:22 error: the trait `for<'r, 'r, 'r> core::ops::Fn<(&'r mut iron::request::Request<'r, 'r>,)>` is not implemented for the type `logger::Logger` [E0277]
src/main.rs:22     chain.link_before(logger_before);
                         ^~~~~~~~~~~
src/main.rs:22:11: 22:22 help: run `rustc --explain E0277` to see a detailed explanation
src/main.rs:23:11: 23:21 error: the trait `for<'r, 'r, 'r> core::ops::Fn<(&'r mut iron::request::Request<'r, 'r>, iron::response::Response)>` is not implemented for the type `logger::Logger` [E0277]
src/main.rs:23     chain.link_after(logger_after);

changing it to:

[dependencies]
iron = "*"
router = "*"
logger = "*"

removes the error. what is the difference? why does the way of building listed in the readme break?

Dying on
unresolved import iron::errors::FileError.
and
unresolved import std::vec::MoveItems.

Wasn't able to figure out a fix (my first day with Rust!), but I did notice from the docs that std::vec no longer includes MoveItems in nightly (http://doc.rust-lang.org/std/vec/), which is consistent with the second error message.

When asking Iron to listen on localhost:0, the kernel assigns an unused port number, and getaddrinfo resolves localhost to 127.0.0.1. The actual address can be displayed via format!("{}", listening.socket) where listening is an instance of the type returned by Iron::http and friends.

Example output from racerd

The first line is my own logging, and the second line is from this crate.

racerd listening at 127.0.0.1:54663
GET http://localhost:0/ping -> 200 OK (0.086167 ms)

Discussion

I'm not familiar with all members of the Request type, but it seems that Iron would need to pass in either the address or a reference to the listening server in order to access this information.

We need to cut 0.2.0. This is a breaking change because of #92.

The latest term breaks the build, probably would be good to set some semantic versions to depend on

This middleware is currently out of sync with the latest version of iron (0.5.1).

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 logger Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @AerialX
• @adamreeve
• @brycefisher
• @cmr
• @duelinmarkers
• @lyddonb
• @maxrp
• @mcreinhard
• @mfeckie
• @reem
• @theptrk
• @viraptor
• @zmbush
• @zzmp

I don't know whether this is a bug in iron/logger or iron/router, but when the router has a 404 or 301 response, it returns an Err, and logger doesn't log anything. Either router should return an Ok with the 401 or 301 status, or logger should handle logging when there's an error. I'm thinking it's the latter.

Example app demonstrating this problem:

extern crate iron;
extern crate logger;
extern crate router;

use iron::prelude::*;
use iron::status;

use logger::Logger;
use router::Router;

fn handle_hello(_ : &mut Request) -> IronResult<Response> {
    Ok(Response::with((status::Ok, "Hello world")))
}

fn main() {
    let (logger_before, logger_after) = Logger::new(None);

    let mut router = Router::new();

    router.get("/hello", handle_hello);

    let mut chain = Chain::new(router);

    chain.link_before(logger_before);
    chain.link_after(logger_after);

    Iron::new(chain).http("0.0.0.0:8080").unwrap();
}

Documentation link provided in readme is broken

Maybe related to #80 .

src/consumer/http.rs:20:11: 20:22 error: the trait bound `for<'r, 'r, 'r> logger::Logger: std::ops::Fn<(&'r mut iron::Request<'r, 'r>,)>` is not satisfied [E0277]
src/consumer/http.rs:20     chain.link_before(logger_before);
                                  ^~~~~~~~~~~
src/consumer/http.rs:20:11: 20:22 help: run `rustc --explain E0277` to see a detailed explanation
src/consumer/http.rs:20:11: 20:22 note: required because of the requirements on the impl of `iron::BeforeMiddleware` for `logger::Logger`
src/consumer/http.rs:20:11: 20:22 error: the trait bound `for<'r, 'r, 'r> logger::Logger: std::ops::FnOnce<(&'r mut iron::Request<'r, 'r>,)>` is not satisfied [E0277]
src/consumer/http.rs:20     chain.link_before(logger_before);
                                  ^~~~~~~~~~~
src/consumer/http.rs:20:11: 20:22 help: run `rustc --explain E0277` to see a detailed explanation
src/consumer/http.rs:20:11: 20:22 note: required because of the requirements on the impl of `iron::BeforeMiddleware` for `logger::Logger`
src/consumer/http.rs:21:11: 21:21 error: the trait bound `for<'r, 'r, 'r> logger::Logger: std::ops::Fn<(&'r mut iron::Request<'r, 'r>, iron::Response)>` is not satisfied [E0277]
src/consumer/http.rs:21     chain.link_after(logger_after);
                                  ^~~~~~~~~~
src/consumer/http.rs:21:11: 21:21 help: run `rustc --explain E0277` to see a detailed explanation
src/consumer/http.rs:21:11: 21:21 note: required because of the requirements on the impl of `iron::AfterMiddleware` for `logger::Logger`
src/consumer/http.rs:21:11: 21:21 error: the trait bound `for<'r, 'r, 'r> logger::Logger: std::ops::FnOnce<(&'r mut iron::Request<'r, 'r>, iron::Response)>` is not satisfied [E0277]
src/consumer/http.rs:21     chain.link_after(logger_after);
                                  ^~~~~~~~~~
src/consumer/http.rs:21:11: 21:21 help: run `rustc --explain E0277` to see a detailed explanation
src/consumer/http.rs:21:11: 21:21 note: required because of the requirements on the impl of `iron::AfterMiddleware` for `logger::Logger`

Built with Rust Nightly 1.12, Iron 0.3.

Logger should just log without colouring output when stdout isn't a tty. Somewhat related to issue #5.

@reem Travis failed for #34 (merged, was for rustup over HTTPS).

https://travis-ci.org/iron/logger/builds/32297997

Beta is almost out, now would be a good time to update.

Add an alternate constructor like ::from_writer that will take a writer other than stdout to allow for arbitrary logging.

Thank you for such a handy middleware stack!

When I use the logger in a Heroku app, it prints:

2014-09-18T16:20:53.267041+00:00 heroku[router]: at=info method=GET path="/" host=radiant-cliffs-2720.herokuapp.com request_id=fe3b8e00-e4fc-446a-8441-8deba5340382 fwd="<DELETED>" dyno=web.1 connect=1ms service=6ms status=200 bytes=77
2014-09-18T16:20:53.265665+00:00 app[web.1]: Logger could not open terminal
2014-09-18T16:20:53.642865+00:00 app[web.1]: Logger could not open terminal

As far as I know, the standard output of a Heroku application is piped off to a logging daemon somewhere, and it isn't attached to a real terminal. To reproduce, see this blog post, which explains how to deploy iron apps to Heroku.

I believe that supporting output to terminal does not belong in standard logger.
It consist half of logging codebase, breaks docker, provides no benefits whatsoever in most production scenarios, its very easy to cause hard to debug issues, and the work has already been done:
https://github.com/alexander-irbis/logger/commit/fe6dab0f81e77224e553fbcb1179f3003f86f007

so it would be nice if someone would just merge it back into master.

If I take a basic Iron app with logger 0.0.3:

fn main() {
    // Set up very basic logging to the console.
    env_logger::init();

    // Declare our REST API using Rustless, which is much tidier than using
    // bare Iron APIs.
    let api = rustless::Api::build(|api| {
        // ... SNIPPED  ...
    });
    let app = rustless::Application::new(api);

    // Put our app into a middleware chain so we can attach the logger,
    // etc.
    let mut chain = Chain::new(app);

    // Call the logger middleware at the beginning and end of our request
    // chain.
    let (logger_before, logger_after) = Logger::new(None);
    chain.link_before(logger_before);
    chain.link_after(logger_after);

    // Run our web server.
    println!("Listening on 0.0.0.0:3000");
    match Iron::new(chain).http("0.0.0.0:3000") {
        Ok(_) => {},
        Err(ref e) => println!("Could not start server: {}", e),
    }
}

…and run it under Docker as:

docker run --rm myimage

I get:

ERROR:iron::iron: Error handling:
Request {
    url: Url { scheme: "http", host: Ipv4(172.17.0.11), port: 3000, path: ["health"], username: None, password: None, query: None, fragment: None }
    method: Get
    remote_addr: V4(172.17.42.1:35256)
    local_addr: V4(0.0.0.0:3000)
}
Error was: CouldNotOpenTerminal

Running docker run --rm myimage env does not show the TERM variable as being set. But it looks like it's trying to open a terminal anyway, instead of just logging to stdout.

There's probably a way to reproduce this without docker; I'm investigating further.

It should eventually be refactored to speed development time for those unfamiliar with the middleware.

(Low priority)

/Users/vesakaihlavirta/.multirust/toolchains/stable/cargo/registry/src/github.com-0a35038f75765ae4/logger-0.0.3/src/lib.rs:80:57: 80:75 note: in this expansion of try! (defined in <std macros>)
<std macros>:6:1: 6:32 help: run `rustc --explain E0277` to see a detailed explanation
<std macros>:6:1: 6:32 note: required by `core::convert::From::from`
<std macros>:6:1: 6:32 error: the trait `core::convert::From<term::Error>` is not implemented for the type `std::io::error::Error` [E0277]
<std macros>:6 $ crate:: convert:: From:: from ( err ) ) } } )

I suppose #72 could be related