Handling MTOM in DataSourceType and Base64Type

[Nikolajs Krasnikovs <ni...@gmail.com>]

Hello,

I found a difference of  behavior in handling of MTOM in Aegis
org.apache.cxf.aegis.type.basic.Base64Type and
org.apache.cxf.aegis.type.mtom.DataSourceType. The approach is more or less
the same as in XFire-1.2.6, where I meet it at the first time ( and got some
interoperability issues with .NET client).

As far as I see, DataSourceType ALWAYS assumes there is a MTOM content in
incoming message :

if (child.getName().equals(XOP_INCLUDE)) {
      MessageReader mimeReader = child.getAttributeReader(XOP_HREF);
       String type = mimeReader.getValue();
       o = readInclude(type, child, context);
   }
..otherwise nothing happens

At the same time, Base64Type handles both MTOM and inline  ( if there are no
XOP_INCLUDE tag)

In WSDL, the attributes of DataSource and byte[] are both desribed as
xsd:base64Binary.

The trouble is, some clients ( at least, .NET I am trying to use - see more
here http://devauthority.com/blogs/area51/archive/2006/07/09/1534.aspx )
can "optimize" the request message and volutarily chose use XOP_INCLUDE or
put data inline. So even with MTOM enabled on client, I am getting content
like

<data>VGhpcyBpcyBhIHNpbXBsZSB0ZXh0IGRvY3VtZW50Lg0KDQpZZXMgaXQgaXMu</data>

instead of

<data><Include> <href=... /> </Include></data>.

Actually, when the property was defined as byte[], everything seems to be
fine - the Base64Type handles both inline data and attacments. But if the
proerety was defined as DataSource, the inline content is lost.

Is this behavior for DataSource type intentional ?

Thanks,
Nick