Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> Hi,
>>
>> When the JAXBHeader implementation implements the following methods to
>> get access to the JAXB object:
>>
>> public <T> T readAsJAXB(Unmarshaller unmarshaller) throws
>> JAXBException {
>> JAXBResult r = new JAXBResult(unmarshaller);
>> bridge.marshal(context,jaxbObject,r);
>> return (T)r.getResult();
>> }
>>
>> public <T> T readAsJAXB(Bridge<T> bridge, BridgeContext context)
>> throws JAXBException {
>> return bridge.unmarshal(context,new
>> JAXBBridgeSource(this.bridge,this.context,jaxbObject));
>> }
>>
>> why is the JAXB object that was passed into the constructor not
>> returned directly? e.g. for the case where pipe adds a header using a
>> JAXB object and a pipe further down the line wants to access this
>> header using JAXB.
>
>
> A part of the reason is that the JAXBContext used to create the header
> could be different from the JAXBContext used to read it.
>
> Another reason for that is that you don't want the reader of the header
> to make changes, causing the header itself to change.
>
> I guess yet another is that I don't expect it to be common for a
> JAXBHeader (which almost exclusively used for an outgoing message), to
> be read.
>
Ok.
> But if you think this is a big enough problem. We can do better --- like
> perhaps the readAsJAXB method can take a boolean flag indicating 'read
> only copy'.
>
That looks useful.
The security pipe securing a message can potentially optimize for the
case when headers and the payload are JAXB beans. It could use the
optimal JAXB canonical serialization (although EXC14N needs to be
supported, which i think is not that difficult).
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109