I am running GeoServer 2.7.1 on Tomcat 7.0.62 on OS X 10.10. I have installed Tomcat with Homebrew and copied the GeoServer 2.7.1 war file to the webapps dir. When I try to start GeoServer it fails with this message.
SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file
I see no other specific errors in catalina.out. Maybe this is an issue below?
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
Jun 22, 2015 3:48:20 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file
Jun 22, 2015 3:48:20 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/geoserver] startup failed due to previous errors
Anyone know where I can start looking for config errors etc. ?
I had a similar problem, adding setenv.sh file in tomcat/bin folder or changing the jdk path in service script (if you are starting tomcat as a service) resolves this issue. The web-application you are deploying depends on specific jdk version.
Thanks #S.L. Barth, that was the problem. I had to downgrade Java8 to Java7. Now it works! This guide was helpful
The server suddenly stopped to work and on restarting it gave the following error. Couldn't find anything related to this online. Any idea what is wrong and how to resolve this?
org.neo4j.server.logging.Logger log SEVERE:
org.neo4j.server.ServerStartupException: Starting Neo4j Server failed:
Active marked as 1 but no data/graph.db/nioneo_logical.log.1 exist at
org.neo4j.server.AbstractNeoServer.start(AbstractNeoServer.java:218)
at org.neo4j.server.Bootstrapper.start(Bootstrapper.java:87) at
org.neo4j.server.Bootstrapper.main(Bootstrapper.java:50) Caused by:
java.lang.IllegalStateException: Active marked as 1 but no
data/graph.db/nioneo_logical.log.1 exist at
org.neo4j.kernel.impl.transaction.xaframework.XaLogicalLogFiles.determineState(XaLogicalLogFiles.java:138)
at
org.neo4j.kernel.impl.recovery.StoreRecoverer.recoveryNeededAt(StoreRecoverer.java:65)
at
org.neo4j.server.preflight.PerformRecoveryIfNecessary.run(PerformRecoveryIfNecessary.java:56)
at
org.neo4j.server.preflight.PreFlightTasks.run(PreFlightTasks.java:70)
at
org.neo4j.server.AbstractNeoServer.runPreflightTasks(AbstractNeoServer.java:333)
at
org.neo4j.server.AbstractNeoServer.start(AbstractNeoServer.java:152)
... 2 more
Apr 25, 2014 9:13:07 PM org.neo4j.server.logging.Logger log SEVERE:
Failed to start Neo Server on port [7474]
It looks like you've messed up your datastore e.g. by a unclean shutdown. To recover try the following procedure:
IMPORTANT: before doing any manual changes to your graph.db folder, make sure that you have a valid backup copy e.g. by tar -zcf <path>/graph.db.tar.gz data/graph.db.
Check that the backup from 1. is fine.
rm data/graph.db/nioneo_logical.log.active. NB: this operation might be harmful.
try to restart the server
if it comes up, check if the latest changes you did before the DB reached its current state.
We have a multicore SOLR setup with two cores, one for site and one for catalog data.
Inside solr.xml the core config is as follows;
<cores adminPath="/admin/cores">
<core name="catalog" instanceDir="e:\SolrInstances\catalog" />
<core name="sites" instanceDir="e:\SolrInstances\sites" />
</cores>
e:\ is a mapped/mounted network drive that is regularly backed up.
However, when we try to access a core we get a nasty stack trace
Jul 17, 2013 8:28:00 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or 'e:\SolrInstances\sites\conf/', cwd=C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0
at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:268)
at org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:234)
at org.apache.solr.core.Config.<init>(Config.java:141)
at org.apache.solr.core.SolrConfig.<init>(SolrConfig.java:131)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:435)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:316)
We initially had the cores in the Tomcat root with relative paths during development, and it worked fine, but moving to a mapped/mounted network drive with absolute paths does not work.
And solrconfig.xml does exist in both e:\SolrInstances\sites\conf and e:\SolrInstances\catalog\confand the solr user has permissions to those directories.
Does anyone have any clues?
Try the UNC path instead, see: http://wiki.apache.org/tomcat/FAQ/Windows#Q6
I've been trying to set up Solr 4.3 on my home PC (in Tomcat 7) but it doesn't run. I have set up Tomcat and deployed the solr.war file which both unpacks and shows up in the Tomcat Web Apps Manager screen in Tomcat but its not running and clicking the start button doesn't do anything (as it should already be running in the first place).
Here is my solr.xml context file in Tomcat which also gives the path to the solr.war file and where my solr Cores are (which is the default Collection1):
<Context path="/solr" docBase="C:/LocalApps/Tomcat/apache-tomcat-7.0.40/webapps/solr.war" debug="0" crossContext="true">
<Environment name="solr/home" type="java.lang.String" value="C:/LocalApps/Solr/solr-4.3.0/example/solr/" override="true"/>
</Context>
this is the error log in tomcat:
INFO: Starting Servlet Engine: Apache Tomcat/7.0.40
Jun 09, 2013 11:04:07 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor C:\LocalApps\Tomcat\apache-tomcat-7.0.40\conf\Catalina\localhost\solr.xml
Jun 09, 2013 11:04:07 PM org.apache.catalina.startup.HostConfig deployDescriptor
WARNING: A docBase C:\LocalApps\Tomcat\apache-tomcat-7.0.40\webapps\solr.war inside the host appBase has been specified, and will be ignored
Jun 09, 2013 11:04:07 PM org.apache.catalina.startup.SetContextPropertiesRule begin
WARNING: [SetContextPropertiesRule]{Context} Setting property 'debug' to '0' did not find a matching property.
Jun 09, 2013 11:04:09 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Error filterStart
Jun 09, 2013 11:04:09 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/solr] startup failed due to previous errors
You need to install the jars for logging as explained here.
Just copy all the mentioned files into your tomcat/lib dir. And restart Tomcat.
Copy the jars from solr/example/lib/ext into your container's main lib directory. These jars will set up SLF4J and log4j.
Exactly where this lib directory is highly variable. For a Debian or
Ubuntu server using the Tomcat package available from the OS vendor,
this is likely to be /usr/share/tomcat6/lib or
/usr/share/tomcat7/lib.
Copy the logging config from solr/example/resources/log4j.properties into a location on the
classpath. Usually you can use the same location as the jar files
above. Edit the configuration file for your preferred log destination.
Optionally, if you did not place log4j.properties on the classpath, set java option
-Dlog4j.configuration=file:///path/to/log4j.properties
Download latest solr-4.x.zip file.
Extract zip file somewhere like C:\solr setup.
Apache Tomcat (version greater than 5) and Java 6 or greater should be installed. Copy solr-4.x.war file from “C:\solr setup\solr-4.3.0\dist” to “Apache Tomcat” webapps folder most probably in C:\Program Files\Apache...\Tomcat...\webapps\ and rename copied war file to some meaningful name like solrTest.Start Tomcat. If already running then restart Tomcat. New folder with same name as of war file (solrTest) will be created.
Stop Tomcat. Copy bin and collection1 folders from C:\solr setup\solr-4.x\example\solr to C:\Program Files\Apache ...\Tomcat...\webapps\solrTest.
Copy all jars from C:\solr setup\solr-4.x\example\lib\ext to C:\Program Files\Apache...\Tomcat...\lib. SOLR 4.x will use these jars for logging.
Create xml file in C:\Program Files\Apache...\Tomcat...\conf\Catalina\localhost\ with same name as of war file (solrTest.xml) with contents as given below. Tomcat looks for this xml file to get a start of the application.
Update C:\Program Files\Apache...\Tomcat...\webapps\solrTest\collection1\conf\schema.xml and add required fields and update too.
Remove copy fields if not required. Usage of copy fields is available in same file.
Update C:\Program Files\Apache...\Tomcat...\webapps\solrTest\collection1\conf\solrconfig.xml.
Update physical index path in tag like ${solr.data.dir:C:/Indexes/solrTest Index/}. If it will be commented then C:\Program Files\Apache...\Tomcat...\webapps\solrTest\collection1\data\ directory will be used by default. DataDir tag is available in file. No need to add your own.
Update replication entries to set either master or slave in replication request handler.
Try accessing “...localhost:portNumber/solrTest”. If no error comes then you have successfully configured SOLR 4.x.
The easiest way to get started with Solr on Tomcat is to use HDS (Heliosearch Distribution for Solr), a
Tomcat/Solr distribution
It's a super-set of Apache Solr, containing an additional "server" directory that is a pre-configured (threads, logging, connection settings, message sizes, etc) Tomcat based Solr server.
Some other implementation notes:
start scripts can be run from anywhere, and allow passing JVM args
on command line (just like jetty, so it makes it easier to use)
start scripts work around known JVM bugs
start scripts allow setting port from command line, and default stop
port based off of http port to make it easy to run multiple servers on
a single box)
zkcli, the start script for the solr zookeeper tool, will auto-explode the WAR if necessary
the "server" directory has been kept clean but stuffing all of
tomcat under the "server/tc" directory
To start:
$ cd server
$ bin/startup.sh
To start on a different port (e.g. 7574):
$ cd server
$ bin/startup.sh -Dhttp.port=7574
To shut down:
$ cd server
$ bin/shutdown.sh -Dhttp.port=7574
The scripts even accept -Djetty.port=7574 to make it easier to
cut-n-paste from start examples using jetty. The "example" directory
is still there too, so you can still run the jetty based server if you
want.
Check the localhost_yyyy_mm_dd.log logs created by Tomcat. It should typically show you the reason for this issue. Full stack trace might not be displayed in console...
I had some problem doing the same thing, the official documentation is not really helpful about this. I wrote a blog post about it which reads:
Solr install
Download and unpack the latest version of Solr, somewhere on the disk.
cd /tmp
wget "http://mirrors.ircam.fr/pub/apache/lucene/solr/4.6.0/solr-4.6.0.tgz"
cd /opt
sudo tar zxvf /tmp/solr-4.6.0.tgz
sudo chown -R tomcat:tomcat solr-4.6.0
Here, I use /opt, but you can install it anywhere as long as Tomcat has access to it. Just to be sure, make Tomcat the owner, so it can read and write in Solr folders.
Deployment
Now, let's deploy the Solr webapp on Tomcat. To do so, we will take advantage of an XML context configuration file, wich we will use to deploy and configure Solr.
In your Tomcat installation folder, create a new XML context configuration file in conf/Catalina/localhost. The base name of the file will define the Solr context path.
We first need to define ${solr.home}. Here, we use the example Solr configuration provided in the distribution. It is located in /opt/solr-4.6.1/example/solr.
To avoid startup errors, we need to add some jars to the webapp classpath, located in /opt/solr-4.6.1/example/lib/ext. But we don't want to pollute Tomcat's lib folder with Solr jars, so we just declare a virtual loader.
We also need to configure Log4J properly. Here we use the Log4J configuration file provided in Solr distribution in /opt/solr-4.6.1/example/resources, by adding the folder in Solr classpath.
<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="/opt/solr-4.6.1/dist/solr-4.6.1.war">
<Environment
name="solr/home"
type="java.lang.String"
value="/opt/solr-4.6.1/example/solr"
override="true" />
<Loader
className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="/opt/solr-4.6.1/example/lib/ext/*.jar;/opt/solr-4.6.1/example/resources/" />
</Context>
Save the file, wait for Tomcat to read it and deploy the war.
That's it! Solr is up and running.
Here is instruction provided by Tony at Drupal for Windows with XAMPP installed:
Preliminaries
Make yourself a nice cup of tea
Make sure you have the Windows Java environment installed. It's up to version 6 at the moment.
I assume you use XAMPP to run Apache and MySQL and latest version of PHP5
Installing Tomcat
If you installed XAMPP with Tomcat, go to your Service Tray, stop XAMPP services and remove the Tomcal directory from within your XAMPP installation. Then restart your XAMPP again. The reason is that you want to be able to configure Tomcat easily from Services Tray in Windows. If Tomcat runs under XAMPP, it does not show up in the Services Tray.
Before you install Tomcat, copy the file c:\windows\microsoft.net\framework\v1.1.4322\msvcr71.dll to c:\windows\system32\msvcr71.dll If you don't do this, Tomcat won't start up.
Now install Tomcat 6.x. Start it running. You should get a page showing at http://localhost:8080 if Tomcat is working.
Have a peek at the file structure of Tomcat. It is very straightforward. Note the directory called webapps.
Now have a nice cup of tea.
If you're on Linux, check: Apache Solr 4.6.0 installation.
I am trying to deploy my spring application in a server machine which having the tomcat 6.0.29 server. But tomcat server getting stop automatically while extracting the war.
In Catalina Log I have the following:
Jan 27, 2012 3:02:44 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive application.war
In localhost.log
Jan 27, 2012 3:03:21 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
There is no any stacktrace.
I tried to restart the tomcat but server getting stop while extracting the war file. I tried by increasing the JVM memory to 1024MB. Still same problem.
I have deployed the same war in my another testing server and it is working fine.
Any help...
Are you seeing something like this "SEVERE: Error listenerStart"? or none in the logs.
If Tomcat fails there should be a thread dump and/or a heap dump in the startup directory.
Also check the ports available from OS/firewall to bind with.
Enabling debug logging might help. (Change the log levels to DEBUG instead of INFO in the log files below)
Enabling Tomcat debug log:
Refer to : How to set level logging to DEBUG in Tomcat 6?
Enabling Spring debug log:
You can enable spring debug logging mode (why its failing to deploy the webapp) by adding the logging.properties(name should match exactly) in your WEB-INF/classes directory
Refer to : SEVERE: Error listenerStart
How are you launching Tomcat? What OS is this? I have encountered this problem myself in the past when launching Tomcat on CentOS using a startup script. Usually had something to do with security settings of the files and/or of selinux preventing the writing/reading of certain filespaces on the disk.
Try running from the console using ./catalina.sh run and see if that works on the server (assuming it is a *nix server). If so, check ownership of all files and read/write permissions. Disable selinux (if currently enabled) momentarily to see if that makes any difference.
It's a bunch of trial and error when you don't have any further debug information available.
Last time I faced this problem it was due to the fact I was thinking that I am using h2database while the configurations were such that it was using mysql and of course there was no mysql server to connect to.
I was using a maven project in eclipse and none of my changes were taking effect until I did
Project Properties-> Maven-> Update Project and then in
Servers Tab right click on the server name and Publish.
Check the jdbc.properties file in the webapp (in my case it was somewhere inside /.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/ folder) not in source code to see what are the final parameters for database connection.