Latest Jersey with latest Scala

Version 2.6.0 of Scala was recently released so i thought i would try out this version with the new life-cycle changes in 0.3 of Jersey.

The following Scala class works just fine when deployed:
 1 @UriTemplate("/{id}")
2 class MyResource(@UriParam("id") id: String,
3                  @HttpContext var uriInfo: UriInfo,
4                  @HttpContext var headers: HttpHeaders) {
5
6     var hmap = new JavaMapAdaptor[String, java.util.List](
7     headers.getRequestHeaders())
8
9     @ProduceMime(Array("text/html"))
10     @HttpMethod
11     def getMe() = <html>
12     <body>
13     <p>ID: { id }</p>
14     <p>URI : { uriInfo.getAbsolute() }</p>
15    <table>
16        <tr>
17         <th>Header</th>
18         <th>Value</th>
19         </tr>
20        { for (header <- hmap) yield
21        <tr>
22         <td>{ header._1 }</td>
23         <td>{ header._2 }</td>
24        </tr>
25        }
26     </table>
27     </body>
28 </html>.toString()
29 }

The above class supports a HTTP GET method that returns an HTML representation containing the value of the URI parameter, the absolute URI of the request, and a table of the HTTP request headers. 

Scala has a compact syntax for class constructors, see lines 2 to 3. The URI parameter "id" is a field on the class as well as a parameter to the constructor of the class. Jersey correctly passes the URI parameter when creating a new instance of this class.

Line 6 declares a field on the class that adapts the HTTP request headers, that is of the type MultivaluedMap, to a scala.collections.mutable.Map so the headers can be accessed using familiar Scala operations on collections.

Lines 9 to 11 declare an HTTP method that responds to a GET request with a HTML representation generated using Scala's XML support.

Lines 20 to 24 iterate over the HTTP request headers. Each header is a tuple of two values, the header name and a java.util.List of values. This functionality is only possible if the HTTP request headers are adapted (see line 6).

As you can see Scala's close integration with Java makes it easy to use Jersey with Scala. However, i think such integration could be improved by providing appropriate Scala adapters for injected interfaces so that a developer is not required to do such adaption.

I am still very new to Scala and need to get stuck into writing a more "real world application". Perhaps a good exercise would be to write in Scala what Tim is doing in Erlang.

[Update on comments]

Michael, see my other blog entry after this on how get things working with GF. It proved to be reasonably simple given the smooth integration of Java and Scala. What is really missing is NetBeans support for editing and compiling Scala classes. If that was in place deploying to GF would be very simple.

Rafael, thanks for the tip, that is much better. I was wondering how to that and the solution you presented is obvious, of course with hindsight :-)

Comments:

Nice! Any special gotchas to deploy this on GlassFish? - eduard/o

Posted by eduardo pelegri-llopart on September 24, 2007 at 08:44 AM CEST #

I have only deployed using the light weight HTTP server in a Scala class. The reason being is I can kick start everything from "scala" i.e. it is the easiest solution to get things going.

To deploy in GF needs some more investigation. I suspect it is probably just a matter of including the Scala runtime libraries and ensuring the resource configuration class referenced in the web.xml is written in Scala and references Scala classes, or is written in Java and references Scala classes.

Posted by Paul Sandoz on September 24, 2007 at 09:13 AM CEST #

Great editing! and thanks for sharing..

though I like the kickstart from 'scala', I agree, that an easy integration with Glassfish would be great.. guess I have to find it out myself, some day :-)

Posted by Michael Nischt on September 27, 2007 at 02:58 AM CEST #

That's very cool!I would just change a little the for comprehension to something like this:

20 { for ((name, value) <- hmap) yield
21 <tr>
22 <td>{ name }</td>
23 <td>{ value }</td>
24 </tr>
25 }

I usually find pattern matching on tuples to be more readable than explicit calls to ._i

Posted by Rafael de F. Ferreira on September 29, 2007 at 04:31 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

sandoz

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today