Multi-dimensional array brakes HTTP invokers remoting [SPR-5473]

[spring-projects-issues]

Konstantin Bakaras opened SPR-5473 and commented

Hi,
I am using spring HTTP invokers remoting for my client-server interoperation.

When I was using spring 2.5.0 everything worked perfectly. I decided to upgrade 2.5.0 to 2.5.6. After switching Spring's version there appeared a problem with deserialization of remote call result, if the letter has int[][] objects in its object tree.

I also tried spring 2.5.5 and had same error result with.

The issue is definitely on the client side (if I use 2.5.0 on client side and 2.5.6 on server side then everything's OK). I suspect changes have been made with unmarshalling of remote invocation results. Suspicious new class in 2.5.5 is ConfigurableObjectInputStream.

Sample code to reproduce error:

1. Server side exporter bean:
   <bean name="/TestService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
   <property name="service" ref="testService"/>
   <property name="serviceInterface" value="ru.glance.test.client.ITestService"/>
   </bean>

2. Service class:
   package ru.glance.test.service;

import org.springframework.stereotype.Service;

import ru.glance.test.client.ITestService;

@Service
public class TestService implements ITestService {

public int[][] get() {
    return new int[][] `1, 2, 3}, {4, 5, 6}, {7, 8, 9`;
}

}

Client bean:
<bean id="testService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl">
<bean factory-bean="settings" factory-method="getServiceUrl">
<constructor-arg value="TestService"/>
</bean>
</property>
<property name="serviceInterface" value="ru.glance.matrix.client.ITestService"/>
</bean>

---

Affects: 2.5.5, 2.5.6

[spring-projects-issues]

Juergen Hoeller commented

Thanks for pointing this out! Seems we've encountered another difference between "Class.forName" and "ClassLoader.loadClass" there... For OSGi reasons, we have to consistently use the latter. Unfortunately, internal array class names are only really handled by "Class.forName"; so we need to catch up with those names manually.

Fixed as of 3.0 M2.

Juergen