Hi,
I have recently started using Avalon and Phoenix so please excuse my ignorance if I
have things wrong.
I am facing a different problem (dynamic dependency) with the application I am
building but I believe that it's related to this discussion. I have many different
components which all have the same role, let's say Role1. I have another component,
Role1User, which uses some number of Role1 components. This number is not known at
development time and therefore dependencies can not be described in the .xinfo file.
What I would like to do is configure Role1User with names of Role1 components and have
it lookup Role1 components by name at initialization.
Configuration[] role1Configs = m_config.getChild( "role1s" ).getChildren();
for ( int i = 0; i < role1Configs.length; i++ )
{
Role1 role1 = (Role1)m_sm.lookup( role1Configs[i].getName() );
}
Since there are no explicit dependencies declared for all the Role1s the above code
may fail even though all required components are defined in the assembly file. This
would not be a problem if the ServiceManager loaded components dynamically on request.
Now, one solution is to follow the pattern 1 or 2 (not much difference in the context
of this discussion) described by Peter. This implies, however, that my factory must be
able to:
a) map component name to implementation class
b) somehow provide services to Role1 that a particular Role1 implementation depends on
(load them in the context of my factory?).
c) manage newly loaded components' lifecycle
d) export my components to JMX
This basically means that I need to develop my own container complete with the meta
model which I would rather not do. And even if I did, I would have two places where
different parts of my application are assembled and configured which is ugly.
What is the 'correct' way to develop this?
Thanx
Boris
---------------------- Original Message -------------------------------
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
From: Peter Donald <[EMAIL PROTECTED]>
To: "Avalon Developers List" <[EMAIL PROTECTED]>
Subject: Re: Configuring components dynamically
Date: Fri, 20 Sep 2002 19:59:47 +1000
MIME-Version: 1.0
Message-Id: <[EMAIL PROTECTED]>
On Fri, 20 Sep 2002 10:34, Jason van Zyl wrote:
> Or are you saying that for the above scenerio I implement a factory that
> would do essentially what a container is doing:
>
> ContainerUtil.enableLogging(component, log);
> ContainerUtil.contextualize(component, context);
> ContainerUtil.service(component, this);
> ContainerUtil.configure(component, cd.getConfiguration());
> ContainerUtil.initialize(component);
> ContainerUtil.start(component);
>
> Except use a Configuration that I supply?
I think that is what he was implying.
> Would the following signature be useful for this sort of thing
> generally:
>
> ServiceManger.lookup(String role, Configuration configuration)
>
> I imagine that something akin to this must be used all the time, no?
We have debated it and generally came to the conclusion that there is three
"solutions". Say we wanted the component Foo - because Velocity is too long
to type in an example ;).
Solution one:
The component in the SM is a FooFactory that we can pass parameters/config to
to create Foo. Useful if Foo is private to each component.
ie
void service( ServiceManager sm )
{
final FooFactory factory = (FooFactory)sm.lookup( FooFactory.ROLE );
m_foo = factory.createFoo( myParams );
}
Solution two:
The component in the SM is a FooManager. The Foos that FooManager manages are
defined in the configuration of FooManager. Useful if Foo needs to be shared
between multiple components.
ie
void service( ServiceManager sm )
{
final FooManager factory = (FooManager)sm.lookup( FooManager.ROLE );
m_foo = factory.getFoo( "my-foo" );
}
Solution three:
There are several different instances of Foo in the container. ie Foo1, Foo2,
Foo3. Each component that needs a Foo has the assembler map the most
appropriate Foo into their SM namespace.
ie
void service( ServiceManager sm )
{
m_foo = (Foo)sm.lookup( Foo.ROLE );
}
Onlt Solution One provides a "dynamic" solution where the Foo iscreated
according to specified parameters. All the others require that the assembler
configure all the Foo instances in the application and either
* map them to correct component
* place them in a FooManager
That make sense?
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
