aspose file tools*
The moose likes JSP and the fly likes http status 500 error Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "http status 500 error" Watch "http status 500 error" New topic
Author

http status 500 error

torina mascarenhas
Greenhorn

Joined: Mar 13, 2006
Posts: 3
thanks Paul and Charles for your solutions to my problem.It works.Charles your detailed corrections helped me a great deal.
Torina
[ March 14, 2006: Message edited by: torina mascarenhas ]
kalatta kalatta
Greenhorn

Joined: Mar 14, 2006
Posts: 2
you are setting the value of custID field in Stock.java to String "myCustID". But the custId field is of type int so it is unable to set the string value to a int field hence the exception.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61426
    
  67

"kalatta kalatta",

There aren't many rules that you need to worry about here on the Ranch, but one that we take very seriously regards the use of proper names. Please take a look at the JavaRanch Naming Policy and adjust your display name to match it.

In particular, your display name must be a first and a last name separated by a space character, and must not be obviously fictitious.

Thanks!
bear
JavaRanch Sheriff


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
torina mascarenhas
Greenhorn

Joined: Mar 13, 2006
Posts: 3
thanks for replying
But even if i have a constructor in my Stock.java that takes in String custId and parses it to an int it still does not work as you see in the lines of code that i commented out.
Cannot change the data type of my field custID as that is one of the specifications of the program
Any more suggestions are welcome.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

I guess that you accidentally set the value of that property to the string "myCustID" when you really wanted to use the value of the scripting variable myCustID? If so, I think you would do this:I am no JSTL expert but I do recognize this error, having made it frequently myself.
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
Paul's absolutely right - the 'value' attribute of <jsp:setProperty> should resolve the actual value you require there (which will be type converted to int if necessary). In case this helps, the clue is in the stack trace, where (a) all errors relate to JSP pages (so it was unlikely that your bean class was doing it, and a static HTML page certainly won't) and (b) the presence of the NumberFormatException 'for input string "myCustID"'.

Having said that, I have other issues with your code which will prevent it from working as intended:

(1) You've got malformed (X)HTML in there, where you write <head>s inside of <body>s and also nest <body>s within one another. I've tried to tidy it up below.

It also wasn't valid XML - if you were writing a JSP Document this would be a big issue. If you're writing a JSP page, it isn't so bad, but to be clear, I've wrapped all malformed (piecewise) XML into <jsp:text> and CDATA sections.

(2) Your test on "numShares" is incorrect, or at best misleading. You write:

<c:when test="numShares > 1000">
...
<c:when test="numShares <= 1000">

But there is no variable "numShares" that I can see; you're either trying to reference the bean property called "numShares" (i.e. the getNumShares() accessor), in which case you need to access that property on the Stock object, or the "myNumShares" page-scoped scripting variable you created earlier using <c:set>.

Either way, the above won't work because you forgot the EL expression or JSP scripting expression delimiters; using EL you should have written:

<c:when test="${ myNumShares > 1000 }">
...
<c:when test="${ myNumShares <= 1000 }">

Personally, I would be tempted to avoid the page-scoped scripting variables altogether, and just write:

<c:when test="${ !(empty param.numShares) and param.numShares > 1000 }">
...
<c:when test="${ !(empty param.numShares) and param.numShares le 1000 }">

which to me is a lot cleaner. Notice that I've used "le" as the <= operator and "and" for &&, just because if you try to port this over to a JSP Document, the < and & characters are illegal as character entities on their own (so I always stick to using "le"/"and" to avoid the confusion).

---

NOTE: The default coersion rules for EL state that if a variable, such as the param.numShares, is 'null' or empty, the value 0 will be returned. I could therefore have written the first statement (but not the second) as just:

<c:when test="${ param.numShares > 1000 }">

---

If you don't want to use EL, the equivalent will work using JSP scripting elements, but will be a lot messier.

(3) You don't actually seem to make any other use of the "myStockName", "myCustID" and "myValueEach" variables declared using <c:set>, so are these declarations necessary (they seem to be taking up space and making the code more difficult to follow, with no real reason)?

You could simply miss out this stage, and just wrap the <jsp:setProperty> bits in <c:if>s.

Even better, since you are extracting the data from request parameters, make use of the <jsp:setProperty>'s special "param" attribute, which will do all the extracting for you, without the need for EL and if blocks/tests. Your whole code can be condensed very nicely...

So making all those changes, I've come up with the following code:

NOTE: I've replaced your isELIgnored="true" with ="false" just because I prefer EL to JSP scripting elements; if you want to replace all my EL (where valid) with scripting elements, please feel free to do so.

NOTE 2: I've replaced the URI of your JSTL Core tag library with the v1.1 edition to make use of the container's EL processor. If you don't have JSTL 1.1 on your machine, but your container is JSP 2.0 compliant, you should use the RT version of the 1.0 library for EL or scripting element support. If your container is not JSP 2.0 compliant, you should use the RT 1.0 library for scripting element support, and the non-RT library for EL support (this is all very confusing, but summarised very nicely in a table in my book!)



That seems much more elegant to me - but if I've many any mistakes/typos please feel free to correct me. I haven't actually deployed and tested this page, so something might still go wrong! If it does, or you have any further questions, please post again!


Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: http status 500 error