You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Renaud Bruyeron (JIRA)" <ji...@apache.org> on 2007/07/04 17:29:33 UTC
[jira] Created: (SM-993) StaxSource + FragmentStreamReader
interference with TRaX
StaxSource + FragmentStreamReader interference with TRaX
--------------------------------------------------------
Key: SM-993
URL: https://issues.apache.org/activemq/browse/SM-993
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.1.1
Environment: JDK5
Reporter: Renaud Bruyeron
Attachments: patch.txt
My use-case is this:
* a message comes in via an http:endpoint - it is a soap with attachment message, and thus the body is stored in a SoapMessage as a StaxSource, and a FragmentStreamReader is used to cut out the SOAP envelope and only keep the content of the soap message.
* I try to apply an XSL on this body directly - I notice that it fails (output document is empty)
* if I switch to saxon (instead of the default TrAx=xalan 2.7.0), it kind of works if I use a StreamResult, but not if I use a DOMResult: saxon complains that something is doing some unspeakable deed with namespaces ;-)
I narrowed this down to the FragmentStreamReader, and wrote a simple testcase that shows the bug. However I can't see what's throwing off xalan/saxon, I am not familiar enough with Stax, therefore I don't have a fix.
The testcase includes: an XML document, an XSL stylesheet, and a new testcase in FragmentStreamReaderTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-993) StaxSource + FragmentStreamReader
interference with TRaX
Posted by "Renaud Bruyeron (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39606 ]
Renaud Bruyeron commented on SM-993:
------------------------------------
After applying the patch:
{code}
$ cd core/servicemix-core
$ mvn -Dtest=FragmentStreamReaderTest
{code}
To see that saxon + StreamResult works, you need to modify the servicemix-core pom to add saxon to the classpath:
{code:title=core/servicemix-core/pom.xml}
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>saxon</artifactId>
<version>8.8</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>saxon-dom</artifactId>
<version>8.8</version>
<scope>test</scope>
</dependency>
{code}
Then change the testcase like so:
{code:title=switch to stream mode}
public void testStaxSourceOnFragmentStream() throws Exception {
InputStream is = getClass().getResourceAsStream("mm7.xml");
InputStream xlsis = getClass().getResourceAsStream("clean-namespace.xsl");
XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLInputFactory.IS_COALESCING, Boolean.FALSE);
XMLStreamReader xsr = factory.createXMLStreamReader(is);
xsr.nextTag();
StaxSource ss = new StaxSource(new FragmentStreamReader(xsr));
Transformer transformer = TransformerFactory.newInstance().newTransformer(new StreamSource(xlsis));
//DOMResult result = new DOMResult();
StringWriter sw = new StringWriter();
StreamResult result = new StreamResult(sw);
transformer.transform(ss, result);
System.out.println(sw.toString());
// output must be a document
//assertTrue(Document.class.isAssignableFrom(result.getNode().getClass()));
// there should be more than one element in the output document
//assertTrue(result.getNode().getChildNodes().getLength() > 0);
}
{code}
You should see this in the output:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<SubmitReq xmlns="http://www.firsthop.com/specs/MM7-extended/MM7-extended-1-2">
<MM7Version>5.3.0</MM7Version>
<SenderIdentification>
<VASPID>yo</VASPID>
<VASID>dude</VASID>
<SenderAddress>
<Number>33611111125</Number>
</SenderAddress>
</SenderIdentification>
<Recipients>
<To>
<Number>33601020304</Number>
</To>
</Recipients>
<ServiceCode>9999</ServiceCode>
<MessageClass>Personal</MessageClass>
<TimeStamp>2007-07-04T11:49:38.260Z</TimeStamp>
<DeliveryReport>false</DeliveryReport>
<Content allowAdaptations="true" href="cid:mmscontent"/>
</SubmitReq>
{code}
> StaxSource + FragmentStreamReader interference with TRaX
> --------------------------------------------------------
>
> Key: SM-993
> URL: https://issues.apache.org/activemq/browse/SM-993
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-core
> Affects Versions: 3.1.1
> Environment: JDK5
> Reporter: Renaud Bruyeron
> Attachments: patch.txt
>
>
> My use-case is this:
> * a message comes in via an http:endpoint - it is a soap with attachment message, and thus the body is stored in a SoapMessage as a StaxSource, and a FragmentStreamReader is used to cut out the SOAP envelope and only keep the content of the soap message.
> * I try to apply an XSL on this body directly - I notice that it fails (output document is empty)
> * if I switch to saxon (instead of the default TrAx=xalan 2.7.0), it kind of works if I use a StreamResult, but not if I use a DOMResult: saxon complains that something is doing some unspeakable deed with namespaces ;-)
> I narrowed this down to the FragmentStreamReader, and wrote a simple testcase that shows the bug. However I can't see what's throwing off xalan/saxon, I am not familiar enough with Stax, therefore I don't have a fix.
> The testcase includes: an XML document, an XSL stylesheet, and a new testcase in FragmentStreamReaderTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-993) StaxSource + FragmentStreamReader
interference with TRaX
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39879 ]
Guillaume Nodet commented on SM-993:
------------------------------------
I can reproduce the error without saxon btw.
Could you try with the following patch and see what it gives? It seems to solve the test case, but i'd like you to try it in your real environment.
{code:title=Patch on servicemix-core}
Index: org/apache/servicemix/jbi/jaxp/StaxSource.java
===================================================================
--- org/apache/servicemix/jbi/jaxp/StaxSource.java (revision 563801)
+++ org/apache/servicemix/jbi/jaxp/StaxSource.java (working copy)
@@ -60,6 +60,7 @@
protected void parse() throws SAXException {
try {
while (true) {
+ streamReader.next();
switch (streamReader.getEventType()) {
// Attributes are handled in START_ELEMENT
case XMLStreamConstants.ATTRIBUTE:
@@ -142,7 +143,6 @@
break;
}
}
- streamReader.next();
}
} catch (XMLStreamException e) {
SAXParseException spe;
{code}
> StaxSource + FragmentStreamReader interference with TRaX
> --------------------------------------------------------
>
> Key: SM-993
> URL: https://issues.apache.org/activemq/browse/SM-993
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-core
> Affects Versions: 3.1.1
> Environment: JDK5
> Reporter: Renaud Bruyeron
> Attachments: patch.txt
>
>
> My use-case is this:
> * a message comes in via an http:endpoint - it is a soap with attachment message, and thus the body is stored in a SoapMessage as a StaxSource, and a FragmentStreamReader is used to cut out the SOAP envelope and only keep the content of the soap message.
> * I try to apply an XSL on this body directly - I notice that it fails (output document is empty)
> * if I switch to saxon (instead of the default TrAx=xalan 2.7.0), it kind of works if I use a StreamResult, but not if I use a DOMResult: saxon complains that something is doing some unspeakable deed with namespaces ;-)
> I narrowed this down to the FragmentStreamReader, and wrote a simple testcase that shows the bug. However I can't see what's throwing off xalan/saxon, I am not familiar enough with Stax, therefore I don't have a fix.
> The testcase includes: an XML document, an XSL stylesheet, and a new testcase in FragmentStreamReaderTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.