I have setup usergrid following this guide.
Steps I have done include:
1. Setup Cassandra (nodetool statusshows me one healty node and I can log in with cqlsh).
2. Setup ElasticSearch (curl localhost:9200 gives me a nice .json back, everything ok.)
3. Built the usergrid app with mvn clean install and moved the built ROOT.warto CATALINA_BASE
4. Created usergrid-deployment.propertiesto CATALINA_HOME at /usr/share/tomcat7
When I start tomcat7 service everything goes ok, no errors in catalina logs. Last line is "Server Startup".
In catalina.out log I have the line:
INFO: Starting Servlet Engine: Apache Tomcat/7.0.52 (Ubuntu)
Mar 08, 2016 9:33:25 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive /var/lib/tomcat7/webapps/ROOT.war
Mar 08, 2016 10:02:50 AM org.apache.catalina.util.SessionIdGenerator createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [5$
Mar 08, 2016 10:02:50 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
Mar 08, 2016 10:02:50 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 5561 ms
So the usergrid app should be running.
I can browse to localhost:8080 and see the Tomcat7"It works" - page.
However, when I try to setup the usergrid database like this:
curl -X PUT http://localhost:8080/system/database/setup -u [user]:[password]
I get a 403 error:
Access to the specified resource has been forbidden.
I am sure that my credentials match those that I have defined in usergrid-deployment.properties in CATALINA_HOME as usergrid sysadmin.login credentials.
In tomcat7 localhost_access_log I have the following output:
0:0:0:0:0:0:0:1 - - [08/Mar/2016:12:27:43 +0200] "PUT /system/database/setup HTTP/1.1" 403 979
However (number2), when I try curl -v localhost:8080/status to see the status of the usergrid app, I get
404 - requested resource is not available
So, any help as to what I might do to:
a) be sure that the usergrid app is deployed correctly with tomcat (as there are no errors in logs
b) to solve the 403 issue?
Thank you for any help!
EDIT:
I noticed that my CATALINA_BASE(/var/lib/tomcat/) didn't have the WEB_INFdirectory inside webapps at all. In the guide I made reference to, we are only instructed to copy the ROOT.war file to webapps directory. Is this correct? Should I also copy the WEB-INF files from the usergrid stack?
Here is what the guide says:
The next step is to deploy the Usergrid Stack software to Tomcat. There are a variey of ways of doing this and the simplest is probably to place the Usergrid Stack ROOT.war file into the Tomcat webapps directory, then restart Tomcat.
I tried copying the WEB-INF files to CATALINA_BASE but that resulted in multiple errors and tomcat7 was unable to start:
This:
21:25:49,923 WARN Slf4jConnectionPoolMonitorImpl:31 - BadRequestException: [host=localhost(127.0.0.1):9160, latency=16(38), attempts=1]InvalidRequestException(why:You have not logged in)
And:
INFO transport:93 - [node-1] bound_address {inet[0.0.0.0/0.0.0.0:9301]}, publish_address {inet[/XX.XXX.XXX.XXX:9301]}
21:25:51,892 INFO discovery:85 - [node-1] elasticsearch/RIaKYgv1R-yTKJ_aknZOuw
21:25:51,905 WARN netty:620 - [node-1] exception caught on transport layer [[id: 0xc1bc7fca]], closing connection
java.net.UnknownHostException: localhost:9200
EDIT 2: I was adviced that only Elasticsearch v 1.4.4 works (I tried with 2.2.0) and for Cassandra 1.2.x and 2.1.x versions (I tried with 3.0.3). I havent yet tried with these versions, I'll update this question if I get it to work.
I don't have an answer for you but I do have a couple of observations:
If you see the Tomcat "it works" page that means that you have not deployed the Usergrid ROOT.war file.
If you see a 404 on /status, that also means Usergrid did not deploy properly.
The Usergrid ROOT.war file that comes with the official release, includes the WEB-INF directory and you do not need to deploy that separately. The only files you need to add to Tomcat are ROOT.war, usergrid-deployment.properties and (optionally) log4j.properties.
The problem is probably that Usergrid is unable to connect to Cassandra or ElasticSearch and ROOT.war file fails to deploy to Tomcat.
If you share you Usergrid properties file (remove any passwords first), it might be easier to diagnose the problem that is preventing the Usergrid WAR file from being deployed.
Related
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
To install tomcat7 I have done:
a. downloaded apache-tomcat7 tar.gz file
b. extracted in /usr/share directory
c. starting tomcat using /usr/share/tomcat/bin/startup.sh
getting message:
Using CATALINA_BASE: /usr/share/tomcat7
Using CATALINA_HOME: /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME: /usr/lib/jvm/java-7-oracle
Using CLASSPATH: /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
Tomcat started.
but when I am going through the URL : localhost:8080 it is saying unable to connect.
Can somebody help me out from this problem.
Thanks in advance
Please check if any other application is holding the port:8080.
Locally tomcat points to 8080 and if any other applicationis running on that port then Tomcat won't start. Tomcat 7 is not an issue here.
The main culprit on your machine may be Skype. check in the processes and kill it and try the url again. Use an open source tool called Diamond port to check which processes are running on 8080
The Issue I'm Having
I've implemented a mild change to my application, and I checked it into the subversion repository. Once that was checked in, I ran a Jenkins build. Jenkins is currently running on a Windows server.
The error I am receiving is the following:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.codehaus.mojo:tomcat-maven-plugin:1.1:deploy (deploy) on project sd-rest-servlet:
Cannot invoke Tomcat manager: FAIL - Deployed application at context path /sd but
context failed to start
I investigated further into this error message, so I checked out the Tomcat logs on the Jenkins server, and I found an underlying issue:
SEVERE: Error starting static Resources
java.lang.IllegalArgumentException: Document base C:\Program Files\Apache Software Foundation\Tomcat 6.0\temp\28-sd does not exist or is not a readable directory
at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:142)
at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4320)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4489)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:675)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:601)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1385)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:306)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1389)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1653)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1662)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1642)
at java.lang.Thread.run(Unknown Source)
Now, as I understand it, the temp folder is only ever used in this way when I set antiJarLocking or antiResourceLocking to true in the context file. However, as you can see, I have not included this in the Context element:
<Context unpackWAR="false">
Other Behaviour
Unable to Undeploy
After some close inspection, I've found that Jenkins isn't able to undeploy the application. In the logs, I see this message.
[INFO] Undeploying application at http://localhost:8082/sd
[INFO] OK - Undeployed application at context path /sd
However, the build fails when it attempts to deploy, with the following error:
Cannot invoke Tomcat manager: FAIL - Application already exists at path /sd
Erratic access to the Temp directory
I've also noticed that it throws the same IllegalArgumentException whenever it attempts to access any file inside the temp directory. This tells me there is something wrong with the temp directory, however I've set the permissions, and earlier on in the application, Jenkins actually puts a file in the temp directory.
No Problems Depoying
Jenkins actually deploys the application without a problem. I've watched the directories change when the files are added to them, including the temp directory. This tells me that Jenkins is randomly deciding it can't read the contents of the directory, despite the fact that it is added a file to it. It appears that it has write permissions, but not read permissions, which really doesn't make much sense!
Attempts to Solve the problem
Ensured the file exists
I first attempted to look inside C:\Program Files\Apache Software Foundation\Tomcat 6.0\temp\28-sd to see if the file existed. Sure enough, it existed.
Altered Permissions
I've set permissions to allow for full access from every user on the server, as a precaution.
Researched the use of the Temp directory
I've attempted to configure my context file to avoid all use of the temp directory, so I don't have a clue why it's still attempting to read from it. I am inexperienced with the ins and outs of this technology, so I may still have some settings that require the temp folder.
Edits
Expanded Tomcat Logs
18-Dec-2013 12:14:19 org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context [/sd]
18-Dec-2013 12:16:06 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor sd.xml
18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext resourcesStart
<!-- Above stacktrace goes here -->
18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start
SEVERE: Error in resourceStart()
18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start
SEVERE: Error getConfigured
18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext start
SEVERE: Context [/sd] startup failed due to previous errors
18-Dec-2013 12:16:09 org.apache.catalina.core.StandardContext stop
INFO: Container org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/sd] has not been started
Some more information on the issue
After reading through the logs for the thousandth time, I reread this line:
...Tomcat 6.0\temp\28-sd does not exist or is *not a readable directory*
So when I looked inside the temp directory again, I realized that the files being generated aren't directories. They are these weird file objects with no extension, and they look like this:
For me, this indicates that something has gone wrong with the way Tomcat manipulates files and this is the core of the issue. I hope this extra information helps someone with the answer!
I see that Hoaz suggested moving the deployment out of C:\Program Files\ because of the space character. I wonder if it's rather a permissions issue than the space in the name?
Can you please also try these (without uninstalling the Tomcat from C:\Program Files\):
Configure the location of the temp directory to be outside C:\Program Files\
Reference : SO question How is the Tomcat temp directory location defined?
Change the location of docBase and/or appBase
Reference :Apache documentation http://tomcat.apache.org/tomcat-6.0-doc/config/host.html
Also, forcing the installation outside "C:\Program Files" would work fine unless / until someone insists that "That's where the Program Files should live, you know". :-)
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.