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:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 11:39 AM To: [email protected] 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 <[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: > >> 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:[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.: >>>> >>>> >> > 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> > > > -- you too? --------------------------------------------------------------------- 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]
