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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
