GAE supports the JVM now. If anyone has an interest, it would be a really cool project to get Fan up and running on AppEngine. One the key things that is needed is to do an implementation of the web APIs which binds to the Java servlet API. That happens to be a really useful pod we need regardless. Andy originally wrote one using native methods, but with Java FFI should be much easier.

I work for Sun on the glassfish webtier team so I have my hands on/in those APIs. :) Maybe I could give it a shot. What would that look like? Where would I start?

There is an existing webServlet pod you can take a look at it. But I'd start from scratch and start off creating three classes in a webServlet pod:

• ServletWebService : WebService
• ServletWebReq : WebReq
• ServletWebReq : WebRes

Copy WispReq and WispReq to get started. But it really just a matter of wrapping the javax.servlet APIs as WebReq and WebReq. Then from there try to get Fan's web hello world running your glassfish servlet container.

Classloading might be tricky though, although you can just jstub everything for now.

Interesting. This looks to be along the lines of something I was going to start looking into after this big push at work: fan on top of grizzly (and other NIO stacks). So there could be a lot of overlap there.

I think with the new Actor API there is a cool opportunity to add async IO to Fan as actor messages.

I was thinking the same thing, too. Native NIO/AIO would be ideal but if I can get fan apps working on top of grizzly's adapters, we could deploy fan apps on top of glassfish. :)

Copy WispReq and WispReq to get started.

Better to factor out duplication into a common parent class, or use the impl design pattern, etc. :-)

As many have said before, "Ctrl + C" should not be available in any IDE or programmer's text editor. :-)

Better to factor out duplication into a common parent class, or use the impl design pattern, etc.

I believe all the functionality which can be factored into the base classes is already in the parent classes. I merely suggested using those classes b/c they already stub out all the overrides - I expect in a servlet implementation, they will all require servlet specific implementations.

But we won't know for sure until someone does the work. For example I implement my own cookie handling in web. We may want delegate that to the servlet container, or we may not.