HTTPInvoker and JavaConfig

[kuvera]

Hello,
I need some help using the proxy factory in the code below. When I use getBean() for the remoteService in the application code, it properly returns the service proxy object. But when I try to inject it into another bean, it doesn't work (ClassCastException is thrown on a $Proxy7 object). Neither with, nor without the factory.getObject() call. Can you tell me how to do it?

(at)Bean
public HttpInvokerProxyFactoryBean remoteService()
{
	HttpInvokerProxyFactoryBean o = new HttpInvokerProxyFactoryBean();
	o.setServiceUrl(Props.getApp().getProperty("sql.servlet.url"));
	o.setServiceInterface(IBatchService.class);
	return o;
}

(at)Bean
public IServiceQueue remoteServiceQueue()
{
	IServiceQueue o = new SwtServiceQueue();
	o.setService((IBatchService) remoteService().getObject());
	return o;
}

[Chris Beams]

There may be an underlying issue worth taking a look at here, but as a general recommendation / best practice, when you're using a FactoryBean in JavaConfig, there's no need to return the FactoryBean object from the @Bean method. Simply return the value of getObject() directly. I've tweaked your example to demonstrate:

(at)Bean
public IBatchService remoteService()
{
	HttpInvokerProxyFactoryBean o = new HttpInvokerProxyFactoryBean();
	o.setServiceUrl(Props.getApp().getProperty("sql.servlet.url"));
	o.setServiceInterface(IBatchService.class);
	return (IBatchService) o.getObject();
}

(at)Bean
public IServiceQueue remoteServiceQueue()
{
	IServiceQueue o = new SwtServiceQueue();
	o.setService(remoteService());
	return o;
}

This is better from a type-safety point of view (no casting in calling methods) and from an information-hiding / encapsulation point of view (the HttpInvokerProxyFactoryBean becomes an implementation detail known only to the remoteService() method. In fact, at that point, it may make more sense to simply call the method service() or batchService(), because callers need not have any awareness that it is remote.

Hope that helps.

[Chris Beams]

By the way - if this doesn't meet your needs, or you'd like to pursue the issue further, please create a new bug in JIRA and attach a simple test case reproducing the issue.

Thanks.

[kuvera]

Chris,
Thank you very much for your answer.
Unfortunately this modification throws another exception with a "Target object must not be null" message during context creation. It looks like factory.getObject() cannot be used within a Configuration class. Please forgive me, but I am too pressed for time right now to create a standalone test case, I will rather go with the code that is working and inject the service manually.
Thanks again.

[Chris Beams]

I reproduced your issue. Turns out it's just an issue with the contract for using HttpProxyInvokerFactoryBean. It must have afterPropertiesSet() in order to actually generate the proxy, etc. This was not being called in your scenario, thus the 'target must not be null' issue.

There are at least two reasonable approaches to solving this, and I've checked them both in to FactoryBeanTests.java in the SJC test codebase. Please take a look here:

https://fisheye.springframework.org/...java?r=675#l52

[kuvera]

Very nice detailed explanation, thank you very much.