Re: [Springframework-developer] Adding Contribution support

[Howard L. S. <hl...@gm...>]

Have you considered using *both* HiveMind and Spring?  HiveMind has
good integration into Spring, and Rob recently added  integration from
Spring into HiveMind.  Use each for its strengths.



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


On Tue, 22 Feb 2005 08:48:24 -0800, Andy Depue <an...@ma...> wrote:
> I'm going to add my 2c and just throw in what we do.  Our rich client is
> modular, in the sense that if a customer pays for a certain module, then they
> get that functionality.  To easily support this we split each module into its
> own .jar.  Our goal is that if a module's .jar is on the classpath, then its
> "contributions" automatically becomes a part of the application.  Our server
> creates a WebStart .jnlp for each customer with their particular set of
> module .jars setup for their classpath.  Yes, this is basically nothing more
> than a plugin architecture we are talking about.
> So, how do we approach this from a configuration standpoint, seeing that we've
> decided to use Spring and Spring-richclient?  Basically how Rob has
> described.  Each module can specify its own Spring configuration file.  We
> can automatically detect these by requiring all module .jars to have their
> Spring config in the same location and with the same name
> (META-INF/context.xml).  We then pass this into
> FileSystemXmlApplicationContext: "classpath*:/META-INF/context.xml"
> At this point we have one big ApplicationContext containing all the beans for
> all modules.  We now need some way to meaningfully and dynamically connect
> the various beans together.  Modules do not directly reference beans from
> each other, because there is no guarantee that a module is going to be
> present - meaning I can't do something like this:
> 
> <bean id="modelManager" class="...">
>   <property name="modelSources">
>     <list>
>       <ref bean="fooModuleModel"/>
>       <ref bean="barModuleModel"/>
>       ...
>     </list>
>   </property>
> </bean>
> 
> because fooModuleModel and/or barModuleModel might not be present in the
> ApplicationContext.  So, we implement an idea that is similar in spirit to
> "extension points".  For each "extension point" we define a simple Java
> interface, and then the extension point "stakeholder" will query the
> ApplicationContext for beans implementing that interface:
>         Map modelSources =
> BeanFactoryUtils.beansOfTypeIncludingAncestors(getApplicationContext(),
> ModelSource.class, false, false);
> Which will rake in all beans implementing ModelSource.  The interface also
> defines a contract that an extension point contributor must implement in
> order to meaningfully "contribute" to the extension point.  Granted, it would
> be nice if Spring provided some automated way to perform this so I wouldn't
> have to create dependencies on Spring in my classes (ApplicationContext,
> getBeansOfType, etc).
> If Spring wanted to automate this "extension point" mechanism such as it
> exists in our project, it could provide something like this:
> 
> <bean id="modelManager" class="...">
>   <property name="modelSources" extension-point="com.mypackage.ModelSource"/>
> </bean>
> 
> Which would automatically build a collection by gathering all beans that
> implement the specified interface and injecting the collection into the
> "modelSources" property.
> 
>   - Andy
> 
> PS In Spring, this whole idea is currently implemented in "recipe" fashion.
> IoC containers like HiveMind make the idea a first class citizen.  Actually,
> we considered HiveMind, but it is not as mature as Spring and doesn't offer
> many of the advanced integration constructs of Spring.
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>