GWT SeralizationStreamFactory проблема чтения

Question

У меня есть веб-приложение, встроенное в GWT, которое должно отправлять и получать сериализованные данные на всей клиентской стороне.(Я использую веб-работников и мне нужно обмениваться данными между основным потоком и веб-работниками)

Пока я создаю сериализованный объект (в этом примере я просто отправляю ArrayLists из строковых объектов, но я, конечно,я действительно пытаюсь посылать массивы сериализуемых объектов классов)

Похоже, что документации по правильному использованию этого процесса сериализации / десериализации, когда все это происходит на стороне клиента, не так много.

Но моя функция записи имеет общую форму:

    public String streamResult(){
        SerializationStreamFactory factory = GWT.create(streamFactory.class);
        SerializationStreamWriter writer = factory.createStreamWriter();
        ArrayList<String> strlst = new ArrayList<>();
        strlst.add("First String");
        strlst.add("Second String");
        try {
           writer.writeObject(strlst);
        }  catch (Exception e) {
           printf("exception caught while serializing object");
        }
        return  writer.toString();
     }

И это правильно создает строковый объект, представляющий данные ArrayList

"7|0|6||788C596190777F280A9EF3D57029FB2C|java.util.ArrayList/4159755760|java.lang.String/2004016611|First String|Second String|1|2|3|2|4|5|4|6|"

Но потом, когда я иду десертировать результатset Я получаю сообщение об ошибке, которое как-то связано с попыткой чтения целых чисел в результирующей строке.

 public void unStreamResult(String str){
        SerializationStreamFactory factory = GWT.create(streamFactory.class);
        try {
            SerializationStreamReader reader = factory.createStreamReader(str);
            stringArray.addAll((ArrayList<String>) reader.readObject());
        }  catch (Exception e){
            printf("exception caught while deseralizing object");
        }
    }

Где мой класс streamFactory, созданный для моей SeralizationStreamFactory, определяется как:

@RemoteServiceRelativePath("streamFactory")
public interface streamFactory extends RemoteService {
    ArrayList getMessage(ArrayList message);
    String getMessage(String message);
}

Но тогда я получаю NumberFormatException в строке "" некоторыхсортировать в процессе десерализации.

Ошибка: java.lang.NumberFormatException: для входной строки: "" в NumberFormatException_0.createError (Insights-0.js: 13972) в NumberFormatException_0.initializeBackingError (Insights-0.js: 13995) вNumberFormatException_0.Throwable_0 (Insights-0.js: 13948) в NumberFormatException_0.Exception_0 (Insights-0.js: 14012) в NumberFormatException_0.RuntimeException_0 (Insights-0.js: 14022) в NumberFormatException_0.IllegalArgumentException_0) в новом NumberFormatException_0 (Insights-0.js: 46861) в __parseAndValidateInt (Insights-0.js: 22987) в $ prepareToRead (Insights-0.js: 39707) в $ unStreamResult (Insights-0.js: 9415) в onMessageImpl(Insights-0.js: 46204) в Worker.this $ static.onmessage (Insights-0.js: 46198)

Answer 1

Существующий протокол GWT-RPC является асимметричным - один формат сообщения используется для перехода от клиента к серверу, а другой формат используется для перехода от сервера к клиенту.Во всей моей работе с RPC я никогда не понимал, почему это так, за исключением, может быть, облегчения отладки, поскольку два формата сообщений несовместимы, поэтому вы сразу же знаете, что ищете?

В любом случае, именно поэтому это не работает - ваш unStreamResult ожидает сообщение другого формата, которое должно начинаться с //OK или //EX, а затем следовать массивом JS.Этот массив будет содержать в основном числа, но также будет содержать массив строк.

В черновом обновлении репозитория GWT-RPC, в настоящее время на https://github.com/vertispan/gwt-rpc (оставьте сообщение об этом ответе, если этоссылка становится устаревшей, я обновлю), мы изменили потоковые читатели и писатели, чтобы они были полностью симметричными.Это позволяет избежать путаницы, с которой вы и другие сталкивались, и дает возможность использовать формат сериализации независимо, например, для связи с веб-работником, или для некоторой простой сериализации в BLOB-объект для использования в IndexedDb или чем-то еще (с оговоркой, чтоэтот формат не версионный, поэтому данные, сохраненные при обновлении приложения, могут больше не работать).

Если вам нужно, чтобы этот формат работал до того, как я завершу этот проект, посмотритечто-то вроде https://github.com/niloc132/webbit-gwt/blob/master/workers/src/main/java/com/colinalworth/gwt/worker/client/impl/StreamReader.java (и StreamWriter.java в одном пакете) - это просто подтипы AbstractSerializationStreamReader и AbstractSerializationStreamWriter, но тщательно написанные, чтобы избежать различий между клиентом и читателем.Они написаны для использования ByteBuffers (которые сами оборачивают JS TypedArrays для лучшей производительности).В проекте gwt-rpc есть «модернизированная» версия этого как для строк, так и для ByteBuffers, но они могут быть не полностью совместимы со старым RPC.Использование этих функций также требует дополнительной работы: вы должны прекратить использовать factory.createStreamWriter() и т. Д., Чтобы построить для вас программу чтения и записи, а затем вы должны получить доступ к полю serializer из подкласса RemoteServiceProxy (возможно, JSNI?).

---

Но для вашего случая использования WebSockets вам на самом деле не нужен полностью симметричный проводной формат - вам просто нужно отправить полезную нагрузку по проводу на сервер и декодировать, а затем обработатьсвой ответ и отправьте обратно клиенту.Оказавшись на клиенте, эта полезная нагрузка ответа будет правильно прочитана вашим сообщением unStreamResult.

И хотя я никогда не отговариваю кого-либо от изобретать колесо, также рассмотрите возможность использования проекта gwt websocket, который я связал.до того, как уже решены многие из этих вопросов.Конечно, он не идеален, но он становится все ближе, поскольку мы делаем его первоклассной функцией в обновленном модуле GWT-RPC.