cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: Http Authentication Policy
Date Mon, 12 Mar 2007 14:25:20 GMT

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.


View raw message