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.
Related
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.
We are escaping the special characters for exact search (" ") and it works fine, except for few cases where it throws
Arrayindex out of bounds exception at org.apache.solr.spelling.wordbreaksolrspellchecker.getSuggestions
search text : "PRINTING 9-27 TEST CARDS ADD-ON MATT LAMINATION ON 2-SIDE OF TEST CARDS PER BOX OF 100 PCS". the config is spellcheck.dictionary is default and commented the spellcheck.dictionary wordbreak
we cannot apply any patch now, checked the issue LUCENE-5494
any of you suggest any work around to get the results in-spite of the exception. any configuration changes to suppress suggest or spellcheck. commenting word break dictionary also didn't help. solr version 4.10.4
Due to security reasons, I cannot post anything related to code and sorry for the minimal information in the query.
Anyways It might be useful to someone like me. The reason even after commenting the wordbreak dictionary its still showing the exception is,the changes that were made in the solrconfig.xml file was not reflected. I was testing in my local machine which is a standalone environment. Restarting the container (weblogic) doesn't reflect the changes snd reloading the core through admin screen also didn't help. So import and reloadset and then restarting the container did the trick.
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'm trying to parse and load an XML document, however I'm getting this exception when I call the parse method on the class that extends XmlObject. Unfortunately, it gives me no ideas of what element is unexpected, which is my problem.
I am not able to share the code for this, but I can try to provide more information if necessary.
Not being able to share code or input data, you may consider the following approach. That's a very common dichotomic approach to diagnostic, I'm afraid, and indeed you may readily have started it...
Try and reduce the size of the input XML by removing parts of it, ensuring that the underlying XML document remains well formed and possibly valid (if validity is required in your parser's setup). If you maintain validity, this may require to alter [a copy of] the Schema (DTD or other), as manditory elements might be removed during the cut-and-try approach... BTW, the error message seems to hint more at a validation issue that a basic well-formedness assertion issue.
Unless one has a particular hunch as to the area that triggers the parser's complaint, we typically remove (or re-add, when things start working) about half of what was previously cut or re-added.
You may also start with trying a mostly empty file, to assert that the parser does work at all... There again is the idea to "divide to prevail": is the issue in the XML input or in the parser ? (remembering that there could be two issues, one in the input and one in the parser, and thtat such issues could even be unrelated...)
Sorry to belabor basic diagnostics techniques which you may well be fluent with...
You should check the arguments you are passing to the method parse();
If you are directly passing a string to parse or file or inputstream accordingly (File/InputStream/String) etc.
The exception is caused by the length of the XML file. If you add or remove one character from the file, the parser will succeed.
The problem occurs within the 3rd party PiccoloLexer library that XMLBeans relies on. It has been fixed in revision 959082 but has not been applied to xbean 2.5 jar.
XMLBeans - Problem with XML files if length is exactly 8193bytes
Issue reported on XMLBean Jira
Saving data to Postscript in my app results in a Postscript file which I can view without issues in GhostView, but when I try to print it, the printer isn't able to print it because it seems to be invalid.
Is there a way to validate / find errors in Postscript files without actually sending it to a printer? Preferred would be some kind of Java API/library, but a program which does the same would be fine as well.
Edit #1 : no I don't know why it's invalid, nor even necessarily if it's invalid, but would like to be able to validate it outside of ghostview, or figure out what's going on when it can't print.
Answer : Well using the ps2ps trick I was able to see the output that Postscript does and there check the difference. The difference was that I am not allowed to have a decimal number for the width or height of images in the Postscript, but rather only integers. So I still didn't find a way to validate, but this way was good enough for my problem. Thanks.
Whenever I need to validate a PostScript file using Ghostscript without having to actually look at its rendered page images I use the "nullpage" device:
gswin32c ^
-sDEVICE=nullpage ^
-dNOPAUSE ^
-dBATCH ^
c:/path/to/file/to/be/validated.pdf-or-ps ^
1>validated.stdout ^
2>validated.stderr
In case of a problem, there will be a non-zero %errorlevel% set, and the validated.stderr logfile will contain all the messages Ghostscript spit out during rendering.
Do you know why it's invalid?
My suggestion would have been to feed it to Ghostscript/Ghostvoiew, but given Ghostview can view it, it would seem that at least some interpreters think it is valid Postscript.
So it may be something specific to your printer - either it's picky about something in the PS that Ghostscript allows, or it's accessing something that doesn't exist on your printer (filesystem, perhaps) or exceeding some limit of memory, or...
The point being that it may not be an erroneous PS program and so a library/API to validate it might not help
Edit: Does any of it print? Have you tried a printer from a different manufacturer (or vendor of Postscript interpreter, anyway). Does Ghostview give/log any warnings or errors?
Where (what application) does the document originate from?
Can you generate other instances of the document? (e.g. a really simple/empty one to see if that also gives errors)
Unless there's an API providing access to the specific interpreter that's used in your printer, I think you are validating it against another PS interpreter (Ghostscript).
Since there aren't that many PS clones in the world, getting access to another non-GS based one probably isn't going to be easy
Edit2: This link (if quite old information) gives information about how to get more details from your printer on the error: http://www.quite.com/ps/errors.htm
If you can see it on ghostview, it means ghostscript can parse it.
So, one trick you could try using to print (but not to actually validate) your file would be to use ghostscript's postscript output mode (there is a wrapper called ps2ps for it, which mainly adds -sDEVICE=pswrite; there is also ps2ps2 which uses -sDEVICE=ps2write).