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.
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'.
> In general if a pipe wants access to a header as a JAXB bean is it more
> efficient to use BridgeContext or Unmarshaller?
Shouldn't really matter.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com