users@glassfish.java.net

Re: What is the life-cycle of a ServerAuthModule on GF

From: <glassfish_at_javadesktop.org>
Date: Thu, 27 Mar 2008 15:54:00 PST

Dave,

The spec is very light in this regard, mostly because module construction and initialization is handled by the auth context layer; the behavior of which is defined by the auth config provider which is pluggable. fwiw, the relevant parts of the spec are 1.1.7 Authentication exchanges and State" and 1.1.2 Authentication Contexts".

AYK, the GFAuthConfigProvider instantiates a new SAM on each call to getAuthContext, This is an implementation specific detail, and actually one that we would like to change, since the extra module instantiations and initializations are not necessary. SInce our servlet container calls getAuthContext once per each Servlet request, the lifetime of the module is per HttpRequest (your possibility 3).

As noted above, we would like to reduce the frequency of construction to the point where the number of SAMs of a type created for an application context within a server, is equal to the number of variations in parameter values with with the modules are initialized. This requires being able to determine equivalence of request and response MessagePolicies, CallbackHandler, and initialization properties; which, at least so far, has not seemed easy to determine (in the general case).

SAM's are expected to be implemented such that they can be invoked concurrently. They are expected to get most of the information on which they operate from their MessageInfo and Subject parameters, or by using their callback handler to process Callbacks. Modules can contain static objects, shared accross all instances, given that access to these objects is safely scheduled.

Regarding your specific question about connections and user to group caches. I think you can do what you are trying to do. I assume that the purpose of the pool is to support simultaneous lookups for different users, while the purpose of the cache is to reuse results corresponding to individual users. I think you should be able to hide the pooling complexity below the cache implementation, while defining the cache as a static object of the SAM.

I am not sure if you will be able to use a JDBC connection pool of the server. I will need to get back to you on that. I think to do so, may require constructs in the dd of the app, which would complicate the deployment of your SAM.

Ron
[Message sent by forum member 'monzillo' (monzillo)]

http://forums.java.net/jive/thread.jspa?messageID=266340