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.
Hang on - just re-reading this - and I think I disagree.
In Phoenix, blocks are fully processed through the lifecycle one by one. I.e. process block A, process block B, etc. At least that was how it was working the last time I looked. Merlin does almost the same thing - the only difference being that Merlin defers the start phase until after all blocks have been initialized.
Cheers, Steve.
--
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]>
