What is Reddit's opinion of Apache Tomcat?

From 3.5 billion Reddit comments

It's well known among experienced Java programmers that System.exit() shouldn't be used except in e.g. command-line tools. But I wanted to mention that System.exit() (or rather Runtime.exit()) goes through the security manager:

http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityManager.html#checkExit(int)

In general, you should enable the security manager. It catches a lot of security problems! Including this one, turning it into an exception rather than shutting down the whole VM. It's easy to enable the security manager in most application servers. E.g. see:

http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html

If using the security manager seems a bit heavy-handed to you (it shouldn't!), you can still enable checks for exit()s only by overriding the checkPermission method of the SecurityManager class and letting everything through except exits.

This is why the X-Forwarded-For header exists.

The SSL terminator (Apache HTTPD, HAproxy, Pound, Nginx, ...) sets or appends to that header the address of the connecting HTTP client. The backend server (Apache HTTPD, Tomcat, whatever) can then use the contents of the X-Forwarded-For header to display the client's address in its logs (or wherever).

Tomcat can do that using the Remote IP valve, Apache 2.4 has mod_remoteip and Apache 2.2 has mod_rpaf.

You have mentioned three technologies which are essentially independent. I would read about all three on wikipedia, but here are brief summaries. And as always, google will take it further.

1) Servlet. This is actually an interface specification which is now probably close to 15 years old and has undergone many revisions. The two sides of the interface are a) Application Server and b) Servlet implementations. The interface of the servlet provides an easy way to handle HTTP requests. The Application server contains the "main()" method and does all the threading and session management. Most people write to the callee side of the interface.

2) In your particular case "Tomcat7" is an application server that does the caller side of the servlet interface and listens on your HTTP port. Tomcat is the old standby for this, and aside from the servlet API implement some other stuff as well.

3) ActiveMQ broker is pretty much unrelated to #1 and #2. You could run this separately from the others if need be. Activemq is a messaging system. programs can push messages into a "queue" or "bus" and receiving systems will receive those messages. IT can be configured in various ways to provide transaction and/or persistent behavior. The broker is the part of the activeMQ which is sort of like the traffic director.

http://tomcat.apache.org/tomcat-7.0-doc/servletapi/

http://en.wikipedia.org/wiki/Java_Servlet

and

http://en.wikipedia.org/wiki/Activemq

Yes, I was thinking about making a mobile client. But that's a lot of extra work, so I'd like to see demand for the base tool first ;).

In the meantime, workaround: TradeTrax is actually a servlet (java based web app). If you are technically inclined, you ditch the .exe file and stick the application into a servlet container (e.g. apache tomcat or Jetty ). Add some SSL protection and password protection around it and you can access your database from your phone like a normal webpage.

PS: Sorry, I didn't get around to write docs for this, yet.

TOMCAT

I used to say that they were equivalent more or less. That was until tomcat included the ability to have parallel versioned hot deploys. You can now have multiple versions of an app running at the same time. A user will maintain the version they have for the duration of their session. All new sessions work off the latest version. It allows for zero downtime hot deploys during the day.

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment

OP is talking about Apache Tomcat, not Apache HTTP Server. Anyone suggesting *AMP is likely wrong.

To OP: refine your search to include "Tomcat" and "Eclipse". It's also possible that you have installed "Eclipse IDE for Java Developers" - the correct installer to download is "Eclipse IDE for Java EE Developers".

By default, Tomcat will set the context path of the application to the base name of the WAR, as you are seeing. You need to configure the context container to set a different path.

In /META-INF/context.xml, specify something like this:

<Context path="myapp"> </Context>

For your intents and purposes, a java server works exactly the same as a PHP or ASP one, Tomcat is actually built on apache (which PHP websites use). If you're just building static HTML templates and then handing them off to a developer to tie into the backend then you have nothing to worry about. If it's your job to tie the templates into the back-end system, then you'll probably want to read up on Java Server Pages.

If he wants to do it as a java applet, then you should run for the hills because it's an outdated tech that will cause more problems than it could solve. It's highly unlikely that this is the case though.

To be honest, you should speak to him directly about the implications, I'm just second guessing what I imagine the situation is. A good business relationship is founded on transparency and communication.

To easily get started with vanilla Tomcat:

1) Download Eclipse for JavaEE. http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/neon3

2) Download Tomcat http://tomcat.apache.org/download-80.cgi , and unzip to a folder somewhere.

3) Tell eclipse about Tomcat, under Preferences->Server -> Server Runtimes

4) Create a new project. Dynamic Web Project

5) Inside that project, create new Servlet....fill in the details... make sure the URL mapping is set to '*'...so it responds to any URL.

6) Click on the project root folder, right click, Run on Server. Select the tomcat server you configured.

Thats about it.... if you've done everything correct you should get a web page shown in Eclipse.

You should be able to see how this webpage is made by looking at the autogenerated servlet. You need to change your client so it talks HTTP, maybe using URLConnection instead of Glueon, so instead of a webpage viewing the result, its your java client.

When you want to deploy to a live server, you can right click the project, and 'Export as War' - this creates a war file you can copy to the tomcat webapps folder, running on AWS.

This is really about as easy as it can be to get up and running..... Do you know Maven / Gradle? because these tools can let you compile, build, export war files without having to depend on Eclipse to do it for you.... BUT, again, its additional hair that you don't need to know about.

Rolling it yourself wouldn't be my recommendation unless you value the learning experience more than the end result. If you're after a functioning server first and foremost, consider checking out Apache's Tomcat or HTTP Server projects?

You'll likely need a little bit of knowledge in both. HTML will be used in your frontend, and you'll be using a Java based web-framework for backend (probably Tomcat). It seems daunting taken at face value, but the class is meant to guide you along with these things. You'll also have the TA and professor to consult.

I can help you out!

First download tomcat from here: http://tomcat.apache.org/download-80.cgi . This is a server that will host dripstat for you.

Then unzip to some folder. Then download dripstat and unzip the folder into the Tomcat home directory.

Spring is another monster. Just get the JVM going first.

I better not see you ahead of me any time soon. :P

I should note that I've never used JSP (although have used some frameworks that I believe are very similar). However, I believe it simply doesn't work the way you're looking for.

JSP stands for "JavaServer Pages". As the name implies, they must be run on a server. Thus, they aren't standalone programs. You'd have to run some kind of servlet container like Apache Tomcat.

While it totally might exist, I'm not aware of any "one click deployment" options. If anything, this would be because server applications aren't meant to be run by the client. They're meant to be run by some server and the client accesses that server (and thus there's no need for something like you describe).

Welp if you can't copy it you might as well rip it off ;). Original idea is from tomcat as I probably pointed out at a couple of spots.

http://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html

Original idea is a bit more involved because java but yeah basics are there.

Also its on npm now.

https://www.npmjs.org/package/express-session-multicast

So if you want to take it for a ride have fun!

What does "web based" mean? I assume you mean you would run an HTTP server? In which case, the framework really doesn't matter. Compatibility will mostly be in the data sent.

Tomcat is sort of the de facto Java HTTP server.

JVM is "Java Virtual Machine." People who run Java applications (traditionally servers like Tomcat and JBoss, although it's not limited to those) can install some code from Dripstat that reads how much memory that process is allowed to use on their server. 5% of that number is given as an automatic drip once every hour.

If you're not running a Java application that can be instrumented by the dripstat agent, there's really nothing for you in the JVM arena.

Java Web Start is a system to run java applications from a browser without having to install anything but a Java runtime. Java Webstart files can be served from any Webserver that can serve the inital .jnlp file that initiates the app as "application/x-java-jnlp-file".

Then there are servlet containers. The Servlet API is the Java standard for serving websites. The user of such a website just needs a browser. (Examples for a servlet container would be Tomcat or Jetty)

Glassfish also contains an servlet container but is more than that. It is a so called Application-Server which is meant to run larger, maybe multiple-systems involving java applications. Unless your hobby is toying with such architectures, you don't really need an application server.

• obviously need database with daily backups
• login screen with employee number
• input screen
• receipt screen confirming input goes back to login screen

need a controller class that will control which form are you accessing need data access class to record car info need data access class to record logins

db: car user

user table should contain login info car table should contain car info + user id so you can track every car to the mechanic that worked on it

need either jsp pages or swing classes to display forms

if you're using web:

download tomcat http://tomcat.apache.org/download-70.cgi struts are usually easiest web framework or you can use straight servlets

for db -both microsoft and oracle have a single user free db or use mysql

IIRC tomcat has a web based manager you can use to deploy stuff but it's been a long time since I used tomcat.

edit: yeah here you go http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html this should get you running. Remember to lock this down in production otherwise your server will get raped.

Yea I hear ya, my projects felt like they went from 0% to 80%, then that clever anecdote about the last 20% taking 80% of the time.. yea.

Do you use Tomcat? In most non-grails cases we would end up factoring out jars used by many apps in the same instance into the "common" /lib folder in order to save some permgen memory space.. I think this is less of a big deal now, but in the past Tomcat has had some serious memory issues and not being able to recover permgen when redeploying (and we tend to redeploy applications quite a bit)

Essentially you can do sort of the same thing with Grails, but you have to be careful of the jars you take out and which you don't - Grails configures singletons and sticks 'em in some global space that overrides other grails application's variables if they aren't using different classloaders.

Sorry if all of that was confusing.. this might help.. but essentially you can put most of the libs used by grails (including spring) but NOT the grails* jars themselves in a common classloader and it'll work as intended with multiple grails applications in one Tomcat server instance.

It really depends on what the server is supposed to do. Is it managing all world state for an MMO or is it simply a way for multiple players to chat with each other?

You could look at some of the existing server tools out there like an NIO client server framework such as Netty or an HTTP/servlet based engine like Tomcat. Minecraft, for example, uses Netty as the base server component.

Or you could do something simpler and start with the provided HttpServer in the JRE.

Any of these can provide you with a server capability, but you'll need to define the type of communications you use. Do you need permanent open connections between client and server or will a request/response model work? Is your client a web browser? If so, do you need web sockets?

My recommendation, first define what the server does, how it interacts with the clients. Figure out what information needs to flow back and forth and how that flow should work.

Once you have that sketched out, then look at the available tools and see which will work for your needs. Then you should be able to find some tutorials or documentation.

Obligatory, read the documentation its pretty damn helpful. Make sure you read the correct version because there are nuances to each version. Probably are going to want to start here for the certs. The apps deployed on this server should have their individual logging and for other information you might be interested in the access logs. Inside the "server.xml" you could edit the pattern here :
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"

prefix="localhost_access_log." suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

to include some additional parameters for example.

That would probably be javax.servlet.http.HTTPServlet - the x is important.

You are looking for the dependency of servlet-api ( https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api ) that matches your application server specification.

If people were not setting up their environment correctly (by putting the api or application server library directly in the class path), you wouldn't see it there.

You're looking to add something like:

<!-- https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency>

Make sure you have the right servlet spec for your application server. For tomcat, this is described in this page. The 3.1.0 that I linked above works for Tomcat 7 and later. If you have functionality that requires servlet spec 4.0, you'll need tomcat 8 (and the appropriate provided dependency).

There are too many misconceptions about Java floating around.

The java compiler compiles the source code written in the Java programming language into byte code stored in class files. It is a JVM (Java Virtual Machine) that executes the byte code, performs garbage collection etc. While there are many JVMs available, the most well known of the lot is Sun's/Oracle's HotSpot. If you have ever used java over the commandline, javac is the compiler; java is the jvm.

So, you do need java on the target machine. However, there is nothing in the JVM Spec, to my knowledge, that requires that the JVM be installed/distributed separately. Avian is a JVM that can be embedded within your application. So one application = one executable.

> Why would anyone want to program in Java if it seems like all these different pieces have to fit together?

While plenty of client side applications and games use java, it is primarily used in the enterprise to run web applications. Developers write applications targeting java application servers (if you're interested, you could start with something like Apache Tomcat).

I was thinking of server-side Java like Play and Tomcat. These can let you dynamically generate webpages and respond to requests, but yes - you can't actually execute any code on the browser.

If you want to do anything client side, you can't use Python, C or Java - JavaScript is the only language that will run in a user's browser.

When I see questions like yours, it makes me certain that Spring has completely fubard the Java eco-system. Half the answers here will be screaming how good spring is and providing excuses for why complex it is. The other half will be shouting how you should be using some lesser known framework. This infighting is damaging the whole reputation for Java. No wonder people want to move to python / ruby.

Its not like this. At all. If you stick with the standards that Sun (now oracle) created, it turns out it is not really any more complex than setting up PHP.

1) You need a webserver. There are plenty of java Webservers, but Tomcat appears to be the most recognised and used. Download it from http://tomcat.apache.org, unzip it somewhere. Done.

2) Start tomcat by CD into the bin directory, and startup.bat or startup.sh depending on if you're using windows or linux.

3) Navigate to http://localhost:8080 - There will be servlet examples in here which will show how to get started. Go modify some of those apps, they are in the tomcat/webapps directory.

Forget about spring. Even those of us in industry who have been creating java webapps for years are now questioning if spring is still worth its complexity today.

Going mostly from memory here, but I think if you change unpackWARs and autoDeploy attributes of the Host tag to both be true then the wars will be unpacked and deployed as soon as they are detected. See the Tomcat documentation.

I don't see an actual question here though, so I'm not sure if this is what you're looking for.

I was asking that because i had working example. Anyway read http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment_Entries. In your context add as many environment variables as you like. You ll have to google how to get JNDI resources for your development environment (Java EE or whatever you are using).

Yes there is. I have to go to sleep so i cannot write longer and more helpful answer. You could use JNDI. Read more about it here http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html. Here is how to configure date source trough JNDI with spring http://stackoverflow.com/questions/9183321/how-to-use-jndi-datasource-provided-by-tomcat-in-spring.

Strange things can happen. Consider that a key part of the java web world is that of the jsp. The jsp is sent through a program called jspc which is the compiler form jsp ultimately a to a class file. As the tomcat documentation reads:

> If the new Java version introduces new language features then the default JSP compiler may not support them immediately. Switching the JSP compiler to javac may enable these new language features to be used in JSPs.

So, the change to javac may cause issues with certain things generated by jspc.

There is also a bit of fun with libraries...

One example of this was when Java 7 updated to jaxb 2.2 while the rest of the EE stack was expecting 2.1. This caused quite a bit of confusion at a previous employer, completely throwing off the estimates for how long it would take to update the backend - which eventually got cancelled ("do we really need to upgrade? or is this just the devs trying to be on the bleeding edge?").

You'll want to know how the apache config works, enabling and disabling modules. Tomcat live behind apache (usually) so you'll do alot of RewriteRules and Redirects.

You'll also want to get cozy with the tomcat XML files as they control settings and such for the app server. In stall the "tomcat-manager" so you can deploy j2ee apps and start/stop/restart instances from your web browser etc.

Learn how to tune tomcat, you'll also likely be dealing with connection pooling etc. Some linkage for you, obviously choose the right documentation version for what you're running in prod.

http://httpd.apache.org/docs/2.2/ http://tomcat.apache.org/tomcat-6.0-doc/index.html

Invaluable tools for debugging: lwp-request, curl, tcpdump, and tail -F. =) nevermind firebug or chrome devel tools.