This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Pimping Servlet and Jetty

18 replies
Arnold deVos
Joined: 2009-06-18,
User offline. Last seen 42 years 45 weeks ago.
p, li { white-space: pre-wrap; }

Oh no not another web framework, I hear you say :) Well It seems nobody has pimped the servlet API yet (as opposed to building a web application framework on it).

And sometimes you just need a servlet. So the idea is to stick to pimping without adding any new pieces. There is some (clearly delimited) Jetty-specific pimping as well.

Here is the basic strategy:

If we extract a service method in the servlet API as a function we get (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created as a side effect by mutating the HttpResponse.

But, curry this giving HttpRequest => HttpResponse => Unit and call the last bit a 'Responder' as in type Responder = HttpResponse => Unit.

Now the Responder contains all the ugly side effects. Conveniently, we can write these separately and a few canned Responders cover most needs.

Implicit conversions can wrap result types such as scala.xml.Node in appropriate Responders. Implicit parameters work well for content types. And extractors are good for dealing with requests.

Here is an example that generates some KML for google earth:

implicit val contentType = ContentType("application/vnd.google-earth.kml+xml")


get("/cafe") {
case Params(BBox(w, s, e, n)) =>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
{
for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
<Placemark>
<name>{name}</name>
<Point>
<coordinates>{lon},{lat},0</coordinates>
</Point>
</Placemark>
}
</Document>
</kml>


case _ => 404
}

The full narrative is here:

http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html

If you like it, embrace and extend it here:

http://github.com/arnolddevos/JettyS

--

Arnold deVos

Langdale Consultants

David Flemström
Joined: 2009-08-10,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
This looks very interesting, but very similar to Alan Dipert's Step. Have you seen that framework before?

On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos <adv-list-scala [at] langdale [dot] com [dot] au> wrote:

Oh no not another web framework, I hear you say :) Well It seems nobody has pimped the servlet API yet (as opposed to building a web application framework on it).

And sometimes you just need a servlet. So the idea is to stick to pimping without adding any new pieces. There is some (clearly delimited) Jetty-specific pimping as well.

Here is the basic strategy:

If we extract a service method in the servlet API as a function we get (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created as a side effect by mutating the HttpResponse.

But, curry this giving HttpRequest => HttpResponse => Unit and call the last bit a 'Responder' as in type Responder = HttpResponse => Unit.

Now the Responder contains all the ugly side effects. Conveniently, we can write these separately and a few canned Responders cover most needs.

Implicit conversions can wrap result types such as scala.xml.Node in appropriate Responders. Implicit parameters work well for content types. And extractors are good for dealing with requests.

Here is an example that generates some KML for google earth:

implicit val contentType = ContentType("application/vnd.google-earth.kml+xml")


get("/cafe") {
case Params(BBox(w, s, e, n)) =>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
{
for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
<Placemark>
<name>{name}</name>
<Point>
<coordinates>{lon},{lat},0</coordinates>
</Point>
</Placemark>
}
</Document>
</kml>


case _ => 404
}

The full narrative is here:

http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html

If you like it, embrace and extend it here:

http://github.com/arnolddevos/JettyS

--

Arnold deVos

Langdale Consultants


David Copeland
Joined: 2009-06-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty

I think the biggest thing making Scala web-based development painful
is the Servlet spec and J2EE. The Servlet spec is antiquated even by
Java standards (java.util.Enumeration anyone?). I wonder what a
Scala-focussed HTTP request handling framework would look like? I
don't mean web framework (like Lift or Play), I mean something like
Servlets or Spring MVC, but tailored to take full advantage of Scala.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Sat, Apr 17, 2010 at 6:08 AM, David Flemström
wrote:
> This looks very interesting, but very similar to Alan Dipert's Step. Have
> you seen that framework before?
>
> On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos
> wrote:
>>
>> Oh no not another web framework, I hear you say :) Well It seems nobody
>> has pimped the servlet API yet (as opposed to building a web application
>> framework on it).
>>
>> And sometimes you just need a servlet. So the idea is to stick to pimping
>> without adding any new pieces. There is some (clearly delimited)
>> Jetty-specific pimping as well.
>>
>> Here is the basic strategy:
>>
>> If we extract a service method in the servlet API as a function we get
>> (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created
>> as a side effect by mutating the HttpResponse.
>>
>> But, curry this giving HttpRequest => HttpResponse => Unit and call the
>> last bit a 'Responder' as in type Responder = HttpResponse => Unit.
>>
>> Now the Responder contains all the ugly side effects. Conveniently, we can
>> write these separately and a few canned Responders cover most needs.
>>
>> Implicit conversions can wrap result types such as scala.xml.Node in
>> appropriate Responders. Implicit parameters work well for content types. And
>> extractors are good for dealing with requests.
>>
>> Here is an example that generates some KML for google earth:
>>
>> implicit val contentType =
>> ContentType("application/vnd.google-earth.kml+xml")
>>
>> get("/cafe") {
>> case Params(BBox(w, s, e, n)) =>
>>
>>
>> {
>> for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
>>
>> {name}
>>
>> {lon},{lat},0
>>
>>
>> }
>>
>>
>>
>> case _ => 404
>> }
>>
>> The full narrative is here:
>>
>> http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html
>>
>> If you like it, embrace and extend it here:
>>
>> http://github.com/arnolddevos/JettyS
>>
>> --
>>
>> Arnold deVos
>>
>> Langdale Consultants
>

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Pimping Servlet and Jetty
Isn't that what Dispatcher does?

On Sat, Apr 17, 2010 at 10:38 AM, David Copeland <davec [at] naildrivin5 [dot] com> wrote:
I think the biggest thing making Scala web-based development painful
is the Servlet spec and J2EE.  The Servlet spec is antiquated even by
Java standards (java.util.Enumeration anyone?).  I wonder what a
Scala-focussed HTTP request handling framework would look like?  I
don't mean web framework (like Lift or Play), I mean something like
Servlets or Spring MVC, but tailored to take full advantage of Scala.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Sat, Apr 17, 2010 at 6:08 AM, David Flemström
<david [dot] flemstrom [at] gmail [dot] com> wrote:
> This looks very interesting, but very similar to Alan Dipert's Step. Have
> you seen that framework before?
>
> On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos
> <adv-list-scala [at] langdale [dot] com [dot] au> wrote:
>>
>> Oh no not another web framework, I hear you say :) Well It seems nobody
>> has pimped the servlet API yet (as opposed to building a web application
>> framework on it).
>>
>> And sometimes you just need a servlet. So the idea is to stick to pimping
>> without adding any new pieces. There is some (clearly delimited)
>> Jetty-specific pimping as well.
>>
>> Here is the basic strategy:
>>
>> If we extract a service method in the servlet API as a function we get
>> (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created
>> as a side effect by mutating the HttpResponse.
>>
>> But, curry this giving HttpRequest => HttpResponse => Unit and call the
>> last bit a 'Responder' as in type Responder = HttpResponse => Unit.
>>
>> Now the Responder contains all the ugly side effects. Conveniently, we can
>> write these separately and a few canned Responders cover most needs.
>>
>> Implicit conversions can wrap result types such as scala.xml.Node in
>> appropriate Responders. Implicit parameters work well for content types. And
>> extractors are good for dealing with requests.
>>
>> Here is an example that generates some KML for google earth:
>>
>> implicit val contentType =
>> ContentType("application/vnd.google-earth.kml+xml")
>>
>> get("/cafe") {
>> case Params(BBox(w, s, e, n)) =>
>> <kml xmlns="http://www.opengis.net/kml/2.2">
>> <Document>
>> {
>> for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
>> <Placemark>
>> <name>{name}</name>
>> <Point>
>> <coordinates>{lon},{lat},0</coordinates>
>> </Point>
>> </Placemark>
>> }
>> </Document>
>> </kml>
>>
>> case _ => 404
>> }
>>
>> The full narrative is here:
>>
>> http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html
>>
>> If you like it, embrace and extend it here:
>>
>> http://github.com/arnolddevos/JettyS
>>
>> --
>>
>> Arnold deVos
>>
>> Langdale Consultants
>



--
Daniel C. Sobral

I travel to the future all the time.
Arnold deVos
Joined: 2009-06-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty

Yes I looked at Step and Circumflex too. I included a Step example in the
referenced write up.

There are several differences between my effort and those. I only wanted to
enhance the servlet API and I wanted to come up with a pure function that
serves a request. Step creates a nice syntax but it relies on thread locals
and, sometimes, side effects to do it.

Regards,
Arnold

On Sat, 17 Apr 2010 08:08:00 pm David Flemström wrote:
> This looks very interesting, but very similar to Alan Dipert's
> Step.
> Have you seen that framework before?
>
> On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos <
>
> adv-list-scala [at] langdale [dot] com [dot] au> wrote:
> > Oh no not another web framework, I hear you say :) Well It seems nobody
> > has pimped the servlet API yet (as opposed to building a web application
> > framework on it).
> >
> > And sometimes you just need a servlet. So the idea is to stick to pimping
> > without adding any new pieces. There is some (clearly delimited)
> > Jetty-specific pimping as well.
> >
> > Here is the basic strategy:
> >
> > If we extract a service method in the servlet API as a function we get
> > (HttpRequest, HttpResponse) => Unit. This is nasty. The response is
> > created as a side effect by mutating the HttpResponse.
> >
> > But, curry this giving HttpRequest => HttpResponse => Unit and call the
> > last bit a 'Responder' as in type Responder = HttpResponse => Unit.
> >
> > Now the Responder contains all the ugly side effects. Conveniently, we
> > can write these separately and a few canned Responders cover most needs.
> >
> > Implicit conversions can wrap result types such as scala.xml.Node in
> > appropriate Responders. Implicit parameters work well for content types.
> > And extractors are good for dealing with requests.
> >
> > Here is an example that generates some KML for google earth:
> >
> > implicit val contentType =
> > ContentType("application/vnd.google-earth.kml+xml")
> >
> >
> > get("/cafe") {
> > case Params(BBox(w, s, e, n)) =>
> >
> >
> > {
> > for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
> >
> > {name}
> >
> > {lon},{lat},0
> >
> >
> > }
> >
> >
> >
> >
> > case _ => 404
> > }
> >
> > The full narrative is here:
> >
> > http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html
> >
> > If you like it, embrace and extend it here:
> >
> > http://github.com/arnolddevos/JettyS
> >
> > --
> >
> > Arnold deVos
> >
> > Langdale Consultants
>

Steven Shaw
Joined: 2009-02-01,
User offline. Last seen 2 years 39 weeks ago.
Re: Pimping Servlet and Jetty
Scalaz5 has a http module that could be worth looking into. 
  http://github.com/scalaz/scalaz/tree/master/http/src/main/scala/scalaz/http/
I don't get it yet but I'm getting there :)
davetron5000
Joined: 2009-06-07,
User offline. Last seen 2 years 31 weeks ago.
Re: Pimping Servlet and Jetty

Dispatcher (assuming you mean this:
http://dispatch.databinder.net/Stdout_Walkthrough ) seems to be the
opposite; it seems to wrap HttpClient with a symbolriffic syntax.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

On Sat, Apr 17, 2010 at 9:56 AM, Daniel Sobral wrote:
> Isn't that what Dispatcher does?
>
> On Sat, Apr 17, 2010 at 10:38 AM, David Copeland
> wrote:
>>
>> I think the biggest thing making Scala web-based development painful
>> is the Servlet spec and J2EE.  The Servlet spec is antiquated even by
>> Java standards (java.util.Enumeration anyone?).  I wonder what a
>> Scala-focussed HTTP request handling framework would look like?  I
>> don't mean web framework (like Lift or Play), I mean something like
>> Servlets or Spring MVC, but tailored to take full advantage of Scala.
>>
>> Dave
>>
>> ---
>> My Blog: http://www.naildrivin5.com/blog
>> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
>> Fork me on Github: http://davetron5000.github.com
>>
>>
>>
>>
>> On Sat, Apr 17, 2010 at 6:08 AM, David Flemström
>> wrote:
>> > This looks very interesting, but very similar to Alan Dipert's Step.
>> > Have
>> > you seen that framework before?
>> >
>> > On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos
>> > wrote:
>> >>
>> >> Oh no not another web framework, I hear you say :) Well It seems nobody
>> >> has pimped the servlet API yet (as opposed to building a web
>> >> application
>> >> framework on it).
>> >>
>> >> And sometimes you just need a servlet. So the idea is to stick to
>> >> pimping
>> >> without adding any new pieces. There is some (clearly delimited)
>> >> Jetty-specific pimping as well.
>> >>
>> >> Here is the basic strategy:
>> >>
>> >> If we extract a service method in the servlet API as a function we get
>> >> (HttpRequest, HttpResponse) => Unit. This is nasty. The response is
>> >> created
>> >> as a side effect by mutating the HttpResponse.
>> >>
>> >> But, curry this giving HttpRequest => HttpResponse => Unit and call the
>> >> last bit a 'Responder' as in type Responder = HttpResponse => Unit.
>> >>
>> >> Now the Responder contains all the ugly side effects. Conveniently, we
>> >> can
>> >> write these separately and a few canned Responders cover most needs.
>> >>
>> >> Implicit conversions can wrap result types such as scala.xml.Node in
>> >> appropriate Responders. Implicit parameters work well for content
>> >> types. And
>> >> extractors are good for dealing with requests.
>> >>
>> >> Here is an example that generates some KML for google earth:
>> >>
>> >> implicit val contentType =
>> >> ContentType("application/vnd.google-earth.kml+xml")
>> >>
>> >> get("/cafe") {
>> >> case Params(BBox(w, s, e, n)) =>
>> >>
>> >>
>> >> {
>> >> for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
>> >>
>> >> {name}
>> >>
>> >> {lon},{lat},0
>> >>
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> case _ => 404
>> >> }
>> >>
>> >> The full narrative is here:
>> >>
>> >> http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html
>> >>
>> >> If you like it, embrace and extend it here:
>> >>
>> >> http://github.com/arnolddevos/JettyS
>> >>
>> >> --
>> >>
>> >> Arnold deVos
>> >>
>> >> Langdale Consultants
>> >
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Grey
Joined: 2009-01-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
Instead of shoehorning my application as some sort of mondo servlet, I opted to embed the a modular, high performance HTTP engine in my application.
I'm using Grizzly, which I'd recommend.  I'd also suggest looking at Mina.
I completely ignore the whole servlet thing coding against Grizzly's HTTP Request/Response API.
Very easy to start the engine (google for Grizzly on some blogs by the team) with tons of functionality, custom protocols, asynch I/O, ...
You have complete control of _everything_ and the API is high enough to operate from a embedding an out-of-box Servlet container, COMET, Websocket, etc with minimal coding.
I added a very thin Scala adapter layer to track and control my coupling and created my own custom adapter.
Performance and stability have been excellent.   No XML configuration / injection silliness.
All-in-all pretty successful.
Ray

On Sat, Apr 17, 2010 at 9:38 AM, David Copeland <davec [at] naildrivin5 [dot] com> wrote:
I think the biggest thing making Scala web-based development painful
is the Servlet spec and J2EE.  The Servlet spec is antiquated even by
Java standards (java.util.Enumeration anyone?).  I wonder what a
Scala-focussed HTTP request handling framework would look like?  I
don't mean web framework (like Lift or Play), I mean something like
Servlets or Spring MVC, but tailored to take full advantage of Scala.

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Sat, Apr 17, 2010 at 6:08 AM, David Flemström
<david [dot] flemstrom [at] gmail [dot] com> wrote:
> This looks very interesting, but very similar to Alan Dipert's Step. Have
> you seen that framework before?
>
> On Sat, Apr 17, 2010 at 4:41 AM, Arnold deVos
> <adv-list-scala [at] langdale [dot] com [dot] au> wrote:
>>
>> Oh no not another web framework, I hear you say :) Well It seems nobody
>> has pimped the servlet API yet (as opposed to building a web application
>> framework on it).
>>
>> And sometimes you just need a servlet. So the idea is to stick to pimping
>> without adding any new pieces. There is some (clearly delimited)
>> Jetty-specific pimping as well.
>>
>> Here is the basic strategy:
>>
>> If we extract a service method in the servlet API as a function we get
>> (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created
>> as a side effect by mutating the HttpResponse.
>>
>> But, curry this giving HttpRequest => HttpResponse => Unit and call the
>> last bit a 'Responder' as in type Responder = HttpResponse => Unit.
>>
>> Now the Responder contains all the ugly side effects. Conveniently, we can
>> write these separately and a few canned Responders cover most needs.
>>
>> Implicit conversions can wrap result types such as scala.xml.Node in
>> appropriate Responders. Implicit parameters work well for content types. And
>> extractors are good for dealing with requests.
>>
>> Here is an example that generates some KML for google earth:
>>
>> implicit val contentType =
>> ContentType("application/vnd.google-earth.kml+xml")
>>
>> get("/cafe") {
>> case Params(BBox(w, s, e, n)) =>
>> <kml xmlns="http://www.opengis.net/kml/2.2">
>> <Document>
>> {
>> for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
>> <Placemark>
>> <name>{name}</name>
>> <Point>
>> <coordinates>{lon},{lat},0</coordinates>
>> </Point>
>> </Placemark>
>> }
>> </Document>
>> </kml>
>>
>> case _ => 404
>> }
>>
>> The full narrative is here:
>>
>> http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html
>>
>> If you like it, embrace and extend it here:
>>
>> http://github.com/arnolddevos/JettyS
>>
>> --
>>
>> Arnold deVos
>>
>> Langdale Consultants
>



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
Dear Arnold,
Being very simple minded, i love the simplicity! Thanks! BTW, have you worked out an example supporting a simple presence-based editing scenario? 
Best wishes,
--greg

On Fri, Apr 16, 2010 at 7:41 PM, Arnold deVos <adv-list-scala [at] langdale [dot] com [dot] au> wrote:

Oh no not another web framework, I hear you say :) Well It seems nobody has pimped the servlet API yet (as opposed to building a web application framework on it).

And sometimes you just need a servlet. So the idea is to stick to pimping without adding any new pieces. There is some (clearly delimited) Jetty-specific pimping as well.

Here is the basic strategy:

If we extract a service method in the servlet API as a function we get (HttpRequest, HttpResponse) => Unit. This is nasty. The response is created as a side effect by mutating the HttpResponse.

But, curry this giving HttpRequest => HttpResponse => Unit and call the last bit a 'Responder' as in type Responder = HttpResponse => Unit.

Now the Responder contains all the ugly side effects. Conveniently, we can write these separately and a few canned Responders cover most needs.

Implicit conversions can wrap result types such as scala.xml.Node in appropriate Responders. Implicit parameters work well for content types. And extractors are good for dealing with requests.

Here is an example that generates some KML for google earth:

implicit val contentType = ContentType("application/vnd.google-earth.kml+xml")


get("/cafe") {
case Params(BBox(w, s, e, n)) =>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
{
for((name, lon, lat) <- findCafesIn(w, s, e, n)) yield
<Placemark>
<name>{name}</name>
<Point>
<coordinates>{lon},{lat},0</coordinates>
</Point>
</Placemark>
}
</Document>
</kml>


case _ => 404
}

The full narrative is here:

http://notes.langdale.com.au/Pimping_Servlet_and_Jetty.html

If you like it, embrace and extend it here:

http://github.com/arnolddevos/JettyS

--

Arnold deVos

Langdale Consultants




--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com
Steven Shaw
Joined: 2009-02-01,
User offline. Last seen 2 years 39 weeks ago.
Re: Pimping Servlet and Jetty
On 18 April 2010 03:01, Ray Racine <ray [dot] racine [at] gmail [dot] com> wrote:
I'm using Grizzly, which I'd recommend.  I'd also suggest looking at Mina.
I completely ignore the whole servlet thing coding against Grizzly's HTTP Request/Response API.
Very easy to start the engine (google for Grizzly on some blogs by the team) with tons of functionality, custom protocols, asynch I/O, ...
You have complete control of _everything_ and the API is high enough to operate from a embedding an out-of-box Servlet container, COMET, Websocket, etc with minimal coding.
I added a very thin Scala adapter layer to track and control my coupling and created my own custom adapter.

That sounds really interesting. Are you willing and able to share your thin adapter code or perhaps just post a few examples it's usage? 
Performance and stability have been excellent.   No XML configuration / injection silliness.

Great.
david.bernard
Joined: 2009-01-08,
User offline. Last seen 1 year 27 weeks ago.
Re: Pimping Servlet and Jetty
there is grizzly, mina and ... netty (jboss) well documented (better than mina IMO)see http://www.jboss.org/netty/documentation.html to have the list of 2 http example (work well in scala (as java))

/davidB

On Sat, Apr 17, 2010 at 23:18, Steven Shaw <steshaw [at] gmail [dot] com> wrote:
On 18 April 2010 03:01, Ray Racine <ray [dot] racine [at] gmail [dot] com> wrote:
I'm using Grizzly, which I'd recommend.  I'd also suggest looking at Mina.
I completely ignore the whole servlet thing coding against Grizzly's HTTP Request/Response API.
Very easy to start the engine (google for Grizzly on some blogs by the team) with tons of functionality, custom protocols, asynch I/O, ...
You have complete control of _everything_ and the API is high enough to operate from a embedding an out-of-box Servlet container, COMET, Websocket, etc with minimal coding.
I added a very thin Scala adapter layer to track and control my coupling and created my own custom adapter.

That sounds really interesting. Are you willing and able to share your thin adapter code or perhaps just post a few examples it's usage? 
Performance and stability have been excellent.   No XML configuration / injection silliness.

Great.

Arnold deVos
Joined: 2009-06-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty

On Sun, 18 Apr 2010 01:03:01 am Steven Shaw wrote:
> Scalaz5 has a http module that could be worth looking into.
>
>
> http://github.com/scalaz/scalaz/tree/master/http/src/main/scala/scalaz/http
> /
>
> I don't get it yet but I'm getting there :)
>

Right, it does look like it is scalaizing the servlet API. There is a lot
more code there than my minimalist effort. Although the code is commented, I
wonder if the author(s) have a descriptive piece on this somewhere? Something
that would guide us to the central idea.

Regards,
Arnold

Steven Shaw
Joined: 2009-02-01,
User offline. Last seen 2 years 39 weeks ago.
Re: Pimping Servlet and Jetty
On 18 April 2010 09:00, David Bernard <david [dot] bernard [dot] 31 [at] gmail [dot] com> wrote:
there is grizzly, mina and ... netty (jboss) well documented (better than mina IMO)see http://www.jboss.org/netty/documentation.html to have the list of 2 http example (work well in scala (as java))

It makes sense that Netty is better than Mina since my understanding is that the primary developer of Mina - Trustin Lee - left that project to join JBoss and created Netty... So Netty is like "Mina done right" or "2nd generation Mina".
Hmmm, after googling, it's seems that Netty was Trustin's original project and after a hiatus working on Mina, he's now back working on Netty because of some kind of community disagreement. Sounds ominous :).
  www.jboss.org/netty/community.html#nabble-td724026
Steve.
Steven Shaw
Joined: 2009-02-01,
User offline. Last seen 2 years 39 weeks ago.
Re: Pimping Servlet and Jetty
On 18 April 2010 10:58, Arnold deVos <adv-list-scala [at] langdale [dot] com [dot] au> wrote:

Right, it does look like it is scalaizing the servlet API.  There is a lot
more code there than my minimalist effort.  Although the code is commented, I
wonder if the author(s) have a descriptive piece on this somewhere?  Something
that would guide us to the central idea.

There's the following presentation by Tom Adams
http://files.meetup.com/1443989/ScalazWebBFGSept2009.pdf
There was a recent video presentation covering Scalaz5 but I'm don't recall that it focused on the http library (aka slinky).
Steve.
Grey
Joined: 2009-01-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
gist.github.com/370427
Starts up a HTTP server with behavior defined via the CDAP2Adapter trait.
Some thoughts on Mina, Netty, Grizzly et al.
Grizzly appears to be the fastest, Mina really close behind and Netty 1/2 a lap down.
The statement of Mina being Netty 2.0 (done right) sounds correct sums it up nicely.  Mina's API is super nice and clean.  If I had to do it all over again I may have gone with Mina over Grizzly for the API cleanliness alone.  But Grizzly has been good to me, the API is not that bad and I think you get more batteries included type stuff with the Griz vs. Mina.  Mina vs. Grizzly is probably a toss up depending on individual needs.
There is a Grizzly 2.0 well underway which is supposed to clean up the API, with the HTTP API a big focus.  But I haven't dug into it to see if its incremental or major a refactoring.  I don't think I've _ever_ not received a solid same day response from the Grizzly list on any questions.
The core Grizzly guy JFarcand left in Dec/Jan for Ning when Oracle consumed Sun.  There is still a core team who do nothing but work on Grizzly and they push the latest NIO JDK apis to achieve max performance.  That said, who knows if Oracle will drop the hammer on Glassfish altogether next week?   FYI, Grizzly is the engine which drives Glassfish.
With Trusten Lee moving back to Netty from Mina, again who knows what tomorrow will bring.
That all being said just do your code right, use a couple of adapting interfaces to help minimize coupling, and if necessary one could move from one to the other in a matter of days.
All of them are open source.
On Sat, Apr 17, 2010 at 5:18 PM, Steven Shaw <steshaw [at] gmail [dot] com> wrote:
On 18 April 2010 03:01, Ray Racine <ray [dot] racine [at] gmail [dot] com> wrote:
I'm using Grizzly, which I'd recommend.  I'd also suggest looking at Mina.
I completely ignore the whole servlet thing coding against Grizzly's HTTP Request/Response API.
Very easy to start the engine (google for Grizzly on some blogs by the team) with tons of functionality, custom protocols, asynch I/O, ...
You have complete control of _everything_ and the API is high enough to operate from a embedding an out-of-box Servlet container, COMET, Websocket, etc with minimal coding.
I added a very thin Scala adapter layer to track and control my coupling and created my own custom adapter.

That sounds really interesting. Are you willing and able to share your thin adapter code or perhaps just post a few examples it's usage? 
Performance and stability have been excellent.   No XML configuration / injection silliness.

Great.



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
Grey
Joined: 2009-01-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
YIKES.  I crossed up Mina and Netty pretty much consistently in the previous email.
Grizzly and NETTY where the two best options from my review of the options.  Netty being smaller and cleaner.  Grizzly a bit bigger and faster.
Mina was a more distant third.
Fixed up below.
Some thoughts on Mina, Netty, Grizzly et al.
Grizzly appears to be the fastest at scale, Netty really close behind and Mina 1/2 a lap down.
The statement of Netty being Mina 2.0 (done right) sounds correct sums it up nicely.  Netty's API is super nice and clean.  If I had to do it all over again I _may_ have gone with Netty over Grizzly for the API cleanliness alone.  But Grizzly has been good to me, the API is not that bad and I think you get more batteries included type stuff with the Griz vs. Netty.  Netty vs. Grizzly is probably a toss up depending on individual needs.
There is a Grizzly 2.0 well underway which is supposed to clean up the API, with the HTTP API a big focus.  But I haven't dug into it to see if its incremental or major a refactoring.  I don't think I've _ever_ not received a solid same day response from the Grizzly list on any questions.
The core Grizzly guy JFarcand left in Dec/Jan for Ning when Oracle consumed Sun.  There is still a core team who do nothing but work on Grizzly and they push the latest NIO JDK apis to achieve max performance.  That said, who knows if Oracle will drop the hammer on Glassfish altogether next week?   FYI, Grizzly is the engine which powers Glassfish.
That all being said just do your code right, use a couple of adapting interfaces to help minimize coupling, and if necessary one could move from one to the other in a matter of days.
All of them are open source.
Steven Shaw
Joined: 2009-02-01,
User offline. Last seen 2 years 39 weeks ago.
Re: Pimping Servlet and Jetty
Hi Ray, thanks for posting the coding sample and the info on Grizzly, Mina and Netty. I haven't looked at those projects for ages. I worked briefly on Qpid messaging broker which used Mina. I didn't mind it but found the filters to have quite a strange set up (aka design pattern) but maybe I just didn't understand the rationale :) [it's similar/same as servlet filters IIRC]. On the Qpid project, we were keen to try out Grizzly because it was definitely getting better figures than Mina - but this was all back in 2006. I haven't kept up with that project and don't know if they finally switched over to Grizzly. I know at the time it was easier to use Grizzly for HTTP and harder to use it as a NIO network layer/framework.

I was wondering if you miss anything in particular by embedding a http library rather than using the typical servlet container/server. We use GlassFish at guvera.com and I think are still using the access logging that it supports (although we're getting Zeus/Apache load balancers to take over that job soon). The 'asadmin' is also a nice tool. We use it for starting, stopping, deploying and dumping performance monitoring (by dumping JMX-style attributes/counters). One of our deployments has a GF instance running 2 webapps which I guess would be harder to setup using an embedded http library. However, we've got plenty of memory and running two separate JVMs for each of those web apps would have other advantages...
Would you say that there particular advantages to using a http library over avoiding the servlet api?
Steve.
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty
Dear Arnold,
The code i checked out from github wouldn't compile under scala-2.8 (i'm still on the beta). However, with some minimal changes it did. Let me know if you want me to fork the repo and post them back.
Best wishes,
--greg

On Sat, Apr 17, 2010 at 5:58 PM, Arnold deVos <adv-list-scala [at] langdale [dot] com [dot] au> wrote:
On Sun, 18 Apr 2010 01:03:01 am Steven Shaw wrote:
> Scalaz5 has a http module that could be worth looking into.
>
>
> http://github.com/scalaz/scalaz/tree/master/http/src/main/scala/scalaz/http
> /
>
> I don't get it yet but I'm getting there :)
>

Right, it does look like it is scalaizing the servlet API.  There is a lot
more code there than my minimalist effort.  Although the code is commented, I
wonder if the author(s) have a descriptive piece on this somewhere?  Something
that would guide us to the central idea.

Regards,
Arnold

--
Arnold deVos
Langdale Consultants



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com
Arnold deVos
Joined: 2009-06-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Pimping Servlet and Jetty

Hi Greg,

Yes please fork it or otherwise give me something I can pull.

Regards,
Arnold

On Fri, 23 Apr 2010 10:59:43 am Meredith Gregory wrote:
> Dear Arnold,
>
> The code i checked out from github wouldn't compile under scala-2.8 (i'm
> still on the beta). However, with some minimal changes it did. Let me know
> if you want me to fork the repo and post them back.
>
> Best wishes,
>
> --greg
>
> On Sat, Apr 17, 2010 at 5:58 PM, Arnold deVos <
>
> adv-list-scala [at] langdale [dot] com [dot] au> wrote:
> > On Sun, 18 Apr 2010 01:03:01 am Steven Shaw wrote:
> > > Scalaz5 has a http module that could be worth looking into.
> >
> > http://github.com/scalaz/scalaz/tree/master/http/src/main/scala/scalaz/ht
> >tp
> >
> > > /
> > >
> > > I don't get it yet but I'm getting there :)
> >
> > Right, it does look like it is scalaizing the servlet API. There is a
> > lot more code there than my minimalist effort. Although the code is
> > commented, I
> > wonder if the author(s) have a descriptive piece on this somewhere?
> > Something
> > that would guide us to the central idea.
> >
> > Regards,
> > Arnold
> >
> > --
> > Arnold deVos
> > Langdale Consultants
>

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland