• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Tomcat Greenhorn

 
Ranch Hand
Posts: 127
1
Monad Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm a Tomcat greenhorn and I'm looking for a resource or tutorial for URL paths. I can put the simplest web application together when it consists of a few html docs and servlets but I resort to guessing resource paths when the web application starts growing in size. I understand there is a document root and server side and client side to consider when building URL paths but that's about it.

Note: I'm not using an IDE(no Eclispe or NetBeans or Intellj), I'm using the command line and GNU Emacs because I want to understand how everything is wired together before I let an IDE take-over house keeping chores.

If anyone knows of a good(good meaning simple) resource for me.
 
Saloon Keeper
Posts: 22658
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Gerard!

I applaud your dedication using Emacs - the One True Editor to build your webapp.

Web applications have a sophisticated directory structure and the easiest way to build them is by using a build tool such as Ant, Maven, or Gradle.  If you're a really serious Emacs fan, there are some modules to make Emacs Maven-friendly, incidentally. Of course, all the popular IDE's have support as well.

A URL is comprised of the following components:

1. Protocol: for example, http:. The protocol part of the URL sets the well-known port number that the request will be sent to by default. For HTTP, that would be port 80.For HTTPS, it would be 443. The protocol may also be used to determine what sending and receiving mechanisms are to be used.

2. Server domain name. This should be a string sufficient that the client can translate said domain name to a TCP/IP address. Domain names include a machine ID and optional domain name. The machine name may indicate a specific host or one of a set of hosts. For web servers, this machine name is often "www". Note that a host can have multiple machine names, so for example, www.mousetech.com may resolve to the same IP address as mail.mousetech.com. However, it's best to use the recommended machine name, since there's something called a "virtual hostname" that can affect where web requests get sent.

3, Override port ID. For example, a test Tomcat app might have a URL starting with http://localhost:8080. Localhost is the standard machine name for whatever machine you're actually sitting at and has the IP address of 127.0.0.1. Port 8080 is the standard port ID for Tomcat (instead of port 80). There are several reasons why Tomcat doesn't default to port 80.

Now we come to the application-specific parts of the URL. A webapp server can host more than one webapp, so to tell the server which webapp to talk to, you must provide a [context path. Every webapp managed by that server will have a unique context path assigned to it. For example: "/mywebapp". An empty context path: "/" routes to the default webapp. For Tomcat, that would usually be a pre-installed JEE demo or admin application.

Following the context path comes the part of the URL that the web application itself works on. A web application is not a unified program - in fact, in the standard sense it's not a "program" at all. So the URL is dissected by the webapp server and matched to a set of logical and physical resource paths. Logical resource paths route control to servlets using a path-to-class mapping defined in the webapp's /WEB-INF/web.xml file or by an annotation on the servlet's class definition. If that fails, the webapp server looks to see if the URL residual path (the part after server and context) maps to a JSP. In which case, the JSP is compiled to create a corresponding internal servlet and executed. If the residual path doesn't map to either a servlet or JSP, then the webapp server looks in the WAR for a resource and if found, copies that resource (prefixed by appropriate HTTP headers) back to the client. For example, the residual resource path /images/bird.jpg would presumably be a JPEG file containing the picture of a bird.

We can break a residual path down further into dispatching and argument components. The dispatching component determines the resource to receive the request. The arguments are stuff like the HTTP GET URL arguments. So for example, /mywebapp/calculator/sum?a=123*b=456 might map to web application "mywebapp", the "calculator" part might map to com.coderanch.mywebapp.Calculator.class" (a compiled servlet), the "sum" part might be eaten by the servlet as a command or data value and the arguments a and b might be used by the servlet's "sum" function to compute and return the sum of 123+456.
 
Gerard Gauthier
Ranch Hand
Posts: 127
1
Monad Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the detailed post Tim!

About the Emacs 'Maven-friendly' modules... Is there anything that could make something Maven friendly? I jokingly say this because most project mangers are more complicated than the languages they serve. This from a person(me) who has never ventured past a simple makefile but I will look into that Maven 'friendly' module.

Again thanks for the post and you'll probably be hearing from me in the near future with more detailed questions.

 
Tim Holloway
Saloon Keeper
Posts: 22658
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When I first attempted to build Java webapps, I used Windows .bat files. That's a very unsatisfactory solution. The Unix make utility is also a major disappointment for such tasks. Then I discovered Ant.

Ant did the job, but managing third-party libraries was messy and the one-off filesystem structure made porting build environments difficult. Ivy wasn't yet available to help Ant, either.

I got nudged in the direction of Maven, but resisted for 2 reasons: 1) It worked by "magic" rather than by explicitly-visible rules and 2) It forced a specific directory structure on projects. One that I didn't agree with.

On the other hand Maven's management of third-party libraries, and its ability to fetch them at need was a real winner. The standard project structure proved to be less onerous than I'd originally thought - and made it easier to find my way around "foreign" projects, and I managed to get clued into the most common goals and plug-ins.

Granted, anything that uses XML as a declarative language is a pain (and one that cannot leverage schema validation to boot), but for the most part, using a POM is like programming in COBOL. You set up one and you clone and customize thereafter. Or, for that matter, you can use Maven's archetype feature to have Maven itself build a custom POM for you to use as a basis. There are also useful side goals, like the one that can map library dependencies and the ones that can convert a command-line only Maven project into an Eclipse and/or IntelliJ-project. I've also used Maven to create OS installer packages, so that, for example, I can build a WAR and have it installed and managed as part of the OS native package inventory including the creation of extra-WAR files such as external data storage directories and deployment descriptor files.

The icing on the cake, though is that I can do a "mvn clean", ZIP the resulting project directory, send the ZIP file to Outer Mongolia where someone I've never met can UNZIP it, and with only a compatible JDK and Maven completely re-create the project ready-to-run without further instruction from me. That's really cool (and useful!).

Of course, in addition to Maven, there are now several alternatives that attempt to do Maven one better, such as Gradle. I've not developed much expertise with Gradle myself, although I think it's the preferred build tool for Android these days. It's better for systems that have non-java code in them, but I ran into problems with breakage. A properly-written Maven project will generally still build clean years after the components it's working with become technically obsolete. Rather like Java's deprecation system.
 
The harder I work, the luckier I get. -Sam Goldwyn So tiny. - this ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic