Jon writes:
> Please take a look at the following "skeleton code":

     Thanks for saving me time, but next time I recommend you append the
full code for reference.  I suspect that's where the problem lies here.

> public void doPost(HttpServletRequest request, HttpServletResponse response)
>     throws ServletException, IOException {
>     String requestedPage = request.getParameter("id");
>     if (requestedPage.equalsIgnoreCase("welcome")) {
>            ( puts up a HTML form with two text fields
>              and two buttons (SUBMIT / RESET)
>              with the form action set to Servlet?id=login )
>     }
>     if (requestedPage.equalsIgnoreCase("login")) {
>       ( Performs some login authentication stuff and
>         presents the result to the user )
>     }
>   } // end doGet

     If your first comment here (id=welcome) is literally true and
you're writing the "<FORM ACTION=" as you say, that's probably the
problem.  Your <FORM> should look something very much like:

<FORM METHOD=GET ACTION=http://yourserver.yourdomain.com:8080/Servlet>
<INPUT TYPE=TEXT NAME=ID>
<INPUT TYPE=SUBMIT>
</FORM>

> Okay, so what's my problem then? Well, when I type
> http://localhost:8080/Servlet?id=welcome
> or
> http://localhost:8080/Servlet?id=login
> it works like a charm.
>
> However, if I press the SUBMIT button, the form loads
> "Servlet?id=login" for sure, but then I get a 500 error
> from the server with a "reported exception:
> java.lang.NullPointerException."

     For testing purposes, you can just type the whole URL string into
the browser's Location: box, as you indicate below, complete with
arguments.  But in the form tag you point the form at only the
domain/servlet and leave arguments for the browser to construct from
the INPUT tags.

     There's a lot I like about Java - but there are things that
really bug me, like the usability aspects of the API.  One aspect is
that you always have to check the return values from the parameters.
I usually set up some boilerplate code that includes a
"checkParameter(String paramName)" method, which basically does
getParameter() and checks to make sure it's not null, and non-blank
(which in the CGI world is always a possibility) and returns
true/false.  I have some similar methods for cookies, but I think they
made things a bit simpler in the 2.3 servlet spec.

> What's the difference between loading the page "manually" from the
> browser compared to the same page being loaded from a form action?

     For a GET-style request, nothing.  I strongly suggest you dig
up a simple HTTP proxy that will log what's going on for you, install
it on your browser machine, point your browser at it, and watch the
different messages going back and forth.  It's a very instructive
experience, not to mention being a heck of a lot easier to debug.  I
used to use a freeware package called HttpProxySpy for this, with the
intent of eventually finding an open-source Java proxy and tweaking
it.  HttpProxySpy apparently is shareware now, so I guess I'lll have
to get my own version.

> I suppose that one difference is of course that in the latter case,
> the parameters from the form gets sent along with the request, but
> what's the cause of the exception?

     In both cases they get sent along with the request.  For a
GET-style request the entire URL is sent pretty much as you see it in
the "Location:" box and the servlet engine parses the URL apart and
puts it into the HttpRequest object.  A POST-style request is sent in
very much the same fashion, except that the arguments are sent on a
separate line (and can be much longer - many separate lines) from the
request line.  Get the proxy and see for yourself.

Steven J. Owens
[EMAIL PROTECTED]

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to