HessianProxyFactoryBean and PropertyPlaceholderConfigurer

[smozely]

Howdy,

I'm trying to use a properties file to be able to externalize the 'serviceUrl' property of my HessianProxyFactoryBean definitions. Seems fair engouh ... but it doesn't work for me ... I keep getting a error

no protocol: ${server.address}/OUCH/hessian/StatusUpdate

from this bean definition

<bean id="hessian.StatusUpdate" class="org.springframework.remoting.caucho.HessianProxyFactoryBean">
<property name="serviceUrl" value="${server.address}/OUCH/hessian/StatusUpdate" />
<property name="serviceInterface" value="nz.co.ouch.hessian.HessianClientInterface"/>
</bean>

and a properties file that defines server.address ... I have been using the server.address in other (written by me) bean definitions for some other services that I can't use the HessianProxyFactoryBean for (e.g. very large file transfer) and that works fine.

Anybody have any idea? ... is it possibly because bean FactoryBeans get handled differently?

Any help appreicated

[Andreas Senft]

Is the PropertyPlaceholderConfigurer located in the same allication context?

Besides that: try turning on debug-level logging to see what is going on when the context gets loaded.

Regards,
Andreas

[smozely]

Hi thanks for the response, yeah it was being loaded in the same application context.

I never really fiugured out what was happening I turned on the debug logging to try and figure out where this was happening and it dissappeared ... turned the logging off and the problem stayed gone. I think it might have to do with the order that PostProcessor beans are being loaded (as I have a custom PostProcesser bean) and if the problem re-occours I will try modifying the Order property of these beans to force the PropertyPlaceholderConfigurer to load first

[Andreas Senft]

Strange, indeed. Besides that, as far as I know post processors are always loaded before other beans in order to do their work.
Anyway, fine that it works now.

[smozely]

Yeah ... I hate saying the problem just fixed itself, but it didn't really, it came back (I must have stuffed up my Text/Prod versions of my XML files).

But this time I did fix it, It was by changing the order attributes on the BeanFactoryPostProcessor's I have defined in my context ... It seems my custom BeanFactoryPostProcessor needed to be run after the PropertyPlaceholderConfigurer (i.e. Higher order number)

This leaves me with one more question ... why did my custom BeanFactoryPostProcessor interfere with the PropertyPlaceholderConfigurer?

All my custom one does is for every bean defined in the context ... if it implements an interface called LifeCycle add init and destroy methods to the definition of the bean.

String[] beanNames = bf.getBeanNamesForType( LifeCycle.class );
 
for( String name : beanNames )
{
AbstractBeanDefinition bd = (AbstractBeanDefinition)bf.getBeanDefinition( name );
String initMethodName = bd.getInitMethodName( );
 
if( ( initMethodName == null ) || ( initMethodName.length( ) == 0 ) )
{
bd.setInitMethodName( "initalize" );
}
 
String destroyMethodName = bd.getDestroyMethodName( );
 
if( ( destroyMethodName == null ) || ( destroyMethodName.length( ) == 0 ) )
{
bd.setDestroyMethodName( "destroy" );
}
}

This just seemed a easy way to save on writing the init and destory on pretty much every bean in the app context .xml files.

And the only relationship I can see is that the HessianProxyFactoryBean is created because one of my beans that implements LifeCycle depends on the HessianProxyFactoryBean.

Any Ideas out there?

[Andreas Senft]

It seems my custom BeanFactoryPostProcessor needed to be run after the PropertyPlaceholderConfigurer (i.e. Higher order number)
...
And the only relationship I can see is that the HessianProxyFactoryBean is created because one of my beans that implements LifeCycle depends on the HessianProxyFactoryBean.

That sounds reasonable. I guess when your post processor is invoked first it tries to handle a bean which gets instantiated in the process. This might cause instantiation of the dependent HessianProxyFactoryBean _before_ the PropertyPlaceholderConfigurer had a chance to do its work. Setting the order flag here is appropriate as the implicit order of post-processors is not specified, as far as I know.

Besides that: Maybe you can do a test: Just have a normal bean implementing Lifecycle and add a placeholder to a property value of it and see how it gets processed with one ordering or the other. It should show the same effect. I would say that the premature instantiation due to postprocessing should show up in the DEBUG log as well.

That said: Glad that you could nail it down