Hi, This is more or less what I did in hiveutils.ObjectBuilderFactory, except that just copied/pasted the schema of BuilderFactory... (this is what led me to enter the JIRA-70 that you mentioned actually!)
Cheers Jean-Francois -----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 16, 2006 1:31 AM To: [email protected] Subject: Re: Changes to BuilderFactory... 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: [email protected] > 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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
