-何を拡張したらよいか

やっと高井さんのJRuby on Rails実装の意味が理解できました。
Grizzlyはいろんな拡張ポイントがあるのですが、一番簡単なのはcoyote.Adapterを実装することです。たぶんこれが想定されている一番わかりやすいもので、TomcatはこのAdapterからServlet#service()へ呼び出しを行っていくので、GrizzlyをTomcatに埋め込むとそのままNon-Blockingなパワーが得られるという仕組みが出来上がってます。Tomcatへの埋め込み部分が見当たらないのでいくらか書かないとダメかもしれませんが、たぶんこれが歴史的経緯か作者の狙いでしょう。
次に、ServletAPIを無視したり、もしくはCoyoteではない実装を行いたい場合にはProcessorTaskを実装することになります。Coyoteはバイトストリームとしてアクセス可能なリクエスト電文をRFCの仕様そのままパースしてJavaオブジェクトにするフレームワークで、同じような機能を持つものはたとえばJettyでもフルセットで別に実装されているし、AsyncWebでも用意されています。私もやろうと思ってるのはCoyoteを用いないProcessorTaskでの実装です。しかしJettyやAsyncWeb共にProcessorTask#process(InputStream,OutputStream)での細工しているところ、私はProcessorTask#preprocess() / parseRequest() / invokeAdapter() / postResponse() / postProcess() / terminateProcess()の内部実行手順詳細のところを喰らったほうがいいように思います。
内部実行手順を踏んだほうがいいと思う理由は、Grizzlyには実行のSyncとAsync両方のロジック実行機能を持っていることにあります。またAjax-Cometの実行エンジンも組み込まれています（今日はこれを見ていました）。これらは通常のProcessorTaskの実装をAsyncProcessorTaskというフレームワーク提供のモノにラップするようになっています。そしてその外側のAsyncProcessorTaskが内包したユーザーProcessorTaskの前述の内部実行手順を追うようになっていました。Adapterを実装するか、ProcessorTaskを手順作法どおりに実装すれば、すぐさまこのGrizzlyのAsync実行やCometの実装が使えるはずです。一方でJettyやAsyncWebは使えないハズ。でもJettyはいいのです。Cometのフルセット実装が別にあるようですので。AsyncWebはまだそこまでは追ってないので不明。。。でもなんかあるでしょう。Ajax対応がそもそもの存在目的ですからね。
あと裏を取りたいのはSSLの実装について。AsyncProcessorTaskのパターンのようにSSLもうまいことフレームワークが提供しているものを勝手ProcessorTaskでも透過的に使える仕組みになっていればOK。なっていなければSSLをベタに実装。もしそうなってもそのへんはCoyoteから機能を引っ張ってくればOKなはずですが、なるべくはやりたくない。