Rajkishore Pujari

Ranch Hand
+ Follow
since Sep 03, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rajkishore Pujari

Thanks to Ivan A Krizsan for his excellent study material and providing references in each topic, and Mikalai Zaikin for Quiz. Both helped a lot.

Thank you all ranchers.

Fellow test takers, work hard and good luck.


Regards,
Rajkishore.

Ravi C Kota wrote:

Rajkishore Pujari wrote:http://www.infoq.com/minibooks/emag-03-2010-rest. Read the free book available in PDF.



Thank you sir.



Have fun...
what is the role of the .src file?.

Here is how you can do it

In the servlet,
  • read the countries collection from database and store in collection variable.
  • add the collection variable in the request as an attribute.
  • forward the request to a JSP

  • In the JSP
  • use JSTL tag c:foreach to loop through the collection
  • and in the loop for each iteration create an OPTION HTML element with code and value.


  • 13 years ago
    Okay I guess I took the wrong path to explain.

    - I don't think you can force all requests to go through FrontControllerServlet first based on your current URL mappings

    Here is how URL/Servlet mapping works in order

    1. If the request URL matches one of the exact mapping, that exact mapping is used
    (example /success/DisplayHtmlAndReadData will go to DisplayHtmlAndReadData servlet directly, and will not
    go through FrontControllerServlet first)
    2. If there is no exact match, container will choose the longest path match
    3. If there is no longest path match, it will check for extension(*.jsp) match.
    4. If there is no extension match, it will use default mapping used.
    5. If none found, error is thrown


    So I am not sure why it is going into infinite loop for you. Once you login successfully, it will never go to FrontControllerServlet
    and instead goes HomePage and then DisplayHtmlAndReadData

    If you want all requests to go through FrontControllerServlet, you will have to map only FrontControllerServlet in your web.xml
    13 years ago
    And regarding Front Controller Vs Intercepting Filter


    Front Controller:

    In any web application, you would either

  • request a resource
  • or
  • submit a form/ an action


  • Whenever a servlet processes a request, here are the most common things it does
  • convert request parameters from String to appropriate data type you need
  • validate request parameters, so it has to invoke appropriate validator
  • create a java bean from request parameters if needed
  • Invoke appropriate business logic handler
  • handle exceptions and redirect to error pages
  • dispatch to appropriate view


  • There are several other things that are done, but I listed only simple ones.

    So if you don't have Front Controller, you would be duplicating several lines of code in all your servlets. For example in all your servlet you call getRequestDispatcher and the only difference is view name that you are forwarding to.

    And if Front Controller does all that for you with some configuration files, then you will only be worried about business logic, not all this request handling stuff.


    You can check how ActionServlet in Struts Framework or DispatcherServlet in SpringFramework works. Both of these implement Front Controller design pattern.

    Intercepting Filter
    Intercepting filter is useful when you have some pluggable feature which also applies several things (cross-cutting concern).

    Lets say you want the authentication feature now and some time later you don't want it. If you implement this feature in Front Controller, you will have to modify the code, where as if you have it as filter, you will just change the configuration so that filter won't get invoked and no code changes. You can reapply it if you want that later. But with Front Controller, you have to re-code again.

    I hope I answered your question.
    13 years ago
  • I see that you are checking for session.getAttribute("LoggedInUser") if session!= null, where are you setting that attribute.
  • In web.xml you have URL mapping /success/LoginServlet that is mapping to DisplayHtmlAndReadData servlet. That is not correct. or at least that may not work




  • 13 years ago
    Are you planning to make a server call when you click on delete? You can actually disable and hide them using Javascript when you click on delete and when you save the form, the disabled (which are also hidden in this case) checkbox values will not be sent to server and you will have only uncheked checkboxes.
    13 years ago
    JSP
    Seems like you are doing it right. One small thing though, you do not have to call newInstance after Class.forName.
    Here are couple of links that may be helpful for you

    http://jtds.sourceforge.net/faq.html#noSuitableDriver
    http://www.javacamp.org/moreclasses/jdbc/jdbc.html

    sekar bala wrote:This is the tag details

    <jsp-property-group>
    <url-pattern>*.jsp</url-pattern>
    <el-enabled>true</el-enabled>
    </jsp-property-group>



    Is it under jsp-config

    look at the sample snippet here. http://www.oracle.com/technology/sample_code/tech/java/codesnippet/jsps/jspconfig/web.xml.html
    13 years ago
    JSP

    Prabhakar Reddy Bokka wrote:

    Rajkishore Pujari wrote:http://download-llnw.oracle.com/javaee/5/api/javax/servlet/ServletContext.html#getContext%28java.lang.String%29



    This never works for accessing resources of other web application.
    ServletContext.getRequestDispatcher(java.lang.String) the path must start with '/' (no scope of keeping a URL). So, the resource should always be local to that context root. No options to access different context even if other web application is deployed in same server/ web container.

    ServletRequest.getRequestDispatcher(java.lang.String)
    The pathname specified may be relative, although it cannot extend outside the current servlet context.
    Again the resource should be within the context.

    David O'Meara wrote:How about showing what you tried.



    Hope that makes sence.



    Please read this statement under link I have given before. Have you tried doing this.

    "This method allows servlets to gain access to the context for various parts of the server, and as needed obtain RequestDispatcher objects from the context. The given path must be begin with "/", is interpreted relative to the server's document root and is matched against the context roots of other web applications hosted on this container".

    servletContext.getContext("/someOtherWebappContext").getRequestDispatcher("/resourceInOtherWebAppContext");

    13 years ago