• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

a very basic servlet start question

 
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings,

I have a fairly mature webapp running under Tomcat but I didn't spend enough time in the beginning to understand one of the most basic things. How to get Tomcat to call the servlet directly.

I'm embarrassed but it is better to broadcast my ignorance than to perpetuate it. So here's the issue:

I have an index.jsp file that just calls the servlet. It looks like:



I believe this is unnecessary and I should be able to do the same thing with a properly configured web.xml file and override a method or two. But I can't quite seem to get it to work.
In it's current state if I remove the index.jsp file, deploy and call it. It will call the Viewer class constructor then report a 404 Error requested resource is not available.

Can someone point me to a good web.xml tutorial or point out what is needed to call this class?

Here is the current stab at a web.xml file:


I have overridden the methods service and doGet but neither get called.

I'm in a cleanup, document, harden state on this project. What I have works but I'd like to understand this.

Thanks for reading this.

Joe


 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm lost - where are you calling a servlet? Does "viewer.main()" somehow fire off an HTTP request?
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, I see - Viewer is a servlet. A JSP wouldn't call a servlet - a URL embedded in an HTML page might call a servlet.

If that servlet has functionality that you need to execute from within a JSP, factor it out into its own Java class, and use it as a backing bean.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lastly, you shouldn't override a servlet's service method - override doGet or doPost specifically.
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the quick reply Ulf.

Yes, Viewer is the servlet that handles all the requests.

I am trying to get https://example.com/viewer to call the servlet directly without the index.jsp in the middle.

My problem is the contructor gets called but neither doGet nor doPost method gets called. I was grasping at straws with the service method and it's now gone.

As is probably obvious, I'm confused. I can keep it like it is and not derive Viewer from HttpServlet, I don't think that is significant overhead but I just don't think it's necessary.

Joe
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because there is no context path in your URL, I assume that you have this deployed as the ROOT web app? If not, then the problem is just that you are omitting the context path from the URL.
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:Because there is no context path in your URL, I assume that you have this deployed as the ROOT web app? If not, then the problem is just that you are omitting the context path from the URL.



I think we're getting to the source of my confusion.

request.getContextPath() returns /viewer

There are multiple web apps on this server but Apache is set up as a reverse proxy and calling them using an AJP connector so the ROOT question is less than clear to me.

The relevant apache configuration is



The Shibboleth stuff all happens with 302 redirects before the ProxyPass is invoked. It's actually very cool as we have thousands of users that are authorized and I don't have to do anything to manage them.

I do appreciate the help. It's very hard to ask a good question when I don't understand what it is that I'm missing.

Joe
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Then your URL should likely be:

https://example.com/viewer/viewer

which looks confusing because you gave the context path and the server path the same name. (Don't do that.)

Deconstructed, the URL is:

https://example.com/context-path/servlet-path
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have some reading to do.

I am confused about the difference between context path and server path but you are correct if I keep the configuration I posted and point my browser to https://example.com/viewer/viewer it works.

Thanks for the help. If I figure out what I don't understand. I'll post again.

Best,
Joe

 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joe Areeda wrote:I am confused about the difference between context path and server path


Ooops, my bad. (Or auto-correct's bad). That should have been servlet-path.

context-path -- the path that identifies the web context (app)
servlet-path -- the path that identifies the servlet within the context

The servlet-path for the servlet is what you defined at line 31 of the deployment descriptor.
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I'm starting to understand, but I'm still a ways away from fully comprehending. Some of this may have to do with the way we designed this app.

Would you please poke holes in the follow description of how I see things?

A context element is the name of the web application which is usually the name of the .war file. A context path starts with a slash and may have a directory structure but ends with the name of the war file deployed.

In this discussion a servlet is a class defined in war file (context element) that is derived from HttpServlet and overrides doGet and/or doPost so that it is able to respond to a client (browser) request. For clarity the war file and the servlet class should be named differently, unlike a .jar application where they are named the same (at least by convention in NetBeans 7).

The servlet path is specified in web.xml whereas the context is set when the app is deployed.

To make a servlet the default application for a virtual host (that is what responds to https://example.com/) the web server, in my case Apache is configured in a <Location> element with a ProxyPass directive eg: ProxyPass ajp://localhost:8009/<context-path>/<servlet-path>.

I guess part of the problem is I use a full feature IDE like NetBeans which does a lot of the work and follow recipes I find in helpful forums like this one without spending a boatload of time and effort to understand what's going on under the covers until absolutely f-in necessary. I can't help it that's just the way I was drawn.

Thanks again for helping me work through this.

Joe
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joe Areeda wrote:A context element is the name of the web application which is usually the name of the .war file.


A context is the JEE term for a web application. A war file is only one way to deploy, but yes, when a war file is deployed to webapps (assuming Tomcat), its name becomes the context path.

A context path starts with a slash and may have a directory structure but ends with the name of the war file deployed.


No. No folder structure. The context path is either the empty string (for the ROOT context) or a slash followed by a string. Whether its the name of a war file or not depends upon how it is deployed.

In this discussion a servlet is a class defined in war file (context element) that is derived from HttpServlet and overrides doGet and/or doPost so that it is able to respond to a client (browser) request.


Pretty much true, but incomplete. There may not be a war file. There are more methods than GET and POST.

For clarity the war file and the servlet class should be named differently


A typical web app has much more than one servlet, so yeah, servlets should be named according to what they do, not what app they are in.

unlike a .jar application where they are named the same (at least by convention in NetBeans 7).


I have no idea what that's all about. But whatever it is, it's a Netbeans only thing and don't get invested in it.

The servlet path is specified in web.xml whereas the context is set when the app is deployed.


The servlet paths (plural). There is typically more than a single servlet.

By the way, one way to tell if you're doing something wrong is if the context path is ever hard-coded anywhere in your code. An application should be completely independent of the context path upon which it is deployed. If you need the context path, it should be obtained programatically.

To make a servlet the default application for a virtual host (that is what responds to https://example.com/) the web server


A servlet is not an application. If you are referring to the default action, that is defined by the welcome-file in the deployment descriptor. You can make it the path to a servlet.

I guess part of the problem is I use a full feature IDE like NetBeans


I will not disagree. I use an IDE (IntelliJ) as a fancy editor. I do not run applications in the IDE. I do not let the IDE dictate any of its own agenda. I deploy to a standalone Tomcat instance that knows nothing about the IDE, and vice versa. The code is completely independent of the IDE.

An IDE can be very helpful (I love the refactoring features of IntelliJ), but it can also be a huge impediment to understand how things actually work if overused.
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much Bear!

I'm starting to get it.

After I figure out the welcome-file I may try again to put my understanding in words to find more holes.

As usual, your comments have been very helpful and are much appreciated.

Joe
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This has been a good learning experience but I've come full circle and think using a simple index.jsp to start things is a reasonable way to do this.

I do see now that my main class is not really a servlet and doesn't need to be derived from HttpServlet.

Some of my confusion about the difference between Applications and Servlets comes from an early design decision that this application would have only one action as far as the Container is concerned. The overall flow looks something like:


Looking at the welcome-file documentation at http://wiki.apache.org/tomcat/HowTo (search for default home page) they recommend the default index.jsp use a 302 redirect to the default servlet.

This is problematic because Apache not Tomcat is the web server. Apache uses the ProxyPass directives to Tomcat's AJP connector. That decision was clinched because of Shibboleth support but supported by the fact that I'm a better Apache admin than a Tomcat admin, which ain't sayin much. The site also supports a private Shib protected wiki and some public and private static pages.

So all that leads me to believe that there's little benefit to changing the current implementation. To recap:

To use Shibboleth with Apache we define a Location section in the Virtual Host, plus a whole lot of global configuration to communicate with the Identity Provider, that looks like:



Note: I believe this approach is common to most Single Sign On protocols.

Then the context contains an index.jsp calls what we can call the main command processing class of my application.

Even though the result of this 3 day exercise was to conclude no change is necessary, it has been very beneficial to me. I now understand much better what a servlet is and how they are really used.

I want to thank Bear and Ulf for their patience and experience. Now I just have to find 3 or 4 threads in this forum that I can help with.

Best,

Joe
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I cannot agree as your original implementation employs Java scriptlets in a JSP which have been obsolete for over 12 years.
 
Joe Areeda
Ranch Hand
Posts: 334
2
Netbeans IDE Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bear Bibeault wrote:I cannot agree as your original implementation employs Java scriptlets in a JSP which have been obsolete for over 12 years.



I am certainly open to discussion. This is a learning experience for me and I'm more than willing to refactor this into something better.

I'd like the url to be as short as possible so https://example.com/ is the best I can do.

I suppose I can rename the main class to CommandDispatcher, derive it from HttpServlet, override doGet and doPost (I don't think I need to override the other entry points for now) and use the Apache Location section to connect to Tomcat at /viewer/CommandDispatcher

That would eliminate the almost trivial index.jsp, which is what started this exercise. And thanks to your help, I think now do that.

Perhaps, I was disillusioned by the welcome-file recommendation in the Tomcat documentation. That might have been a red herring because I'm not using Tomcat as the web server.

I'll give it another try. It does seem the JSP is a superfluous and insignificant piece of a separate technology. If it's also obsolete that's another reason not to use it.

I do appreciate the advice.

Joe
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For the welcome file, I've never done anything more complicated than set it to the servlet path of the servlet I want to invoke.

But if you insist on using index.jsp, at least use it to forward or redirect to a servlet, or use some other other conventional means of invoking the Java code other than resorting to poor practices and obsolete technologies such as scriptlets

While doing things that violate best practices, or "going your own way" with non-standard approaches, may seem to work at first, in my experience they invariably come back to bite you in the keester at some later point.
 
reply
    Bookmark Topic Watch Topic
  • New Topic