Allow custom options to wrap-file

[pepijndevos]

I ran into trouble with a web app where index.md was served as an index file. I discovered two things.

First, the options for file-response are hard-coded into wrap-file. Second, find-index-file accepts any file -- regardless of its extension -- as an index file.

The second might be desired behavior, but the first is definitely a problem.

My solution is backwards compatible, and allows people to (re)set options

[pepijndevos]

I resorted to using Jetty's own file server for more control, figured out :configurator can be used to do this, only to find out the next action after running configurator is to set handlers, so that my brand new handler gets overwritten. It's only one word changed, but allows me to actually add my own handlers.

[weavejester]

I'll add the fix to wrap-file in after 0.3.0 is released, which should be this weekend if all goes according to plan.

Some observations:

1. Commit messages should be descriptive and written from a neutral point of view. They shouldn't be a place to vent frustrations (no matter how irritating they may be). I'll remove the "I don't want the f*cking :index-files?" part from your commit message when I merge.

2. Try to keep each pull request to a specific fix. The wrap-file patch seems an obvious fix, but I'm increasingly wary about changing the Jetty adapter. Adapters have a well-defined and simple interface. By adding additional bits of functionality, we degrade the usefulness of that interface, because people will start to rely on pieces of functionality not covered in the adapter specification.

Note that the Jetty adapter is not supposed to be a wrapper for the Jetty web server. That should be handled by a separate project ("cljetty", perhaps?).

[pepijndevos]

Thanks.

1. I'm sorry about the commit message. Note to self: Do not commit when tired and/or frustrated.

2. I'll send separate pull requests for separate features next time. I do think changing set to add is a useful thing to do. A feature for configuring Jetty already exists, this change serves just to remove the unexpected behavior that is caused by resetting the handlers just after running the configurator. The same effect can be achieved by switching the order of the statements, which shows in my opinion that no extra behavior is added.

Also note that using Jetty directly for serving files might increase performance. I do realize relying on these options makes it harder to switch to another adapter.

[weavejester]

I've just taken a look at the Jetty adapter, and it turns out I'm a little behind the times. The :configurator option is new to me, but makes sense and doesn't violate the adapter specification. The options of the adapter are the one place where server-specific code is allowed.

So in that context, your patch for changing setHandler to addHandler is, I think, a sound idea. I don't think it crosses the line into an implementation detail, though it might brush it :)