Re: [Springframework-developer] Spring / HiveMind Integration

[Colin S. <col...@ex...>]

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
>>