Please see stackoverflow link here:
http://stackoverflow.com/questions/42772424/testng-xml-not-valid
I am getting issues with the XML not meeting the DTD.
Tried on 6.11 and 6.9.11
XML should be valid with DTD.
Getting the error: 1: 3 The markup declarations contained or pointed to by the document type declaration must be well-formed.
I have some generated TestNG XMLs that worked for a long time, but recently they are invalid when I run them through Java's SAXParser and through http://www.xmlvalidation.com/
Example generated XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite thread-count="1" verbose="2" name="TestNG Forum" parallel="tests">
<test name="TestNG Test0" preserve-order="false">
<parameter name="device" value="58f56054954b6b3e323a3405fc49023eb1569a98"/>
<packages>
<package name="output"/>
</packages>
</test> <!-- TestNG Test0 -->
</suite> <!-- TestNG Forum -->
Example XML from TestNG's site @ http://testng.org/doc/documentation-main.html
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Suite1" verbose="1" >
<test name="Nopackage" >
<classes>
<class name="NoPackageTest" />
</classes>
</test>
<test name="Regression1">
<classes>
<class name="test.sample.ParameterSample"/>
<class name="test.sample.ParameterTest"/>
</classes>
</test>
</suite>
EDIT:
SAXParser error:
[Fatal Error] testng-1.0.dtd:1:3: The markup declarations contained or pointed to by the document type declaration must be well-formed.
org.xml.sax.SAXParseException; systemId: http://testng.org/testng-1.0.dtd; lineNumber: 1; columnNumber: 3; The markup declarations contained or pointed to by the document type declaration must be well-formed.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:205)
at com.video.recorder.XpathXML.parseXML(XpathXML.java:42)
at com.cucumber.listener.ExtentCucumberFormatter.feature(ExtentCucumberFormatter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at cucumber.runtime.Utils$1.call(Utils.java:37)
at cucumber.runtime.Timeout.timeout(Timeout.java:13)
at cucumber.runtime.Utils.invoke(Utils.java:31)
at cucumber.runtime.RuntimeOptions$1.invoke(RuntimeOptions.java:290)
at com.sun.proxy.$Proxy17.feature(Unknown Source)
at cucumber.runtime.model.CucumberFeature.run(CucumberFeature.java:161)
at cucumber.api.testng.TestNGCucumberRunner.runCucumber(TestNGCucumberRunner.java:63)
at cucumber.api.testng.AbstractTestNGCucumberTests.feature(AbstractTestNGCucumberTests.java:21)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:108)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:661)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:869)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1193)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.privateRun(TestRunner.java:744)
at org.testng.TestRunner.run(TestRunner.java:602)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:380)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:39)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:414)
at org.testng.internal.thread.ThreadUtil$1.call(ThreadUtil.java:52)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
@brtu
It is saying that DTD https://raw.githubusercontent.com/cbeust/testng/master/src/main/resources/testng-1.0.dtd is not valid but I don't see why.
Ping @cbeust @krmahadevan
From http://www.xmlvalidation.com/
Getting the error: 1: 3 The markup declarations contained or pointed to by the document type declaration must be well-formed.
From TestNG it should not happen because it uses the DTD included into the jar.
@brtu What is the message from SAXParser?
@juherr @cbeust updated the issue with the SAXParser message. I'm afraid it is pretty vague and not very helpful.
I think that the https://raw.githubusercontent.com/cbeust/testng/master/src/main/resources/testng-1.0.dtd is correct, because when I change the DTD reference in the XML from the external reference
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
to a local reference
<!DOCTYPE suite SYSTEM "testng-1.0.dtd">
and put the following into www.xmlvalidation.com
<!DOCTYPE suite SYSTEM "testng-1.0.dtd" >
<suite name="Suite1" verbose="1" >
<test name="Nopackage" >
<classes>
<class name="NoPackageTest" />
</classes>
</test>
<test name="Regression1">
<classes>
<class name="test.sample.ParameterSample"/>
<class name="test.sample.ParameterTest"/>
</classes>
</test>
</suite>
and then copy+paste the results of https://raw.githubusercontent.com/cbeust/testng/master/src/main/resources/testng-1.0.dtd to www.xmlvalidation.com as a local reference, then there are no errors.
Could there be a problem with the redirect?
Could there be a problem with the redirect?
Yes, it looks like xerces doesn't follow redirection.
But you can use your own dtd resolver: https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/xml/TestNGContentHandler.java#L89-L116
BTW, what are you trying to do? If you need to access to XmlSuite
from your code, you may create an ISuiteListener
which store the XmlSuite
in a static variable and you will be able to use it in your code.
Ah, I see. This problem arose when I was using the https://github.com/saikrishna321/AppiumTestDistribution library to run Appium tests in parallel. My quick workaround was just removing the DTD reference from the xml file so it wouldn't throw a parsing exception. I'll look into using another dtd resolver/ISuiteListener.
@brtu In fact, I proposed 2 different solutions: ISuiteListener
should avoid parsing the suite and a custom dtd resolver should allow to parse the suite without problem.
I just removed the redirect and restored the actual testng-1.0.dtd
file at http://testng.org/testng-1.0.dtd
. Let's see if this fixes the problem.
@cbeust - I can confirm it works fine. I just now removed the testing-1.0.dtd
from src/main/resources
in the TestNG codebase and ran a suite xml test. It successfully retrieves the DTD from the URL and works with it. Doesn't complain any more. So I guess we should be good now.
@cbeust Thanks, I believe that this fixes the problem. When I plug the sample xml into www.xmlvalidation.com there are no errors that are found.
I also noticed that by default, the server sets the MIME type as application/html
for the DTD, which might have been a reason for the errors (although we would have seen them when we were serving the local file too).
I am now returning application/xml-dtd
for the DTD file, which I guess can't hurt:
org.xml.sax.SAXParseException; systemId: http://testng.org/testng-1.0.dtd; lineNumber: 1; columnNumber: 3; The markup declarations contained or pointed to by the document type declaration must be well-formed.
Above issue is back as of April 03, 2019. All tests were working fine as of yesterday but today we are getting above error message. Was there any update done recently? Can anyone help? We are completely blocked by this.
That DTD hasn't changed in a while, no idea what is causing this right now.
--
Cédric
On Wed, Apr 3, 2019 at 6:30 AM equazi notifications@github.com wrote:
org.xml.sax.SAXParseException; systemId: http://testng.org/testng-1.0.dtd;
lineNumber: 1; columnNumber: 3; The markup declarations contained or
pointed to by the document type declaration must be well-formed.
Above issue is back as April 03, 2019. All tests were working fine as of
yesterday but today we are getting above error message. Was there any
update done recently? Can anyone help? We are completely blocked by this.—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cbeust/testng/issues/1385#issuecomment-479489538, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFootZV56yAmwCjd95AYOvhma7Fsz5Sks5vdKzCgaJpZM4Mb0Wu
.
Confirm, it's broken again today (yesterday worked fine).
curl shows redirect info:
curl http://testng.org/testng-1.0.dtd
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
`</head><body>`
<h1>Found</h1>
<p>The document has moved <a href="https://testng.org/testng-1.0.dtd">here</a>.</p>
<hr>
<address>Apache/2.2.34 Server at testng.org Port 80</address>
</body></html>
If I change the link in xml to https the validation is passed.
How is that broken, though?
It's a 302, redirection, to the https version, and that https URL works:
$ curl https://testng.org/testng-1.0.dtd|head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 8337 100 8337 0 0 86570 0 --:--:-- --:--:-- --:--:-- 86843
<!--
Here is a quick overview of the main parts of this DTD. For more information,
refer to the <a href="http://testng.org">main web site</a>.
Since Xerces doesn't honor redirections (which is baffling, to be honest), you should point to the https
version of the DTD directly.
If we use https in testng.xml and using maven surfire report then getting error
as org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the forked process
java.net.ConnectException: Connection timed out (Connection timed out)
Hi All,
The parsing of Testng.xml with http://testng.org/testng-1.0.dtd was working till 02-April-2019. It started failing parsing by throwing same error same as error reported earlier from yesterday onwards i.e. 03-April-2019. Please help me how to overcome this issue.
Thanks,
Shyamal Surai
I removed the doctype tag from the testing.xml, then my tests are running fine without any errors.
Is there any impact in removing Doctype tag?
The XML parser you are using is not honoring redirects. Point to the DTD
on the https port directly.
--
Cédric
On Wed, Apr 3, 2019 at 10:59 PM ssurai notifications@github.com wrote:
Hi All,
The parsing of Testng.xml with http://testng.org/testng-1.0.dtd was
working till 02-April-2019. It started failing parsing by throwing same
error same as error reported earlier from yesterday onwards i.e.
03-April-2019. Please help me how to overcome this issue.
Thanks,
Shyamal Surai—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cbeust/testng/issues/1385#issuecomment-479761038, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFoogJHQY6nzd6uZmj8VsAbN9HqQqC0ks5vdZSCgaJpZM4Mb0Wu
.
@cbeust
We have hundreds of suite files and before April 03 all of them were validated perfectly with http link to DTD. But starting from April 03 the problem occurs again.
Just wondering how it could happen that it works before 03 (as you can see many people reporting the issue starting from this day)? Was anything changed since March, 15 of 2017, when you left the comment like this?
I just removed the redirect and restored the actual testng-1.0.dtd file at http://testng.org/testng-1.0.dtd. Let's see if this fixes the problem.
I curl the dtd file and saw a message that it was moved to https://testng.org/testng-1.0.dtd. So I just changed the url in my in the testng xml to https://testng.org/testng-1.0.dtd instead of http://testng.org/testng-1.0.dtd, now it's working on my end.
@zloygreko I set up a redirect that automatically routes all traffic from port 80 to 443 on testng.org. This is a requirement to keep everyone safe.
If your XML parser doesn't follow redirects, you should make sure to reference the DTD via https and not http.
@cbeust : if we use https://testng.org/testng-1.0.dtd., i see maven-surfire is throwing connection reset when generating surefire-reports
Hi!
Starting from this Wednesday we see the problem described in this issue ticket. Cedric, I tried first to swith to HTTPS to access testng.org in our test suites (as you advised to do), but unfortunately this turned out to be not simple in case of our project due to complicated Firewall setup.
And I agree with idea which zloygreko expressed, like why it failed if it worked before? No matter what was done there - it shouldn't have affected Testng users.
And in our project case we are affected dramatically. Can't you please kindly resolve the problem on your end somehow?
like why it failed if it worked before
Because I recently configured testng.org to automatically redirect HTTP to HTTPS.
Your options are either to point to the DTD at the HTTPS URL, or to use an XML parser that supports redirects.
I'm a bit hesitant removing the rerouting because not using HTTPS is unsafe.
By default, TestNG is not looking for the dtd on the web but takes the one from the jar.
Sadly, the https URL is not known by the old TestNG versions and only the next beta version will fix the issue thanks to https://github.com/cbeust/testng/pull/2023
Another option could be to add the new URL in the Java XML Catalog but I don't know if all tools will support it.
Right Click on the class, select Run--> Run configuration
By default one testNg class will be generated with same class name under testng option
Select that class and go to Arguments tab
In the VM arguments provide -Dtestng.dtd.http=true
and update testng.xml file as follows
http -----> https
Recently getting the error while trying to parse the HTTPS request with TestNG.
Changing to HTTPS did work as Intellij was able to accept the server certificates
By using TestNG 7.3.0, when JVM option -Dtestng.dtd.http=true
is used with <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
together, test failed due to java.net.ConnectException: Connection timed out (Connection timed out)
finally.
Without the JVM option, test failed with error message: TestNG by default disables loading DTD from unsecured Urls. If you need to explicitly load the DTD from a http url, please do so by using the JVM argument [-Dtestng.dtd.http=true]
.
When changed to https, it works well.
I curl the dtd file and saw a message that it was moved to https://testng.org/testng-1.0.dtd. So I just changed the url in my in the testng xml to https://testng.org/testng-1.0.dtd instead of http://testng.org/testng-1.0.dtd, now it's working on my end.
Thanks a lot, it's helped me
I'm having this problem when using TestNG 7.3.0 in Eclipse. Where do you find the "TestNG xml" ... is that somehow generated by Eclipse?
By using TestNG 7.3.0, when JVM option
-Dtestng.dtd.http=true
is used with<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
together, test failed due tojava.net.ConnectException: Connection timed out (Connection timed out)
finally.Without the JVM option, test failed with error message:
TestNG by default disables loading DTD from unsecured Urls. If you need to explicitly load the DTD from a http url, please do so by using the JVM argument [-Dtestng.dtd.http=true]
.When changed to https, it works well.
when running the test.xml, your solution works. but if just want to run the single test not the xml file, how to solve this problem except edit every test's JVM parameter as following? this way is a little complex and annoying.
@juherr does this issue need to be reopened? I think this got a bit more streamlined when https://github.com/cbeust/testng/pull/2409 was merged.
And if the problem is in eclipse only shouldn't we be moving this or opening a new one on the eclipse project ?
@juherr I don't know where is the issue the latest updates are recent.
To be honest, I didn't remember #2409. Could you confirm it is fixing the issue?
Most helpful comment
I curl the dtd file and saw a message that it was moved to https://testng.org/testng-1.0.dtd. So I just changed the url in my in the testng xml to https://testng.org/testng-1.0.dtd instead of http://testng.org/testng-1.0.dtd, now it's working on my end.