Knut, Maybe. But, is it really necessary to have to place them at the top-level, especially if they're going to be used just one time? I guess I'd have to see an example descriptor file. Maybe I don't quite get what you guys are talking about.
James -----Original Message----- From: Knut Wannheden [mailto:[EMAIL PROTECTED] Sent: Sunday, February 06, 2005 10:12 AM To: HiveMind Dev List; James Carman Subject: Re: AOPAlliance Service Interceptors... James, On Sun, 6 Feb 2005 09:44:47 -0500, James Carman <[EMAIL PROTECTED]> wrote: > > Well, I think if we're going to do this (generic, dependency injection > capable object builder), we should do it the right way. As soon as we > implement an object provider with this limited capability and no > work-around, someone is going to ask for an improvement. Then, we're going > to end up trying to encode dependency information (like what service-id to > use when there are multiple services of the property type) into the "locator > string." What I would like to do would be something like this... > > <invoke-factory service-id="hivemind.BuilderFactory"> > <construct class="myco.services.impl.MyServiceImpl"> > <set-object property="a"> > <construct class="myco.helpers.A" /> > </set-object> > <set-object property="b"> > <construct class="myco.helpers.B"> > <set-service property="c" service-id="mymodule.A" /> > </construct> > </set-object> > </construct> > </invoke-factory> > > Maybe we should let object providers provide a schema of their own. > Wouldn't that do the trick? > Wouldn't Howard's proposed top-level <bean> and the bean: object provider solve this? I find that easier to grasp :-) --knut --------------------------------------------------------------------- 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]
