I' am currently debugging why a legacy Maven web application compiled in Java 1.8 that we deploy on a Tomcat 8.5 is sending all the time following message:
Warning: Could not get charToByteConverterClass!
Curiously enough, when launching it on my local Tomcat instance, I see the warning in the console, but not in the catalina.out file.
My guess so far is that this is caused by some dependency, as we have no such warning inside our code.
The problem is that we have very old dependencies and also lot of them, so before getting into trying to upgrade them I would like to know if there is any way to:
see the printing "call stack".
or at least see which class is printing that.
Things I have tried so far:
Setting application log level to info.
Setting Tomcat's logging level to All.
You need to upgrade xalan due to a fixed issue since 2.7 release:
issue is now resolved as being fixed in the Xalan-J 2.7 release. As the issue reporter please confirm the code no longer has this problem so that we can close this issue down.
Actually the code that had the problem is totally gone, haha! Through XALANJ-2087 the dependancy on CharToByteConverter was removed plus a number of bugs were fixed due to an incorrect algorithm.
If anyone encounters this problem. xalan 2.7 did not eliminate the message. Adding the following stub class to your build will silence the error message:
package sun.io;
public class CharToByteConverter {
public static CharToByteConverter getConverter(String encoding) {
return new CharToByteConverter();
}
}
Related
I have gotten this result from running a javafx application using fontawesomefx
Caused by: java.lang.IllegalAccessError: tried to access method com.sun.javafx.css.parser.CSSParser.<init>()V from class de.jensd.fx.glyphs.GlyphIcon
at de.jensd.fx.glyphs.GlyphIcon.<clinit>(GlyphIcon.java:49)
I do not know how to fix a problem like this please help.
I would like to integrate resizable icons as font elements in java programs and this is one way I tried to do it but it does not work.
A couple of FontAwesomeFX library existing bug reports exist for this:
IllegalAccessError on FontAwesomeIcon construction. The bug report has been closed, but a comment by a user on the bug report states
the issue is still there in 8.9, try FontAwesomeFX 8.4
IllegalAccessError on FontAwesomeIcon construction. Same error, different report and further comments . . .
yes I was using JDK 1.8.0_31 that's why it doesn't work for me after updating to 1.8.0_92 version everything is working great.
AND
This is still an issue. com.sun.javafx.css.parser.CSSParser is not accessible in Java 9 resulting in java.lang.NoClassDefFoundError.
So, whether you get an error or not will depend on the Java version you are using (and, from your comments, the library is incompatible with all Java versions you have tried).
You will need to work with the developer of the library to get the error resolved.
I am using the gradle-cobertura-plugin in my Jenkins-build. Yesterday I fixed an issue in this plugin that overwrote the configured auxiliaryClasspath. This issue prevented some classes being present in the coverage report. The fix is something quite simple:
I changed the following:
auxiliaryClasspath = project.files("${project.buildDir.path}/intermediates/classes/${classesDir}")
to
if (auxiliaryClasspath != null) {
auxiliaryClasspath += project.files("${project.buildDir.path}/intermediates/classes/${classesDir}")
} else {
auxiliaryClasspath = project.files("${project.buildDir.path}/intermediates/classes/${classesDir}")
}
Running the build locally with gradle cobertura everything works fine and the missing classes showed in the report.
After installing the patched version of the plugin on Jenkins the coverage on Jenkins went to zero.
Looking around what happened I found that the classes in the instrumented_classes-folder are not instrumented anymore! Rolling everything back (build.gradle, uninstalling my plugin, clearing the gradle cache, etc.) the behaviour stays the same. As it is working locally I'm wondering what causes this issue.
I assume there is something going awefully wrong that's perhaps logged and silently ignored, but I don't have a clue where to look for this information. The Jenkins logs are clean, so I think adding a logger for the code responsible for instrumenting might help. Unfortunately I don't have any idea what loggers to enable. org.sourceforge.cobertura didn't output anything.
So my question is: Did anybody else see this behaviour and might throw in a clue how to resolve this issue?
OK, I figured it out. After much trial and error I found that a little change in the coverageExcludes-property was the culprit. After changing it several times the classes are instrumented once again. Funny that it did work locally but not on jenkins. I think I have to dive a little bit deeper in this if it occurs again.
For now I'm happy that it works. :-)
I am trying to debug a Java / Maven project with a lot of depencies on various libraries.
When I run it on a Linux server the program starts up fine, but when I try to run it in Eclipse it throws the following exception:
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.camel.model.RouteDefinition.getErrorHandlerBuilder()Lorg/apache/camel/ErrorHandlerFactory;
at org.apache.camel.spring.spi.SpringTransactionPolicy.wrap(SpringTransactionPolicy.java:69)
at org.apache.camel.model.PolicyDefinition.createProcessor(PolicyDefinition.java:133)
at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:437)
at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:183)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:817)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:165)
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:697)
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:1654)
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1441)
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1338)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1316)
Now, I can see that the RouteDefinition class is in the camel-core-2.9.3,jar and I can see that this library is imported. So how come it doesn't see that method?
How do I go about debugging this?
Could I get info from the process running on the Linux server? For example can I get the list of Jars that are imported and the order in which they are imported?
Many thanks!
The error that you're getting is caused by Maven pulling in the wrong version. Try deleting all versions out of your local repo, add it explicitly to your pom, clean out all of your builds, pray to the eclipse gods, etc. If it still gives you the error, check your local repo to see which wrong versions it pulled in, figure out what depends on them, and add explicit ignores for them while keeping the explicit include.
I've seen this type of error over here for exceptions that are thrown by various classes, though I haven't found the right solution for mine just yet.
I'm trying to get AWS Java SDK work locally so I can write a test application that reads data from a Kinesis stream.
Problem is, when I run the init() static method I encounter the following error:
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.http.impl.conn.DefaultClientConnectionOperator.<init>
(Lorg/apache/http/conn/scheme/SchemeRegistry;Lorg/apache/http/conn/DnsResolver;)V
Now, this is not the first error I've been thrown. I've been thrown four or five exceptions prior to this one, and the solution to all of them was just importing some jar's into the project. e.g.:
apache-httpcomponents-httpclient.jar
com.fasterxml.jackson.databind.jar
commons-codec-1.9.jar / commons-codec-1.9-javadoc.jar / commons-codec-1.9-sources.jar
httpclient-4.2.jar
httpcore-4.0.1.jar
I've seen in other threads around here that it could be the version of the httpcore library, however I imported the latest one.
Any ideas how I can resolve this? I'm thinking about starting over, as my project seems to be a heap of imports I'm not sure I'll actually utilize. Furthermore, I can't debug the binary imports of the AWS SDK (or can't I?).
Cheers.
Problem solved, I gradually added the missing libraries to the project and when the apache httpclient jar should be version 4.0 or later, and without any previous version to contradict.
I imported httpclient-4.2.jar and it worked.
Other than that, I just solved the exception that followed by importing joda-time-2.4.jar and it's all up and running.
I have a Java program running an axis2 1.5.3 with rampart 1.5 client working perfectly fine on my linux using openjdk. When I ported it over to Windows 7, it works on some machines but does not on most with the error "No user value in the rampart configuration"! This is the same regardless if I recompile the code or not. I also tried duplicating the java environment such as java version, ant version, system arch to no avail. Can anyone suggest a solution?
Thank you.
I'm not sure what is the exact reason for this issue. but this exception is thrown at the BindingBuilder.java class which is in the rampart-core module and package org.apache.rampart.builder
please try to debug following methods
addUsernameToken() method
getSignatureBuilder() method
there this exception occurs when rampart cannot read user values from the policy.xml file.
hope this might be helpful.
suresh..