You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hivemind.apache.org by James Carman <ja...@carmanconsulting.com> on 2006/05/17 13:29:02 UTC

HiveMind 2.0: Dependency Injection

All,

An idea came to me during my morning walk today.  It's amazing what a little
exercise will do for your brain.  Anyway, in HiveMind, dependency injection
should be free (and I do mean as in beer).  If someone wants to write a
custom service implementation factory, they shouldn't be worried about the
dependency injection part and they shouldn't have to use BuilderFactory to
get it.  Here's my idea:

<service-point id="MyService" interface="com.myco.MyService">
  <instance class="com.myco.MyServiceImpl">
    <assembly autowire="true"> <!-- autowire would be on by default -->
      <set property="myDao" value="service:MyDao" />
      <set property="myConfig" value="config:ConfigurationParameters" />
      <listener service-id="MyEventSource" />
    </assembly>
  </instance>
</service-point>

Now, this is for the trivial case where we're not using a "factory", but
here's the syntax for that:

<service-point id="MyService" interface="org.hibernate.SessionFactory">
  <instance factory-id="HibernateSessionFactoryFactory">
    <configuration>
      <mapping file="yadda yadda" />
    </configuration>
    <assembly autowire="false">
      <set property="myDao" value="service:MyDao" />
      <set property="myConfig" value="config:ConfigurationParameters" />
      <listener service-id="MyEventSource" />
    </assembly>
  </instance>
</service-point>

So, within any <instance> element you can give it "assembly instructions"
and HiveMind will wire it together accordingly.  So, the <instance> element
tells us to either instantiate a class directly (using reflection or we can
generate instantiator classes using Javassist if we really want) or call a
ServiceImplementationFactory to get the instance.  This way, a user can
create their own ServiceImplementationFactory and not worry about the
dependencies at all.  HiveMind will take care of that.  If you want to do
constructor-based dependency injection, you would have to use the
"hivemind.CbdiFactory" factory, which would allow parameters to tell it what
constructor to use and what parameters (no params means find the "longest"
possible constructor and use that).  And <implementation> elements can
contain exactly the same thing as <service-point> elements just like we do
now.  So, what do you think?

James 



---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org

Re: HiveMind 2.0: Dependency Injection

Posted by Knut Wannheden <kn...@gmail.com>.

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 <kn...@gmail.com> 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 <ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
> > Sent: Thursday, July 06, 2006 6:22 AM
> > To: hivemind-dev@jakarta.apache.org
> > 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 <ja...@carmanconsulting.com> 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.
> > >
> >
> >
> >
>