I get this error when I use my autogenerated ServiceBindingStub.java. WebService side is working ok, so this error must be in code, but code is autogenerated, so I cannot know why it doesn't work. Some other calls work fine, but this doesn't. This call included updating, while other working calls are just fetching data from WebService.
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXParseException: Premature end of file.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXParseException: Premature end of file.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
This happens when service you are connecting to does not return SOAP response, but some text or HTML. Try opening the URL in the browser or use some SOAP debugger like SOAP UI to see what is returned from the service.
I once had the same problem. In my case, I received messages with 'binary data' between tags (imagery). Axis used a fixed size buffer to read the data, once the buffer was full it just proceeded and ran out of sync.
In fact, you should be able to find the tag or part in the xml file by debugging the stub code step by step. No guarantee, that the issue will can be solved easily but it might give you a hint that the (a) stub is not generated correctly or (b) the xml file is just not well-formed or valid against the schema that has been used to generate the stub.
Good luck! (I didn't solve my issue..)
I just had (and solved) this problem, following Superfilin's answer. In the end, the problem turned out to be that I hadn't added a <beanMapping> for one of the classes I was returning in my deployment.wsdd file. Any time the response would have included that class, I'd get a completely empty message body instead.
Even we have faced the same issue. But there are some special characters in the content. We removed those special characters and it worked fine.
Related
Test case:
1.Open valid application url, for example
http://127.0.0.1:8888/rest/hosted/index?gwt.codesvr=127.0.0.1:9997#xxx:yyy
2.Change url to have some UTF-8 encoded characters, for example,
http://127.0.0.1:8888/rest/hosted/index?gwt.codesvr=127.0.0.1:9997#xxx:%u0041
As you see, it contains invalid character %u0041.
After that, GWT is throwing infinite exceptions with stacktrace
com.google.gwt.core.client.JavaScriptException: (URIError) #com.google.gwt.core.client.impl.Impl::apply(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)([JavaScript object(10822), JavaScript object(10823), JavaScript object(11420)]): The URI to be decoded is not a valid encoding
at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:249)
at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:576)
at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:284)
at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
at com.google.gwt.core.client.impl.Impl.apply(Impl.java)
at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:356)
at sun.reflect.GeneratedMethodAccessor299.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)
at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:293)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:547)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
at java.lang.Thread.run(Thread.java:662)
Why it throws repeated exceptions and how can I avoid it?
EDIT
Unfortunately I cannot show code since it seems to me that it is GWT's internal stuff. I don't code it, when I change URL in URL bar and press enter, GWT reacts all by itself. It is not feasible option, but it fails penetration tests.
EDIT 2
It appears it happens only in IE 11
GWT version - 2.6.1
Hi I am using jena to read som rdf file:
InputStream in = FileManager.get().open(adress);
model.read(in, adress);
problem in second row which throw sometimes SAXParseException:
org.xml.sax.SAXParseException: Element or attribute do not match QName production: QName::=(NCName':')?NCName.
com.hp.hpl.jena.shared.JenaException: org.xml.sax.SAXParseException: Element or attribute do not match QName production: QName::=(NCName':')?NCName.
at com.hp.hpl.jena.rdf.model.impl.RDFDefaultErrorHandler.fatalError(RDFDefaultErrorHandler.java:45)
at com.hp.hpl.jena.rdf.arp.impl.ARPSaxErrorHandler.fatalError(ARPSaxErrorHandler.java:35)
at com.hp.hpl.jena.rdf.arp.impl.XMLHandler.warning(XMLHandler.java:225)
at com.hp.hpl.jena.rdf.arp.impl.XMLHandler.fatalError(XMLHandler.java:255)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLEntityScanner.scanQName(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.hp.hpl.jena.rdf.arp.impl.RDFXMLParser.parse(RDFXMLParser.java:142)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:158)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:145)
at com.hp.hpl.jena.rdf.arp.JenaReader.read(JenaReader.java:215)
at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:197)
so I want to do some try catch block. The problem is when I do this, compiler return:
exception org.xml.sax.SAXParseException is never thrown in body of
corresponding try statement
So how I can chatch this exception ? I know that I can catch just Exception but then I cannot be sure where the problem occurs
SAXParserException is a "checked-exception" meaning that the method signature is forced to declare it, if it throws. Obviously, the method you call does not declare it, so you cannot catch it.
It looks like Jena is actually wrapping that exception in an "unchecked-exception" (ie, an exception that extends RuntimeException). This exception is actually JenaException. So you could add a try/catch for a JenaException and then use getCause() to find the original error encoutered by Jena.
You should catch JenaException instead of the SAXParseException. And then try to get the cause that might be the SAXParseException.
If you are looking to handle problems with your RDF XML input, there is a more direct way using the error handler interface to the Jena reader.
I created a web services client using Eclipse's built-in web service client creator (which I believe uses Apache Axis to generate the code?), and I'm running into an error that I can't seem to figure out. Here's what the exception says:
Exception in thread "main" AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server
faultSubcode:
faultString: Call to a member function setValue() on a non-object
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:Call to a member function setValue() on a non-object
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.symplicity.oppsplace_demo.ws.job_api_php.JobWebServiceBindingStub.processJob(JobWebServiceBindingStub.java:280)
at com.symplicity.oppsplace_demo.ws.job_api_php.JobWebServicePortProxy.processJob(JobWebServicePortProxy.java:56)
at main.OppsPlaceIntegration.main(OppsPlaceIntegration.java:37)
I'm using the API provided by OppsPlace (a job posting site), and specifically I used this WSDL to build a client for their test environment.
Basically I create a Job object and a Contact object (generated classes from the WSDL) that are passed into the service along with my unique ID. It just bombs out with this same exception no matter what I try changing in my code.
As can be seen, the exception is happening pretty deep inside the Apache code, and for the life of me I can't figure out why. Any thoughts/ideas?
It mentions 'member function' while Java officially has no functions, only methods. The error message looks like the PHP 'Call to a member function on a non-object'. It is probably no coincidence that the OppsPlace API is implemented in PHP.
Congratulations, you ran into a bug in the API you are calling.
I'm less than a beginner in Java (I'm a .NET developer), but i have to fix a Java error when invoking a WebMethod through a proxy class.
From .NET, I can call it with no problems, but in Java, this is what happens:
java.lang.IllegalArgumentException
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at weblogic.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1411)
at weblogic.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1613)
at weblogic.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1174)
at weblogic.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:399)
at weblogic.apache.xerces.framework.XMLParser.parse(XMLParser.java:1147)
at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:135)
at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:147)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:796)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.verizon.vmw.csgw.ws.updateDOJob.v4_4.wsdl.UpdateDOJobServiceSoapBindingStub.updateDOJob(UpdateDOJobServiceSoapBindingStub.java:206)
at com.verizon.vmw.csgw.ws.updateDOJob.v4_4.wsdl.UpdateDOJobServiceProxy.updateDOJob(UpdateDOJobServiceProxy.java:50)
at rm.interfaces.wfadosnd.WfaDoSndWorker.updateDOJobComments(WfaDoSndWorker.java:1111)
at rm.interfaces.wfadosnd.WfaDoSndWorker.checkEtaAsgn(WfaDoSndWorker.java:507)
at rm.interfaces.wfadosnd.WfaDoSndWorker.resequenceDODispatches(WfaDoSndWorker.java:541)
at rm.interfaces.wfadosnd.WfaDoSndWorker.processOutboundRows(WfaDoSndWorker.java:283)
at rm.interfaces.wfadosnd.WfaDoSndWorker.run(WfaDoSndWorker.java:112)
at rm.util.WorkerThread.run(ThreadPool.java:152)
Does anyone have any idea of what could be causing this exception?
Check with Wireshark what goes over the wire and diff the .NET request with the java request.
Looks like your web application was receiving a message, and one of its fields failed verification that it was the right type (or acceptable value).
Whether that was a data issue, or a coding issue depends heavily on the data, code, and intent which are all not provided.
As you can see from the class names in the stack trace, the exception is thrown during deserialization of the webservice response.
The exception itself is pretty generic and hence carries little useful information.
Try looking at the response sent over the wire, or set an exception breakpoint in eclipse so you can inspect the stack frames the exception is thrown to get additional context. (To ease interpretation of what went wrong, you'll probably want to procure the source code of your web service stack).
look in the code for something is parsed for user input
like this Integer i = Integer.parseInt("string");
and the "string" contains none valid number
on Windows systems. I get the following NPE with the FileChooser. It is a known bug that is not fixed by sun yet. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342301
Does somebody know a workaround to prevent this exception?
Thanks.
André
Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
at
javax.swing.plaf.metal.MetalFileChooserUI$IndentIcon.getIconWidth(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabelImpl(Unknown
Source) at javax.swing.SwingUtilities.layoutCompoundLabel(Unknown
Source) at javax.swing.plaf.basic.BasicLabelUI.layoutCL(Unknown
Source) at
javax.swing.plaf.basic.BasicLabelUI.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source) at
javax.swing.plaf.basic.BasicListUI.updateLayoutState(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState(Unknown
Source) at
javax.swing.plaf.basic.BasicListUI$Handler.valueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown
Source) at
javax.swing.DefaultListSelectionModel.fireValueChanged(Unknown Source)
at javax.swing.DefaultListSelectionModel.changeSelection(Unknown
Source) at
javax.swing.DefaultListSelectionModel.changeSelection(Unknown Source)
at javax.swing.DefaultListSelectionModel.setSelectionInterval(Unknown
Source) at javax.swing.JList.setSelectedIndex(Unknown Source) at
javax.swing.plaf.basic.BasicComboPopup.setListSelection(Unknown
Source) at javax.swing.plaf.basic.BasicComboPopup.access$300(Unknown
Source) at
javax.swing.plaf.basic.BasicComboPopup$Handler.itemStateChanged(Unknown
Source) at javax.swing.JComboBox.fireItemStateChanged(Unknown Source)
at javax.swing.JComboBox.selectedItemChanged(Unknown Source) at
javax.swing.JComboBox.contentsChanged(Unknown Source)
In the bug report that you linked to, they also mention a workaround.
It seems to come down to calling the methods in a specific order.
Have you tried that?
A DESCRIPTION OF THE PROBLEM :
There appears to be an undocumented bad intereaction between
explicitely setting the UI and removing all file filters, even temporarily.
If the latter is done before setting the ui, trying to display a file dialog
will throw an exception but not if the ui was set prior to messing with
the filters. Maybe it is possible to make the code more robust against
this or to include a warning in the docs?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached program: it will not bomb. Then move the setUI
line to the bottom of the constructor and try again: it will.
So, now with registered account :)
The problem with these steps in the mentioned link is, that the look and feel and therefor the UI is set globaly in our software. So the UI is set before I'm able to manipulate the file filters.
Edit: Missunderstood the code for reproduction. The exampled works as mentioned. Thanks.
It looks like the workaround description says you should try to set the UI before manipulating the filters. Does this not work?
If that doesn't work, is it possible to create an instance of your manipulated FileFilters at the same point that you are setting your UI?