I'm not entirely sure, but I think that you gotta have an
org.w3c.dom.Element, not a string.
The universe we are working in here is not friendly to what you want to
do.
On Sun, 2008-01-13 at 14:00 -0800, jas_nabble wrote:
> Hi Dan:
>
> I'm not sure I'm getting this DomHandler thing right, but I end up with:
> org.apache.cxf.interceptor.Fault: Marshalling Error: unable to marshal type
> "java.lang.String" as an element because it is missing an @XmlRootElement
> annotation
>
> @XmlAnyElement(value=MyDomHander.class)
> public Object legacyXml = new String("<x
> a=\"hello\"><y><z>data</z></y></x>");
>
> class MyDomHander implements DomHandler<String, StreamResult> {
>
> public StreamResult createUnmarshaller(ValidationEventHandler
> errorHandler)
> {
> // TODO Auto-generated method stub
> return null;
> }
>
> public String getElement(StreamResult rt) {
> // TODO Auto-generated method stub
> return null;
> }
>
> public Source marshal(String n, ValidationEventHandler errorHandler) {
> System.out.println("marshal, n: " + n);
> return new StreamSource(new StringReader(n));
> }
> }
>
> Will I ever be able to get down to a level where JAXB will not escape the
> characters being marshaled into XML from whatever Source I provide it?
> Looking at the JAXB RI code a little more, it looks like unless I can set
> the escape handler, I cannot avoid it. Perhaps it's time to look at
> Aegis...
>
> Regarding MTOM, I'm looking at providing both SOAP and REST interfaces. I'm
> not quite sure how attachments work for REST. Also, I would like the legacy
> XML string to just be encompassed as an element returned in the overall
> response, and not be added on in some manner.
>
>
> dkulp wrote:
> >
> >
> > I think XmlAnyElement might work if you also write a DomHandler that does
> > something with StreamSource/StreamResults instead of the DOM elements.
> > You would create a StreamSource using a StringReader that wraps your
> > string. That MIGHT work. Don't really know.
> >
> > Honestly, this sounds like an ideal case for MTOM. Use a "Source" as
> > your type. You can say it will be an "text/xml" mime type. It will
> > then be attached as a mime attachment untouched. The soap processors
> > don't have to touch it at all.
> >
> > Dan
> >
> >
> >
> > On Wednesday 09 January 2008, jas_nabble wrote:
> >> Hello Benson:
> >>
> >> @XmlAnyElement came up in the JAXB forum as well, but I don't
> >> understand how it applies to my problem. For one thing, the javadoc
> >> for XmlAnyElement only discusses unmarshaling, so I'm not sure it
> >> applies to marshaling as well. Even if it does, I don't want to parse
> >> the legacy XML and hand over an Element.
> >>
> >> However, would it be possible to use JAXBElement and set is value to
> >> the XML String? Will that then get marshaled and not be escaped? I'll
> >> have to try that.
> >>
> >> Thanks,
> >>
> >> Jeff
> >>
> >> Benson Margulies-4 wrote:
> >> > On Wed, 2008-01-09 at 11:15 -0800, jas_nabble wrote:
> >> >> Hello:
> >> >>
> >> >> I'm so far successfully making use of CXF 2.0.3 using JAXB 2.0.
> >> >> However, a
> >> >> problem I have to resolve pertains to returning as part of a
> >> >> response, existing XML that is already in the for of
> >> >> java.lang.String. This content is
> >> >> coming from legacy code accessing database CLOBs. They can be
> >> >> pretty large,
> >> >> and they don't change. There are lots of them (~100K). I would
> >> >> rather not parse them into an object graph that could be marshaled
> >> >> by JAXB, or cache those graphs in memory etc. I did see the email
> >> >> thread "Return direct XML",
> >> >> but that seems to involve creating a DOM.
> >> >
> >> > Try looking into the @XmlAnyElement.
> >
> >
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer, IONA
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog
> >
> >
>
