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]>
