First of all, something like MVC is all about separation of concerns. You have different components handling different things, which has some advantages like maintainability, extensibility, reusability, less code duplication, etc.
You already mentioned a GUI Controller and an Application Controller. That's separation of concerns right there. You now have one component handling presentation logic, and one component handling application logic.
You are asking about a GUI controller. Depending on how big or small your application is, you might build this using servlets, plain Java classes, or web frameworks like Struts or SpringMVC.
The standard for implementing Java classes that respond to requests is the servlet, so you can write your GUI controller with servlets. You can find a mini example of implementing MVC with servlets here. The purpose would be to handle requests received from the user, extract parameters from the request, send that data to the application controller who implements your use case, which the returns the result, which your servlet will then use to build data for your JSP pages, select one of the JSP pages for execution, and handle control to it to build the response.
To send data to the JSP, the servlet will use a RequestDispatcher and usually request attributes.
You can also create the GUI controller with a simple java class, but you would still need a servlet as an entry point that will then delegate control to your Java classes to handle the requests. As a matter of fact, that's how various web frameworks work: they register a dispatcher servlet that gets the requests and delegates to the framework classes to be handled.
You can implement this presentation controller in any matter of ways, just remember the part about separation of concerns. Things like HttpServletRequest, HttpServletRequest, RequestDispatcher, or JSP paths should not leak into your Application Controller or deeper into your model classes as that is not something they should concern themselves with.
