[Springframework-developer] RetryableBean

[Bryant H. <bry...@ho...>]

Hi,
  I've got a Spring related class I wrote a couple of years ago that is 
obvious enough that it might already exist in Spring but thought I'd mention 
it if you would like to take a look.

  It is useful in places where a bean might have external dependencies (such 
as a JMSFactory that is trying to connect to a remote broker) which could 
cause the spring initialization to fail.

  Basically it creates a proxy as a place holder bean and the first time a 
method on the bean is invoked the proxy tries to create the actual object 
(which may or may not fail).  This allows the spring startup up to succeed. 
The retry semantics of the proxy allow it to recreate the underlying bean as 
needed.  To continue the example of JMS we use this so that if we forget to 
start our broker the server comes up fine, when the broker finally starts it 
heals, etc.

  The stripped down configuration looks as follows:

<bean id="jms.connectionFactory" 
class="com.iris.platform.runtime.infra.spring.RetryableSpringBeanWrapperFactory" 
destroy-method="dispose">
    <property name="configLocation" value="jms.xml" />
    <property name="beanName" value="jms.managedConnectionFactory" />
    <property name="interfaces">
        <list>
            <value>javax.jms.ConnectionFactory</value>
            <value>javax.jms.TopicConnectionFactory</value>
            <value>javax.jms.QueueConnectionFactory</value>
        </list>
    </property>
</bean>

jms.xml might contain something like
<beans>
    <bean id="jms.managedConnectionFactory" 
class="org.apache.activemq.ActiveMQConnectionFactory">
        <constructor-arg><ref bean="${jms.broker.url}" /></constructor-arg>
    </bean>
</beans>

The property configLocation basically tells the wrapper where to load (and 
reload) its configuration with the beanName obviously being the bean in the 
spring context to forward invocations to.  The interface list of course 
defines what is exposed on the proxy.

There's more but I didn't want to overload the email if this either 
duplicates existing work in spring or there's no interest.  I've also used 
it to get around bootstrapping issues with Spring and a legacy framework. 
In that case the legacy startup process bootstrap spring, so I wrap 
references to the legacy services so I can inject them into POJOs as I would 
any other bean even though the services are still being initialized while 
the Spring framework is starting.

Regards,

Bryant