I think the injection XML syntax should be a "first-class citizen" and not a
schema that folks have to include if they want it.  I'm still struggling
with how to include it, but I really think it should be just available to
you without configuration.

-----Original Message-----
From: Knut Wannheden [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 06, 2006 6:22 AM
To: [email protected]
Subject: Re: HiveMind 2.0: Dependency Injection

All,

I've been thinking about how to solve the problem with the factory
parameters next to the <assembly> element. And I think this would
probably be a good candidate for the schema extesion request
(HIVEMIND-70). Any service factory which wants to support this free
dependency injection would simply have to define its schema to include
the schema defining the <assembly> element. E.g.

<service-point id="MyFactory" interface="ServiceImplementationFactory">
  <parameters-schema>
    <element name="my">
      <.../>
    </element>
    <include-schema id="hivemind.Assembly"/>
  </parameters-schema>
</service-point>

This would make the dependency injection *almost* free.

HiveMind would then in InvokeFactoryServiceConstructor, after invoking
the service factory, invoke any assembly instructions passed in the
list of parameter objects (as constructed by the SchemaProcessor). It
would identify those by checking whether they implement a given
interface. E.g.

public interface AssemblyInstruction
{
  public void injectDependencies(Object service, AssemblyParameters params);
}

(The AssemblyParameters object would be similar to (probably a subset
of) the ServiceImplementationFactoryParameters object.)

What do you think?

I have already started exploring this idea with some coding. Is this
something we'd want in the trunk or on a separate branch for a later
release?

--knut

On 5/19/06, James Carman <[EMAIL PROTECTED]> wrote:
> I struggled with that too.  But, the assembly instructions tell HiveMind
how
> to assemble the instance that's returned.  So, I thought they should go
> inside the <instance> (or <impl> or <implementation>) element.  The
problem
> with that is that the params for the <instance> have to coexist with the
> assembly instructions.
>


Reply via email to