MTOM value adapter

[heiko.braun]

We need to be able to adapt different marshalling/unmarshalling values to specific java types. With MTOM a xsd:base64Binary can have multiple java representations: Source,Image,DataHandler, Stream ...

What i am picturing is similiar to the concept of ValueAdapters, but we need that for the marshalling process as well. Furthermore it needs to be injected through some plugin mechanism in order to shield XB from having to deal with external dependencies (i.e. JAF).

[aloubyansky]

Why can't it be done in implementations of XOP[Un]marshaller interfaces?

[heiko.braun]

It cannot be done in the Marshaller/Unmarshaller impl. because MTOM can potentially be disabled for particular requests. Some vendor implementations do this based on a content-length threshold. What we end up with is ambiguous behaviour which requires XB to adopt base64Binay to various java types.

I already did that for unmarshalling using the ValueAdapter on specific schema types. Actually it did work fine except for:

- Simple types have not been covered, because their TypeMapping is hardcoded
- It did not cover marshalling

[aloubyansky]

I need to understand the problem better.
How do you imagine this should work?
I still don't understand why it can't be done in the [un]marshaller implementations.

[heiko.braun]

The [un]marshaller implementations are only called when isXOPPackage() actually returns true. In certain cases (described above) other vendors send binaries inlined as base64 values. Still a user might this want to be mapped to various valid MTOM java types. XB however unmarshalls inlined base64 as byte arrays, that somehow need to be mapped to, let's say an Image property of a bean. The same applies to marshalling: Even though it's a valid MTOM java type, a user might decide to disable MTOM on a per request base. In this case XB somehow needs to know how to convert i.e. an Image to a byte array, prior to marshalling it.

[heiko.braun]

Alexey Loubyansky: 15:20:01
so, it's about doing XOP w/o actually using standard XOP api?

Heiko Braun: 15:20:43
see we got isXOPPackage()

Alexey Loubyansky: 15:20:51
and w/o xop:Include, as I understand

Heiko Braun: 15:21:15
XB checks wether thats true and the element is actually optimizeable

Alexey Loubyansky: 15:21:44
yes, base64binary is optimizable now

Heiko Braun: 15:21:50
in certain cases, MTOM is disabled, even though the element is optimizable

Heiko Braun: 15:21:54
right

Heiko Braun: 15:22:07
let's look at unmarshalling first:

Heiko Braun: 15:22:37
a) client sends a XOP encoded request, isXOPPackage() returns true. everythikng is fine

Heiko Braun: 15:23:09
b) clients sends to the same endpoint, this time the binary is inlined as base64 value -> isXOPPackage() returns false

Heiko Braun: 15:23:34
in the later case that base64 value will be unmarshalled as byte[]

Heiko Braun: 15:23:59
but the actual java bean expects an java.awt.Image

Alexey Loubyansky: 15:24:16
yes, that's clear..

Heiko Braun: 15:24:23
the XOPUnmarshaller is not being called, and thus i dont have control over the unmarshalling

Heiko Braun: 15:24:25
okk

Heiko Braun: 15:24:39
the same problem exists when we look at marshalling

Heiko Braun: 15:24:49
it's just the reverse problem

Heiko Braun: 15:25:05
start witrh an java.awt.Image that mapped to xsd:base64Binary

Heiko Braun: 15:25:11
no mapping in place

Heiko Braun: 15:25:26
but it should be marshalled as base64 value

Heiko Braun: 15:26:04
i mamaged to solve the unmarshalling problem by using a ValueAdapter impl. on specific TypeMappings

Alexey Loubyansky: 15:26:15
right now it would throw an error for marshalling?

Heiko Braun: 15:26:29
yes

Heiko Braun: 15:26:41
i think it looks for _value

Heiko Braun: 15:26:48
if i remember correctly

Heiko Braun: 15:26:57
ah no

Heiko Braun: 15:27:16
the SimpleTypeBindings throws a ClassCastException

Alexey Loubyansky: 15:27:28
yes, that's what i was thinking it was

Heiko Braun: 15:27:31
it tries to cast everything to byte[]

Heiko Braun: 15:28:03
i was thinking if it might be possoble to extend the ValueAdapter concept

Heiko Braun: 15:28:14
to support marshalling as well

Alexey Loubyansky: 15:28:25
yes, i think we can do it this way

Alexey Loubyansky: 15:28:39
it kind of makes sense having it for unmarshalling

Heiko Braun: 15:28:45
there is two requirements though

Heiko Braun: 15:29:13
a) We to be able to apply that to simple types as well

Heiko Braun: 15:29:25
b) It needs to injected as plugin

Alexey Loubyansky: 15:30:14
ok, i got it

Heiko Braun: 15:30:20
i think for marshalling i should look like this:

Heiko Braun: 15:30:41
java type -> value adapter -> byte[] -> simple type bindings

Alexey Loubyansky: 15:31:08
yes

Heiko Braun: 15:31:31
i did actually play with it, but couldnt find the correct place for the marshalling interception

Heiko Braun: 15:31:51
i think the unmarshalling callbacks can stay where they are

Heiko Braun: 15:32:31
what about the simple types problem?

Heiko Braun: 15:32:52
i don't have control over the SchemaBinding in this case

Heiko Braun: 15:33:09
how to inject a plugin here?

Alexey Loubyansky: 15:33:51
how do you inject it for complex types?

Heiko Braun: 15:34:15
i did set it on TypeBinding when i created the SchemaBinding

Heiko Braun: 15:34:26
SimpleTypeBindings is static though

Alexey Loubyansky: 15:35:14
yes, you can set the value adapter but it'll be static..

Alexey Loubyansky: 15:35:18
not good

Alexey Loubyansky: 15:35:36
well, it should be fixed..

Heiko Braun: 15:36:11
what about some kind of overloading the SimpleTypeBindings for particular types?

Heiko Braun: 15:36:45
SchemaBinding.hasSimpleTypeOverloaded() -> call it, else SimpleTypeBindings->call it

Heiko Braun: 15:37:27
first ask the SchemaBindings for the overloaded type, if it doesnt exist then call the static SimpleTypeBindings

Alexey Loubyansky: 15:37:32
yes, or maybe some more transparent way...

Alexey Loubyansky: 15:39:11
i would like it to look like for complex types ideally

Alexey Loubyansky: 15:39:19
it'd be easier

Alexey Loubyansky: 15:39:25
i'll think about it

Heiko Braun: 15:39:46
ok

Heiko Braun: 15:40:05
thanks