Tim Holloway

+ Follow
since Jun 25, 2001
Tim likes ...
Android Eclipse IDE Java Linux Redhat Tomcat Server
Long-time moderator for the Tomcat and JavaServer Faces forums. Designer and manager for the mousetech.com enterprise server farm, which runs VMs, a private cloud and a whole raft of Docker containers.
These days, doing a lot of IoT stuff with Arduinos and Raspberry Pi's.
Jacksonville, Florida USA
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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.
6 hours ago
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.
7 hours ago
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.
1 day ago
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.
1 day ago
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.
1 day ago

Stephan van Hulst wrote:
You may not create your own ExecutorService, because it will be populated with threads from the JVM directly, while you want the threads to be managed by your application container.

The difference between the JVM and the application container (by which I assume you mean the webapp application itself - e.g., Tomcat) is relatively minor. More specifically, you'd be best served by having the engine controlled by the ServletContext because that way it goes up and down with the webapp rather than leading a rogue existence of its own.

I should qualify that whether you do roll-your-own or a sophisticated manager like ManagedExecutorService that it is absolutely essential that the engine manager's worker threads not be parented by servlets or JSPs. That is, if a servlet request should invoke a ManagedExecutor (or whatever), and the ManagedExecutor spawns a thread or threads but it's doing so under the servlet thread, you're still violating J2EE constraints.
1 day ago
I haven't been writing major webapps lately either. In fact, I haven't done much with Futures or the ExecutorService. I just meant any generic process or processes that can be handed a task and allowed to go its merry way. Back when I dealt with such things regularly I had to use brute force, since more civilized approaches hadn't been invented yet, but an ExecutorService would certainly work. As would some of the Spring Framework services that weren't available to me back then either.
1 day ago
Indeed. Context is everything. A "lifetime" could mean the entire time from startup to shutdown of a JVM and its apps such as a Tomcat webapp server. But withing Tomcat, if you're using JavaServer Faces, each JSF request/response has a documented lifecycle, which can be represented as a flow chart covering the various phases of processing. That lifecycle runs for each JSF request being handled, and in the case of multiple concurrent JSF requests, each of the concurrent requests is running its own independent lifecycle.
1 day ago
HTTP doesn't need "broken connections". The HTTP standard is nothing but broken connections. A client makes an HTTP URL request, the server processes it, returns a response and the client/server connection is closed. End of sentence. If you want to make another request, the client must open another connection. Again. And again. And again.

A well-behaved web application will spend a minimum amount of time processing that request and returning the response. The web is not the place for long-running request/response cycles. The browser will, in fact, eventually time out and break the request on its own if a response doesn't come back soon enough.

If you need ReST (or any other HTTP request) to set off a long-running process, then you should use the HTTP request to queue up an out-of-band processor and either poll for completion (as successive periodic HTTP requests) or provide some sort of callback mechanism to notify anyone who wants to know when the long-running request is done. Email, for example.

The out-of-band processor might be some sort of batch system, but you can also spawn an engine thread(s) in your webapp ServletContextListener startup listener.

On no account should a servlet or JSP attempt to spawn threads themselves, either directly or via methods invoked by the servlet or JSP. This violates the J2EE specification and can potentially randomly crash the entire webapp server.

On the other hand, the ServletContextListener can safely spawn threads. So a servlet or JSP can use a shared synchronized resource to push processing requests to those threads.
1 day ago
Common thread here.

NONE of the issues I see relate to the Raspberry Pi. They're all related to Java and to the dependence on an IDE. The main issue with the Pi is that as far as I can tell, it's NOT running the IDE, it's running the actual application. As it should.

Java does not ever look at jars that are inside other jars for classes. The only way to make it do so is by adding extra support code to the application or its framework. For example, webapp servers dig around in the WEB-INF/lib jars for class resources as well as the WEB-INF/classes directory for loose class resources.

To make a stand-alone executable jar work like that, as I said, some external magic has to be injected. That's what the Maven Shade plugin does when it builds an executable jar. In addition to copying the included jars into the product jar file, it also injects extra classloader logic into the app startup so that the contents of those included jars will appear on the app's classpath. Simply building with the java "jar" command isn't enough.

And just to make things perfectly clear: Java on the Raspberry Pi is no different than Java on any other hardware platform. It has exactly the same write-once/run anywhere rules as for the larger Linux desktop and server systems.

I say that as a person who right this moment is literally surrounded by Pi systems. I'm doing a home automation server project on them.
1 day ago
As it happens, I just ran across a related problem/solution. When designing electronic circuit boards (PCBs), the object of the game is to run "wires" (traces) between the electronic components laid out on the boards - transistors, resistors, capacitors and so forth.

However, it's not as easy as you might think. The traces are limited mostly to 2 dimensions, and many components cannot be directly connected without crossing wires.

The solution to that problem is to temporarily jump into the third dimension and run wiring on the other side of the PCB. In ancient times, typically only one side was etched with wiring traces and to wire the other side, you had to literally punch holes through the board and connect the crossovers with actual wire. These days, factories simply etch both sides of the board and make the cross-connection via a metal plug through the hole (known as a "via").

Vias are undesirable. They are less mechanically secure than a simple trace run and more likely to introduce funny electrical effects, especially at high frequencies. And they don't always cure everything. Really complex PCBs such as computer motherboards actually stack 2 double-sided PCBs to get 4 layers of wiring. But that's a bit much for most of us - although if you're so inclined I can direct you to some good design software (it's open-source and free).

So it's a bit of a game to design a PCB where the number of vias is kept to a minimum and the traces are kept as short and simple as possible.

Many people think that the only real way to do this is by hand, but automation is everywhere, and there are programs available to attempt optimal routing automatically. One such program is FreeRouting by Alfons Wirtz and it's in Java, if you want to see how it's done. As it is a visual program you can actually watch it run as it lays down traces, decides it made a bad move, rips them up and lays down new ones, making multiple passes until it is satisfied that it has done the best job reasonably possible.

And, incidentally, it reminded me that there are 2 other problems of this same general class: the "Bridges of Konigsberg" problem, where the graph overlays 7 islands connected by bridges where you have to visit each island crossing each bridge only once, and "map coloring" problems, where you have a limited number of colors and a geographic map of, say, post-Roman Europe where you have lots of little countries and you want to color each one such that it is a distinct color - no two adjacent countries being the same color.
2 days ago

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.
3 days ago

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.
3 days ago
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.
3 days ago