Re: Cannot request WSDL with CXF-2.1 deployed to Tomcat

Thu, 12 Jun 2008 09:02:56 -0700 


On Jun 12, 2008, at 11:51 AM, Wolf, Chris (IT) wrote:


Dan,

I just ran a live StAX factory configuration test; my web app is
configured as
follows:

javax.xml.stream.XMLEventFactory:
com.sun.xml.stream.events.ZephyrEventFactory
javax.xml.stream.XMLInputFactory: com.sun.xml.stream.ZephyrParserFactory 

javax.xml.stream.XMLOutputFactory:
com.sun.xml.stream.ZephyrWriterFactory
This is identical to the previous April snapshot, which does not exhibit 
the
wsdl output problem that I get with CXF-2.1 release.
That's because the April snapshot didn't use StAX to write the wsdl. It used the javax.xml.transform stuff to write the DOM. However, that had a problem in that if any recent version of xalan was on the classpath, the resulting wsdl/schemas were not valid. Thus, we changed to using the Stax stuff to write out the wsdl. For the most part, we always use woodstox as our Stax implementation. Thus, that was what was tested for 2.1. For 2.1.1-SNAPSHOTs, we've done some limitted testing with the Sun parser and did fix this issue with that parser. 

Thus, I would suggest one of:
1) Use a 2.1.1-snapshot for the time being. (actually, I'd really like this if you could test this over the next couple days. I'm hoping to do the final 2.1.1 build really early next week so having some confirmation that it's really fixed would be great)
2) Figure out how to get woodstox properly configured as the parser. I really don't know how to do that other than to find suns jar and remove it. 



Dan






Thanks,

  -Chris        

-----Original Message-----
From: Wolf, Chris (IT)
Sent: Thursday, June 12, 2008 10:15 AM
To: [email protected]
Subject: RE: Cannot request WSDL with CXF-2.1 deployed to Tomcat
What do I have to do to get it working? I did not have this issue with the 2.1 snapshot from April. I verified that the wstx-asl-3.2.4.jar is 
in the build path and in WEB-INF/lib.

My JAXP settings are as follows:

javax.xml.parsers.DocumentBuilderFactory:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl       
javax.xml.parsers.SAXParserFactory:
org.apache.xerces.jaxp.SAXParserFactoryImpl     
javax.xml.transform.TransformerFactory:
org.apache.xalan.processor.TransformerFactoryImpl

These settings are unchanged from the April 2.1-snapshot, which works
fine.
They are the defaults as set in the META-INF/services of each of the
respective jar files.

In any case, these settings don't appear to have anything to do with
streaming parsers, which, unfortunately, I am not that familiar with.

It looks the the META-INF/services inside "wstx-asl-3.2.4.jar" is
configuring:

javax.xml.stream.XMLEventFactory:   com.ctc.wstx.stax.WstxEventFactory
javax.xml.stream.XMLInputFactory:   com.ctc.wstx.stax.WstxInputFactory
javax.xml.stream.XMLOutputFactory: com.ctc.wstx.stax.WstxOutputFactory 

What else would I have to do to force StaxUtils to use woodstox?

Thanks,

  -Chris
        
-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 7:27 AM
To: [email protected]
Subject: Re: Cannot request WSDL with CXF-2.1 deployed to Tomcat


This seems to be picking up the Sun JAXP parser and not woodstox.

This is fixed in the latest 2.1.1 snapshots (to work with either
parser).    For 2.1 release, you will probably need woodstox instead
of Sun's.

Dan


On Jun 10, 2008, at 6:37 PM, Wolf, Chris (IT) wrote:


I am not getting this exception:

javax.xml.stream.XMLStreamException: NamespaceURI cannot be null

If anyone can help, that would be great.
I recently upgraded from an April snapshot to CXF-2.1, and now I get a 


stack trace whenever I do an HTTP GET for the WSDL from my published
endpoint:



WARNING: org.apache.cxf.transport.http.WSDLQueryHandler Exception
caught writing response.
org.apache.cxf.transport.http.WSDLQueryException: Exception occurred
while trying to process
http://localhost:8080/wsstest/services/secadmin?wsdl
        at
org
.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHa
ndler.java:229)
        at
org
.apache.cxf.transport.servlet.ServletController.invoke(ServletControl
ler.java:137)
        at
org
.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFSe
rvlet.java:170)
[...]
Caused by: javax.xml.stream.XMLStreamException: NamespaceURI cannot be 


null
        at
com
.sun.xml.stream.writers.XMLStreamWriterImpl.writeAttribute(XMLStreamW
riterImpl.java:620)
        at
org.apache.cxf.staxutils.StaxUtils.writeElement(StaxUtils.java:520)
        at
org.apache.cxf.staxutils.StaxUtils.writeElement(StaxUtils.java:440)
        at
org.apache.cxf.staxutils.StaxUtils.writeDocument(StaxUtils.java:421)
        at
org.apache.cxf.staxutils.StaxUtils.writeDocument(StaxUtils.java:411)
        at
org.apache.cxf.staxutils.StaxUtils.writeNode(StaxUtils.java:560)
        at
org
.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHa
ndler.java:226)
I traced the problem to org.apache.cxf.staxutils.StaxUtils.java, lines 
484-488:

     } else {
//            System.out.println("Calling writeStartElement for local
name : "
//            + localName + " URI: " + ns + " Prefix :" + prefix);
          writer.writeStartElement(prefix, localName, ns);
      }

The values for the "writeStartElement" are:
prefix = "wsdl"
localname = "definitions"
ns = "http://schemas.xmlsoap.org/wsdl/";

The start element looks like:

<wsdl:definitions name="SecAdmin"
targetNamespace="urn:secadmin.svcscore.ibd.ms.com"
  xmlns="http://schemas.xmlsoap.org/wsdl/";
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
  xmlns:tns="urn:secadmin.svcscore.ibd.ms.com"
  xmlns:x1="urn:secadmin.svcscore.ibd.ms.com/types"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
  xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender.
Sender does not intend to waive confidentiality or privilege. Use of
this email is prohibited when received in error.


---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email 
is prohibited when received in error.
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. 

---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to