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.
