>
> I'm thinking that the best approach might be to use
> some thread-safe singletons which are shared by the
> SAMs as they come into being.
Yes, I would view your cache as this singleton, and
then I would have it perform the necessary db lookups whenever
there is a cache miss.
> In Weblogic we could not
> reuse JDBC pools that were defined as part of the
> Weblogic domain because we would get a recursive
> endless loop because of the design of the security
> framework. I was hoping that on GF we could maintain
> our DB connection info in just one place. So the SAM
> and the applications would share the same pool.\\
from what I have been told, it should be possible for you to reuse
the connection pool In Glassfish). I haven't tried it myself, but the section in
https://glassfish.dev.java.net/javaee5/docs/DG/beamj.html#gavro
on "Allowing Non-Component Callers" describes how to configure
a Glassfish connection pool for use by things like ServletFilters. SAM's
are like filters that are called at the right place and with the necessary
interfaces to perform container authentication.
Hope this helps, and please let me know how your SAM turns out.
Ron,
PS: fwiw, if you are willing to define and register your own AuthConfigProvider, then
you can establish whatever lifecycle you would like for your SAM. If your focus is being
able to configure one specific SAM, writing the ACP is relatively easy thing to do. Also,
The AuthConfigFactory that ships with Glassfish, will read ACP registrations from an
auth.conf file (if present). I think using the singleton approach we discussed above will
be sufficient, but we could investigate writing a new ACP if it turns out differently.
[Message sent by forum member 'monzillo' (monzillo)]
http://forums.java.net/jive/thread.jspa?messageID=267359