On Sep 30, 2008, at 2:55 PM, Rob Heittman wrote:
I see that I am in fact using the Simple connector, as per the
FirstResource
tutorial, I went out of my way to put its jar on the classpath. This
configuration is what I meant by 'standalone server'.
I like Simple in concept, but I've had some not-so-wonderful
experiences with it in practice. It also seems to be supported by a
smallish team with limited resources. Jetty's been uniformly
wonderful for us in production -- we were using it for embedded apps
before we started working with Restlet, and I recommend it as both a
Servlet and a Restlet container.
My app is pretty simple, and thus far has no traditional state I need
to maintain - except the notion of "is logged in".
I'd like to use the Jetty connector.
As I said, I'm using the Simple connector in my FirstResource-like
app, and when I remove from my runtime classpath
estlet-1.1rc2/lib/org.simpleframework_3.1/org.simpleframework.jar
and add
restlet-1.1rc2/lib/org.mortbay.jetty_6.1/org.mortbay.jetty.jar
restlet-1.1rc2/lib/javax.servlet_2.5/javax.servlet.jar
per
http://www.restlet.org/documentation/1.1/connectors#jetty
I get on startup:
Exception in thread "main" java.lang.NoClassDefFoundError: simple/http/
ProtocolHandler
which indicates that something in my build is still looking for Simple
connector support. I looked to the Configuration section here
http://www.restlet.org/documentation/1.1/connectors#server_connectors
to understand how to code the server's main() entry point, but
couldn't see how my FirstResource-like app, with its Component,
subclassed Application, and Routers ( and router.attach()'s )
translates. If in fact translation is necessary? That is, perhaps
the NoClassDefError owes to something else?
The philosophy behind all this is a bit head-twisting, but once I did
it this way a few times, I never ever ever EVER wanted to go back to
the "old" way! It is more up front work to decide I need a class of
server-side resource, and work through how to handle it, rights and
responsibilities, side effects of operations, etc. But, once I've
done that, I'm DONE with the server architecture ... and the resource
integrates with any kind of Web-based client, regardless of platform,
language, etc. With the Servlet session model, it's so easy to throw
things in the session bag, but then I need to invent ways of getting
them out every time I want to move processing to the client. Net
effect: with sessions, I don't wanna move any processing to the
client.
I generally get this, and appreciate it.
P.S. Since Restlet doesn't do it on its own yet, here's my browser
identity cookie generator:
http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java
Nice. Thanks.
I'm clearly angling for neophyte of the week here. I appreciate the
first-principles feedback and code snippets.
