Develop Reference

How to do a url redirection in Struts1 and Spring

For legacy reasons I need to do a url redirection from an old website to the new one.
For example, this is the old URL:
https://my_old_site/a_section_of_the_website
So when a user types this URL because they think it is still the actual URL, I want to redirect the user to:
https://my_new_site/a_section_of_the_website
I mean, I don't want to redirect to another action, I want to intercept the URL and redirect it to another url. But after searching here, on Google and other sites, I can't figure out how to do it.
I would like to know if there is a way in Struts or Spring to manage the URLs of the application and handle redirects. I don't know if it can be done in the struts.xml or there is another file in Spring in which it performs this task.
Best regards.

Finally, the only thing I have found to achieve this was:
In the Action class of the old URL, as it received HttpServletResponse response as a parameter, I made the redirection there directly and forced a null return since the signature of the method expects an ActionForward.
protected ActionForward doExecute(..., HttpServletResponse response) throws Exception {
...
response.sendRedirect("https://my_new_site/a_section_of_the_website");
return null;
}
I hope this may be of help to someone in the future.

Servlet Parameters vs Attributes

My question is - if I'm using a gatekeeper servlet to forward pages to other servlets, is it better to let the second servlet refer to the parameters or create attributes for them to refer to?
Say I have a form of:
<form action=www.ermehgerdpuppies.com/Gatekeeper id = puppyForm>
<select name=puppyList>
<option value=cutePuppyServlet_12>CutePuppy
<option value=uglyPuppyServlet_14>UglyPuppy
</select></form>
I submit this form which gets to the Gatekeeper servlet:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
if (request.getParameterMap().containsKey("puppyList"))
{
String qString = request.getParameter("puppyList");
String[] qsArray = qString.split("_");
request.setAttribute("merPuppy", qsArray[1]);
RequestDispatcher rd = getServletContext().getRequestDispatcher(qsArray[0]);
rd.forward(request, response);
}
}
Which then goes to the cutePuppyServlet (for this example, it goes to cutePuppy)
Now in my cutePuppyServlet.java, I can either refer to the data this way:
request.getParameter("puppyList");
OR
request.getAttribute("merPuppy");
With parameter, I can check if it exists in order to prevent blowing everything up. My question is, which is better for maintainability? Should I just stick with forwarding the parameter or should I create an attribute?

Advantages of using a parameter for the inner servlet:
The nested servlet can stand on its own without the parent servlet, if need be.
Developers are more aware of parameters (I don't know why, but I rarely see request attributes used)
Less code because the container passes them in from client implicitly.
Advantages of using a request attribute:
Includes, forwards, etc. will include them because the request does not change, though its URL may.
This is what attributes are actually meant for, messaging passing between components. Therefore, you are adhering to the servlet design.
At the end of the day, it's not going to matter much. I would pick attributes because I care more about doing things the standard way (even if it is a standard that nobody cares about or follows) than doing it quickly.

If data is already available as a parameter, and is always accessible in your design (that is: your entire request cycle can access the request parameters), and you see no design benefit in setting it as an attribute, then access it as a parameter and forget about setting it as an attribute.
"Less is more", I guess that's the point I'm trying to get across.

I think that the main differentiation is that the "value" part in the pair in attributes can be a Java Object, whereas with parameters it can only be a String.

servlet doGet and doPost methods [duplicate]

This question already has answers here:
doGet and doPost in Servlets
(5 answers)
Closed 6 years ago.
I want to know that in servlets why we use doGet and doPost methods together in the same program. What is the use of it??
What does the following code means?
Why to call the doGet method from doPost? I am not at all clear about this code.
public class Info extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
doGet(request, response);
}
}
Thanks

doGet() handles incoming HTTP GET requests while doPost() handles... POST requests. There are also equivalent methods to handle PUT, DELTE, etc.
If you submit your form using GET (default), the doGet() will be called. If you submit using POST, doPost() will be invoked this time. If you only implement doPost() but the form will use GET, servlet container will throw an exception.
In many programs the server doesn't care whether the request uses GET or POST, that's why one method simply delegates to another. This is actually a bad practice since these methods are inherently different, but many tutorials write it this way (for better or worse).

Simply, it is to make the servlet generalized so that even if we change the request method in future, it is not required to edit the servlet, which will reduce the efforts to modify the application in future.

This is to handle both requests type eg. GET and POST of http. depending upon app's requirement people may chose to keep request type as GET or POST so incase you are handling both of them you will get error. and in case you want to handle both of them in similar fashion then you can create another method doSomething and call it from your doGet and doPost methods for more info see this answer

Isn't it to do with a get request allows the parameters to be seen in the URL in the browser window and the post request incorporation the parameters into the structure of the request and hence hidden from view. How will your request be made from the client as a get or a post. I think it is something to do with security and avoiding sql injections, but it is not my area really. Hopefully, some expert with correct my view/comment as I need to know this myself.

As you noted here you can indeed call a third method but you also can override the service() method from the HttpServlet motherclass so that it calls alawys one unique method.

How to use context.getNamedDispatcher with the Guice Servlet Extension

I am trying migrate a servlet-project to use Guice 3.0-rc2 (from maven central) and its servlet extension. I already migrated another project where I had the same problem:
Since Guice renders the web.xml basically useless, I have no idea where to define my servlets names. The codebase makes quite heavy use of ServletContext#getNamedDispatcher("name") and I would like to change as little as possible. The first codebase used getNamedDispatcher only once, so I was able work around that.
The Servlets in question are not listening to any path, so using getRequesetDispatcher won't do.
Does anyone have any suggestions?

One of the big things Guice tries to do is move away from using unreliable String identifiers to using actual Java types to do things. While guice-servlet managed servlets do have names (the toString() of the Key they are bound as), I don't think the ServletContext is aware of them.
One option that may work for you is to actually inject the servlet(s) you want to be able to pass requests to and do it directly yourself:
#Singleton
public class TestServlet extends HttpServlet {
private final TestServlet2 testServlet2;
#Inject public TestServlet(TestServlet2 testServlet2) {
this.testServlet2 = testServlet2;
}
#Override
protected void doGet(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws ServletException, IOException {
testServlet2.doGet(httpServletRequest, httpServletResponse);
}
}
For this to work, you do need to register the servlets in your ServletModule... I think you can serve("").with(TestServlet2.class) in order to not have it map to any URL.

Implementing Authentication for a WebDAV Servlet

I am currently using this WebDAV Java Servlet Implementation, it's as far as I know the smallest and the easiest to use WebDAV java solution that doesn't depend on Tomcat ( Using WebLogic ).
So I would like to extend this to use my underlying security layer which somewhat uses a database connection to authenticate users.
My question is if this is possible? Does the HttpServletRequest even get the Authentication?
Consider the following method header:
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { }
Now I would like to use req.getPrincipal to get the User Principal containing the Username and Password. However, my getPrincipal always returns null even if I set my WebDAV client to Windows Authentication or anything else for that matter.

If you are using your own authentication layer, you need to inject your authentication information to the ServletRequest. This is normally done through a filter and wrapped HttpServletRequest.
You can find a good example in CAS,
http://www.jasig.org/cas
Download the source and look at this class,
org.jasig.cas.client.web.filter.HttpServletRequestWrapperFilter