[ 
https://issues.apache.org/jira/browse/CXF-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Pansier updated CXF-7087:
-----------------------------------
    Description: 
I defined a service endpoint with a custom XmlOutputFactory
{code:xml}
<jaxws:endpoint id="myWebService" implementorClass="a.b.c.MyService"
        implementor="#Mybean" address="/myService">
        <jaxws:properties>
            <entry key="javax.xml..XMLOutputFactory">
                <ref bean="invalidCharacterReplacingXmlOutputFactory"/>
            </entry>
        </jaxws:properties>
</jaxws:endpoint>
{code}
When Using the WSDLGetOutInterceptor, I get the following error;
Can not output XML declaration, after other output has already been done.
The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when using 
a custom xmlOutputFacory, then writes the prolog. The WSDLGetOutInterceptor 
writes it again and throws the exception.

This was supposed to be fixed with commit 
25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm 
correct(changed class: WSDLGetOutInterceptor, commit message: Write the prolog 
only if it hasn't already been written). But I think the change is not correct:

{code}
-            StaxUtils.writeNode(doc, writer, true);
+            StaxUtils.writeDocument(doc, writer, true,
+                                    
!MessageUtils.getContextualBoolean(message, 
+                                                                       
StaxOutInterceptor.FORCE_START_DOCUMENT, 
+                                                                       false));
{code}
Knowing that the signature of StaxUtils.writeDocument is:
{code}
public static void writeDocument(Document d, XMLStreamWriter writer, boolean 
writeProlog,  boolean repairing)
{code}

That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT 
from version 3.3, whereas the boolean writeProlog is always true ! To me, it 
seems like the two parameters have been swapped.



  was:
I defined a service endpoint with a custom XmlOutputFactory
{code:xml}
<jaxws:endpoint id="myWebService" implementorClass="a.b.c.MyService"
        implementor="#Mybean" address="/myService">
        <jaxws:properties>
            <entry key="javax.xml..XMLOutputFactory">
                <ref bean="invalidCharacterReplacingXmlOutputFactory"/>
            </entry>
        </jaxws:properties>
</jaxws:endpoint>
{code}
When Using the WSDLGetOutInterceptor, I get the following error;
Can not output XML declaration, after other output has already been done.
The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when using 
a custom xmlOutputFacory, then writes the prolog. The WSDLGetOutInterceptor 
writes it again and throws the exception.

This was supposed to be fixed with commit 
25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm 
correct(changed class: WSDLGetOutInterceptor, commit message: Write the prolog 
only if it hasn't already been written). But I think the change is not correct:

{code}
-            StaxUtils.writeNode(doc, writer, true);
+            StaxUtils.writeDocument(doc, writer, true,
+                                    
!MessageUtils.getContextualBoolean(message, 
+                                                                       
StaxOutInterceptor.FORCE_START_DOCUMENT, 
+                                                                       false));
{code}
Knowing that the signature of StaxUtils.writeDocument is:
public static void writeDocument(Document d, XMLStreamWriter writer, boolean 
writeProlog,  boolean repairing)

That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT 
from version 3.3, whereas the boolean writeProlog is always true ! To me, it 
seems like the two parameters have been swapped.




> Getting the wsdl from a cxf webservice with custom XMLOuputFactory throws an 
> exception
> --------------------------------------------------------------------------------------
>
>                 Key: CXF-7087
>                 URL: https://issues.apache.org/jira/browse/CXF-7087
>             Project: CXF
>          Issue Type: Bug
>            Reporter: Guillaume Pansier
>
> I defined a service endpoint with a custom XmlOutputFactory
> {code:xml}
> <jaxws:endpoint id="myWebService" implementorClass="a.b.c.MyService"
>         implementor="#Mybean" address="/myService">
>         <jaxws:properties>
>             <entry key="javax.xml..XMLOutputFactory">
>                 <ref bean="invalidCharacterReplacingXmlOutputFactory"/>
>             </entry>
>         </jaxws:properties>
> </jaxws:endpoint>
> {code}
> When Using the WSDLGetOutInterceptor, I get the following error;
> Can not output XML declaration, after other output has already been done.
> The StaxOutputInterceptor sets the flag FORCE_START_DOCUMENT to true when 
> using a custom xmlOutputFacory, then writes the prolog. The 
> WSDLGetOutInterceptor writes it again and throws the exception.
> This was supposed to be fixed with commit 
> 25f0eb7f955a84baf6c3b634ff316cb831a2acfa, with version 3.3 if I'm 
> correct(changed class: WSDLGetOutInterceptor, commit message: Write the 
> prolog only if it hasn't already been written). But I think the change is not 
> correct:
> {code}
> -            StaxUtils.writeNode(doc, writer, true);
> +            StaxUtils.writeDocument(doc, writer, true,
> +                                    
> !MessageUtils.getContextualBoolean(message, 
> +                                                                       
> StaxOutInterceptor.FORCE_START_DOCUMENT, 
> +                                                                       
> false));
> {code}
> Knowing that the signature of StaxUtils.writeDocument is:
> {code}
> public static void writeDocument(Document d, XMLStreamWriter writer, boolean 
> writeProlog,  boolean repairing)
> {code}
> That means that the boolean reparing depends on the flag FORCE_START_DOCUMENT 
> from version 3.3, whereas the boolean writeProlog is always true ! To me, it 
> seems like the two parameters have been swapped.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to