On Sat, 2004-05-01 at 01:09, Niclas Hedhman wrote:
> 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)?
>
> 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.
Actually, I have a use-case that's got some similar requirements.
I have a service that handles NIO selectors. Basically components can
ask it to open a ServerSocketChannel and it will handle the select()
loop. When it a new connection arrives, the service inserts an entry
into an event queue.
The problem is that I'd like to be able to have the Configuration
specify some ServerSocketChannels to be created at startup, and have
those wired to specific event queues. In other words, connections on the
listener at port 80 go to the HTTP service queue, connections on port 21
go to the FTP queue, and so on.
In the block.xml, I'd list a <dependency/> for each of the output queues
in the NIO component's <component/> definition. But then I'd have to be
able to declare those dependencies for the NIO component's .xinfo to
match, or Merlin won't give 'em to me.
This seems like it would be a fairly common scenario. The set of
services on which a component depends may be a function of the scenario
in which it's deployed, and can't always be determined at compile time.
Of course, there's a chance I haven't thought on this long enough and
there's an alternative arrangement of dependencies that would eliminate
the problem.
You could invert the dependency and have the output queues register
themselves with the NIO component - though in my application, the queues
are fairly dumb objects - they're used all over the place and shouldn't
need to know about registration with their input source. In my case,
it's really a third component that knows about the need for the
dependency - and the person responsible for block assembly knows it,
too.
I guess the idea I'm looking for is a dependency on a *collection* of
(heterogeneous) services. The dependent (the NIO component in my
example) would get a Map back from the ServiceManager#lookup() call, and
the assembler would be able to specify the dependency with something
like:
<component name='nioComponent' class='NIOComponentImpl'>
<dependencies>
<dependency key='outputQueue'>
<entry name='ftp' source='ftpQueue'/>
<entry name='http' source='httpQueue'/>
</dependency>
</dependencies>
The NIOComponentImpl would then have:
/**
* @avalon.dependency type='NIOComponent' key='outputQueue'
*/
public void service( ServiceManager) throws ServiceException {
outputQueues = ( Map) service.lookup( "outputQueue");
}
private Map outputQueues;
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
