> 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.
For JDK-1.6.0_04 the stream parser impl is in the JRE rt.jar, so you can't get rid of it, however, this impl can be overidden simply by including the wstx-asl.x.x.x.jar in the deployment. Please refer to the JAR Service Provider mechanism for details: http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Service% 20Provider If there is (inadvertantly) more then one StAX impl in the deployment (WEB-INF/lib), then the impl jar whose name is lower in alpha-numeric sequence. (At least with Tomcat) e.g. if both wstx-asl-x.x.x.jar and sjsxp.jar are in the deployment, then sjsxp.jar takes precedence and the XMLOutputFactory impl class will be com.sun.xml.stream.ZephyrWriterFactory rather then com.ctc.wstx.stax.WstxOutputFactory (woostox) or com.sun.xml.internal.stream.XMLOutputFactoryImpl (JRE-1.6.0_04 default). On the otherhand, if you were to rename "wstx-asl-x.x.x.jar" to "Awstx-asl-x.x.x.jar" in WEB-INF/lib, then the Woodstox impl would take precedence. If you completely remove all StAX impl JARs from WEB-INF/lib, then the JRE default parser factories will be in effect. i.e. For output, com.sun.xml.internal.stream.XMLOutputFactoryImpl For JRE 1.5.x you also need to put the StAX API jar into the deployment. With JRE-1.5.x, the StAX API will default to com.bea.xml.stream.XMLOutputFactoryBase as the XMLOutputFactory impl, in the absence of a StAX impl JAR. -Chris -----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 12:02 PM To: [email protected] Subject: Re: Cannot request WSDL with CXF-2.1 deployed to Tomcat 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 -------------------------------------------------------- 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.
