Maybe a kind of InjectorDelegate service, where the (partially) constructed service is passed to another service to do some of the work (with a corresponding XML element, say <delegate object="service:Biff"/> ?
On 5/14/06, James Carman <[EMAIL PROTECTED]> wrote:
What would be nice would be if we could "wrap" the injection logic around another factory. So, if a custom implementation factory does have to be written for some reason (Hibernate configuration stuff, maybe), the resulting object can still be injected via the Injector factory. Maybe one change we could make to the schema would be to tell Injector to actually call another service implementation factory to get the object and then inject stuff into it. What do you think? -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Sunday, May 14, 2006 10:00 AM To: hivemind-dev@jakarta.apache.org Subject: Re: Changes to BuilderFactory... I'd like to see that. Tapestry uses a number of threaded services. It would be nice if they could be instantiated quickly. I would like to see BuilderFactory maintained for compatibility, and replaced with a code-and-syntax streamlined Injector (or InjectorFactory). Something like: <invoke-factory service-id="hivemind.Injector"> <construct class="BarImpl"/> <inject property="foo" object="service:Foo"/> <set property="timeout" value="100"/> <event-listener object="service:Hub"/> </invoke-factory> Note: not nested, just <construct> first. For inject-via-constructor, we might want elements inside <construct>. <inject> is always an object reference. <set> is for literals (but will translate from string to property type as needed). I think <module> should also have a @default-factory attribute. In this way, we can allow the same easy access to hivemind.Injector that we currently get with hivemind.BuilderFactory (i.e., omit the service-id from the <invoke-factory> element). In a much later release, we can switch the meta-default from BuilderFactory to Injector. I've also been thinking again about properly dealing with threaded services and <event-listener>. My current thinking is that we need to un-register implementations as listeners during thread cleanup (to balance registerring the implementations during service construction). I still have as many idea for HiveMind as for Tapestry, and so little time ... On 5/14/06, James Carman <[EMAIL PROTECTED]> wrote: > Oops. I forgot to call factory.getObject() on the factory that I get out of > the map, but you get the idea. :-) > > > -----Original Message----- > From: James Carman [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 14, 2006 8:16 AM > To: hivemind-dev@jakarta.apache.org > Subject: Changes to BuilderFactory... > > All, > > Howard came up with an idea a while back. Instead of using reflection to > build objects in BuilderFactory, why don't we have BuilderFactory generate a > class via Javassist which builds the object? It'd look something like this: > > public Object > createCoreServiceImplementation(ServiceImplementationFactoryParameters > params) > { > if( !factoryMap.containsKey( params.getServiceId() ) > { > // Dynamically generate a factory class and put it in the map. > } > return ( Factory )factoryMap.get( params.getServiceId() ); > } > > I've implemented it before in my "Syringe" project and it works quite > nicely. Of course, this is really only useful for non-singleton services. > But, for singleton services, it shouldn't be too much overhead. What do you > guys 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- 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]
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
