Cheers,
Johan
On Tue, 8 Feb 2005 11:06:04 -0500, James Carman <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 11:03 AM To: [email protected] 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 <[EMAIL PROTECTED]> wrote:
instance:mypackage.MyClass,booleanProperty=true,numericProperty=30,stringProThe 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.:
perty='somestring'
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]
