Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • SCWCD : The Structure and Deployment of Web Applications

    SCWCD 1.5 Exam Kit

      The Structure and Deployment of Web Applications

    A Web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application. For example, for a Web application with the context path /catalog in a Web container, the index.html file at the base of the Web application hierarchy can be served to satisfy a request from /catalog/index.html.

    A special directory exists within the application hierarchy named "WEB-INF". This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is NOT part of the public document tree of the application. NO file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. Hence, if the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed directly to the Web client, he may place it under this directory. Since requests are matched to resource mappings in a case-sensitive manner, client requests for /WEB-INF/foo, /WEb-iNf/foo, for example, should not result in contents of the Web application located under /WEB-INF being returned, nor any form of directory listing thereof.

    The contents of the WEB-INF directory are:

    • The /WEB-INF/web.xml deployment descriptor.

    • The /WEB-INF/classes/ directory for servlet and utility classes. The classes in this directory must be available to the application class loader.

    • The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files.

    The Web application class loader must load classes from the WEB-INF/classes directory first, and then from library JARs in the WEB-INF/lib directory. Also, any requests from the client to access the resources in WEB-INF/ directory MUST be returned with a SC_NOT_FOUND (404) response.

    Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. For example, an application for issue tracking might be distributed in an archive file called issuetrack.war.

    When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. This directory MUST NOT be directly served as content by the container in response to a Web client's request, though its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext. Also, any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND (404) response.

    Tag extensions written in JSP using tag files can be placed in one of two locations. The first possibility is in the /META-INF/tags/ directory (or a subdirectory of /META-INF/tags/) in a JAR file installed in the /WEB-INF/lib/ directory of the web application. Tags placed here are typically part of a reusable library of tags that can be easily dropped into any web application.

    The second possibility is in the /WEB-INF/tags/ directory (or a subdirectory of /WEB-INF/tags/) of the web application. Tags placed here are within easy reach and require little packaging. Only files with a .tag or .tagx extension are recognized by the container to be tag files.

    Tag files that appear in any other location are not considered tag extensions and must be ignored by the JSP container. For example, a tag file that appears in the root of a web application would be treated as content to be served.

    The following is a listing of all the files in a sample Web application:

    					
    /index.html
    /howto.jsp
    /feedback.jsp
    /images/banner.gif
    /images/jumping.gif
    /WEB-INF/web.xml
    /WEB-INF/lib/jspbean.jar
    /WEB-INF/lib/jstl.jar
    /WEB-INF/jsp/example-taglib.tld 
    /WEB-INF/jsp/debug-taglib.tld 
    /WEB-INF/jsp2/jsp2-example-taglib.tld 
    /WEB-INF/tags/displayProducts.tag
    /WEB-INF/tags/helloWorld.tag     
    /WEB-INF/tags/panel.tag          
    /WEB-INF/tags/xhtmlbasic.tag     
    /WEB-INF/classes/com/mycorp/servlets/MyServlet.class
    /WEB-INF/classes/com/mycorp/util/MyUtils.class
    
    
    					

    Construct the correct structure for each of the following deployment descriptor elements: error-page, init-param, mime-mapping, servlet, servlet-class, servlet-mapping, servlet-name, and welcome-file.

    Error pages.

    
    <!--
    The error-page element contains a mapping between an error code or
    exception type to the path of a resource in the web application
    -->
    
    <!ELEMENT error-page ((error-code | exception-type), location)>
    
    					

    Init parameters.

    				
    <!--
    The init-param element contains a name/value pair as an
    initialization param of the servlet
    -->
    
    <!ELEMENT init-param (param-name, param-value, description?)>
    
    					

    MIME mapping.

    
    <!--
    The mime-mapping element defines a mapping between an extension and
    a mime type.
    -->
    
    <!ELEMENT mime-mapping (extension, mime-type)>
    
    					
    
    <!--
    The extension element contains a string describing an
    extension. example: "txt"
    -->
    
    <!ELEMENT extension (#PCDATA)>
    
    					
    
    <!--
    The mime-type element contains a defined mime type. example: "text/
    plain"
    -->
    
    <!ELEMENT mime-type (#PCDATA)>
    
    					

    Servlet.

    				
    <!--
    The servlet element contains the declarative data of a
    servlet.
    If a jsp-file is specified and the load-on-startup element is
    present, then the JSP should be precompiled and loaded.
    -->
    
    <!ELEMENT servlet (icon?, servlet-name, display-name?, description?,
    	(servlet-class|jsp-file), init-param*, load-on-startup?,
    	security-role-ref*)>
    
    					
    
    <!--
    The servlet-name element contains the canonical name of the
    servlet.
    -->
    
    <!ELEMENT servlet-name (#PCDATA)>
    
    					
    
    <!--
    The servlet-class element contains the fully qualified class name
    of the servlet.
    -->
    
    <!ELEMENT servlet-class (#PCDATA)>
    
    					
    
    <!--
    The jsp-file element contains the full path to a JSP file within
    the web application.
    -->
    
    <!ELEMENT jsp-file (#PCDATA)>
    
    					

    Servlet mapping.

    				
    <!--
    The servlet-mapping element defines a mapping between a servlet and
    a url pattern
    
    -->
    <!ELEMENT servlet-mapping (servlet-name, url-pattern)>
    
    					

    Welcome files.

    
    <!--
    The welcome-file-list contains an ordered list of welcome files
    elements.
    -->
    
    <!ELEMENT welcome-file-list (welcome-file+)>
    
    					

    env-entry

    
    <!--
    The env-entry element contains the declaration of an application's
    environment entry.
    This element is required to be honored on in J2EE compliant servlet
    containers.
    
    The env-entry-type element contains the fully qualified Java type of
    the environment entry value that is expected by the application
    code.
    
    The following are the legal values of env-entry-type:
    java.lang.Boolean, java.lang.String, java.lang.Integer,
    java.lang.Double, java.lang.Float.
    -->
    
    <!ELEMENT env-entry (description?, env-entry-name, env-entry-value?,
    env-entry-type)>
    
    					
    
    <env-entry>
    	<env-entry-name>tableName</env-entry-name>
    	<env-entry-value>StockTable</env-entry-value>
    	<env-entry-type>java.lang.String</env-entry-type>
    </env-entry>
    					
    					

    ejb-ref

    
    <!--
    The ejb-ref element is used for the declaration of a reference to
    an enterprise bean's home. The declaration consists of:
    - an optional description
    - the EJB reference name used in the code of
    the web application that's referencing the enterprise bean
    - the expected type of the referenced enterprise bean
    - the expected home and remote interfaces of the referenced
    enterprise bean
    - optional ejb-link information, used to specify the referenced
    enterprise bean
    
    The ejb-ref element is used to declare a reference to an enterprise
    bean.
    
    The ejb-ref-name element contains the name of an EJB
    reference. This is the JNDI name that the servlet code uses to get a
    reference to the enterprise bean.
    
    The ejb-ref-type element contains the expected type of the
    referenced enterprise bean.
    
    The ejb-ref-type element MUST be one of the following:
    
    <ejb-ref-type>Entity</ejb-ref-type>
    <ejb-ref-type>Session</ejb-ref-type>
    
    The home element contains the fully qualified name of the EJB's
    home interface
    
    The remote element contains the fully qualified name of the EJB's
    remote interface
    
    The ejb-link element is used in the ejb-ref element to specify that
    an EJB reference is linked to an EJB in an encompassing Java2
    Enterprise Edition (J2EE) application package.
    The value of the ejb-link element must be the ejb-name of and EJB in
    the J2EE application package.
    -->
    
    <!ELEMENT ejb-ref (description?, ejb-ref-name, ejb-ref-type, home,
    remote, ejb-link?)>
    
    					
    
    <!-- reference on a remote bean without ejb-link-->
    <ejb-ref>
    	<ejb-ref-name>ejb/MySessionBean</ejb-ref-name>
    	<ejb-ref-type>Session</ejb-ref-type>
    	<home>org.sample.beans.MySessionBeanHome</home>
    	<remote>org.sample.beans.MySessionBean</remote>
    </ejb-ref>
    
    					
    
    <!-- reference on a remote bean using ejb-link-->
    <ejb-ref>
    	<ejb-ref-name>ejb/EjbLinkMySessionBean</ejb-ref-name>
    	<ejb-ref-type>Session</ejb-ref-type>
    	<home>org.sample.beans.MySessionBeanHome</home>
    	<remote>org.sample.beans.MySessionBean</remote>
    	<ejb-link>MySB.jar#MySessionBean</ejb-link>
    </ejb-ref>
    					
    					

    ejb-local-ref

    
    <!--
    The ejb-local-ref element is used for the declaration of a reference
    to an enterprise bean's local home. The declaration consists of:
    - an optional description
    - the EJB reference name used in the code of the web application
    that's referencing the enterprise bean
    - the expected type of the referenced enterprise bean
    - the expected local home and local interfaces of the referenced
    enterprise bean
    - optional ejb-link information, used to specify the referenced
    enterprise bean
    
    The ejb-ref-type element contains the expected type of the
    referenced enterprise bean.
    
    The ejb-ref-type element MUST be one of the following:
    
    <ejb-ref-type>Entity</ejb-ref-type>
    <ejb-ref-type>Session</ejb-ref-type>
    -->
    
    <!ELEMENT ejb-local-ref (description?, ejb-ref-name, ejb-ref-type,
    local-home, local, ejb-link?)>
    
    					
    
    <!-- reference on a local bean -->
    <ejb-local-ref>
    	<ejb-ref-name>ejb/MySBLocal</ejb-ref-name>
    	<ejb-ref-type>Session</ejb-ref-type>
    	<local-home>org.sample.beans.MySessionBeanLocalHome</local-home>
    	<local>org.sample.beans.MySessionBeanLocal</local>
    	<ejb-link>secusb.jar#Op</ejb-link>
    </ejb-local-ref>
    					
    					

    resource-ref

    
    <!--
    The resource-ref element contains a declaration of a Web
    Application's reference to an external resource.
    
    The res-auth element indicates whether the application component
    code performs resource signon programmatically or whether the
    container signs onto the resource based on the principle mapping
    information supplied by the deployer. Must be CONTAINER or SERVLET !
    -->
    
    <!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth)>
    
    					
    
    <resource-ref>
    	<res-ref-name>jdbc/BookDB</res-ref-name>
    	<res-type>javax.sql.DataSource</res-type>
    	<res-auth>Container</res-auth>
    </resource-ref> 
    					
    					

    resource-env-ref

    
    <!--
    The resource-env-ref element contains a declaration of a web
    application's reference to an administered object associated with a
    resource in the web application's environment. It consists of an
    optional description, the resource environment reference name, and
    an indication of the resource environment reference type expected by
    the web application code.
    -->
    
    <!ELEMENT resource-env-ref (description?, resource-env-ref-name,
    resource-env-ref-type)>
    
    					
    
    <resource-env-ref>
    	<resource-env-ref-name>jms/Orders</resource-env-ref-name>
    	<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
    </resource-env-ref>
    					
    					

    Explain the purpose of a WAR file and describe the contents of a WAR file, how one may be constructed.

    Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. For example, an application for issue tracking might be distributed in an archive file called issuetrack.war. When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. This directory must not be directly served as content by the container in response to a Web client’s request, though its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext. Also, any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND(404) response.

    A WAR usually contains following resources:

    • Servlets, JavaServer Pages (JSP), Custom Tag Libraries.

    • Server-side utility classes (database beans, shopping carts, and so on).

    • Static web resources (HTML, image, and sound files, and so on).

    • Client-side classes (applets and utility classes).

    The directory structure of a Web application consists of two parts. The first part is the public directory structure containing HTML/XML documents, JSP pages, images, applets, and so on. The container appropriately serves the directory's contents against incoming requests. The second part is a special WEB-INF directory that contains the following files and directories:
    • web.xml - the web application deployment descriptor.

    • Tag Library Descriptor files.

    • classes/ - a directory that contains server-side classes: servlet, utility classes, and JavaBeans components.

    • lib/ - a directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes).

    • tags/ - a directory that contains Tag files (made easily accessible to JSPs without the need to explicitly write a Tag Library Descriptor files).

    The structure of the WAR files looks like this:
    
    WEB-INF/
    WEB-INF/web.xml
    WEB-INF/classes/
    WEB-INF/lib/
    WEB-INF/tags/
    
    					

    To prepare the web application for deployment, package it in a WAR file using the following jar utility command from the top-level directory of the application:

    					
    jar cvf web_app.war .
    					

    The information you are posting should be related to java and ORACLE technology. Not political.