Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> Hi Santiago,
>>
>> There is a design issue here in that optimized encoding is being
>> pushed to the Message layer rather than implemented at the encoding
>> layer (which is why things will become a little more hacky to
>> ascertain when XOP is used).
>>
>> IMHO this fix is OK to performance test but IMHO we need to do this
>> properly by writing an optimized Encoder implementation that can
>> obtain references to the JAXB beans given appropriate hints that these
>> are the most optimal representation to use. Then it may not be
>> necessary to support the Map concept in Zephyr because we can
>> essentially turn things inside out i.e. Zephyr does not have control
>> of the OutputStream.
>
>
> I thought the semantics of "sjsxp-outputstream" is defined in such a way
> that it's there only when we are writing to UTF-8 OutputStream in a
> plain XML fashion, so I think the code is correct.
>
> If we are writing to XOP, we use a custom XMLStreamWriter impl, so the
> "// TODO: XOP handling" doesn't have to do anything.
>
Doh! you are correct.
But i think the main point still applies, that we are putting a
specific encoding feature into JAXBHeader/Message. What happens if we
want to support the UTF-16 encoding later on? and JAXB has some
optimizations for this in the future?
I know this is not a major requirement but it does make things more
complicated in the future and that is why we have the Encoder/Decoder
framework to clearly separate layers. To some extent we are not eating
our own design dog food :-)
We are also creating a dependency between JAX-WS and Zephyr which can
potentially be avoided.
I think it would be really simple to have methods on Header and Message
that is the following:
enum Representation {
JAXB,
SAAJ,
Source,
Stream,
None;
};
Representation getPreferredRepresentation();
JAXBHeader and JAXBMessage would implement JAXBRepresentation.
public interface JAXBRepresentation {
Bridge getBridge();
Context getContext();
Object getObject();
}
Then the optimized UTF-8 Encoder implemention could do:
OutputStream os = ...
Message m = ...
if (m.getRepresentation() == Representation.JAXB) {
JAXBRepresentation r = (JAXBRepresentation)m;
r.getBridge().marshal(r.getContext(), r.getObject(),
os,
namespaceContext);
}
(infact i am not sure we really need the enum after i got this far
writing this email).
and everything is kept local to an Encoder for about the same overhead.
Further, it allows us to optimize the Encoder implementation in the
future e.g. writing UTF-8 SOAP message infoset directly to the
OutputStream.
In addition i think the use of JAXBRepresentation would also be
beneficial for optimized security that can operate efficiently using
JAXB rather than going through the readAsJAXB method.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109