On Oct 26, 2009, at 12:13 PM, Bruno de Carvalho wrote:
> Hi Paul,
>
>
> I'm actually reluctant to use sessions too, but the issue here is
> that the REST interface is part of a multi-protocol interface to a
> server, that already has SIP, RTMP (flash) and another custom TCP
> interface - all these interfaces share the concept of a session, so
> the HTTP should (must?) follow the same lines.
>
> There's a translation layer between protocols and the server core,
> so no matter where the request comes from/goes to, it's always seen
> (from the core of the server) as being the same kind. All these
> requests are associated with a "Client" (interface), so I was using
> the http sessions to create an HttpClient and keep it between
> requests, in order not to have each and every request need
> authentication.
>
> I know it goes against REST principles, but it's the only way to
> keep things completely uniform regardless of client protocol.
That is OK. I do not think one has to apply such principles
religiously. They should be applied pragmatically. They key is to
understand what the implications are to using or not using sessions
given your requirements (e.g. including legacy infrastructure).
> Still, I'm inclined to change it in the near future and add support
> for operations outside a session :)
>
>
> Regarding the @PerSession, you mean if I annotate my HttpClient
> class with @PerSession, each http session would have its own
> HttpClient class? Reading the API it seems so, but how then would I
> access this instance from my resource class? I'd like to completely
> avoid using @Context HttpServlet* on the resource (and it's methods).
>
No annotate a resource class:
@PerSession
@Path("sessionscoped")
public class MySessionScopedResource {
...
}
An instance of MySessionScopedResource will be stored in the session.
Thus you can place any state you wanted stored as fields.
If you need multiple resources resources to access such session state
you can do:
@PerSession
public class MySessionScopedResource {
...
}
Then inject:
@Context ResourceContext rc;
...
and access the instance:
rc.getResource(MySessionScopedResource.class);
Note that you can of course use a dependency injection framework like
Guice or Spring to do the same thing. And that is what i recommend if
you want to do full on dependency injection.
>
> I currently have something like:
>
> @GET
> public void someMethod(@Context Client client, ...) { ... }
>
> And then I have my ClientContextProvider which injects a Client
> instance, fetched from the HttpSession.
>
>
> As a side note, I've been looking at Jersey's source code and this
> has some *REALLY* cool stuff in it :))
>
Thanks!
Paul.