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.
On Sun, 6 Feb 2005 10:14:37 -0500, James Carman
<[EMAIL PROTECTED]> wrote:
> Knut,
>
> Maybe. But, is it really necessary to have to place them at the top-level,
> especially if they're going to be used just one time? I guess I'd have to
> see an example descriptor file. Maybe I don't quite get what you guys are
> talking about.
>
> James
>
> -----Original Message-----
> From: Knut Wannheden [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 06, 2005 10:12 AM
> To: HiveMind Dev List; James Carman
> Subject: Re: AOPAlliance Service Interceptors...
>
> James,
>
> On Sun, 6 Feb 2005 09:44:47 -0500, James Carman
> <[EMAIL PROTECTED]> wrote:
> >
> > 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?
> >
>
> Wouldn't Howard's proposed top-level <bean> and the bean: object
> provider solve this? I find that easier to grasp :-)
>
> --knut
>
> ---------------------------------------------------------------------
> 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]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
