Announcement Announcement Module
Collapse
No announcement yet.
remote proxies behavior in case of transit Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • remote proxies behavior in case of transit

    what we wanted to do is to expose a hessian-remoted service as flex destination. i suppose that's not the behavior ever expected from *ProxyFactoryBean classes (same for Hessian, HttpInvoker and RMI), but anyway.

    please don't question why . we just want to do it.

    when RemotingDestinationExporter of spring-flex tries to create a flex destination for already remoted service it throws NPE when trying to determine targetClass. that apparently happens because all remote proxies have EmptyTargetSource as target source.

    so i wonder if that can be considered a bug in spring-remoting, or it's just inappropriate use and we'll have to fix it ourselves ?

  • #2
    so it seems that in order to fix this the following patch should be applied.

    in HessianProxyFactoryBean.afterPropertiesSet()

    instead of
    Code:
    this.serviceProxy = new ProxyFactory(getServiceInterface(), this).getProxy(getBeanClassLoader());
    this should be used

    Code:
    ProxyFactory pf = new ProxyFactory(getServiceInterface(), this);
    pf.setTargetSource(new SingletonTargetSource(hessianProxy) {
    	@Override
    	public Class<?> getTargetClass() {
    		return getObjectType();
    	}
    });
    this.serviceProxy = pf.getProxy(getBeanClassLoader());
    also HessianClientInterceptor.hessianProxy should be made protected so that you don't need to reflectionally access the field .


    for RMI in RmiProxyFactoryBean i suppose that the same should be done using RmiClientInterceptor.getStub().

    in case of HttpInvokerProxyFactoryBean we don't really have the underlying proxy, so i don't know if it causes problems .

    Comment

    Working...
    X