Why can't it be done in implementations of XOP[Un]marshaller interfaces?
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
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.
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.
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
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
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
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
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
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
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
Heiko Braun: 15:40:05