Clojure runs on the JVM. If there is one thing the JVM has to much of it's application servers. Jetty(non blocking), Glassfish for enterprise apps. Tomcat, websphere, weblogic, apache geronimo...etc. Why not just conform to those standards and make the clojure applications deploy to them. What is the advantage of this server over jetty?

This is a wrapper around the Java Netty server: http://www.jboss.org/netty

Why the downvotes? This is a decent question. All other things being equal, having a "standard" Java webapp is preferable to a server-specific app.

Of course, the correct answer is (IIRC) that standard Java web servers don't support the NIO asynchronous request paradigm - the standard Java servlet spec is thread-per-request.

But not everyone knows that.

The 3.0 servlet spec fortunately includes support for async processing, so you can give your thread back mid-handling the request; No more thread-per-request required.

Jetty has also supported their own async handling extension for quite some time now (but they're moving to the 3.0 standard). I've used it to build 'Comet' servers before, and it does the trick.

We use Jetty's ability to do both sync and async HTTP in RingoJS. I've written about it here: http://hns.github.com/2010/07/02/versatility.html

I think Netty is great if you want fine grained control over each aspect of your network stack and/or ultimate performance. But having a full featured web server that does sync and async equally well is a value that shouldn't be dismissed either.

Cool.

In that case, someone should write a Clojure library that utilizes the 3.0 standard. That'd be even cooler.

I imagine the idea is to have it better integrated with the Clojure language, especially Clojures concurrency mechanisms.

I see that that Aleph implements Ring, so you can use it with a bunch of existing Clojure web frameworks, such as Compojure.

While Java world doesn't lack appserver infrastructure (though they're not as good as they're marketed but that is another point), it lacks web programming paradigms which wouldn't be a PITA.

What PITA features does the java app server have?

Many kinds; Java itself, and lack of stable dynamic redeploying without bringing the services down, despite being marketed otherwise. I'm talking about real life production configurations, not about what's possible on Joe R. Hacker's machine under special circumstances. Of course it's not the fault of appservers themselves but rather of JVM architecture esp. classloaders. Still the RL situation is that today's complicated stacks of libraries, dependency injection frameworks and code using it can make life of admins and change management folks miserable.

Add to it a monstrosity from the deepest ends of Moria: maven (hint: google for 'maven sucks') and you have the world lots of people want to forget about.

Today's Clojure webservers being usually wrappers around existing solutions won't cure all these wounds, but at least it's a step in a refreshing direction.

What does a build tool (Maven) really have to do with using any of the app servers?

You could say nothing, technically, but that wouldn't reflect real life situations and existing "best" practices.

It's usually used to build deployments, CI, autodeploying and stuff. In fact for many operations tasks Maven cannot be decoupled, because it's used for almost everything. When using Makefile, to copy a compiled archive to a destination you'd use shell commands; in Maven you cannot leave the Java world so you pick up a plugin to do the same, usually of poor quality. This way you introduce even more code, which is hardly manageable at some point, and contrary to the maxim "every line of code not written is a correct one".

Short answer:

Pick a job in operations or change management at a large Java shop, then you'll know.

This still has nothing to do with using a Java app server. You could be using other tools to handle those tasks just as easily. Even if you have developers that love Maven and use it to build and package their applications, this certainly doesn't mean you need to use the tool for other tasks in which you find it to be a poor fit.

I wish you having this freedom you're talking about on all your projects.

The RL is that in most shops usage of appserver & Maven is tighly coupled to the high ends of pain, and you don't decide the next big thing that could replace even parts of this sick marriage. Of course maybe you're talking about a situation when you decide about the whole infrastructure but then there are big chances you wouldn't choose Java in the first place. So please make a distinction if you're talking about theoretical "who could do what" or practical "what's already going on this planet" or even more practical "I'm gonna conquer the world with the new X and I really have freedom to choose it" :]

I think that the Java language is, for some people. If you choose some language like Clojure it usually means you don't want to deal with Java or any of its derivatives. At least this holds for me.

Moreover I'm looking at Clojure mainly for web development, so this is really something I'm happy they are addressing.

Java is "verbose" and I'm real happy to see other languages target the JVM. It will make it very easy to convince "corporate america" to adopt them in the future. In no way is Java a PITA. It's got it's quirks but it remains one of the best platforms for building anything. The community support is great and it has years of development libraries and experience for you to leverage.

While I spared my comments on Java on this thread, I was specially referring to the fact that Java's classloaders are braindead. You'll know some years in operations; as a dev you can be hidden from its ugly influence for quite a time.

I've implemented servlet-based solutions with Clojure on top of Tomcat (e.g. at http://elev.at), and although it wasn't too bad, there is still cruft to deal with. This looks like an interesting option indeed.

Why not? CPU and RAM are cheap enough and we even would see NIO2 implementation some day.