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]
