I have one question which is inlined below...
Stephen J. McConnell wrote:
>Corey Jewett wrote:
>
>>Several components I am writing have a unified access class that
>>sublets
>>it's actions to a set of providers. Example:
>>
>>AuthLogic might simultaneously have an HTTPProvider, SQLProvider, and
>>LDAPProvider. AuthLogic is responsible for directing auth requests to
>>the appropriate provider and returning a response.
>>
>>Ideally each provider would have a full component lifecycle. Currently
>>AuthLogic is acting as a sort of pseudocontainer, wherein it provides a
>>partial lifecycle (partial meaning a subset of it's own lifecycle).
>>Preferable Merlin would be used to load/manage these providers.
>>
>
>Let me rephrase this (to confirm that I have a good idea of the
>problem). What you have is component called AuthLogic which is
>basically responsible for mediating incomming requests for access to an
>appropriate authorization provider. Presumably, AuthLogic has been
>configured such that it has a rule base that declares criteria for
>provider selection together with information about respective provider
>types. In this situation the providers are not dependencies of the
>AuthLogic component - and this raises the issue concerning the lifecycle
>management of the provider components.
I'm wondering about the statement "the providers are not dependencies
of the AuthLogic component". Why aren't they? AuthLogic needs the
providers in order to get anything done. The problem that I do see is
that new providers may come along and need to be handled by AuthLogic.
That will require code changes to AuthLogic anyway, so adding a new
*Provider to the <dependency/> section doesn't seem that awkward.
What am I missing?
>>
>>I know I can declare each provider and then tell AuthLogic which
>>components to hunt down. I dislike this methodology as it seems clunky
>>at best, confusing and hard to manage at worst.
>>
I don't understand why AuthLogic isn't handed the Providers as
services at Serviceable time? Help!
>Agreed - what would be prefereble is that AuthLogic manages the
>establishment and deployment of the providers it is delegating to.
>
>>
>>
>>Would it be appropriate/possible to upgrade AuthLogic from a component
>>to a custom container.
>>
>
>Possible but probably not appropriate.
>My impression is that your needs are more closely aligned with the need
>for "a deployment service". I.e. a component (to which AuthLogic could
>declare as a depedent) that provides the service of assembly and
>deployment based on a supplied profile.
>
>E.g.
>
> public interface DeploymentService
> {
> Resource deploy( Profile profile ) throws DeploymentException;
> }
>
>and in you AuthLogic component implemetation you would have something
>like:
>
> public void initialize() throws Exception
> {
> DeploymentService deployer =
> (DeploymentService) m_manager.get("deployment");
>
> Configuration[] configs = m_config.getChildren("provider");
> for( int i=0; i<configs.length; i++ )
> {
> Configuration conf = configs[i];
> String name = conf.getAttribute("name");
> Resource resource = deployer.deploy( conf );
> m_providers.put( name, resource );
> }
> }
>
>The DeploymentService implementation could be based on Merlin (or other
>solutions) - the importabnt thing being that your dependecies concerning
>the management of component assembly and deployment are isolated into a
>seperate service.
>
>>
>>I am considering this 'upgrade' for several components. What negative
>>effects would such an action have on future development.
>>
>
>In principal you do not want to have dependencies on a container because
>that locks you into one particular deployment scenario. However, moving
>to a situation where you have a depedency on a particular service (e.g.
>DeploymentService) means that your components will be reusable across
>different containers (even if the implemetation of the DeploymentService
>is based on Merlin).
>
>Cheers, Steve.
>
>>
>>Corey
>
>--
>
>Stephen J. McConnell
>
>OSM SARL
>digital products for a global economy
>mailto:mcconnell@;osm.net
>http://www.osm.net
--
To unsubscribe, e-mail: <mailto:avalon-users-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-users-help@;jakarta.apache.org>
