I've started getting this error when trying to run a cucumber test:
No tests were found
Exception in thread "main" cucumber.runtime.DuplicateStepDefinitionException: Duplicate step definitions in e2e.brukerveiledning.BrukerveiledningSteps.jegGårTilLivssituasjonForAaSeNyFunksjonFor(String) in file:/home/frank/Desktop/saksbehandling/e2e/cucumber/target/test-classes/ and e2e.brukerveiledning.BrukerveiledningSteps.jegGårTilLivssituasjonForAaSeNyFunksjonFor(String) in file:/home/frank/Desktop/saksbehandling/e2e/cucumber/target/test-classes/
Now, I really don't understand this error message. It claims there is a duplicate step definition, and it points to a folder, calling it a file. Also, it's an output folder, and not a folder containing actual source files. So how does anything get "duplicate"?
And this goes for a lots of steps and definitions that have been working fine up until now. Every time I comment out one alleged "duplicat", it goes on to claim that another step is a duplicate. And for every single one of them, a search yields one and only one result.
Any ideas?
And the step definition it claims is duplicated IS NOT DUPLICATED. A search for the name yields only one result.
For the example above:
#Når("^jeg går til livssituasjon for aa se ny funksjon for \"([^\"]*)\"$")
public void jegGårTilLivssituasjonForAaSeNyFunksjonFor(String sakTag) {
long sakId = ScenarioState.getSakId(sakTag);
navigationPage.gaTilPath("/sak/" + sakId + "/livssituasjon", false);
}
When searching for this step definition, only one match is found:
If I comment out this definition and try to run the test(s), it moves on to the next one with the same claim, yielding an identical result.
So there's clearly some deeper error somewhere, since the error claim is completely bogues (seemingly, at least).
Also, when the error first occurs (in Jenkins, and reproduced locally afterwards), some tests run fine and som don't. But after trying to run one of those that failed, all other tests suddenly fail too.
Related
While using IText to process HTML to create a PDF file I get the following error in the logger:
ERROR 9260 --- [nio-8080-exec-2] c.i.h.attach.impl.DefaultHtmlProcessor : Worker of type com.itextpdf.html2pdf.attach.impl.tags.PTagWorker unable to process com.itextpdf.html2pdf.attach.impl.tags.DivTagWorker
The error is not a typical stack trace error, just a single in the logger. It also doesn't stop execution, and a PDF is generated eventually. Both my HTML and PDF files are rather large, so it's difficult to check piece by piece, but a quick look doesn't seem to show any actual errors in the target file.
Is there a specific reason why this error happens/is shown? And will it eventually prevent a PDF file from being generated?
(All of this is happening in the context of a Spring Boot application. I don't know if that might be relevant).
Even if your HTML file is large, you don't have to check piece by piece and you can make use of binary search approach instead - split your document into two more or less equal pieces and try with the first half of the file, and if the problem reproduces split it further down into two pieces. If the problem does not reproduce for the first half of the file then it should reproduce for the second half of the file and you will continue to split the file pieces into two smaller ones until the file is small enough to see the problem.
As pdfHTML add-on is open source, you can debug the source of the problem instead - just go to the source of PTagWorker#processTagChild and hit the breakpoint at the return false; line (see source on GitHub) - if the result if false then the error in question is logged. From there you will be able to better see the context of the elements triggering the log error by inspecting the invocation one level down the call stack in DefaultHtmlProcessor#visit and namely element local variable that corresponds to an HTML element.
So specific reason can be deducted by using on of the approaches presented above - it can be a bug/missing feature in pdfHTML, or the fact that a block level element is added to a paragraph level element and that was not normalized automatically.
This log error will by itself not prevent a PDF file from being generated, but it can result in some content missing in the resultant PDF, so it it important to find the root cause.
For my computing gcse, i have to write code which takes a text file, i used JFK's moon speech and pasted it into a word file five times, and the code has to do a few things; -Rewrite the speech with no duplicates -Rewrite the speech but in digits. each word in the speech (excluding duplicates) are given a number which corresponds with the position of the word in the speech When compiling the code im getting no syntax errors but when i run the program the program displays: "Error Occurred Error occured when writing file" i have no clue on how to fix this so if anyone could take a look at my code and suggest how to fix it that'd be a great help.
http://pastebin.com/3avu4ni3
Well actually your error was very simple.
Your code does not handle the Exception where there is no data written in the ImportantSentence.txt
If you write anything inside it, save it and then run your code you will see it works just fine.
I think you put the file in the incorrect path and it was not finding it. Since you did not add a case that checks the existence of the txt and creates it if it does not finds it, then the error occurred. I have done the above two checks and everything works just fine.
Hope it helps.
Best regards
I have a large block of programmatically generated HTML. I ran it through Tidy (version r938) with the following Java code:
StringReader inStr = new StringReader(htmlInput);
StringWriter outStr = new StringWriter();
Tidy tidy = new Tidy();
tidy.setXHTML(true);
tidy.parseDOM(inStr, outStr);
I get the following output:
InputStream: Document content looks like HTML 4.01 Transitional
247 warnings, 3 errors were found!
This document has errors that must be fixed before
using HTML Tidy to generate a tidied up version.
Trouble is, Tidy doesn't tell me what 3 errors it found.
I'm fibbing here a little. The output above actually follows a long list of all 247 warnings (mostly trimming out empty div elements). I can suppress those with tidy.setShowWarnings(false); either way, I see no error report, so I can't figure out what I need to fix. 300Kb of HTML is too much for me to eyeball.
I've tried numerous approaches to finding the error. I can't run it through validate.w3.org, sadly, as the HTML file is on a proprietary network. The most informative approach was to open it in IntelliJ IDEA; this revealed a dozen or so duplicate div IDs, which I fixed. Errors still occurred.
I've looked around for other mentions of this problem. While I find plenty of hits on things like "How can I get the error/warning messages out of the parsed HTML using JTidy?", they all appear to be asking for dissimilar things, or assume conditions that simply aren't holding for me. I'm getting warnings just fine, for example; it's the errors I need, and they're not being reported, even if I call setShowErrors(100) or something.
Am I going to have to dive into Tidy's source code and debug it, starting where it reports errors? Or is there something much simpler I could do?
Here's what I ended up doing to track down the errors:
Download JTidy's source. Most people should be able to go straight to the source.
Unzip the source into my dev area. Right on top of my existing source code. This also meant removing the Maven entry for JTidy from my pom.xml. (It also meant beating IntelliJ into submission (re: editing the relevant .iml files and restarting IJ a lot) when it got extremely confused by this.)
Set a breakpoint in Report.error. The first line of org.w3.tidy.Report.error() increments lexer.errors; error() is called from many places in the lexer.
Run my program in debug mode. Expect this to take a little while if the input HTML is large; a 300k file took around 10-15 seconds on my machine to stop on an error that turned out to be at the very end of the file.
Look at the contents of lexbuf. lexbuf is a byte array, so your IDE might not show it as text. It might also be large. You probably want to look at what index the lexer was looking at within lexbuf. If you have to, take that section of the byte array and cross-reference it with an ASCII table to get the text.
Search for that text in your HTML. Assuming it appears only once, there's your error. (In my case, it appeared exactly three times, and sure enough, I had three errors reported.)
This was much more involved than it probably should have been. I suspect Report.error() was being called inappropriately.
In my case, error() was called with the constant BAD_CDATA_CONTENT. This constant is used only by Report.warning(). error() doesn't know what to do with it, and just exits silently with no message at all. If I change the call in Lexer.getCDATA() from error() to warning(), I get the exact line and column of my error. (I also get what appears to be reasonably well-formed XHTML, instead of an empty document.)
I'd submit a ticket to the JTidy project with some suggestions, but SourceForge isn't letting me log in for some reason. So, here:
Given that this "error" appears not to doom the document to unparseability, I'll tentatively suggest that that call be made a warning instead. (In my specific case, it was an HTML tag inside a string constant or comment inside a script element; shouldn't have hurt anything. I asked another question about it, just in case.)
Report.error() should have a default case that reports an unhandled error code if it gets one.
Hope this helps anyone else having what I'm guessing is a rather esoteric problem.
I have a Java program, using Vertx 2, and when I run it, I get a message:
% vertx run -cluster com.abc.prep.manager.PrepStartup -cp ./build/libs/Operational-all-1.0.jar -conf safe.conf
Starting clustering...
No cluster-host specified so using address 172.17.0.1
[Fatal Error] :6:3: The element type "hr" must be terminated by the matching end-tag "</hr>".
Prep Starting up!
Succeeded in deploying verticle
I cannot figure out where that '[Fatal Error]' message is coming from. If someone knows what vertx is doing (since I think it's coming from there), that would be great.
But my real question is: How do I find out who is printing that? What class in which jar? I can't seem to set a breakpoint in System.out or System.err that catches it (I'm using Intellij). Can I override (all) output so that it prints a stacktrace?
How do you find who is printing that? I can't speak to specifics with Vertx 2, but I've had to track down plenty of mysterious errors. This is my general pattern, applied as far as possible to yours:
Get an idea of what the error is. Google the static (would be the same for anybody) elements in the error message. Here, that could be "must be terminated by the matching end-tag". Adding "vertx" to the query gave me some links, but I didn't see any instant answers. I did find out that it's probably an XMLStreamException. You might be able to breakpoint on that.
Assuming that didn't work, search your code base by text, looking for that same static text. Armed with the knowledge from your Google investigation, you should be able to narrow down any results to a manageable number to check.
If your search finds nothing, make sure you have source files attached for everything in your module that you can get source files for. Then retry step 2.
Once you've found the code that throws the error, you should be able to put a breakpoint.
The code basically just compares two files line by line and reports an error to the error collector every time a mismatch is found. However, although it reports the correct number of failures which is 4 in this case, the Result comparison window only shows the first one. I think this is because a new try/catch block is required for a separate entry in the Result Comparison window but in this case I am using a while loop and not sure how I can implement a separate try/catch block for each iteration. Anyone know how I can make the Result Comparison window of JUNIT show each mismatch. I have provided images of the code and the window. Thanks
Try using an error collector rule as described in the accepted answer to this other question
Ignore Assertion failure in a testcase (JUnit)