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. 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 really think that the problem is that Merlin doesn't really have > support for an object lifestyle that's somewhere between 'singleton' and > 'transient'. Maybe "lifestyle" isn't the right attribute - 'thread' and > 'pooled' are kind of between singleton and transient, but they're along > a different curve. Not sure what you mean by this paragraph, or how it fits in to your problem domain. Feel free to elaborate. > 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. > 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) Cheers Niclas P.S. Try to look into what I am really saying, and not stare yourself blind on the 'extra' that you discard as not needed. -- +---------//-------------------+ | http://www.bali.ac | | http://niclas.hedhman.org | +------//----------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
