• 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

Servlet "freezes" up without parameters

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would like to thank everyone who participates in this forum. This has been an extremely valuable resource for me and many others. I look forward to one day contributing suggestions and comments as I become more knowledgeable.
Here's my recent challenge:
I have a servlet (AddAdminServlet) who's context path is "/addtool". This servlet is the heart of my application. ALL requests are sent to this servlet and it determines the actions to take and the next page to display. Under normal conditions, if the servlet was invoked WITHOUT sending any parameters (via the URL or a submitted from), the servlet would set the appropriate variables and the user would end up at the designated "welcome page" (see code below).
Here was the dilemma: I've recently added functionality for my application to handle MultipartRequest (for file uploading). I discovered, rather quickly, that when submitting MultipartRequest there was no straightforward way of "grabbing" the parameters which were submitted with the form, even though they were present (e.g. req.getParameter("cmd") would return a null value). I realized that I would have to parse the request to find the desired values. I wrote the code to do all of my parsing, access the database, create the entries, handle the errors, etc. It works fine (I was kinda proud of myself!). BTW, that servlet was being tested having its own context path, say, "/dopost", for example.
I didn't want it in its own context path because I wanted to call it from the heart of the application, AddAdminServlet. I made the necessary changes and integrated the DoPost into the rest of the application.
Now, my reasoning was, when the AddAdminServlet receives a request where the parameter value "cmd" is null ( req.getParameter("cmd") ) it must be a MultipartRequest, call DoPost, if a file is not present or the desired format, or any other non-desirable scenario let DoPost set the appropriate variable and return the user to the "welcome page".
Here's the PROBLEM: When firing up my test environment for the first time (TomCat 3.2) and entering "http://localhost:8080/addtool", the page just sits there displaying "Opening page at http://localhost:8080/addtool ..." for an INDEFINITE period of time.
The application now only works if I enter: "http://localhost:8080/addtool/?cmd=main-menu" which accesses the "welcome page". Once I've accessed that page, I can navigate fine. Functionality returns to normal, including file uploading (MultipartRequest), etc. Wonderful.
The goal with this application was to have "http://localhost:8080/addtool" in the URL at all times. This was achievable until I recently directed DoPost to handle all null "cmd" values.
I must add that once I am "in" the application, entering "http://localhost:8080/addtool" in the URL and pressing "enter" goes back to "Opening page at http://localhost:8080/addtool ..." for an INDEFINITE period of time.
It appears to me that my DoPost can only handle legitimate MultipartRequest and "freezes up" when it receives a URL without ANY parameters?
Any thoughts?

HERE IS THE AddAdminServlet CODE:

HERE IS THE DoPost CODE (ONLY FOR REFERENCE!):
 
Darrell Henry
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd like to make it easier on you kind folks out there. I'll attempt to simplify my question. I guess I see so many posts lacking info, maybe I overdid it.
Here's the "cliff notes" version:
What exactly does the HttpServletRequest actually see when absolutely nothing is submitted via the URL as opposed to when parameter values, etc. are submitted?
My "director" servlet tests for two conditions (handles all requests):
1. A valid value returned from a "cmd" parameter: req.getParameter("cmd")
If it returns something, it performs the necessary functions
2. A "null" "cmd" value. Indicating that a form was submitted via MultipartRequest or the user pressed enter at the URL without any parameters (parsing is necessary).
In either case (in 2 above), there's only one class that parses until it finds the appropriate "cmd" value, then responds. However, if the user just presses "enter" at the URL with no values, the class that handles the MultipartRequest should see that "cmd" never existed and should simply take the user back to the "welcome page". Instead, it just sits there displaying "Opening page at http://localhost:8080/addtool ..." for an INDEFINITE period of time.
Otherwise, it works properly when a true form is submitted with an attachment.
Thanks, again.
- Darrell
 
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well Darrell,

I gotta hand it to you, that's a heck of a chunk of code you wrote.

I've never seen anything quite like it.. (ie: "what's a command?")

Anyways.. the problem is maybe related to your overriding the service method? In the API it says :

Part of the problem of writing code in the service method is that you don't know yet if the request is post'ed or get'ed, if you'll forgive my use of English. the provided impl of service will shuffle off these two request types to the two doXXX methods, and so that's how you can determine a file upload request. If you are doing a multi-part request, you are definately posting. So in the doPost method, you'd immediately call your multipart request processing, and THEN examine the post for your 'cmd' parameter.

Does that make sense?
 
Darrell Henry
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mike Curwen:
[B]Well Darrell,

I gotta hand it to you, that's a heck of a chunk of code you wrote.

I've never seen anything quite like it.. (ie: "what's a command?")

Anyways.. the problem is maybe related to your overriding the service method? In the API it says :

Part of the problem of writing code in the service method is that you don't know yet if the request is post'ed or get'ed, if you'll forgive my use of English. the provided impl of service will shuffle off these two request types to the two doXXX methods, and so that's how you can determine a file upload request. If you are doing a multi-part request, you are definately posting. So in the doPost method, you'd immediately call your multipart request processing, and THEN examine the post for your 'cmd' parameter.

Does that make sense?[/B]



Made a TON of sense! Thanks so much! You helped me solve my problem. The key was, as you stated, "maybe related to your overriding the service method". Here is what I ended up doing:
Used both the doGet and doPost classes instead of the service class. I have the doXXX call their own respective functions. This works fine, because the application is driven by "posting" forms. If a "get" request is submitted, most likely it should be directed back to the default, welcome page. I still need to tweak this for the exceptional cases. I can probably clean this up a little better, but, at least I'm on track now.
BTW, a "command" is an interface used throughout the application:


Here are the changes I made:


Thanks Mike. I appreciate your assistance.
- Darrell
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic