Как я должен использовать Apache XML-RPC TypeConvertorFactory на стороне сервера? - PullRequest
Новая
       11

Как я должен использовать Apache XML-RPC TypeConvertorFactory на стороне сервера?

1 голос
/ 21 сентября 2011

Я изо всех сил пытаюсь заставить Apache XML-RPC вообще вызвать мой TypeConvertorFactory. Он вызывает его на стороне клиента (только возвращенные значения, подтвержденные для работы до сих пор, еще не протестировали параметры), но на стороне сервера его вообще не вызывает.

Мой код инициализации выглядит так: 

XmlRpcServlet servlet = new XmlRpcServlet();
XmlRpcServerConfigImpl config = new XmlRpcServerConfigImpl();
config.setEnabledForExtensions(true);
servlet.getXmlRpcServletServer().setConfig(config);
servlet.getXmlRpcServletServer().setTypeConverterFactory(
    new ServerTypeConvertorFactory());

API выглядит так: 

private interface API {
    AvailableLicencesResponse availableLicences();
}

AvailableLicencesResponse - это обычный скучный, хотя и глубоко вложенный JavaBean.

В данный момент сервер отправляет этот ответ как Base64 (это работает, потому что я позвонил setEnabledForExtensions(true) - но если я не вызываю это, вместо этого я получаю ошибки типа «неожиданный конец потока», без каких-либо дополнительных ошибок нигде сказать мне, почему.)

Я установил точки останова внутри ServerTypeConvertorFactory, и похоже, что ни один из методов не вызывается на сервере. Те же точки останова показывают, что клиент вызывает функцию convert (), когда сервер возвращает результат, но результат уже имеет правильный тип из-за волшебства сериализации, поэтому мне не нужно преобразовывать его.

По сути, я пытаюсь реализовать проводной протокол, который соответствует стандарту XML-RPC (и не использует огромные объемы данных Base64 ...), при этом все еще имея API, который не требует тысяча приведений и вызовов Map.get (). Я также хочу избежать необходимости делать больше вызовов, чем необходимо, поэтому я возвращаю бин вместо того, чтобы иметь отдельные методы для получения каждого его свойства, что также сработало бы.

(Также, если есть более простой в использовании API, чем этот, я открыт для предложений. Сначала все было очень просто, но пока вам не нужно настраивать его. Кроме того, любой, кто предлагает Axis или другой SOAP- основанные API будут сняты на рассвете.)

...