We Keep Coding

How to deploy a Tomcat application with URL API when using custom context XML

My application context is defined as an XML file located in my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml.
<Context docBase='/my/path/to/myApp/myAppWarFile.war'>
<Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/>
</Context>
/my/path/to/myApp contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring.
Tomcat is configured with autoDeploy turned off. When I start Tomcat, it creates my/path/to/Tomcat/conf/webapps/my-app/ and the WAR file gets unpacked into this location as expected, and the application of course can run as expected.
When I want to deploy a new version without restarting Tomcat, I run the undeploy command as follows:
curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password
... and that works. But when I instruct Tomcat to deploy with the following curl statement, I get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password
# Tomcat response
FAIL - Invalid context path null was specified
Adding the path does not help much, I still get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password
# Tomcat response
FAIL - Failed to deploy application at context path /my-app
The worst part is that tailing catalina.out does not yield any insight. And on top of that, Tomcat deletes the application context XML file my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml!
Naturally I have reviewed Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) and I have googled all day to figure this out, but I have not found anything that can help me with this particular configuration.
It feels as though the choice is:
Tomcat with autoDeploy on (not recommended for production) in which case simply dropping the new WAR to /my/path/to/myApp/ will cause Tomcat to hot deploy the app.
Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart because the deploy API does not seem to be working as advertised.
Has anybody made this work with this configuration?
EDIT:
I turned up the logging on Catalina. When I run the first deploy command without the path, I get this set of log entries:
FINE: Start processing with input [config=file:/my/apth/to/tomcat/conf/Catalina/localhost/my-app.xml]
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper#189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [OPEN]
Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor process
FINE: Error parsing HTTP request header
java.io.EOFException: Unexpected EOF read on the socket
at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper#189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [CLOSED]
Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown
FINE: Counting down[http-bio-8080-exec-16] latch=1

Have you tried:
curl --upload-file /my/path/to/my-app.war http://localhost:8080/manager/text/deploy?path=/my-app --user my-username:my-password

Tomcat home page is not coming properly

After installing Apache tomcat8 I am getting below home page.
I just installed tomcat8, start service and hit url
http://localhost:8080/
I haven't created any project.

It looks to me that the page in your screenshot is being served up by Oracle Application Express (APEX), not Tomcat.
APEX typically uses port 8080, and if you started this before starting Tomcat, Tomcat will be unable to use port 8080. To confirm that this is the case, take a look in your Tomcat stderr log file (it should be under C:\Tomcat 8.0\logs and have a name like tomcat8-stderr.2014-09-21.log). It will quite probably contain an exception whose stacktrace begins as follows:
21-Sep-2014 12:09:15.607 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler ["http-nio-8080"]
java.net.BindException: Address already in use: bind
at sun.nio.ch.Net.bind0(Native Method)
I would recommend that you change Tomcat to use another port. To do this, open your server.xml file (in C:\Tomcat 8.0\conf\). There should be a Connector element in here with an attribute port="8080": change this port number to 8081 (say) and restart Tomcat.

Ok, try this
1- Download a tomcat version.
2- unzip it in a folder. (let say C:\Java)
3- open a command prompt window
4- Type C:\Java\ your tomcat installation \bin\startup.bat
5- Access http://localhost:8080

Looks like you have not started tomcat yet.
Are you sure you have followed a guide like this ?

Jenkins headless linux slave connection error

I get java.net.SocketException: Connection reset when trying to connect a headless debian slave to my main Jenkins master. It's been running good for a couple of weeks without error and suddenly I can't get it to connect.
I can telnet into the master on port 6256.
Slave output:
#> java -jar ~/slave.jar -jnlpUrl https://test.tv/jenkins/computer/debian_slave_node_1/slave-agent.jnlp
Aug 12, 2013 10:10:46 AM hudson.remoting.jnlp.Main$CuiListener <init>
INFO: Hudson agent is running in headless mode.
Aug 12, 2013 10:10:46 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Locating server among [https://test.tv/jenkins/, http://test.tv/jenkins/]
Aug 12, 2013 10:10:46 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to test.tv:6256
Aug 12, 2013 10:10:46 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Aug 12, 2013 10:10:46 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:189)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at hudson.remoting.ClassicCommandTransport.create(ClassicCommandTransport.java:98)
at hudson.remoting.Channel.<init>(Channel.java:391)
at hudson.remoting.Channel.<init>(Channel.java:387)
at hudson.remoting.Channel.<init>(Channel.java:348)
at hudson.remoting.Channel.<init>(Channel.java:344)
at hudson.remoting.Channel.<init>(Channel.java:332)
at hudson.remoting.Engine.run(Engine.java:238)
Jenkins Master output:
java.io.IOException: Unexpected termination of the channel
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2596)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1316)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at hudson.remoting.Command.readFrom(Command.java:92)
at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:72)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Hard to say what happens before knowing more. In particular:
does it fail at every connection request ? If so please check your auth.log on your server as it seems the failure happens after "status INFO: Handshaking" and before "Connected"
are your clock properly synchronized ?
what OSes are you using ? Which java version on your slaves ? check your PATH and JAVA_HOME
have you updated jenkins lately ? If so, have you updated the slave(s) ? Also have you tried reverting the update ? Which version are you using ? 1.520 took out support for JDK 1.5.
how do you run your java command ? From a terminal in an SSH session ? Is this scripted from the master ?
See also Jenkins slave jobs failing on "Unexpected termination of channel"

I've run into the same issue, which seemed to be worked-around by running jenkins-slave as root. Now, the thing periodically disconnects with that very same error, which I'm wondering is due to a LB keepalive. I'll update this answer as soon as I get more info.

In my case everything was working under root account. But under user account, node client failed to connect to server with message "failed Unexpected termination of the channel".
The problem was with access-or-write to working folder. As soon as I've reassigned owner throug "chown -R", node starts successfully.

Remote debugging on Tomcat with Eclipse

I'm trying to initiate a remote debugging session on my PC with Eclipse & Tomcat.
I managed to run tomcat (not through eclipse) with the following params:
set JPDA_TRANSPORT=dt_socket
set JPDA_ADDRESS=5050
cataline jpda start
The server starts ok, this is the outcome:
Using CATALINA_BASE: "C:\Java\Tomcat"
Using CATALINA_HOME: "C:\Java\Tomcat"
Using CATALINA_TMPDIR: "C:\Java\Tomcat\temp"
Using JRE_HOME: "C:\Java\jdk1.6.0_27"
Using CLASSPATH: ...
Listening for transport dt_socket at address: 5050
...
...
INFO: Server startup in 12502 ms
Now, I opened eclipse, and loaded the relevant project.
I set a new debugging configuration using Remote Java Application with localhost and the right port. however when I run it, I get this error message:
Failed to connect to remote VM. Connection refused.
Connection refused: connect
Can't really understand where is the problem. this is all local inside the PC, so there shouldn't be any firewalls involved, can someone think of something ?

Found the solution. apparently the connection was made, but Eclipse & Tomcat don'tt show any notification or status regarding it.
Then, when you initiate the connection again, you get the error because you're already connected.
I think that a small notice, either from Eclipse, or from Tomcat would be nice.

Try adding the following debug options directly to the JVM startup by directly modifying the catalina startup script
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5050

There could be problems when there are code mismatches between eclipse and tomcat. So when it matches the error will disappear

You can configure it in remote java application section in debug configuration.
For more details you can refer this link

Launching Jade In Ubuntu10.04 Linux

When I run the below command in terminal of ubuntu linux and also I set the ClassPath properly but I wasn't successful.
java jade.Boot -gui
I got following errors in terminal window:
15 Jun, 2011 6:33:10 PM jade.core.Runtime beginContainer
INFO: ----------------------------------
This is JADE snapshot - revision 6357 of 2010/07/06 16:27:34
downloaded in Open Source, under LGPL restrictions,
at http://jade.tilab.com/
----------------------------------------
Retrieving CommandDispatcher for platform null
15 Jun, 2011 6:33:11 PM jade.imtp.leap.CommandDispatcher addICP
WARNING: Error adding ICP jade.imtp.leap.JICP.JICPPeer#ae506e[Error: Not possible to launch JADE on a remote host (127.0.1.1). Check the -host and -local-host options.].
15 Jun, 2011 6:33:11 PM jade.core.AgentContainerImpl joinPlatform
SEVERE: Communication failure while joining agent platform: No ICP active
jade.core.IMTPException: No ICP active
at jade.imtp.leap.LEAPIMTPManager.initialize(LEAPIMTPManager.java:138)
at jade.core.AgentContainerImpl.init(AgentContainerImpl.java:316)
at jade.core.AgentContainerImpl.joinPlatform(AgentContainerImpl.java:482)
at jade.core.Runtime.createMainContainer(Runtime.java:165)
at jade.Boot.main(Boot.java:89)
15 Jun, 2011 6:33:11 PM jade.core.Runtime$1 run
INFO: JADE is closing down now.
help me to recover from this error.

I am so tired of this problem. It is one of many quirks and problems with JADE.
The problem you are facing is that you need to supply correct host information in the command line. Example
java jade.Boot -gui -local-host
This is all described here: http://jade.tilab.com/doc/tutorials/JADEAdmin/startJade.html
In many cases you don't have this problem and then it is sufficient to use the -gui option only. However I have discovered that Jade does not work very well when your resolves to 127.0.1.1. You can fix this by setting your IP address in or if you are on Linux edit your /etc/hosts file for a more permanent solution.

just type in JADE path..
java -cp lib/jade.jar jade.Boot -gui -local-host 127.0.0.1
(JADE has some problems to set local host adress)

The problem might be is previous java process might be still running on the local port , Make sure to check if port is in use or not if in use kill the java process before you rerun.

It's simple.
Modify /etc/hosts
Modify the line for the address 127.0.0.1, as follows:
127.0.0.1 localhost.localdomain localhost <machine_name>
Remove or comment the line with 127.0.1.1:
# 127.0.1.1 <machine_name>
and you're done.

The error isn't in the jade. It's a bug used by jade to start the default parameters with a bugged java method that should be fixed.
When jade runs the java method, it will retrieve 127.0.1.1 instead the loop-back 127.0.0.1.
I'm saying it because I tested. I read the JADE src that do this and I executed the java method that I didn't remember now.
Unfortunately it's happening in a few linux machines. In windows I didn't see it happens.
What I did to solve this problem was to edit the /etc/hosts file, like this:
Original file:
127.0.0.1 localhost
127.0.1.1 machine-name
Modified file:
127.0.0.1 localhost machine-name
127.0.1.1 machine-name
What I did was to put an alias of the machine-name on the loop-back ip address. This will bypass the bug.