I am on the same boat as Knut. Initially I did think that "beans" will be useful but in the last year I have seen no use for a bean when configurations are available. Now that does NOT mean that there is no need for it, but I personally would like see a concrete scenario where it can be useful before giving my vote. My current stand is managed objects are always either services or configurations.
-Harish 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
