Menu
▾
▴
Re: [Springframework-developer] Spring / HiveMind Integration
|
From: Colin S. <col...@ex...> - 2005-01-29 15:14:06
|
Yes, I have to agree this probably makes sense... It's a little less
convenient, but resolves versioning issues. One question is whether you
can do a good enough integration that way, but I would that would not be
an issue, it's not like you want to make one container dependent on the
other anyway at it's core, so any integration should be at a higher level.
Juergen Hoeller wrote:
>I was mainly wondering whether it makes sense to separate HiveMind/Spring
>integration and Spring/HiveMind integration... Shouldn't we put both into
>the *same* distribution?
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Saturday, January 29, 2005 3:27 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>
>
>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
>>>>>>
>>>>>>
|
