On Saturday 01 May 2004 03:07, [EMAIL PROTECTED] wrote:
> 1. Skip the manager and declare every interested part as a provider of the
> appropriate lifecycle extension
> - is that possible or will just one provider be choosen, forcing you to
> provide a number of "slot"-stages for components to aquire?
IMHO, the LifeCycle extension is a bit flawed (as you have seen), and would be
my last choice.
> 2. Make direct dependencies via the Service manager and try to do the
> choosing via the setup/block.xml
> - the dependencies are no longer loosely coupled since there must be at
> least one implementing component in the system at all times.
This depends on your actual setup. As I understand it, you want to shift
implementing components at a time later than configuration time, and possibly
no implementation at all.
> 3. Provide a observer interface in the manager in order to be able to do a
> callback to interested components when the interesting components enter via
> the lifecycle extension
> - feels like we would be replicating the exact mechanism of merlin once
> more
This also sounds like not doing the right thing.
I'm slightly in the dark of what you are trying to do.
If we look at the 'client' side of things... Isn't the client requesting a
particular functionality, named service, or known service setup?
And that you want to have all those "named services" available in the
configuration (out of human practicalities)?
If so, then the components are plainly declared;
<container>
<classloader>
:
</classloader>
<component name="Timer0" class="org.hedhman.timing.OneShotTimer" />
<component name="Timer1" class="org.hedhman.timing.CyclicTimer">
<configuration>
<priority>2</priority>
</configuration>
</component>
<component name="Timer2" class="org.hedhman.timing.CyclicTimer">
<configuration>
<priority>5</priority>
</configuration>
</component>
<component name="Timer3" class="org.hedhman.timing.CyclicTimer">
<configuration>
<priority>7</priority>
</configuration>
</component>
</container>
In the client you would have the dependency declared;
/** @avalon.dependency key="LowPriorityTimer"
type="org.hedhman.timing.CyclicTimer"
*/
public void service( ServiceManager man )
{
CyclicTimer timer = (CyclicTimer) man.lookup( "LowPriorityTimer" );
:
}
And in the configuration of the client;
<container>
<classloader>
</classloader>
<include name="timers" id="hedhman-timers:standard-set" version="1.0"/>
<component name="ConsumptionAggregator"
class="org.hedhman.calculations.ConsumptionAggregator" >
<dependencies>
<dependency key="LowPriorityTimer" source="timers/Timer1" />
</dependencies>
</component>
</container>
Something along these lines would work for a 'static setup', and unused
components will not be loaded.
If you on the other hand, are looking for resolving the dependency AFTER the
startup, then things get a bit more funky. Stephen talks about push vs pull
architectures.
You create a Facility (and this is bleeding-edge) which is just an ordinary
component, but that is requesting the internal system model as a context
entry. That component can manipulate the whole component model as it wishes.
Please note that Facilities are still ground that is moving, and may change
under your feet.
Now, a clearer use-case would be good to know, for me to provide better
advice.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
