Paul Hammant wrote:
Stephen.
2) We're deciding that (at least within phoenix) Realms will be
configured and provided to the Authenticator as blocks.
+1
(and I'm assuming when you say block, you actually mean a
component + meta-info .. which is equivalent to the notion of a block)
It is coupled to a Phonix impl at present. Are you interested in using outrside of Phonix - i.e . in servlet context?
So, if we decide to support multiple realms how do we provide multiple components that implement the same role (in this case Realm) to a Serviceable component? Or would that not be the right interface to implement?
Yes and no. Some possible approaches:
1. Create an Authenticator component that has a dependecy of a RealmSet
component. The RealSet establishes the realms using whatever
implementation magic it likes (via configuration info, via dynamic
lookup of available realms in a directory or file-system, etc).
The kernel will supply the RealmSet to the Authenticator based on the
dependecies you declare.
The trouble is that in terms of lifecycle, service(..) is called for all blocks before configure(..) is for all blocks.
If it is to take configurable realm class names it would have to be a custom impl.
- Paul
That ok - if you have component RealmSet, it get pipelined through its lifecycle and as a result is ready to provide access to Realms by any component that has declared a dependecy on it. In the above example the service() invocation is relative to the Authenticator wheras the configuration action is relative to the RealmSet.
Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
