Knut,
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?
James
-----Original Message-----
From: Knut Wannheden [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 06, 2005 6:25 AM
To: [email protected]
Subject: Re: AOPAlliance Service Interceptors...
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
