Howard, How about we change the name of BuilderFactoryLogic to DependencyInjectionLogic? Then, when we reuse it, it's more obvious what we're trying to do. Maybe we should make a DependencyInjector service? Does that make sense?
James -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Sunday, February 06, 2005 9:39 AM To: [email protected]; Knut Wannheden Subject: Re: AOPAlliance Service Interceptors... This has been something people would like ... leverage most of the logic of BuilderFactory, but allow it to build simply POJOs. In fact, I think people want a <bean> element at the same level of <service-point>. To my mind, a <bean> is like a <service-point> except: - No choice on the "factory" - No interceptors - Equivalent to the "primitive" service-model (create on first reference, cache forever) Given the split between BuilderFactory and BuilderFactoryLogic, it should be simple to re-use the BuilderFactory code for creating POJOs. Q: Do we want beans to be able to register for events? Can't see why not. Part of this would be to provide an ObjectProvider. I would say the correct prefix would be "bean:". There's already a "bean:" prrovided by the hivemind library (and based on the BeanFactory service). Although it would break backwards compatibility, I would like to re-appropriate the "bean:" prefix to reference <bean> elements. BTW ... I wish I had called "BuilderFactory" something else, say "DependencyInjectionFactory" or some-such. The terminology, DI, came a bit later. On Sun, 6 Feb 2005 12:24:32 +0100, Knut Wannheden <[EMAIL PROTECTED]> wrote: > James, > > It is in fact not very difficult to implement a PojoBuilder as an > object provider which can perform simple service injection. I'm saying > "simple" service injection because the parameter to an object provider > is just a String which IMO shouldn't be overly complicated only to > carry more information. And note that this wouldn't even require any > changes in HiveMind. > > I was thinking that a locator like "pojo:com.foo.Bar" would have the > object provider construct an instance of com.foo.Bar (using the > longest autowirable constructor) and then autowire all writable > properties for whose type exactly one (visible) service has been > registered. So in that respect the object provider would be quite > limited as it would only be able to do what BuilderFactory does by > default. Yet I think that would be good enough in most cases. > > With such an object provider in place I assume that many method > interceptor factories could be defined with a single service. Would it > make sense to add an object provider like this to HiveMind or would > that be going down the wrong road? > > On the other side I think adding a "name" attribute to the > <interceptor> sounds like a really good idea. Two <interceptor>s > constructed by the same factory could after all be entirely different > as the factory uses the nested elements inside <interceptor> to > construct the interceptor. What do others think about this? > > --knut > > On Sat, 5 Feb 2005 16:00:06 -0500, James Carman > <[EMAIL PROTECTED]> wrote: > > Knut, > > > > I don't see any reason why we couldn't get it in for 1.1. I would agree > > that having to have two services is a bit cumbersome. If we could, like you > > said, inject a MethodInterceptor object into the factory (we have to use > > separate factories to wrap each type of MethodInterceptor because of the > > ordering problem, which we may also want to solve sometime by maybe adding a > > "name" or "orderingName" attribute to the interceptor element), which in > > turn can have other services injected into it, then we're golden. We've > > talked about this before that there needs to be some sort of PojoBuilder or > > something that allows us to build arbitrary objects and inject services into > > them. These objects are not needed as services themselves. I would > > consider these objects to be more along the lines of "infrastructure" or > > "support" objects. But, as we can agree, it's too cumbersome to just let > > them be hidden services (one possible alternative), because you have to > > define a service point and implementation. Then again, if we go down that > > road, we're looking more and more like Spring (which isn't necessarily a bad > > thing). I still think that all services that are exposed via the registry > > should have to be "well-formed" (i.e. have a service interface). > > > > James > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta 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]
