You are absolutely right on the XMLBeans behavior. With the current code generator what happens is that XMLBeans generates the correct object for binary representation but always serializes it into a base64 string. The input however works since extracting the binary part from the mime part is done by the MTOMbuilder before data binding. As it stands now, the generated stubs *can* handle incoming optimized messages but never sends out an optimized message!
So I guess we should dig deep into XMLBeans (or any other framework) if we are to solve this!
On 9/2/05, Dennis Sosnoski <
[EMAIL PROTECTED]> wrote:
I may be misunderstanding how XMLBeans works, but I don't see any way
it's possible to add MTOM support without the data binding framework
being aware of it. In the XMLBeans case I'd think that the underlying
XML store would also need to be extended - otherwise it seems like
XMLBeans would insist on storing the data as base64 encoding, and would
also expect the data in that form on input and supply the data in that
form on output.
That's one of the drawback to the layering violations built into the
whole MTOM approach. See the earlier thread discussing this:
http://marc.theaimsgroup.com/?t=112131750700001&r=1&w=2
- Dennis
--
Ajith Ranabahu
