Java and CGI

[Ray Jender]

I am just experimenting and want to play with Apache-Tomcat and CGI.

However I am a java newbee.  Every example/tutorial I see about CGI
says to rename a file servlets-cgi-renameto servlets-cgi.jar  but they don't
say how to use this file?

Any pointers out there to help me learn how to do apache-tomcat CGI?

Thanks.

[William Ng]

You are trying to eat a entire cow, my friend.

Let my get this straignt, You want to combine Servlets and CGI, but yet you are a novice at Java! Before learning to do use CGI with Servlets you need to learn Servlets. And in order to learn Servlets, you should first learn Java.

Anybody that has learned the basics of Java would have little trouble understanding why and how that file is used. I would reccomend you learn the basics of the language before anything else. You can't read if you don't know the language the book is written in. Similarly, you won't be able to follow many tutorials save for the most basic if you don't have a grasp on the language.

To answer you question, I assume that servlets-cgi.renamtojar was named that so it would not be recongnized as a jar file, which is a Java executable file. This disables it by default, and allows it to be activated when required.

[Norm Radder]

Is this your definition of CGI:
Common Gateway Interface (CGI) offers a standard protocol for web servers to execute programs that execute like console applications (also called command-line interface programs) running on a server that generates web pages dynamically.

[Jim Venolia]

In my universe CGI is Computer Graphics Interactive.  You know, the stuff that makes those awful Michael Bay movies possible.

I smell a possibility for confusion here.

[Norm Radder]

There is an html file in my Tomcat installation that talks about CGI: D:\apache-tomcat-8.0.32\webapps\docs\cgi-howto.html

[Tim Holloway]

In a VERY long and very evil Java career, I've never used CGI in a J2EE webapp.  My "cgi" webapps (it's hard to use that term accurately in most modern webapp systems) are completely separate apps generally hosted in an Apache or nginx server.

Java is very capable. There's really no reason to write any part of a Java webapp in any language except Java, and definitely not as CGI. In the really exceptional cases where special resources are needed, there's JNI - or these days - tapping ionto another (micro) server. About the only likely reason for pulling in CGI code would be if you simply wanted to piggyback onto an existing CGI webapp. And since that app almost certainly wasn't designed for life in a Java world, it would tend to be a bit of a Frankenstein creation if you did.

[Tim Holloway]

Jim Venolia wrote:In my universe CGI is Computer Graphics Interactive.  You know, the stuff that makes those awful Michael Bay movies possible.

I smell a possibility for confusion here.

It's actually Computer Generated Imagery. But it has been so long since I did Common Gateway Interface that the first thing I thought of was also the movie kind.

I do have 1 or 2 true CGI programs on my servers. But one of them is on my backlog pile for non-urgent repairs.

[Norm Radder]

been so long

The CGI scripts I pulled out to refresh my memory were dated 1998.

[salvin francis]

Jim Venolia wrote: ... I smell a possibility for confusion here.

Why ? Having some background over the same field, I do not see a direct relation between Tomcat/Java and the movies based CGI that can cause a confusion.

[Tim Holloway]

salvin francis wrote:

Jim Venolia wrote: ... I smell a possibility for confusion here.

Why ? Having some background over the same field, I do not see a direct relation between Tomcat/Java and the movies based CGI that can cause a confusion.

1. Early in the morning, my mental filters are not yet fully in place and free association can easily come up with non sequiturs.

2. This is the Mash-Up Era. We specialize in mixing apparently-unrelated things together.

3. And, if you'd seen some of my most recent projects, having Tomcat invested in GCI graphics wouldn't even be in the top 10 requests I've dealt with.

Java, incidentally, has done a lot of work with video. One of the best video editors I've worked with was 100% Java code. Some versions of Minecraft are done in Java, and if you think that's simple just because Minecraft is blocky, you haven't been paying attention to the lighting and fluid physics. Java also is (was?) at the heart of the control software for Blu-Ray™ video players as well.

[Norm Radder]

If CGI is Common Gateway Interface it has nothing to do with Graphics.
We're waiting for the OP to respond to our queries.

[Ray Jender]

Ok. Let me add some detail to my original question.

First I am using:
Ubuntu 18.04 server
Tomcat v8.5.38


So,  I am not a seasoned programmer.  You can say I am a dabbler.  I can stumble my through most code and get the gist of what it is doing.
If I did this for a living,  I'd know the answers myself. But I am only an experimenter.   I'm the type that likes to learn how to fix what I need to
fix, and not learn how to program the entire app.

I have taken freeware/shareware code in the past (javascript) and managed to modify it to do what I needed.   It has worked out fine for me without
actually knowing the ins and outs of programming in javascript.

In this particular case,  I have a valid/legitimate copy of an Apache-Tomcat based server application that I want to modify slightly.

The app uses googleapps.com/AJAX/jQuery

My file structure is:
 
webapps/
    WebRTCApp/
        index.html
        WEB-INF/
               web.xml
               cgi/
                 hello.cgi

I have added this to the existing web.xml:

 <servlet>
          <servlet-name>cgi</servlet-name>
                <servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
                        <init-param>
                        <param-name>debug</param-name>
                        <param-value>0</param-value>
                        </init-param>
                        <init-param>
                        <param-name>cgiPathPrefix</param-name>
                        <param-value>/WEB-INF/cgi/</param-value>
                        </init-param>
                        <init-param>
                        <param-name>executable</param-name>
                        <param-value>/usr/bin/perl</param-value>
                        </init-param>

        <load-on-startup>5</load-on-startup>
        </servlet>

        <servlet-mapping>
                <servlet-name>cgi</servlet-name>
                <url-pattern>*.cgi</url-pattern>
        </servlet-mapping>

In the index.html, at the very top of the file there is this:

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>

 I'm not sure exactly what this does but my guess is this
page is handled by the apache-tomcat server?

...but the rest of the index.html file is html and javascript only.

I basically want to save a variable that I create with javascript inside the index.html, into a database.  Sounds pretty simple to me.  But no.
At first I thought using php/mysql.  But no, the Apache-Tomcat server the app uses does not support php as a default.

So now I am trying perl.  I am trying a very simple perl script called hello.cgi  

print "Context-type: text/html\n\n;
print "Hello, mister!  How are you today?\n"

 and using the "How-To" at:  Apache-Tomcat CGI

Inside the index.html I have this:  

 var myURL = 'https://localhost:5443/WebRTCApp/WEB-INF/cgi/hello.cgi';
                $.post(myURL);

And when I browse to the index.html file, I am getting this error in the Chrome Dev Console:

XHR failed loading: POST "https://localhost:5443/WebRTCApp/WEB-INF/cgi/hello.cgi".
POST https://localhost:5443/WebRTCApp/WEB-INF/cgi/hello.cgi net::ERR_CONNECTION_REFUSED

I know most of you reading this will probably tell me to go learn Java.  But this is not java code problem.  
Most likely it's a problem with the server configuration supporting CGI?

All I'm looking for is a way to save the variable so a subsequent client user can browse to page on apache-tomcat server and read the same variable.

Whether the way is to use CGI or some other method, I'm open to suggestions.

Let me know if you need any other detaails.

Thanks and I appreciate all responses.

Ray

[Norm Radder]

Have you tried with a simpler URL: http://127.0.0.1:8080/Norms/cgi-bin/ENV2HTML.PL
I was able to configure TomCat 8.0.32 to call the perl script and return with it output to my browser

[Tim Holloway]

OK, first of all NO Java webapp server - including Tomcat - will serve anything out of any file or directory under WEB-INF. That's defined by the 2EE/JEE standards specification. The WEB-INF directory is reserved to hold support files and other vital assets that outsiders shouldn't be able to mess around with, so it's hidden from URL web requests and so are its contents.

Secondly, jQuery isn't necessarily Java. The "j" is for Javascript, and it's a client-side library package used to support AJAX and other advanced client-side functions and features. It is very popular in Java apps, but it can be used with non-Java apps on non-java servers (such as Apache httpd server, which is a completely different software system from Apache Tomcat). It doesn't require or use CGI.

Thirdly, Enterprise Java (J2EE/JEE) does NOT work on loose collections of files. It is based on the WAR (or EAR) architecture which can be represented as a ZIP (or more accurately a JAR) file. The Tomcat webapps directory is simply Tomcat's default place to keep deployed WARs, your WAR name is WebRTCApp and what you therefore have is what is known as an "exploded" WAR, which is to say an unzipped version of what would in strict JEE terms be a file named WebRTCApp.war.

And if that sounds needlessly pedantic never forget that computers are infinitely more pedantic, and if you don't understand the rules, you're likely to not follow them correctly and you're likely to have things fail for reasons you don't understand.

It might help if you could tell us where you got that webapp from. It's probably hideously obsolete, but at least then we could figure out what it really needs.

And finally, Tomcat doesn't normally listen on port 5443. I suspect that's supposed to be an SSL port, although Tomcat's default for SSL is 8443 and only a change to the Tomcat config file will make it listen on 5443.

[Ray Jender]

Norm Radder wrote:Have you tried with a simpler URL: http://127.0.0.1:8080/Norms/cgi-bin/ENV2HTML.PL
I was able to configure TomCat 8.0.32 to call the perl script and return with it output to my browser

I tried that and got the same error.

[Ray Jender]

Tim Holloway wrote:OK, first of all NO Java webapp server - including Tomcat - will serve anything out of any file or directory under WEB-INF. That's defined by the 2EE/JEE standards specification. The WEB-INF directory is reserved to hold support files and other vital assets that outsiders shouldn't be able to mess around with, so it's hidden from URL web requests and so are its contents.

The How-To says something different? Have I misinterpreted it? : https://dzone.com/articles/enable-cgi-mode-in-tomcat

Secondly, jQuery isn't necessarily Java. The "j" is for Javascript, and it's a client-side library package used to support AJAX and other advanced client-side functions and features. It is very popular in Java apps, but it can be used with non-Java apps on non-java servers (such as Apache httpd server, which is a completely different software system from Apache Tomcat). It doesn't require or use CGI.

Sorry if I implied jQuery was java.  I know it is javascript and I am trying to use AJAX;

Thirdly, Enterprise Java (J2EE/JEE) does NOT work on loose collections of files. It is based on the WAR (or EAR) architecture which can be represented as a ZIP (or more accurately a JAR) file. The Tomcat webapps directory is simply Tomcat's default place to keep deployed WARs, your WAR name is WebRTCApp and what you therefore have is what is known as an "exploded" WAR, which is to say an unzipped version of what would in strict JEE terms be a file named WebRTCApp.war.

And if that sounds needlessly pedantic never forget that computers are infinitely more pedantic, and if you don't understand the rules, you're likely to not follow them correctly and you're likely to have things fail for reasons you don't understand.

It might help if you could tell us where you got that webapp from. It's probably hideously obsolete, but at least then we could figure out what it really needs.

And finally, Tomcat doesn't normally listen on port 5443. I suspect that's supposed to be an SSL port, although Tomcat's default for SSL is 8443 and only a change to the Tomcat config file will make it listen on 5443.

The app is from antmedia.io   the community version.  And yes, it's configured to run ssl on 5443.  I don't think it's obsolete.  If does what it is developed to do.  I'm just trying to slightly modify it via html and javascript.

Thanks for the response and appreciate it!

PS:  $ java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.04.1)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.04.1, mixed mode, sharing)

[Norm Radder]

got the same error.

Strange.  The URL I posted does a GET not a POST.

Have you looked at the DOS window console where tomcat is running for error messages?

[Ray Jender]

Norm Radder wrote:

got the same error.

Strange.  The URL I posted does a GET not a POST.

Have you looked at the DOS window console where tomcat is running for error messages?

The apache-tomcat is running on Ubuntu Linux,  not Windows.

[Norm Radder]

Is there a window that you can open and issue the command to start tomcat so any error messages it prints out are shown?
On windows it writes lots of messages on the console window.

[Tim Holloway]

That was rather loud.

OK, a quick trip to antmedia.io seems to be something I'd expect to be more up-to-date than CGI, but whatever.

I think the URL you want is more like https://localhost:5443/WebRTCApp/cgi-bin/hello.cgi

Which, incidentally, is more like non-Java CGI URLs look as well. Now that I think of it, my Nagios server is CGI-based.

Also, as I said, Tomcat doesn't come pre-configured to use port 5443, so you're going to either have to use port 8443 or change the Tomcat server.xml file to use port 5443. And since this is SSL, you WILL need to setup a keystore and certificate no matter which port you use.

Also, please warn us when cross-posting to other sites/forums. It helps in keeping people from getting confused.

[Tim Holloway]

Also, some general notes. Apparently some people are running this product in Docker containers. I don't know if that's an option for the Community Edition or not, but if so, it's probably going to be a lot easier to get running.

I think a system I worked on about 2 years ago did something similar, but it was based on MediaTomb, which is now known as Gerbera. That was a completely non-Java system, though.

[Ray Jender]

Tim Holloway wrote:That was rather loud.

OK, a quick trip to antmedia.io seems to be something I'd expect to be more up-to-date than CGI, but whatever.

I think the URL you want is more like https://localhost:5443/WebRTCApp/cgi-bin/hello.cgi

Tried it.  It does not work.

Which, incidentally, is more like non-Java CGI URLs look as well. Now that I think of it, my Nagios server is CGI-based.

Also, as I said, Tomcat doesn't come pre-configured to use port 5443, so you're going to either have to use port 8443 or change the Tomcat server.xml file to use port 5443. And since this is SSL, you WILL need to setup a keystore and certificate no matter which port you use.

The app come with an ssl install script, using "Lets Encrypt" and port 5443.

Also, please warn us when cross-posting to other sites/forums. It helps in keeping people from getting confused.

I thought I answered this reply already but when  I came back to read it, I didn't see any of the comments I made?   Weird.

[Ray Jender]

Tim Holloway wrote:Also, some general notes. Apparently some people are running this product in Docker containers. I don't know if that's an option for the Community Edition or not, but if so, it's probably going to be a lot easier to get running.

If I can get this to work,  I am considering running this in containers, sure!

I think a system I worked on about 2 years ago did something similar, but it was based on MediaTomb, which is now known as Gerbera. That was a completely non-Java system, though.

[Ray Jender]

Norm Radder wrote:Is there a window that you can open and issue the command to start tomcat so any error messages it prints out are shown?
On windows it writes lots of messages on the console window.

There are three log files that I monitor while restarting the app.  None of them are showing errors.

[Norm Radder]

What about what tomcat prints on the console/terminal window?  What is shown there?
Here is what I see in the console window when I start tomcat

D:\apache-tomcat-8.0.32\bin>"C:\Program Files\Java\jdk1.8.0_60\jre\bin\java.exe" -cp bootstrap.jar;tomcat-juli.jar org.apache.catalina.startup.Bootstrap start
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Server version:        Apache Tomcat/8.0.32
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Server built:          Feb 2 2016 19:34:53 UTC
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Server number:         8.0.32.0
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: OS Name:               Windows 10
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: OS Version:            10.0
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Architecture:          amd64
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: Java Home:             C:\Program Files\Java\jdk1.8.0_60\jre
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: JVM Version:           1.8.0_60-b27
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: JVM Vendor:            Oracle Corporation
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_BASE:         D:\apache-tomcat-8.0.32
Jul 18, 2019 8:08:49 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_HOME:         D:\apache-tomcat-8.0.32
Jul 18, 2019 8:08:49 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: Loaded APR based Apache Tomcat Native library 1.2.4 using APR version 1.5.1.
Jul 18, 2019 8:08:49 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
Jul 18, 2019 8:08:50 AM org.apache.catalina.core.AprLifecycleListener initializeSSL
INFO: OpenSSL successfully initialized (OpenSSL 1.0.2e 3 Dec 2015)
Jul 18, 2019 8:08:51 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-apr-8080"]
Jul 18, 2019 8:08:51 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-apr-8009"]
Jul 18, 2019 8:08:51 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2813 ms
Jul 18, 2019 8:08:51 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jul 18, 2019 8:08:51 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.0.32
Jul 18, 2019 8:08:51 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive D:\apache-tomcat-8.0.32\webapps\quercus-4.0.39.war
Jul 18, 2019 8:08:53 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:08:53 AM org.apache.catalina.util.SessionIdGeneratorBase createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [355] milliseconds.
Jul 18, 2019 8:08:53 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deployment of web application archive D:\apache-tomcat-8.0.32\webapps\quercus-4.0.39.war has finished in 1,935 ms
Jul 18, 2019 8:08:53 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\docs
Jul 18, 2019 8:08:54 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:08:54 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\docs has finished in 748 ms
Jul 18, 2019 8:08:54 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\examples
Jul 18, 2019 8:08:57 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:08:57 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
Jul 18, 2019 8:08:57 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
Jul 18, 2019 8:08:57 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\examples has finished in 3,009 ms
Jul 18, 2019 8:08:57 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\HIW
Jul 18, 2019 8:08:58 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:08:58 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\HIW has finished in 515 ms
Jul 18, 2019 8:08:58 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\host-manager
Jul 18, 2019 8:08:58 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:08:58 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\host-manager has finished in 541 ms
Jul 18, 2019 8:08:58 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\jsp-examples
Jul 18, 2019 8:09:01 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:01 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
Jul 18, 2019 8:09:01 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
Jul 18, 2019 8:09:01 AM org.apache.tomcat.util.descriptor.web.SecurityConstraint findUncoveredHttpMethods
SEVERE: For security constraints with URL pattern [/security/protected/*] only the HTTP methods [DELETE POST GET PUT] are covered. All other methods are uncovered.
Jul 18, 2019 8:09:01 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\jsp-examples has finished in 2,414 ms
Jul 18, 2019 8:09:01 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\manager
Jul 18, 2019 8:09:01 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:01 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\manager has finished in 651 ms
Jul 18, 2019 8:09:01 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\Norms
Jul 18, 2019 8:09:03 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:03 AM org.apache.tomcat.util.descriptor.web.SecurityConstraint findUncoveredHttpMethods
SEVERE: For security constraints with URL pattern [/jsp/security/protected/*] only the HTTP methods [DELETE POST GET PUT] are covered. All other methods are uncovered.
Jul 18, 2019 8:09:03 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\Norms has finished in 1,517 ms
Jul 18, 2019 8:09:03 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\php
Jul 18, 2019 8:09:03 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:03 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\php has finished in 638 ms
Jul 18, 2019 8:09:03 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\ROOT
Jul 18, 2019 8:09:04 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:04 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\ROOT has finished in 589 ms
Jul 18, 2019 8:09:04 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory D:\apache-tomcat-8.0.32\webapps\servlets-examples
Jul 18, 2019 8:09:05 AM org.apache.jasper.servlet.TldScanner scanJars
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.
Jul 18, 2019 8:09:05 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
Jul 18, 2019 8:09:05 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
Jul 18, 2019 8:09:05 AM org.apache.tomcat.util.descriptor.web.SecurityConstraint findUncoveredHttpMethods
SEVERE: For security constraints with URL pattern [/jsp/security/protected/*] only the HTTP methods [DELETE POST GET PUT] are covered. All other methods are uncovered.
Jul 18, 2019 8:09:05 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory D:\apache-tomcat-8.0.32\webapps\servlets-examples has finished in 627 ms
Jul 18, 2019 8:09:05 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-apr-8080"]
Jul 18, 2019 8:09:05 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-apr-8009"]
Jul 18, 2019 8:09:05 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 13320 ms

[Tim Holloway]

1. Did you configure Tomcat to listen on port 5443?

2. Did you setup an SSL keystore and define certs?

Until you do that, no URL path will work.

[Tim Holloway]

Tomcat comes with control scripts. You should be using them. Otherwise it's likely that not all of the necessary system components will be properly configured.

The master script for Linux/Unix/MacOS is named TOMCAT_HOME/bin/catalina.sh. The master script for Microsoft Windows is TOMCAT_HOME/bin/catalina.bat.

There are also "shortcut" scripts named startup.bat/.sh and so forth that can be used.

[Ray Jender]

Tim Holloway wrote:1. Did you configure Tomcat to listen on port 5443?

Yes.  I thought I mentioned that?

2. Did you setup an SSL keystore and define certs?

I'm not sure what that exactly means?

Until you do that, no URL path will work.

Again, like I said.   This app works as designed, using https!
I am simply trying what should be an easy modification that I cannot get to work!

[Ray Jender]

Ray Jender wrote:

Tim Holloway wrote:1. Did you configure Tomcat to listen on port 5443?

Yes.  I thought I mentioned that?

2. Did you setup an SSL keystore and define certs?

I'm not sure what that exactly means?

Until you do that, no URL path will work.

Again, like I said.   This app works as designed, using https!
I am simply trying what should be an easy modification that I cannot get to work!

I have:
/usr/local/antmedia/conf/truststore.jks
/usr/local/antmedia/conf/keystore.jks