We Keep Coding

Which java class issues warning on catalina.out

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();
}
}

Calling a JAX-WS RI 2.2 service from Tomcat6 with java6

I am trying to access a JAX-WS 2.2 service from Tomcat6 with Java6. For what I have researched there is a problem with this, as Java tries to use first some of its default javax.xml.ws libraries which doesn't have the WebFault.messageName method. So it fails with this error:
GRAVE: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String;
at com.sun.xml.ws.model.RuntimeModeler.processExceptions(RuntimeModeler.java:1162)
...
The solution seems to be creating an "endorsed" directory in JAVA_HOME/jre/lib/ (or in TOMCAT_HOME) and putting there the required libraries.
However, some people say the library needed is webservices-api.jar, for example, here (#Issue 3):
https://www.fromdev.com/2010/01/trying-to-run-jax-ws-sample-application.html
And other people talk about jaxb-api-2.2.jar and jaxws-api.jar, for example here:
Grizzly - java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName
I have downloaded all three of them and placed them in both directories (inside JAVA_HOME and TOMCAT_HOME).
My problems:
· I have no issues accessing this service from a standalone java6 application, both from Netbeans or running the .jar from command-line, it fails only from Tomcat. So I am not sure if the stated above is the cause of my problems. Because, shouldn't it also fail from command line?
· I am not being able to test the above solutions, because Tomcat does not seem to know the "endorsed" directory. When I run this in the standalone application:
System.out.println(System.getProperty("java.endorsed.dirs"));
It prints:
/usr/lib/jvm/jdk1.6.0_45/jre/lib/endorsed
However, Tomcat prints a blank line.
I have tried to modify tomcat6.conf, with this (and restarting, of course):
JAVA_OPTS="-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Djava.awt.headless=true -Xms1024m -Xmx1024m -XX:PermSize=1024m -XX:MaxPermSize=1024m"
But it still doesn't seem to know that property.
So, how can I tell Tomcat where the endorsed directory is located? Do you think that my problem can be another than the stated, as it works from a standalone application?

So, the solution:
Do you think that my problem can be another than the stated, as it works from a standalone application?
No, that was exactly the problem.
how can I tell Tomcat where the endorsed directory is located?
It seems that setting this option in tomcat6.conf:
-Djava.endorsed.dirs=/usr/share/tomcat6/endorsed
is not enough. It is required to create a variable called JAVA_ENDORSED_DIRS. So these two lines are needed in tomcat6.conf:
JAVA_ENDORSED_DIRS="/usr/share/tomcat6/endorsed"
JAVA_OPTS="-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS [-Djava....]"
Not really well documented issue, I think.

I'm having a trouble with starting Eclipse : Error : ... cannot be solved to a type

I really don't know what the problem is.
I followed several web postings about installing and settings of JDK/ JRE and also completed clearly on environment variables :Path & CLASS PATH
I'm sure about that since i checked the cmd and it worked well.
the same problem occured over and over again.
I corrected on Library tab
I add the Library list like this,
But, I still have the same problem. Did I make a severe mistake? what should I do about this problem?
still have JAVA problems

Please check the Java source directory configuration under Java Build Path, Source tab and Java Compiler version settings.

Did you recently update your Java version? If so, then you have to readjust your path so that it directs to the new updated version.

libopencv_java249.so requires libopencv_java245.so also?

I am trying to deploy an opencv java application with opencv 2.49, I have build the libopencv_java249.so and opencv-249.jar in the Ubuntu server and these are available in the class path when the application starts.
But it's throwing a exception saying libopencv_java245 not found, so initially I was under a impression that it's referring to a wrong opencv version. so to verify this I have removed the libopencv_java249.so from class path and then it was complaining that libopencv_java249 not available.
As an additional testing I also renamed libopencv_java249.so to libopencv_java245.so then it was saying again that opencv_java249 not found.
With this I guess we can confirm that it looks for the right version of opencv (that is libopencv_java249) but in addition to that it aslo requires libopencv_java245 also. Is my assumption is correct, it would be really helpful if someone can guide me.

WebSphere App Server Not Compiling JSP/Tag Libs

This is a problem that only occurs on application update (only tested through Admin Console, not CLI). Also, this is only happening on our development environment, which is identical to our prod env. On uninstall/install, everything is compiled properly. However, this is a large application and it takes long enough to do an update--we do not want to uninstall/install everytime (esp. during dev. builds).
JSP .java and .smap files are being generated, but not .class. On prod, there is no .smap--only .java and .class. If the JSPs would compile, we believe the tag libs would be compiled also.
Has anyone faced this problem, or know what we are possibly overlooking?
WAS Version: 6.1.0.17
EDIT: This is only happening for one JSP and the tag library its using. We're trying to trouble shoot the issue. Let you know if we figure anything out. We think it may be an issue with the .SMAP file per this fix
SOLUTION

Solution:
Problem was: WAS had debugging enabled. This generated .smap files (source mappings) instead of .class files. Once we discovered this, we disabled the debugging service under the Admin Console (Application Servers > server1 > Debugging Processes > uncheck 'Start service'). I don't know why this created a bug upon an update only, but, whatever the case, the problem is solved.

One suggestion:
Have you checked that your environment has a JAVA_HOME pointing to a JDK and not just a JRE. The JRE doesn't have javac, so there won't be any way to compile .java files created at runtime by the JSP compiler into .classes?
EDIT: Also, perhaps this link may help?

I haven't worked with taglibs, but I can tell you this:
the application server checks timestamps. be very very sure that the "modified" timestamps of the JSP files are reasonable from the point of view of the application server (say, are not in the future)
Hope this helps you solve the problem...