On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
Yep, fair point about the UserPassSupplier possibly requiring more
context than could be provided via a simple no-arg ctor called via
Class.forName().
This could be addressed by making the UserPassSupplier a Spring
bean (so
that its dependencies are injected), but then <ref>erring to this bean
from within the AuthPolicy of the http-conduit bean (so that the
UserPassSupplier is now a dependency of the http-conduit bean, as
opposed to a completely free-standing bean).
Excellent -- this seems workable to me. Another option would of
course be to dynamically load and instantiate via a more
"interesting" ctor, but I am beginning to understand the benefits of
Spring here -- defining said ctor would require definition of some
sort of contract ("You must define a public ctor that takes a map,
such that ... etc"). With a bean, it's all more or less done for you
(if you can figure out what "it" is :)
Yep, good point, we should probably replace the reuse of
AuthorizationPolicy in the receiving context, with a separate
AuthorizationContext or somesuch.
Yes, let's make sure things in the "configuration" namespace are used
for configuration, not for anything else.
But if you want to go ahead and consolidate the common elements of
these
policies into a single base type, I'd be +1.
Sure, I'll try -- I also at one point tried to generate my own PKCS12
file and trustdb, but ran into a wall. I'll try to revitalize that
effort, at well, and document what I find are the requirements. My
first pass failed for reasons I could not explain.
-Fred
