5 Replies Latest reply on Sep 26, 2006 9:45 AM by Heiko Braun

    MTOM value adapter

    Heiko Braun Master

      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).

        • 1. Re: MTOM value adapter
          Oleksiy Lubyanskyy Master

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

          • 2. Re: MTOM value adapter
            Heiko Braun Master

            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

            • 3. Re: MTOM value adapter
              Oleksiy Lubyanskyy Master

              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.

              • 4. Re: MTOM value adapter
                Heiko Braun Master

                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.

                • 5. Re: MTOM value adapter
                  Heiko Braun Master


                  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
                  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
                  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
                  Heiko Braun: 15:40:05