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,stringProperty='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]
