I'm getting the following in my console. It's not coming from my code. I've placed several libraries such as WebLogic, sun, javax, in my step filters. Is there a way to tell which library generated this message? I don't really want to step through all of the library classes that I'm using to try to find this.
[Fatal Error] :1:80: The element type "body" must be terminated by the matching end-tag "</body>".
When this happens to me, I typically first reach for Google. These days most error messages have been posted by someone somewhere, although you have to ensure you strip your specifics (in this case the "body" sounds pretty specific) out of it.
If Google doesn't help or just takes too long, I typically end up running a binary search tool over my lib directory. The results aren't pretty. But once I know which jar contains the message, I can zoom into a prettier format for the details.
Related
I'm trying to debug an XSL transform using Visual Studio, but it keeps barfing on the clause:
xmlns:java="org.dita.dost.util.StringUtils"
This particular item is in the Dita OT library, which I have downloaded. I cannot find a way to "install" it or make it available to Visual Studio to let the XSLT go through.
-- Edit --
Of course it wasn't the mxlns line that was barfing, it was the first time it was used:
Running through another XSLT gives a similar error. In both cases it looks like Java can't find the namespace/class/JAR file. I have very little experience with setting up Java (read "very little" as "none"). Is there something I need to do to make the JAR file visible to Java?
I've noticed a curious thing while trying to dynamically generate JNLP files based on URL parameters passed to a HTTP server. If I have something like this in my HTML code, it works:
<embed type="application/x-java-applet;" launchjnlp="dummy.jnlp"/>
If on the other hand I have a % character in the launchjnlp attribute, the plugin simply won't do anything:
<embed type="application/x-java-applet;" launchjnlp="dummy%3f.jnlp"/>
No error messages, no default Java splash screen, nothing, it silently fails. (Without even attempting to retrieve the JNLP file.)
Is this some kind of security feature? If it is, what is it supposed to guard against?
Or could it be a straightforward bug?
Update: Using the % entity instead of a % sign doesn't work either.
Update 2: I tried and failed to find any documentation on the exact semantics of the launchjnlp attribute, but the entire tag is generated by deployJava.launchWebStartApplication(jnlp), which is supposedly the "official" way of launching a Web Start application from a browser.
Update 3: Just to be absolutely crystal clear about this: the above example is just that: an example. You can observe the described behaviour with absolutely any URL (relative, absolute, file://, http://, you name it), any url-encoded character, or even an invalid escape sequence (though in that case it's more or less justified), the existence or absence of an actual JNLP file is irrelevant, because we don't even get to the point where the plugin would attempt to load the JNLP file.
Is this some kind of security feature? If it is, what is it supposed
to guard against? Or could it be a straightforward bug?
From what I can uncover, 'straightforward bug' is the answer. Here's the issue page:
https://bugs.openjdk.java.net/browse/JDK-8043409
It looks like it's not scheduled to be fixed until the release of JDK 9.
I'd suggest trying a different JDK implementation, but that seems unlikely to change anything given the amount of code shared between the Oracle and OpenJDK implementations and the fact that the WebStart code appears to be proprietary/closed-source.
So the workaround you devised with base64-encoding is probably the best option for now. If you have to do this often, maybe the encoding step can be rolled into the deployJava.launchWebStartApplication(jnlp) JavaSript API so that it happens automatically if/when needed.
I'm getting an error in my program about a class not being found. I have double (and triple) checked and the class is definitely in my jar - it's finding other classes from the same jar just fine.
To help with debugging this, I want to turn on verbose class loading logging as described here:
http://java.dzone.com/articles/how-use-verbose-options-java
That doesn't say how exactly to turn on this option if you're using WebSphere Liberty Profile, though, so I looked around some more and found this:
http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_admin_customvars.html
This says that I need to place the line in ${server.config.dir}/jvm.options.
So I wrote a simple file which consists only of:
-verbose:class
And I saved that to wlp/usr/servers/defaultServer/jvm.options, which means the new file is in the same directory as my apps folder, my logs folder, and my server.xml.
I stopped my server and started it back up and looked in the logs directory. It generated the same logs as always, nothing new: console.log, messages.log, status.log, and trace.log. I checked all of these log files and none of them have anything like the output from my first link.
So I don't think I'm doing this properly. Here are the three points where I think I may have gone wrong:
Was my file too simple? Is there more that I need to put in it than just -verbose:class? Does that perhaps need to be nested in something? Are there more parameters that I must have? Prior to this I didn't have any jvm.options file at all, so I assume that it'll use default values for anything I'm not explicit about.
Did I put the file in the proper place? As far as I can tell from the documentation, I think I put it in the proper spot, but the docs are a bit less explicit than I would like.
Am I looking in the right place for the logs? What will the name of the log file be? Where will it be placed? I assumed it would be in the logs directory just like all of the other logs generated by WebSphere Liberty Profile, but maybe I'm incorrect?
While writing the third bullet for my question, I realized that console.log was actually a new file that didn't previously exist, and I hadn't actually checked what was in it. I just opened it up and lo and behold, it's exactly the class loading logs that I was looking for.
So to recap, here are the answers to my bullets:
You can have a file with nothing but -verbose:class
You save it to wlp/usr/servers/<server name>/jvm.options
The output is in wlp/usr/servers/<server name>/logs/console.log
I've reached a point in my current Android-Project, that requires verifying an XML-Signature with a .pdf file (the pdf File is signed in the XMl file)
and i encountered one major problem. It is related with absolutley NOT beeing able to use the iaik-libaries:
The Signature is made with the ECC-Algorithm (Eliptic curves), which standard java libaries cannot handle.
Does anyone know a way to deal with these signatures?
So what i am looking for is either another libarie or a workaround for the javax-Problem.
Many Thanks for any idea!
Additional Info:
I know about Apache Santuario, but i can not use it, because it
containt classes that would be added to javax, and the DalvikVM does
not allow that.
I know it's easy to do it with iaik, but it is not an option due to
licence-issues (+ the javax-problem).
I do not post any code, because it cannot be done my way, i'm totaly stuck and i need new Ideas from scratch :/
I'm getting the error in the title occasionally from a process the parses lots of XML files.
The files themselves seem OK, and running the process again on the same files that generated the error works just fine.
The exception occurs on a call to XMLReader.parse(InputStream is)
Could this be a bug in the parser (I use piccolo)? Or is it something about how I open the file stream?
No multithreading is involved.
Piccolo seemed like a good idea at the time, but I don't really have a good excuse for using it. I will to try to switch to the default SAX parser and see if that helps.
Update: It didn't help, and I found that Piccolo is considerably faster for some of the workloads, so I went back.
I should probably tell the end of this story: it was a stupid mistake. There were two processes: one that produces XML files and another that reads them. The reader just scans the directory and tries to process every new file it sees.
Every once in a while, the reader would detect a file before the producer was done writing, and so it legitimately raised an exception for "Unexpected end of file". Since we're talking about small files here, this event was pretty rare. By the time I came to check, the producer would already finish writing the file, so to me it seemed like the parser was complaining for nothing.
I wrote "No multithreading was involved". Obviously this was very misleading.
One solution would be to write the file elsewhere and move it to the monitored folder only after it was done. A better solution would be to use a proper message queue.
I'm experiencing something similar with Picolo under XMLBeans. After a quick Google, I came across the following post:
XMLBEANS-226 - Exception "Unexpected end of file after null"
The post states that use of the Apache Commons (v1.4 onwards) class org.apache.commons.io.input.AutoCloseInputStream may resolve this exception (not tried it myself, apologies).
Is this a multithreaded scenario? I.e. do you parse more than one at the same time.
Any particular reason you do not use the default XML parser in the JRE?