You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2005/02/06 19:54:20 UTC
element
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
<ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
> 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
> <ja...@carmanconsulting.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Albert Kwong <ma...@yahoo.com>.
I think <bean> with DI would be useful for a pattern
where service A depends bean B which in turn depends
on service C. Bean B could be a stateful object that
manages some states on behalf of service A. Another
service D may also depend on another instance of bean
B with independent states.
We can somehow simulate this pattern now with threaded
service model, if service A and service D do not
interleave.
We can also simulate it with a singleton service that
has a state object on every parameter. However this
doesn't look very OO.
Yet we can also do it with ObjectProvider. In this
case the ObjectProvider of bean B will have dependency
on all the services B depends on. When it provides
bean B, it will instantiate it, inject the
dependencies, and return the bean. <bean> + DI shall
be able to reduce the need for the OP in this case.
On the other hand, are we still using the setters on
the bean for DI? A bean's setter may be there for
application use rather than DI. Can we describe the
bean so that some setters are ignored. Can we
configure beans (or services) to use injectXXX for DI
rather than setters?
Albert
--- Knut Wannheden <kn...@gmail.com> 內容：
> 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
> <hl...@gmail.com> 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:
> hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> hivemind-dev-help@jakarta.apache.org
>
>
=====
Are you an MBA? Check out http://www.mba.hk for value added services.
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
I guess i am thinking that the service using the dependancy injector would
have some knowledge of what it is trying to auto-wire/inject service into
and would itself be wired with the correct implementation of the services
required (should there be a conflict) and if there was a problem resolving
a service, it could handle it. But i realise now that the object you are
auto-wiring should not have to rely on the caller for this.
To then separate things even further, I guess you could describe an
objects dependancies as a hivemind configuration and the
DependancyInjector could use those to resolve conflicts:
<contribution configuration-id="hivemind.DependancyInjector">
<bean class="com.acme.JavaBean">
<dependancy property="service" service-id="some.module.ID"/>
</bean>
</contribution>
This would allow you to simply do inject(object); or? Only limit would be
that a bean could not be injected with different services depending on the
caller ...
Cheers,
Johan
On Tue, 8 Feb 2005 11:42:16 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
>
> How does the "resolver pattern" differ from mere auto-wiring? The
> problem
> with auto-wiring is that your dependencies can be injected just fine at
> one
> point. But, suppose you add in another module to your application which
> exposes another service that implements the service interface you were
> using. Then, all of a sudden, your stuff (which used to work) breaks!
> Yuck!
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:39 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> Yup, missed it fully - and yes, that makes sense ... :) It would however
> build in knownledge about service id's etc (which would have to be kept
> in
> synch) into the code, but I guess that is not the biggest of problems.
> What about using some sort of ResolverPattern? For this service
> interface, give me the instance to use??
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> Johan,
>> I think you may be missing my point. The dependency descriptors would
>> describe services within the registry. It would be necessary when there
>> are
>> cases where there are two services which implement the same service
>> interface. A dependency descriptor might look something like...
>>
>> public class DependencyDescriptor
>> {
>> private String propertyName;
>> private Class propertyType;
>> private String serviceId;
>> private String moduleId;
>>
>> // Setters/Getters...
>> }
>>
>> I'm not so sure if the propertyType is necessary, as it can be
>> determined
>> via reflection at runtime.
>>
>> James
>>
>> -----Original Message-----
>> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 11:03 AM
>> To: hivemind-dev@jakarta.apache.org
>> Subject: Re: <bean> element
>>
>> I would be happy with just the first case to begin with - whatever is
>> registered within the registry, inject it, otherwise, well, too bad ...
>> If
>> we need to start defining further descriptors outside of the registry,
>> we
>> sort of break the usage of hivemind in the first place or?
>>
>> And I think that having the ability to inject configurations would be
>> good
>> in that you could use that config for display purposes (in a separate
>> part
>> of the system) ...
>>
>> Cheers,
>>
>> Johan
>>
>> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>
>>> 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:johan@kawoo.co.uk]
>>> Sent: Tuesday, February 08, 2005 8:27 AM
>>> To: hivemind-dev@jakarta.apache.org
>>> 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
>>> <kn...@gmail.com> 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
>>>> <hl...@gmail.com>
>>>> 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: hivemind-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
Johan,
How does the "resolver pattern" differ from mere auto-wiring? The problem
with auto-wiring is that your dependencies can be injected just fine at one
point. But, suppose you add in another module to your application which
exposes another service that implements the service interface you were
using. Then, all of a sudden, your stuff (which used to work) breaks!
Yuck!
James
-----Original Message-----
From: Johan Lindquist [mailto:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 11:39 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: <bean> element
Yup, missed it fully - and yes, that makes sense ... :) It would however
build in knownledge about service id's etc (which would have to be kept in
synch) into the code, but I guess that is not the biggest of problems.
What about using some sort of ResolverPattern? For this service
interface, give me the instance to use??
Cheers,
Johan
On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
> I think you may be missing my point. The dependency descriptors would
> describe services within the registry. It would be necessary when there
> are
> cases where there are two services which implement the same service
> interface. A dependency descriptor might look something like...
>
> public class DependencyDescriptor
> {
> private String propertyName;
> private Class propertyType;
> private String serviceId;
> private String moduleId;
>
> // Setters/Getters...
> }
>
> I'm not so sure if the propertyType is necessary, as it can be determined
> via reflection at runtime.
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:03 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I would be happy with just the first case to begin with - whatever is
> registered within the registry, inject it, otherwise, well, too bad ...
> If
> we need to start defining further descriptors outside of the registry, we
> sort of break the usage of hivemind in the first place or?
>
> And I think that having the ability to inject configurations would be
> good
> in that you could use that config for display purposes (in a separate
> part
> of the system) ...
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> 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:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 8:27 AM
>> To: hivemind-dev@jakarta.apache.org
>> 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
>> <kn...@gmail.com> 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 <hl...@gmail.com>
>>> 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: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Yup, missed it fully - and yes, that makes sense ... :) It would however
build in knownledge about service id's etc (which would have to be kept in
synch) into the code, but I guess that is not the biggest of problems.
What about using some sort of ResolverPattern? For this service
interface, give me the instance to use??
Cheers,
Johan
On Tue, 8 Feb 2005 11:06:04 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> Johan,
> I think you may be missing my point. The dependency descriptors would
> describe services within the registry. It would be necessary when there
> are
> cases where there are two services which implement the same service
> interface. A dependency descriptor might look something like...
>
> public class DependencyDescriptor
> {
> private String propertyName;
> private Class propertyType;
> private String serviceId;
> private String moduleId;
>
> // Setters/Getters...
> }
>
> I'm not so sure if the propertyType is necessary, as it can be determined
> via reflection at runtime.
>
> James
>
> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 11:03 AM
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: <bean> element
>
> I would be happy with just the first case to begin with - whatever is
> registered within the registry, inject it, otherwise, well, too bad ...
> If
> we need to start defining further descriptors outside of the registry, we
> sort of break the usage of hivemind in the first place or?
>
> And I think that having the ability to inject configurations would be
> good
> in that you could use that config for display purposes (in a separate
> part
> of the system) ...
>
> Cheers,
>
> Johan
>
> On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
> <ja...@carmanconsulting.com> wrote:
>
>> 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:johan@kawoo.co.uk]
>> Sent: Tuesday, February 08, 2005 8:27 AM
>> To: hivemind-dev@jakarta.apache.org
>> 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
>> <kn...@gmail.com> 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 <hl...@gmail.com>
>>> 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: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
Johan,
I think you may be missing my point. The dependency descriptors would
describe services within the registry. It would be necessary when there are
cases where there are two services which implement the same service
interface. A dependency descriptor might look something like...
public class DependencyDescriptor
{
private String propertyName;
private Class propertyType;
private String serviceId;
private String moduleId;
// Setters/Getters...
}
I'm not so sure if the propertyType is necessary, as it can be determined
via reflection at runtime.
James
-----Original Message-----
From: Johan Lindquist [mailto:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 11:03 AM
To: hivemind-dev@jakarta.apache.org
Subject: Re: <bean> element
I would be happy with just the first case to begin with - whatever is
registered within the registry, inject it, otherwise, well, too bad ... If
we need to start defining further descriptors outside of the registry, we
sort of break the usage of hivemind in the first place or?
And I think that having the ability to inject configurations would be good
in that you could use that config for display purposes (in a separate part
of the system) ...
Cheers,
Johan
On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> 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:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 8:27 AM
> To: hivemind-dev@jakarta.apache.org
> 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
> <kn...@gmail.com> 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 <hl...@gmail.com>
>> 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: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
I would be happy with just the first case to begin with - whatever is
registered within the registry, inject it, otherwise, well, too bad ... If
we need to start defining further descriptors outside of the registry, we
sort of break the usage of hivemind in the first place or?
And I think that having the ability to inject configurations would be good
in that you could use that config for display purposes (in a separate part
of the system) ...
Cheers,
Johan
On Tue, 8 Feb 2005 08:45:18 -0500, James Carman
<ja...@carmanconsulting.com> wrote:
> 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:johan@kawoo.co.uk]
> Sent: Tuesday, February 08, 2005 8:27 AM
> To: hivemind-dev@jakarta.apache.org
> 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
> <kn...@gmail.com> 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 <hl...@gmail.com>
>> 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: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by James Carman <ja...@carmanconsulting.com>.
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:johan@kawoo.co.uk]
Sent: Tuesday, February 08, 2005 8:27 AM
To: hivemind-dev@jakarta.apache.org
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
<kn...@gmail.com> 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 <hl...@gmail.com>
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
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
<kn...@gmail.com> 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 <hl...@gmail.com>
> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Harish Krishnaswamy <ha...@gmail.com>.
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
<kn...@gmail.com> 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 <hl...@gmail.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: element
Posted by Knut Wannheden <kn...@gmail.com>.
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 <hl...@gmail.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
RE: element
Posted by Jean-Francois Poilpret <jf...@hcm.vnn.vn>.
Hello,
I would like to add a few thoughts to this discussion.
I am currently trying to use HiveMind in client (Swing GUI application) and
in the current status (HM1.0, but HM1.1a1 would not bring much to me now), I
found the need for a "PojoFactory", but with needs wider than the ones you
describe.
In particular, I don't need "one-time" objects, but rather need a real
"factory" able to build several instances of the same pojo according to the
same configuration. The number of instances to create is never known in
advance (each instance can be a JPanel, a JTable...)
I finished building my own "ObjectBuilder" service (I would have preferred
"BeanFactory"...) with a very simple interface:
Object create(String name);
And a quite simple configuration (I did not try to reproduce the exact same
features as BuilderFactory, in particular I did not want/need auto-wiring):
<contribution configuration-id="ObjectBuilderObjects">
<object name="MyName" class=" MyClass">
<inject object="service:EventDispatcher"/>
</object>
<object name="OtherName" class="OtherClass">
<inject name="myProperty" object="object:MyName"/>
</object>
</contribution>
The contributions are quite simple since they reuse the "object" translator
and thus can inject:
- services
- configurations
- instances
- beans
- ...
Both constructor and setter injections are supported (if the "name"
attribute is defined then setter-injection is used).
I also added a new ObjectProvider (called "object:") so that other pojos can
be injected also (both in pojos and in services).
It would easily be possible to add new configuration settings so that a name
defines a unique instance (in cases where this would be necessary).
The first version I wrote was a breeze, thanks to HiveMind PropertyUtils and
ConstructorUtils.
Then very quick I discovered problems while using the ObjectTranslator: it
is only evaluated once and very early (as soon as the "ObjectBuilderObjects"
is read by the ObjectBuilder service). This involved two problems:
- all injections (pojos, beans, services, configs...) are instantiated at
the beginning of the application, even if the objects that use these
injections are never used!
- early evaluation could induce recursive calls inside HM (eg: inject a
configuration that itself uses the "object:" ObjectProvider)
So my second version added late evaluation of all injections: for this I
just passed the "object" attribute value as a String (ie, I did not use the
ObjectTranslator anymore at the configuration level). Then the ObjectBuilder
service itself would resolve all injections (by calling the ObjectTranslator
directly, which will be a problem in HM1.1 since the ObjectTranslator has
now private visibility).
Finally, my current version (maybe not the last one however) added the
possibility to inject constructor arguments directly through a new
ObjectBuilder.create(String name, Object[] args) method. In the config, I
just added a new <inject-arg/> empty element to indicate this fact.
This can be used, for instance, to build a JPanel subclass instance, with
some injected services (always the same) plus an additional parameter like
the DTO to show in the panel (which is always different and cannot be
statically configured).
I don't know if I am off-topic here, but I wanted to express my viewpoint
that a new <bean> element to define _individual_ pojos does not seem
interesting to me (I much prefer the service concept with interfaces). What
seems really interesting to me is to have the possibility to create several
instances of one class, with some injected args, and some user-passed args.
I am not sure this would be much useful on the server side, but for sure it
could bring much on the client GUI side (when I have finished my
ObjectBuilder, it eased a lot about adding new panels, new tables... in my
GUI).
Cheers
Jean-Francois
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Monday, February 07, 2005 1:54 AM
To: hivemind-dev@jakarta.apache.org
Subject: <bean> element
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.
On Sun, 6 Feb 2005 10:14:37 -0500, James Carman
<ja...@carmanconsulting.com> 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:knut.wannheden@gmail.com]
> 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
> <ja...@carmanconsulting.com> 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: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
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: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org