Or of course we could try to work out a schema extensibility mechanism (see http://issues.apache.org/jira/browse/HIVEMIND-70). Then a custom factory would be wrapped around and delegate to the BuilderFactory.
--knut On 5/14/06, James Carman <[EMAIL PROTECTED]> wrote:
Actually, that wouldn't work! What if the other service implementation factory required parameters!?!?! Darn it. -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Sunday, May 14, 2006 10:28 AM To: hivemind-dev@jakarta.apache.org Subject: RE: Changes to BuilderFactory... I was thinking something like this... <service-point id="MyService" interface="com.myco.MyInterface"> <invoke-factory service-id="hivemind.InjectorFactory"> <construct factory-id="SomeOtherServiceFactory"> <!-- Everything that normally goes here --> </construct> </invoke-factory> </service-point> <service-point id="SomeOtherServiceFactory" interface="org.apache.hivemind.ServiceImplementationFactory"> <invoke-factory> <construct class="com.myco.impl.MyServiceImplFactory" /> </invoke-factory> </service-point> Here, you can either supply a class name for InjectorFactory to instantiate (along with constructor params possibly) *or* you can tell it to call another service implementation factory to actually construct the object (constructor param stuff would not be allowed then of course), but it gets the chance to inject it with stuff (stuff is a technical term). If we did it this way, we could just use BuilderFactory and beef it up a bit. There'd be no need to change things around. -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Sunday, May 14, 2006 10:17 AM To: hivemind-dev@jakarta.apache.org Subject: Re: Changes to BuilderFactory... 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] --------------------------------------------------------------------- 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]
