avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [merlin] problems plugging in type 3 lifestyle
Date Mon, 05 Jan 2004 21:04:55 GMT


> -----Original Message-----
> From: Leo Simons [mailto:leosimons@apache.org]
> Sent: Monday, January 05, 2004 3:30 PM
> To: dev@avalon.apache.org
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message