I've got quite a few people testing my site while im developing it and they have told me everything runs quick and bug-free.
Tim Moores wrote:Concurrency issues are unlikely to be found by manual testing. Deploying a web app that has lingering concurrency bugs, and hoping for the best, is bad practice.
Dave Tolls wrote:Looking at the bit of code supplied:
There doesn't seem to be any reason at all for this to be an attribute of the servlet.
I would question why this servlet seems to be doing more than one thing.
Why not have a LogoutServlet to handle the logging out?
If nothing else it would save having to have a logout-specific parameter to indicate what it is you want to do with a particular request.
Dave Tolls wrote:Looking at the bit of code supplied:
Why not have a LogoutServlet to handle the logging out?
If nothing else it would save having to have a logout-specific parameter to indicate what it is you want to do with a particular request.
Michael Portman wrote:
because the nwg object gets forwarded to index.jsp within the request object, so index,jsp can access it's methods.
Dave Tolls wrote:Thousand line servlets are often a sign you're doing too much in a single place.
Dave Tolls wrote:
Michael Portman wrote:
because the nwg object gets forwarded to index.jsp within the request object, so index,jsp can access it's methods.
But that doesn't explain why it's an attribute of the servlet.
Adding it to the request makes it available to the JSP, but that doesn't mean it can't be a local variable.
Good that you got the logout to work!
Thousand line servlets are often a sign you're doing too much in a single place.
Bear Bibeault wrote:500 lines is still way too much code, especially for a servlet. Servlets should serve as controllers. As such, they're pretty relegated to coordinating code written in other classes (such as model classes) rather than doing work themselves.
Michael Portman wrote: If I didn't forward the nwg object to the index.jsp page by setting it as a request attribute then how would index.jsp get access to the nwg object?
Dave Tolls wrote:
Michael Portman wrote: If I didn't forward the nwg object to the index.jsp page by setting it as a request attribute then how would index.jsp get access to the nwg object?
I'm not saying don't add it to the request, but:
this line implies that your servlet looks something like:
Now that attribute in line 2 is not needed there.
I don't see anything that means the earlier line couldn't simply be:
removing the need for the attribute.
The key to remember, especially as you are new to Java (and consequently Servlets) is to try and avoid giving them "state". That is, avoid giving them attributes.
They operate in a multi-threaded environment, so lots of users can be hitting the servlet at the exact same time, meaning that any non-final mutable attribute (eg nwg in your code) can be changed between one thread and another.
To take your code in the original post, if two requests hit that code at the same time then user A would set the value of nwg to its value, and user B can then come along an set it to its value, before user A's thread has moved onto the forward.
So you can end up with the wrong value.
Dave Tolls wrote:You need to think in terms of HTTP.
A request to your servlet is one of GET/POST/PUT/PATCH/DELETE.
You define which.
Which one it is determines which of doPost, doGet, doPatch, doPut, or doDelete is called.
Each one should handle tasks related to what it is.
So a GET should handle requests for data.
A POST should handle sending data to the server to be processed.
etc.
There's nothing to stop you mixing these things together, but that will end up with a confusing mess.
The service() method really should not be used.
Don't get me started about those stupid light bulbs. |