Menu
▾
▴
Re: [Springframework-developer] Spring / HiveMind Integration
|
From: jbetancourt <jbe...@co...> - 2005-01-29 16:55:42
|
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
>
|
