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]
