Menu
▾
▴
Re: [Springframework-developer] Spring / HiveMind Integration
|
From: Rob H. <ro...@ca...> - 2005-02-01 14:02:48
|
Howard,
I'm going to spend some time tonight to put some code together for this.
I'll send it over to you.
Rob
Howard Lewis Ship wrote:
>I think you are right about having all the integration code in one
>place. I'd appreciate some help in terms of what the necessary Spring
>code will look like, but it can certainly live in HiveMind.
>
>We should allow the Spring support code to either start up a default
>registry, or to accept a HiveMind registry as a
>configurable/injectable value. We won't know which side, if any, is
>"running the show".
>
>Don't forget about the configurations side of things! Certainly, you
>can consider configurations to just be properties of services, but
>they are in fact stand alone., and it would be very useful for Spring
>to have HiveMind configurations injected into Spring services (as
>either a List or Map property).
>
>
>On Sat, 29 Jan 2005 11:55:22 -0500, jbetancourt <jbe...@co...> wrote:
>
>
>>Why not just go a little further and provide a generic IoC interface? That
>>is, a way for any IoC Container (IoCC) to interact with another.
>>
>>Though there are only a few IoCCs now, there may be more later, or there may
>>be things that are similar, like EJB3 stuff. As with hierarchical
>>containers, you sometimes don't care which level a bean comes from, you also
>>don't care which container is really providing a service. Thus, an
>>application could possibly mix container frameworks and target them where
>>they provide more value-add. Sounds unlikely I guess.
>>
>>
>>----- Original Message -----
>>From: "Colin Sampaleanu" <col...@ex...>
>>To: <spr...@li...>
>>
>>Sent: Saturday, January 29, 2005 10:13 AM
>>Subject: Re: [Springframework-developer] Spring / HiveMind Integration
>>
>>
>>
>>>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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>>>-------------------------------------------------------
>>>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
>>
>>
>>
>
>
>
>
|
