Hi Scott, You could make your QueueManager as a Merlin facility using Merlin 3.3. It would get a reference to the Merlin ContainmentModel from the Context. It could then iterate through the ContainmentModel and find any Queue components. You would design the lookup mechanism, perhaps using fully qualified component name to look up the particular Queue you are interested in, and each Queue consumer would get passed its Queue name in its configuration or something.
Your Queue consumers could then declare a dependency on your QueueManager, and use it to request their particular Queue. In this way, Merlin is managing the lifecycle of all your components, and your Queue components remain dumb. Is this something like what you were looking for? -Cameron On Fri, 2004-05-07 at 13:50, Scott Brickner wrote: > On Fri, 2004-05-07 at 13:19, Niclas Hedhman wrote: > > On Saturday 08 May 2004 00:40, Scott Brickner wrote: > > > > > And the answer? "Make your own component to > > > manage the component lifecycle." > > > So why use Merlin? > > > > Well, you brought up that the "queues" are dumb, can't declare a > dependency on > > their source, and not up to register themselves at the source. > > > > > > > Well, there are really only one or two out of the two dozen queues > in > > > the system that would need to do this sort of registration. > > > > I think you missed the point. > > > > > So, more than ninety percent of the queues have their event > sources > > > depend directly on the queues. The assembler knows enough to set > up the > > > dependency for this case, too. All of these proposals seem like > hack > > > jobs to get around a limitation in Merlin for a case that seems > > > reasonably common. > > > > Not correct. Management of your own lifecycle, I can agree is a > hack, because > > you brought up that those components are not cut to interact with > the rest of > > the system by themself, hence need someone to do it for them. > > > > You have now clarified that this is not the case; > > THEN I will insist that the pattern of registration of yourself onto > your > > dependency, IS the way to handle this kind of scenario, which you > rightly > > says is quite common. > > Hm. I'm not sure I expressed myself clearly on the components here. > The > queues are designed to be *depended upon*, not depend on their > sources. > At one time, I actually had the dependency in the other direction for > the whole system, but it introduces circular dependencies in a way > that > make the structure far too inflexible. > > As a result, the queues have no dependencies - components that produce > events depend on a queue as a Sink, and components that consume events > depend on the queue as a Source. The queue itself is really just > Configurable so that it can be properly managed. > > The specific problem here is that the number of dependencies needs to > change at assembly time. The "natural" solution is to have the NIO > component be able to get a collection of output queues that it > determines how to use at runtime. > > Merlin doesn't support that, however, so to do it, we'd have to take > over responsibility for the lifecycles of the relevant components. > > As an alternative we can introduce another component that mediates the > relationship. So now we have this hypothetical new component that > receives the output from the NIO component and *it* demultiplexes the > output to the various queues. This component has to basically be > custom > built for the application (though it's easy to do) so that it can have > explicit dependencies on the queues. > > The third alternative is to have a modified version of the queue that > knows it's supposed to register itself with the mediating component, > and > is given a dependency on the mediator. > > So, in the way I *want* to do it, the source (NIO component) depends > on > all the queues. The first alternative has the source depend on a > custom > mediator and the mediator depend on the queues. The third solution is > to > have the source depend on a generic mediator and have custom queues > depend on the mediator. > > I think that the first solution seems a natural way to describe the > dependencies and that both of the two alternatives are less natural. > As > a result, I called them "hacks to get around a limitation in Merlin". > > > > > What is NOT common, is that what you see as a solution to the > 'reversed > > dependency' issue will not solve 'all' or even 'most' cases. The > above > > pattern does solve most cases. > > I'm not sure I agree here. The specific case of a homogeneous, but > variable size, collection of dependents for a component. I've got one > case here. The original thread that I replied to had another. In his > case, he had a variable collection of data sources he was trying to > multiplex. > > In both cases, we've got a number of components, all of which > implement > a common interface, that we want to able to hook together with the > same > dependent. In both cases, it's awkward to have the collection elements > know about the dependent - the dependency naturally runs the other > direction. But in both cases, Merlin doesn't support it. > > > > > The situation here is one of multiple homogeneous dependencies. I > think > > > ServiceSelector used to help fill this function, but > ServiceSelectors > > > have inadequate semantics, and it looks like they're being treated > as > > > fatally flawed. > > > > The Selectors did exactly the same as your proposal, providing a > non-generic > > solution, mixing the concern of "Query" and "Dependency" into a > single > > mechanism. > > I've got no problem with trying to keep these concerns separate. But > there's no simple mechanism for doing the "Query" part. I have to roll > my own in each case. Perhaps Selectors were *too* general - they took > an > arbitrary Object as the "policy". The obvious attempt there was to > supply a way to do arbitrary queries. Having no type for the query > parameter almost guaranteed that it wouldn't be portable across > containers. > > > > Nevertheless, I think this is a legitimate scenario, and one that > the > > > container should be able to deal with, I shouldn't have to roll my > own > > > solution. > > > > The "Registration of Dependee on its Dependency" is not a matter of > "roll your > > own". > > If you still think I am an idiot who doesn't understand your > problem, the only > > final advice I can give; If am not mistaken, Phoenix supported > lookup of > > arrays of components, and you might find that this functionality is > still > > around in Loom (http://loom.codehaus.org) which is the continuation > of > > Phoenix. Not that I would like to loose a user, but you won't see a > mix-up > > between Dependency resolution, and Component Querying, as long as I > and > > Stephen are around :o) > > Ok. Don't mix them. Where's the Component Query solution? Do we just > throw that out? > > I've got a simple solution - allow me to get something that supports a > simple query mechanims, a Map from key name to the corresponding > component. I need a simple way to get to the query mechanism too - > lookup seems the natural solution there. > > That's exactly what my suggestion was... an extended syntax for the > <dependency/> tag that let me set up the Map, and which also told the > lookup mechanism that the lookup would return the queryable Map. > > As the system currently stands (and I admit, I've not had the time to > look at 3.3 yet), there's no query at all. So this scenario - which is > plenty common, I've seen you describe these sorts of solutions to a > number of dependency problems in the past - really doesn't have a > satisfactory solution in the current incarnation of Merlin. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
