All,
I like the new "syntax" proposed by James. It makes it more uniform by
not having to make the choice between <create-instance>,
<invoke-factory> to use the BuilderFactory or a custom factory. And
most importantly custom factory get the BuilderFactory injection logic
for free.
I'd like to discuss how we should go about implementing this new
proposed "syntax". In the advent of support for Java based and Java
annotations based module definition I don't think we want to put too
much effort into "perfecting" the XML syntax and also I believe we
should keep the XML syntax backwards compatible in this area (with the
option of deprecating old syntax). I can basically see two approaches:
1. We add the <instance> element as a third choice (the other two
being <create-instance> and <invoke-factory>). This approach would
give us the desired <instance> element, guarantee backwards
compatibility, and we'd also have the choice of deprecating the other
two elements.
2. We don't add the <instance> element but instead just add support
for free dependency injection by allowing the proposed <assembly>
element inside any <invoke-factory> element on the same level as the
factory parameter elements. E.g.
<service-point>
<invoke-factory service-id="...">
<custom-param .../>
<assembly autowire-services="true">
<set .../>
</assembly>
</invoke-factory>
</service-point>
So what do you think?
--knut
On 7/6/06, Knut Wannheden <[EMAIL PROTECTED]> wrote:
James,
Defining the <assembly> element using a schema has the advantage that
we can use the HiveMind schema processor as is and don't have to
extend the descriptor parser. (How would we support things like
translators and object providers?) Also, when defined as a schema, the
developer has the ability to define a custom schema for assembly
instructions for his own service factory as long as the resulting
object implement the AssemblyInstruction interface. What problems do
you see with this approach?
If it's just the <include-schema> element you think doesn't feel right
we could of course have HiveMind "automagically" extend every factory
service's parameter schema with the <assembly> element. Anoter
possibility would be to add an attribute like "use-assembly"
(defaulting to 'true') to the <parameters-schema> element. What do you
think?
--knut
On 7/6/06, James Carman <[EMAIL PROTECTED]> wrote:
> 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.
> >
>
>
>
