[ http://issues.apache.org/jira/browse/WSCOMMONS-32?page=all ]
Dennis Sosnoski updated WSCOMMONS-32:
-------------------------------------
Assign To: Dennis Sosnoski
The technique used to get around this won't work properly with data binding
implementations. Instead, I'll correct the OMSourceElementImpl to pass the flag
properly when calling the base class getXMLStreamReader() method.
> Call to OMSourcedElementImpl.getXMLStreamReaderWithoutCaching() returns an
> XMLStreamReader WITH caching
> -------------------------------------------------------------------------------------------------------
>
> Key: WSCOMMONS-32
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-32
> Project: WS-Commons
> Type: Bug
> Components: AXIOM
> Environment: Windows XP, JBOSS4.0.3 SP1
> Reporter: Lakshmi Chaparala
> Assignee: Dennis Sosnoski
>
> I used Axis2's OMSourcedElementTest.java as an example of how to use a
> custom OMDataSource. In this case you construct an OMSourcedElementImpl
> class and give it your custom OMDataSource. When the service implementation
> class the constructed OMSourcedElementImpl and Axiom streams it out, the
> OMSerializerUtil class makes a call to
> OMSourcedElementImpl.getXMLStreamReaderWithoutCaching(), which returns an
> XMLStreamReader WITH caching. This sends the code down an execution path
> that fails to stream the OMSourcedElementImpl because it looks for OMElement
> objects that aren't there.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
