CentSpring: Community Enterprise Spring Framework?

If Spring is going to stop putting out maintenance releases to the community at large after either three months or when the next release is out, do we simply need another organization to look at the maintenance branch and bundle up the work for us?

In essence, CentOS is to RedHat what X is to SpringSource.  Solve for X.

Spring-Enabled vs. Spring-Dependent

It's getting surprisingly common for projects (e.g. Enunciate, CXF) to bundle Spring amongst their dependencies, which is creating a bit of "DLL-hell" - having to make exclusions for various versions of Spring and make sure that all the projects can agree on a particular version of Spring.

Requiring Spring to work at all makes these projects spring-dependent in a way that I'm not entirely happy with. Personally, I'd prefer them to be spring-enabled, whereby they are well-suited to being injected in your project, but can operate without Spring, and therefore, don't come with their own version of Spring with which you have to negotiate.

I'm not opposed to there being multiple modules available -- a module that is spring-enabled for projects already using spring, and a module that's spring-dependent for projects not otherwise using spring or not worried about the particular version of Spring. That seems like a handy way around the problem.

Enunciate's case is somewhat forgiveable, in that it's generating a WAR that includes Spring MVC code. I haven't investigated CXF's dependency on Spring, but it's causing some grief for a colleague.

Spring-Loaded Observer vs. TypeCollectorFactory

I've just re-read Scott Priolo's Spring-Loaded Observer Pattern on TSS. I had a similar desire to work with something like the observer pattern for an event model on a recent project. Scott's pattern works reasonably well, but you do end up having a fair amount of Spring XML for each listener you want to add. The MethodInvokingFactoryBean is a reasonable approach, but nine lines of Spring XML to inject a single observer can be a fair amount of Spring code, if you have a lot of listeners. (To be honest, I also hadn't thought about using it, but even seeing it, I prefer the pattern I've employed).

So where Scott's example does this:

<bean id="registerTownResident1"
  class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
   <property name="targetObject"><ref local="townCrier"/></property>
   <property name="targetMethod">
     <value>addListener</value>
   </property>
   <property name="arguments">
     <list>
       <ref bean="townResident1"/>
     </list>
   </property>
</bean>

I've done this:

<bean name="eventService" 
  class="CoreEventService">
  <parameter name="eventListeners">
  <bean class="SpringTypeCollectorFactory">
     <parameter name="typeToCollect" 
       value="EventListener" />
   </bean>
 </parameter>
</bean>

The SpringTypeCollectorFactory simply grabs all the items of a particular type from the context and collects them up in a list which it returns. This allows me to simply declare event listeners that match the EventListener interface and voila, they're injected into the event service.

More importantly, it means that client projects which consume our core spring configuration can simply add their own event listeners to their own Spring files and these two are picked up and added into the core event service.

Since this seems like something other people might be able to find good uses for, I'm sharing it, both here (this blog entry), and here.