|
From: Rob H. <ro...@ca...> - 2005-01-29 14:28:38
|
I was thinking of distributing this as one of the first things in the a
separate project containing extensions and add-ons to Spring. I've been
working on a couple of other modules as well which I think should be
kept separate from the core.
Rob
Juergen Hoeller wrote:
>I guess the problem is also about shipping. If HiveMind ships with Spring,
>and Spring would then ship with HiveMind too, it seems to me that we could
>simplify this: Why not put all Spring/HiveMind integration code into
>HiveMind Extras or a Spring-HiveMind project or the like? There would a
>single place to maintain both ways of integration then, for specific
>versions of Spring and HiveMind.
>
>Even if we included HiveMind integration in Spring, we would have to do this
>in a separate distribution, Spring Extras or whatever it would be called. It
>is certainly not feasible to extend the dependencies of the core Spring
>distribution to integration with other lightweight containers, given that we
>already ship all sorts of persistence and web view libraries etc.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Saturday, January 29, 2005 2:54 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
>
>That is a concern, and I guess we could put in hooks to prevent this -
>but I think it is probably simpler to say "Don't do this!".
>
>Rob
>
>Colin Sampaleanu wrote:
>
>
>
>>I'm not sure it really matters, but given that Hivemind already has
>>Spring integration code, and we are talking about Hivemind
>>integration code for Spring, nobody has mentioned that we're going to
>>end up with a circular dependency here... There are some potential
>>versioning issues, but I guess they are a concern if you want to call
>>from Spring to Hivemind back to Spring, or Hivemind to Spring back to
>>Hivemind...
>>
>>Rob Harrop wrote:
>>
>>
>>
>>>Howard,
>>>
>>>I think it will be quite simple to integrate HiveMind services into
>>>Spring. As I see it we need a HiveMindRegistryFactoryBean to create
>>>the Registry instance and then a HiveMindServiceFactoryBean that uses
>>>the Registry to lookup a given service. By default the
>>>HiveMindServiceFactoryBean would use the Spring bean name to lookup a
>>>service in the Registry, but users could configure a different
>>>service name using DI. With this mechanism, users can create one
>>>instance of Registry within a Spring application and then access many
>>>services from that Registry.
>>>
>>>If I have time today, I'll work on this. If not, I'll work on it next
>>>week some time.
>>>
>>>Rob
>>>
>>>Howard Lewis Ship wrote:
>>>
>>>
>>>
>>>>This comes up quite a bit, they are similiar in intent but quite
>>>>different in execution.
>>>>
>>>>- HiveMind has a very sophisiticated configurations model (very
>>>>similar to Eclipse plugins) based on configuration points and
>>>>contributions (from multiple locations)
>>>>- HiveMind is the infrastructure for Tapestry 3.1, and many Tapestry
>>>>applications also use Spring
>>>>- Because Rod and I (and the other Spring team member's I've talked
>>>>to) want to foster cooperation and compatability rather than
>>>>competition
>>>>
>>>>
>>>>On Fri, 28 Jan 2005 10:47:48 +1100, Mason, Ross
>>>><ros...@vi...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Howard,
>>>>>
>>>>>What is the use case for integrating HiveMind and Spring? I must
>>>>>admit I haven't had a chance to get a good look at HiveMind, but my
>>>>>understanding is that it is a DI container that provides service
>>>>>wiring and interception, much in the same vein as the Spring
>>>>>Container. From the outset the two containers seem to be mutally
>>>>>exclusive rather than complimentary.
>>>>>
>>>>>Can you shed some light on this for me?
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Ross
>>>>>
>>>>> -----Original Message-----
>>>>> From: spr...@li...
>>>>>on behalf of Howard Lewis Ship
>>>>> Sent: Wed 26/01/2005 2:46 PM
>>>>> To: spr...@li...
>>>>> Cc:
>>>>> Subject: [Springframework-developer] Spring / HiveMind
>>>>>Integration
>>>>>
>>>>> Since HiveMind 1.0, and improved in HiveMind 1.1, there's
>>>>>been basic
>>>>> integration between HiveMind and Spring.
>>>>>
>>>>> At the core of it is the ability to define a HiveMind
>>>>>service in terms
>>>>> of a Spring bean within a BeanFactory. The essential code is:
>>>>>
>>>>> public Object createCoreServiceImplementation(
>>>>> ServiceImplementationFactoryParameters
>>>>>factoryParameters)
>>>>> {
>>>>> SpringBeanParameter p = (SpringBeanParameter)
>>>>> factoryParameters.getFirstParameter();
>>>>> String beanName = p.getName();
>>>>>
>>>>> BeanFactory f = p.getBeanFactory();
>>>>>
>>>>> if (f == null)
>>>>> f = _defaultBeanFactory;
>>>>>
>>>>> return f.getBean(beanName,
>>>>>factoryParameters.getServiceInterface());
>>>>> }
>>>>>
>>>>> With this, its possible to obtain a Spring bean and the core
>>>>>service
>>>>> implementation of a HiveMind service. The implementation
>>>>>can be
>>>>> extended with interceptors and injected into other HiveMind
>>>>>services.
>>>>>
>>>>> At Javapolis, I talked with Rod about having something
>>>>>similar going
>>>>> the other direction, allowing HiveMind services to be
>>>>>referencable
>>>>> (and injectable) as Spring beans. I'd like to provoke a
>>>>>discussion on
>>>>> what that would look like, and what API changes would be
>>>>>needed in
>>>>> HiveMind 1.1 to support it.
>>>>>
>>>>> Rod seemed to think (and I didn't follow the reasoning) that
>>>>>HiveMind
>>>>> would need an API to iterate over the names of all services.
>>>>>
>>>>> In addition, configuration data (in either List or Map form)
>>>>>is also
>>>>> quite valuable and something that Spring beans would like to
>>>>>have
>>>>> access to.
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
|