Ok, that makes the syntax more consistent and intuitive. Today, the
<invoke-factory> element
is not very intuitive in the standard case that uses BuilderFactory.
A refactoring of the assembly/injector part would come in handy for the
annotation
support, too.
Achim
James Carman schrieb:
In the second example, the factory will build the core object and HiveMind
will take care of "assembling" it (injecting stuff into it). Yes, the
factories would still be parameterizable. The second example includes
parameters. I'm not married to the syntax per se, just the idea. The main
idea is that HiveMind does the injecting and you can customize it by
including "assembly instructions." I'll respond to the annotation stuff
soon. :-)
James
-----Original Message-----
From: Achim Hügen [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 18, 2006 5:41 PM
To: hivemind-dev@jakarta.apache.org
Subject: Re: HiveMind 2.0: Dependency Injection
Nobody has any feedback about this?
Only if I get feedback about my 'Hivemind annotations' mail in return ;-)
Just for clarity, old syntax vs. new syntax:
Old:
<service-point id="MyService" interface="com.myco.MyService">
<invoke-factory>
<construct class="com.myco.MyServiceImpl">
<set property="myDao" value="service:MyDao" />
New:
<service-point id="MyService" interface="com.myco.MyService">
<instance class="com.myco.MyServiceImpl">
<assembly autowire="true">
<set property="myDao" value="service:MyDao" />
<instance> seems to be similar to <create-instance> available today, isn't
it?
Additionally it can do the assembly, probably by using a separate
wiring and autowiring component.
In your second example: Who is responsible for the assembly? The factory
or the <instance> element?
Is a factory still parameterizable? Are <configuration> and <assembly>
parameters of the factory or parameters of <instance> ?
Achim
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
