The service shouldn't be limited to just "autowiring" scenarios. It should
be able to inject ANYTHING, given the necessary DependencyDescriptor(s).
Something like...
public interface DependencyInjector
{
public void inject( Object bean );
public void inject( Object bean, DependencyDescriptor[] descriptors );
}
Also, would we want to have the option of specifying (maybe in
DependencyDescriptor) a module scope for the dependency? That way, our
programs wouldn't break when we add a new module which defines a new service
implementing the same service interface as our dependency.
Would we ever want to inject configurations into something outside the
registry or do you think that's overkill?
-----Original Message-----
From: Johan Lindquist [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 08, 2005 8:27 AM
To: [email protected]
Subject: Re: <bean> element
I agree with Knut on this one - as you get used to using
interface/implementation pairs, even prototyping becomes a brease
(especially with the refactoring support available in popular IDEs) ...
The pain of refactoring all the descriptors just doesn't seem worth it in
my opinion.
I also like the idea of exposing a service which would auto-wire beans -
would be a +1 from me on that one.
Cheers,
Johan
On Tue, 8 Feb 2005 13:24:34 +0100, Knut Wannheden
<[EMAIL PROTECTED]> wrote:
> I think it would be quite interesting to know what others think about
> this proposal as I'm not sure how I'd personally use it either.
>
> I have in the past argued for supporting interface-less services
> because I think it would be great for prototyping and exploring the
> problem domain. Eventually, as I'm clear on the responsibilities of
> the services, I'd however convert the beans to services.
>
> What this would look like with a top-level <bean> element: If I at
> some point decide to add an interface to my bean and turn it into a
> service then I have to both change the <bean> element into a
> <service-point> *and* change all references to it. References exist as
> type declarations of autowired constructor parameters and setter
> parameters, any uses of the "bean:" object provider, and possibly also
> <set-bean> elements. This means quite a bit of work, which I think in
> the end would keep me from using <bean>s for prototyping.
>
> So I am wondering how others who have argued for interface-less
> services feel about this proposal. What problems would (or wouldn't)
> it solve for you?
>
> I'd prefer if the <service-point> element could be used as is. Beans
> would simply declare the bean class itself as their "interface". All
> other restrictions (e.g. service model) could be enforced by HiveMind.
> But I can see how this could be confusing.
>
> Apart from that there is something I think would be even more useful
> wrt beans: A HiveMind service or a programmatic interface which can be
> used to instantiate and / or autowire beans. I find myself quite often
> defining a factory or repository type of service which builds POJOs
> and where access to autowiring would be very useful.
>
> --knut
>
> On Sun, 6 Feb 2005 13:54:20 -0500, Howard Lewis Ship <[EMAIL PROTECTED]>
> wrote:
>> Part of this has been discussed on the wiki:
>>
>> http://wiki.apache.org/jakarta-hivemind/PojoServices
>>
>> People chafe at the use of interfaces for one-time use objects, but
>> still want all the dependency injection that BuilderFactory provides.
>>
>> Adding a new <bean> element would solve a fair amount of this.
>>
>> It wouldn't be quite inline, it might be more like:
>>
>> <set-object property="databaseAccess" value="bean:DatabaseAccess"/>
>>
>> ...
>>
>> <bean id="DatabaseAccess">
>>
>> <construct class="mypackage.DatabaseAccess">
>> <set-object property="daoService" value="service:DAOService"/>
>> </construct>
>> </bean>
>>
>> In this way, beans would be another namespace like services and
>> configurations, could have visibility, etc.
>>
>> I think we could also dress up the instance: object provider to do
>> some *simple* configuration of the object, i.e.:
>>
>>
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringPro
perty='some
>> string'
>>
>> You can already do some of this using hivemind.lib.BeanFactory.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
you too?
---------------------------------------------------------------------
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]
