tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat Java Settings for each webapps, and virtual host strange issue.
Date Fri, 27 Dec 2013 09:58:35 GMT
Peter wrote:
> On Fri, Dec 27, 2013 at 1:31 PM, Mark Eggers <its_toasted@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message