Re: [Springframework-developer] Spring / HiveMind Integration

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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
> 

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