> -----Original Message----- > From: Leo Simons [mailto:[EMAIL PROTECTED] > Sent: Monday, January 05, 2004 3:30 PM > To: [EMAIL PROTECTED] > Subject: [merlin] problems plugging in type 3 lifestyle > > Hi gang, > > since Steve and Niclas been saying how much merlin has evolved, I am > giving it one last chance. Not as a user, but as a co-developer. I > figured I'd have a look at implementing IoC type 3 support (again). > Looking for a short execution path I could digest, I started reading in > AbstractMerlinTestCase. It took some effort, but I finally found the > actual instantiation and lifecycle startup code in
<snip> I've also been looking at this and my solution is a little more radical. Basically, one of the issues with Merlin is that Merlin strictly controls what you can get from the ServiceManager while Fortress and Phoenix are much more liberal. This stems from what Stephen has appropriately identified as the mixed roles of the ServiceManager: it's both a ServiceDiscovery component and a DependencyProvider component. Stephen's solution to this problem was to use the ServiceManager only for dependency resolution and throw out service discovery (mostly for security reasons). However, this means that any Fortress or Phoenix apps which took advantage of the liberal lookup methods cannot run in Merlin. So here's my thought: 1. Switch the ServiceManager to provide ServiceDiscovery like Phoenix and Fortress. Make it some sort of privileged component that can be extended, swapped, etc. We could then allow for multiple ServiceManager implementations. 2. Allow either type III IoC or (for backwards compatibility) the ServiceManager for supplying dependencies. Use of the contructor is very secure and we have a great model for how to do that in PicoContainer. The result could be a container which allows for a much wider array of components and lifecycles. If we're going to add type III IoC, this is the way I think it should work. I know that this would require a bit of work. I've started to look into it, but I think this would be the best and clearest approach. Moreover, it would maintain backwards compatibility. Just my $0.02 J. Aaron Farr SONY ELECTRONICS DDP-CIM (724) 696-7653 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
