Re: Problems after upgrading to Tomcat6
Hi Caldarale, Charles R Wrote: parent=gnu.gcj.runtime.SystemClassLoader You need to use a real JVM (HotSpot, JRockit, IBM), not a toy one. Remove gcj from your system as quickly as possible. It seems like jpackage.org packages is having dependency towards gcj. Do you know perhaps about another repertory that contains prebuilt packages for Centos 5? It seems strange dough, that jpackage.org should build packages that is designed not to work on the system the packages is build for. Are you certain that it isn't any more convenience way to do this than changing the JVM? Pid Wrote: Download a Tomcat binary from tomcat.apache.org and use that instead? Do you mean the deployer? Or just replacing some of the files? If you mean the deployer, could this overwrite other essential system files and mess up the system? Do tomcat.apache.org have rpm-packages? --- Sincerely David Karlsen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems after upgrading to Tomcat6
On 2 June 2010 09:13, David Karlsen dav...@delonic.no wrote: Caldarale, Charles R Wrote: parent=gnu.gcj.runtime.SystemClassLoader You need to use a real JVM (HotSpot, JRockit, IBM), not a toy one. Remove gcj from your system as quickly as possible. It seems like jpackage.org packages is having dependency towards gcj. Do you know perhaps about another repertory that contains prebuilt packages for Centos 5? It seems strange dough, that jpackage.org should build packages that is designed not to work on the system the packages is build for. Are you certain that it isn't any more convenience way to do this than changing the JVM? If you read jpackage.org's mission, it is to use FOSS packages wherever possible. Unfortunately, this means that they prefer GCJ (a toy, as Chuck says) over software that is available for $0 but not free-as-in-speech. This is an ideological choice, not a technical one. And, no, there's no more convenient way to fix this than to change the JVM to a real one. You don't have to use the Sun JVM; it looks like jpackage has details for both the BEA and IBM ones. - Peter
Re: Problems after upgrading to Tomcat6
Hi Problems fixed. It was a mismatch between JVM-versions. Upgrading Tomcat, did not automaticly upgrade JVM. Seems like when building the Tomcat packages, it did not take into account checking the JVM for wrong version. Upgrading the JVM to the latest GCJ version solved the problem. Thanks. --- Mvh David Karlsen Delonic Technology Group AS - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems after upgrading to Tomcat6
Peter Crowther wrote: On 2 June 2010 09:13, David Karlsen dav...@delonic.no wrote: Caldarale, Charles R Wrote: parent=gnu.gcj.runtime.SystemClassLoader You need to use a real JVM (HotSpot, JRockit, IBM), not a toy one. Remove gcj from your system as quickly as possible. It seems like jpackage.org packages is having dependency towards gcj. Do you know perhaps about another repertory that contains prebuilt packages for Centos 5? It seems strange dough, that jpackage.org should build packages that is designed not to work on the system the packages is build for. Are you certain that it isn't any more convenience way to do this than changing the JVM? If you read jpackage.org's mission, it is to use FOSS packages wherever possible. Unfortunately, this means that they prefer GCJ (a toy, as Chuck says) over software that is available for $0 but not free-as-in-speech. This is an ideological choice, not a technical one. And, no, there's no more convenient way to fix this than to change the JVM to a real one. You don't have to use the Sun JVM; it looks like jpackage has details for both the BEA and IBM ones. Let me add something to the above : I do not have specific experience with CentOS, but I do with Debian Linux. When you install Debian Linux, by default it will install and configure as default some specific java package (for example gcj or OpenJdk). When you then install Tomcat from a package, this Tomcat package will detect the installed java, and adapt all its links and references in function of that java package. If you then install the Sun or IBM java package, and make it be the default, that leaves these pre-configured Tomcat links partly wrong, and you get in lots of trouble. The right approach is thus : - de-install Tomcat (and use some purge option to purge all the links it built) - install a real JDK or JRE - configure this JDK/JRE in your OS as the default java. This is important. (For example under Debian this would be done with the command : update-alternatives --config java ) - then re-install Tomcat, so that it finds the correct libraries and creates the correct links, to the real JDK/JRE. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problems after upgrading to Tomcat6
On 01/06/2010 13:20, David Karlsen wrote:
Dear list
I have recently been running Tomcat 5 on my server, without problems.
After an upgrade to Tomcat 6, however I get errors. During the upgrade I
manually removed all the Tomcat 5 packages, and dependent packages
before I installed new Tomcat 6 packages from the jpackage.org repo. The
system is a Centos 5 system. This is the error messages:
From /var/log/tomcat6/catalina.out when running service tomcat6 start:
WARNING: error instantiating 'org.apache.juli.ClassLoaderLogManager'
referenced by java.util.logging.manager, class not found
java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager
not found
No stacktrace available
WARNING: error instantiating '1catalina.org.apache.juli.FileHandler,'
referenced by handlers, class not found
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.FileHandler,
No stacktrace available
Exception during runtime initialization
java.lang.ExceptionInInitializerError
No stacktrace available
Caused by: java.lang.NullPointerException
No stacktrace available
Then Tomcat dies.
Running tomcat6-digest with root user gives:
SEVERE: Exception creating instance of
org.apache.catalina.realm.RealmBase
java.lang.ClassNotFoundException: org.apache.catalina.realm.RealmBase
not found in org.apache.catalina.loader.StandardClassLoader{urls=[],
parent=gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/comm
ons-daemon.jar,file:/usr/share/java/tomcat6/catalina.jar,file:/usr/share
/java/servlet.jar,file:./,file:/usr/share/tomcat6/bin/bootstrap.jar,file
:/usr/share/tomcat6/bin/tomcat-juli.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}}
at java.net.URLClassLoader.findClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
at org.apache.catalina.startup.Tool.main(Tool.java:197)
Can someone give me a hint about how to proceed here?
Download a Tomcat binary from tomcat.apache.org and use that instead?
p
signature.asc
Description: OpenPGP digital signature
RE: Problems after upgrading to Tomcat6
From: David Karlsen [mailto:dav...@delonic.no] Subject: Problems after upgrading to Tomcat6 parent=gnu.gcj.runtime.SystemClassLoader You need to use a real JVM (HotSpot, JRockit, IBM), not a toy one. Remove gcj from your system as quickly as possible. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
