Peter wrote:
On Fri, Dec 27, 2013 at 1:31 PM, Mark Eggers <its_toas...@yahoo.com> wrote:

On 12/26/2013 11:49 PM, Peter wrote:

Guys see here is that error message , I am attaching log file also please
help

OS - Centos 6.5 64 bit

HTTP Status 500 - Error instantiating servlet class
gov.noaa.pfel.erddap.Erddap
------------------------------

*type* Exception report

*message* *Error instantiating servlet class gov.noaa.pfel.erddap.Erddap*

*description* *The server encountered an internal error that prevented it
from fulfilling this request.*
*exception*s













*This looks like an ERDDAP setup problem. Are you trying to set up:
http://coastwatch.pfeg.noaa.gov/erddap/index.html
<http://coastwatch.pfeg.noaa.gov/erddap/index.html> If so, did you read /
understand / follow :
http://coastwatch.pfeg.noaa.gov/erddap/download/setup.html
<http://coastwatch.pfeg.noaa.gov/erddap/download/setup.html> It looks like
that the application should just work. The documentation recommends the
latest JRE / JDK 7. /mde/*


There is no setup problem

*# ERDDAP works fine with this Java*
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.3.el6-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)


*# This Java supports almost all webapps of mine, except ERDDAP *
$ ./java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)



Peter,
one of the main aims/goals/targets of Java, is to provide, on any machine and under any operating system, a "virtual environment" that allows any application written in Java, to run anywhere where a Java Virtual Machine is available, without any change in the Java code of the application. A secondary aim/goal/target is to insure that any Java application which works under a given version of the JVM, would continue to work on later versions of that JVM.

These are the aims.

Anyone can write a Java JVM, as long as that JVM satisfies the official description of how a JVM should work.

Two JVMs that advertise the same "level" /should/ behave in exactly the same way with respect to running Java applications; but that is the ideal, and in the practice this is not always 100% true. No code is perfect, a JVM is a very complex thing, and writing a JVM is not easy. So different JVMs may exhibit slight differences, and any JVM can have bugs.

In many cases, for Java applications it does not matter, because they rarely use these little "corners" where the differences between one and the other JVM may influence the way in which a particular application works.

But sometimes, it can happen that one application works under one JVM, and not under another. You have obviously encountered such a case.

There are 2 possibilities :
a) either the application (this webapp) does something that it should not really be doing, if it is supposed to be portable between different JVMs
b) or there is a bug in the JVM under which the application fails

In case (a), you should discuss the issue with whoever wrote that application.
In case (b), you should discuss the issue with whomever wrote the JVM.

But neither in case (a) nor case (b), there is much that the Tomcat developers (or the people on this list) can do about it.
The Tomcat code itself seems to run fine on both of the JVMs that you are using.
It is with the webapp application that the problem shows up, and nobody here has the code of that application.

In your case, it seems that when the application fails, in one of the error messages it points to some application-specific logfile, where presumably the error information is provided in more details.
Please find that logfile and look at it.
And if you do not find it, then ask the developers of that application what this is all about. Because with the information which you have provided so far, it does not look as if Tomcat code is in any way implicated in the problem.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to