autowiring remote beans

[Jeanne Boyarsky]

I have this working, but I don't understand something. I am writing a JUnit integration test that uses RmiServiceExporter to test a Spring bean on the server. On the server side, I autowire everything in normally including the JdbcTemplate/DataSource. In my JUnit test, I'm using Test Context framework to inject the bean with the RmiProxyFactoryBean. However, I need a JdbcTemplate/DataSource in the client configuration so the bean can get autowired on the client side. (I gave it a dummy one.)

This is the part I don't understand. As a human, I know that the client side one doesn't need the datasource injected as it will not be called. The bean is only there to make a remote call. Am I doing something wrong? Is there a better way to handle this?

[Mark Spritzler]

Are you injecting by Interface type???

If I have a class that implements an interface and that class truly resides on the serverside. But you have the clientside using the ProxyFactoryBean, you tell the FactoryBean what interface the proxy should implement, which means it won't know of any dependencies like a DataSource on the client side.

So I have a Unit Test that the ProxyFactoryBean creates a bean that implements the interface of the bean that is on the remote side. So on the client side, there is no dependencies like DataSource, JdbcTemplate to inject into the client side.


public interface ServerSideBean{…. (no dependencies here) }
public class RealBean implements ServerSideBean { dependency with @Autowired }

on the client side configuration of RmiProxyFactoryBean

<bean id="localRemoteVersion" class="…RmiProxyFactoryBean">
… set two properties one for RMI URL to lookup the bean the other to tell the Proxy what is it's interface, so in this case ServerSideBean.
</bean>

Mark

[Jeanne Boyarsky]

I am injecting by the interface type. And I'm also wrapping the interface type when creating the proxy. I'm starting to suspect WebSphere weirdness with "what is the client" going on.

[Mark Spritzler]

Jeanne Boyarsky wrote:I am injecting by the interface type. And I'm also wrapping the interface type when creating the proxy. I'm starting to suspect WebSphere weirdness with "what is the client" going on.

Then what on your client are you required to inject the DataSource or JdbcTemplate? There shouldn't be any client classes that need it. right?

Thanks

Mark

[Jeanne Boyarsky]

Mark Spritzler wrote:

Jeanne Boyarsky wrote:I am injecting by the interface type. And I'm also wrapping the interface type when creating the proxy. I'm starting to suspect WebSphere weirdness with "what is the client" going on.

Then what on your client are you required to inject the DataSource or JdbcTemplate? There shouldn't be any client classes that need it. right?

Now that was a good question. You are correct; it had nothing to do with the bean I was injecting. The class I was exploring (which I didn't write and clearly didn't read carefully enough) extends AbstractTransactionalJUnit38SpringContextTests. (Long story why the test is using JUnit 3.8 and not 4.0). I switched it to AbstractJUnit38SpringContextTests and no longer need to inject the transaction.

[Mark Spritzler]

Ah ok, so it was an Integration test with Spring.

Mark