We should probably start a Wiki page for all of these neat ideas! :-)
-----Original Message----- From: Achim Hügen [mailto:[EMAIL PROTECTED] Sent: Friday, May 19, 2006 6:36 AM To: [email protected] Subject: Re: HiveMind 2.0: Dependency Injection 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: [email protected] > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
