How can I store information in the context of a web service?

I use a web service which is responsible for user logins. If a login is successful, a token should be generated.

@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/login")
public String login(@QueryParam("userName") String name,
        @QueryParam("password") String password) {
            //Spring Securtity Check
    HttpResponse r =loginResponse(name,password);
    String s = r.getFirstHeader("Location").toString();
    boolean isError = s.contains("login_error");
    if(!isError){
        //TODO store Token in the application context 

        MD5 token = new MD5(name+System.currentTimeMillis());
        return "token:"+token.getMD5();
    }
    return "fail";
}

I would like to store the token in the application context, but I don't know how. The token should exist as l开发者_JS百科ong as the server application is running. Does the web service have its own application context? Should I use some kind of HTTP servlet to store the information?

store it in memcached, using it you can apply some expiration policy, and also when you have more than one server, it will be an problem to store it in the local memory, store it in global cache like memcached is more apropariate.

I don't quite understand what you call the application context.

Is it ServletContext? You can get it in Jersey using the @Context annotation: @Context ServletContext. You can get is either as a field in your resource, or as a parameter to your method.
The ServletContext is up, while servlet is up. It may be removed by the servlet container depending on its configuration.

Btw. your design is really really bad and insecure. You use GET for login operation and pass both username and password on the url. This means few things:

1. GET requests can be cached by intermediaries. Do you want it to happen?
2. Everybody will see password in url. Even if you use SSL, password will be still in url, seen to everyone.
3. URL is often logged, both by client, servers and intermediaries. You really, really, really don't want the password to be logged.

I'm voting your question up, since it's a great example of a bad design for login.