WSO2 ESB 4.5.1: проблема обрезки XML, читаемых с помощью VFS + ApplicationXMLBuilder

Проблема:

Есть прокси сервис VFS->HTTP, читающий XML-сообщения из файлов и отправляющий их по HTTP. Сообщения в файлах лежат без SOAP-обертки, соответственно, ContentType в параметрах сервиса установлен в:

<parameter name="transport.vfs.ContentType">application/xml</parameter>

(в axis2.xml этом типу содержимого соотнесен билдер org.apache.axis2.builder.ApplicationXMLBuilder).

Проблема заключается в том, что объемные сообщение отправляются обрезанными: может не хватать нескольких тегов в конце, в дополнение к чему содержимое последнего из все же переданных тегов также может быть обрезано. При этом корректность XML соблюдается, т.е. содержимое обрезается, а закрывающие теги все равно есть. 

Если класть в файлы сообщения сразу в SOAP-обертке, используя

<parameter name="transport.vfs.ContentType">text/xml</parameter>

, ситуация не меняется.
При этом наблюдается интересная особенность: если логировать сообщение перед отправкой (используя лог-медиатор с уровнем full), то оно и в лог пишется целиком, и на конечный сервис отправляется без обрезки.
Если же попытаться до отправки сообщение не логировать, а логировать после <send/>, то ловим странное:

org.apache.axiom.om.OMException: Parser has already reached end of the document. No siblings found
at org.apache.axiom.om.impl.llom.OMElementImpl.getNextOMSibling(OMElementImpl.java:338)
at org.apache.axiom.om.impl.traverse.OMChildrenIterator.getNextNode(OMChildrenIterator.java:36)
at org.apache.axiom.om.impl.traverse.OMAbstractIterator.hasNext(OMAbstractIterator.java:58)
... at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:988)
at java.lang.String.valueOf(String.java:2854)
at java.lang.StringBuffer.append(StringBuffer.java:232)
at org.apache.synapse.mediators.builtin.LogMediator.getFullLogMessage(LogMediator.java:184)
... at org.apache.synapse.transport.vfs.VFSTransportListener.processFile(VFSTransportListener.java:481)
...

Workaround:

Видимо, проблема связана с какой-то "ленивой" загрузкой входящего XML. При логировании сообщения (и, как оказалось, также при других операциях над сообщением, например,  при выполнении над ним XPath) он все-таки загружается полностью. А вот при выполнении <send/> (а также при любых операциях после него) - нет.

В очередной раз копаться в исходниках и отлаживать ситуацию времени не было. Поэтому нашел простой (временный) workaround для проблемы: перед отправкой обращаться к содержимому сообщения (используя несложный xpath в property-медиаторе):

 <property action="set" name="dummyprop" scope="default" type="STRING" expression="count($body/*)"/>