Ajax call to servlet and JQeury not linking to HTML

I made a mistake in the ajax function where error, function should be error: function. So the ajax call is now being made but it is not retrieving a success but rather an error meaning there is a problem connecting to the servlet right?

Status code is 302:

Request URL: http://localhost:8080/FYP/LoginServlet
Request Method: POST
Status Code: 302
Remote Address: [::1]:8080
Referrer Policy: no-referrer-when-downgrade
Content-Length: 0
Content-Type: text/plain
Date: Sat, 26 Jan 2019 19:43:17 GMT
Location: errorpage.html
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 29
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: JSESSIONID=1718F2C8BE3C15AC348392C030DE5781
Host: localhost:8080
Origin: http://localhost:8080
Referer: http://localhost:8080/FYP/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
X-Requested-With: XMLHttpRequest
method: personal
username:
pw:

Status code is 302:

Request URL: http://localhost:8080/FYP/LoginServlet
Request Method: POST
Status Code: 302
Remote Address: [::1]:8080
Referrer Policy: no-referrer-when-downgrade
Content-Length: 0
Content-Type: text/plain
Date: Sat, 26 Jan 2019 19:43:17 GMT
Location: errorpage.html
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 29
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: JSESSIONID=1718F2C8BE3C15AC348392C030DE5781
Host: localhost:8080
Origin: http://localhost:8080
Referer: http://localhost:8080/FYP/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
X-Requested-With: XMLHttpRequest
method: personal
username:
pw:

I updated the servlet link in the ajax function to the full link as the servlet was in a src file so in ajax function url is /src/controller/LoginServlet. When I tested this the console log was:
jquery.min.js:5 POST http://localhost:8080/src/controller/LoginServlet 404
send @ jquery.min.js:5
ajax @ jquery.min.js:5
(anonymous) @ custom.js:46
dispatch @ jquery.min.js:3
v.handle @ jquery.min.js:3
custom.js:64 Uncaught ReferenceError: data is not defined
at Object.error (custom.js:64)
at c (jquery.min.js:3)
at Object.fireWith [as rejectWith] (jquery.min.js:3)
at k (jquery.min.js:5)
at XMLHttpRequest.r (jquery.min.js:5)
error @ custom.js:64
c @ jquery.min.js:3
fireWith @ jquery.min.js:3
k @ jquery.min.js:5
r @ jquery.min.js:5
XMLHttpRequest.send (async)
send @ jquery.min.js:5
ajax @ jquery.min.js:5
(anonymous) @ custom.js:46
dispatch @ jquery.min.js:3
v.handle @ jquery.min.js:3
jquery.min.js:5 XHR failed loading: POST "http://localhost:8080/src/controller/LoginServlet".

302 is a 'success' code which would normally cause the browser to redirect to whichever URL is at the 'Location', which is 'errorpage.html'

So the request is certainly reaching tomcat, but the server might be hiding the error? Do you have something set up in your tomcat configuration which is picking up the real status code and converting it into a 302 to errorpage.html? Worth checking the configuration to make sure that isn't happening so that you can see what the real error is.


https://stackoverflow.com/questions/199099/how-to-manage-a-redirect-request-after-a-jquery-ajax-call

if 302 is a success code and in my servlet I have put the errorpage link correctly, why is it showing up with an error in the console and not taking me to the new errorpage.html webpage?

In regards to tomcat server settings, I have never modified this and don't really know what to be looking at.

Do you have a web.xml somewhere in your project? (maybe in a WEB-INF folder?) If so, does it have anything which looks like this?

<error-page>
<error-code>500</error-code>
<location>errorpage.html</location>
</error-page>



The reason the browser isn't redirecting is that the browser didn't send the request in the first place, instead the request has come from the JavaScript, so the browser won't handle the response either.

I have web.xml in web-inf folder but the error page code you posted above is not in the web.xml file.

Also you said the browser didn't send the initial request javascript did so whatever the response is the browser wont display it as it didnt send the response. That sounds a tad confusing, how can I correct this then?

Are there any error codes in the web.xml file at all though? e.g. 400, 401, 404, etc.

The error codes could be any number in the range 400-599, but you won't know which until you take all of them out and get rid of the redirect altogether - once you find the real error it should be easier to debug it properly.


What I mean by the browser not sending the request is that it's the browser's built-in JavaScript scripting engine sending the request rather than the main web browser itself - when the scripting engine gets the response, it's entirely up to your code in terms of what it's actually doing.

The thing is that you don't want to handle it at all, you need it gone because a generic "errorpage.html" isn't going to help you actually debug the error. (You could put it back later after you've fixed the problem, but this sort of thing isn't helpful when writing code)

There are no error codes at all in the web.xml file under web-inf. In regards to everything else you said, I somewhat understand it but I’m new to web development in Java. Although I have done java programming before, I’m still quite new to this.

I’m just trying to run a simple banking app. I’ve got my index.html file linked to a JS file with an ajax function linked to a LoginServlet. This then redirect the webpage to another html webpage such as errorpage.

Atm the problem is the ajax code not linking to the servlet/servlet not linking to error page. I’ve followed so many tutorials it’s as though something just isn’t clicking for me.

Web development with java is definitely a lot more complex than just building a plain Java forms app - there are a lot more moving parts for handling the HTTP requests and responses between the browser and the servlet (particularly around the tomcat 'container' which runs the servlet).
There's some good background reading here to help understand what's actually happening with HTTP requests and the tomcat containers, although this page is from 2002 so don't look at the code here as a good example of how to do things because that'll be misleading: https://www.developer.com/java/ent/article.php/2178651/Understanding-Servlets.htm


I can't see anything in the LoginServlet which is redirecting to errorpage.html - is that something you've added? If not, then it suggests to me that tomcat is handling an error and swallowing it up, which makes it hard to find out what the 'real' error is. The redirects I can see in the servlet seem to be for cus_profile.jsp and bus_profile.jsp instead.

If this is happening, then it could be a combination of many things and the best thing to do is to cut out some of the noise and try to rule out different problems - the first thing is to make sure that tomcat isn't doing anything like swallowing real errors - there's 2 different ways you could do that:

One way would be to try using plain HTML to send your login data like this and let the browser send the POST request instead - that way the browser will also handle the 302 redirect

<form action="LoginServlet" method="post">
Method: <br/> <input type="text" name="method"> <br/>
Username: <br/> <input type="text" name="username"> <br/>
Password: <br/> <input type="password" name="pw"> <br/>
<input type="submit" value="login">
</form>

If you do this, then you'll probably go back to the 404 error ("Not found") for errorpage.html that you had earlier - which might just be that there's no errorpage.html in your WebContent folder?


The other way would be to try this out using Postman, which I definitely recommend using so that you can test your servlet on its own - https://www.getpostman.com/


If the above both work then that rules out problems with either tomcat or the servlet

I will try this in a few hours and get back to you. In the mean time do you know anything about JNDI?
I wa wondering Can I seperate the app logic in multiple servlets eg one for login controller one for accounts controller etc and how would this affect my connection pooling?

I have seen tutorials where the init method to initialise context and env context to get jdni datasource is at the beginning of a servlet. But what about if i have multiple servlets, do they all do the init method? If so that seems repetitive is there no way to abstract it and call a connection from a datasource from any servlet within the same project?

I'm not too familiar with JNDI to be honest, but there's nothing special about Servlet Controller classes to prevent you from creating the Datasource in another shared class. Also no reason why you need to have any database connection code in the Servlet Controller either.

It sounds like the examples you've seen are showing a few bad 'habits' putting database logic inside a Servlet controller rather than separating them out (to avoid copy-paste repetition, also separation of concerns - the Servlet Controllers are already doing enough by handling the HTTP request/responses/errors without having to care about database connections too.

You could move all the datasource/connection/database logic verbatim from the LoginServlet into another class, basically following the repository pattern -- https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/. This way, the same Database can be reused in multiple servlets, for example, an AccountRepository which is used by the LoginServlet and the AccountsServlet and maybe others.

Using the repository pattern means you'd put database queries there too so they would have classes like this which encapsulate anything to do with data sources or connections:

public class AccountRepository {
public ArrayList<Account> getAll() { /* ... */ }
public Account getAccount(int accountNumber) { /* ... */ }
public int createAccount(Account newAccount) { /* ... */ }
public Account updateAccount(Account updatedAccount) { /* ... */ }
public void deleteAccount(int accountNumber) { /* ... */ }
}

Also, if you ended up splitting your repositories up for different kinds of objects (e.g. one for Accounts, one for Customers, etc.), you might even have a 'BaseRepository' which has the common logic for creating a DataSource, then derive AccountRepository and CustomerRepository classes from that.

There's always ways to split logic away from servlets anyway - hopefully it means that your Servlets will have much simpler methods like this instead:

public class AccountsServlet extends HttpServlet {
private static final AccountRepository accountRepository = new AccountRepository();
private static final CustomerRepository customerRepository = new CustomerRepository();

@Override
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// TODO -- do something with accountRepository and/or customerRepository
}
}


I'm not too familiar with JNDI to be honest, but there's nothing special about Servlet Controller classes to prevent you from creating the Datasource in another shared class. Also no reason why you need to have any database connection code in the Servlet Controller either.

It sounds like the examples you've seen are showing a few bad 'habits' putting database logic inside a Servlet controller rather than separating them out (to avoid copy-paste repetition, also separation of concerns - the Servlet Controllers are already doing enough by handling the HTTP request/responses/errors without having to care about database connections too.

You could move all the datasource/connection/database logic verbatim from the LoginServlet into another class, basically following the repository pattern -- https://thinkinginobjects.com/2012/08/26/dont-use-dao-use-repository/. This way, the same Database can be reused in multiple servlets, for example, an AccountRepository which is used by the LoginServlet and the AccountsServlet and maybe others.

Using the repository pattern means you'd put database queries there too so they would have classes like this which encapsulate anything to do with data sources or connections:

public class AccountRepository {
public ArrayList<Account> getAll() { /* ... */ }
public Account getAccount(int accountNumber) { /* ... */ }
public int createAccount(Account newAccount) { /* ... */ }
public Account updateAccount(Account updatedAccount) { /* ... */ }
public void deleteAccount(int accountNumber) { /* ... */ }
}

Also, if you ended up splitting your repositories up for different kinds of objects (e.g. one for Accounts, one for Customers, etc.), you might even have a 'BaseRepository' which has the common logic for creating a DataSource, then derive AccountRepository and CustomerRepository classes from that.

There's always ways to split logic away from servlets anyway - hopefully it means that your Servlets will have much simpler methods like this instead:

public class AccountsServlet extends HttpServlet {
private static final AccountRepository accountRepository = new AccountRepository();
private static final CustomerRepository customerRepository = new CustomerRepository();

@Override
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// TODO -- do something with accountRepository and/or customerRepository
}
}


I read the link and I didn’t really understand it so I started researching What is repo pattern and dao v repo but just got confused even more. Would you be able to explain it in the context of my application?
I wasn’t really going to follow a method but thinking about it, it resembled the dao pattern.

I was basically going to have js ajax call (with a parameter METHOD) to login servlet which reads query and has cases eg

Case:
Method 1 // someMethod(“”)
Method 2 // “”

Inside the method, an object would be created eg an acc obj containing name bal acc no etc. a seperate java class accObj will have the aforementioned fields. In this method (called by case in loginservlet) will contain the dbconnection save relavant parameters in accObj fields and return to the servlet only the requested fields.

What do you suggest?