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


  • 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


  • 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 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 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
  • Given a set of requirements, develop and configure a Web service client that accesses a stateful Web service.

    The JAX-RPC specification requires that a service client be able to participate in a session with a service endpoint.

    In the JAX-RPC 1.1 version, the session management mechanisms require use of HTTP as the transport in the protocol binding. This version of the JAX-RPC specification does not specify (or require) session management using SOAP headers given that there is no standard SOAP header representation for the session information. SOAP based session management may be considered in the future versions of the JAX-RPC specification.

    A JAX-RPC runtime system is required to use at least one of the following mechanisms to manage sessions:

    • Cookie based mechanism: On the initial method invocation on a service endpoint, the server side JAX-RPC runtime system sends a cookie to the service client to initiate a new session. If service client wants to participate in this session, the client side JAX-RPC runtime system then sends the cookie for each subsequent method invocation on this service endpoint. The cookie associates subsequent method invocations from the service client with the same session.

    • URL rewriting involves adding session related identifier to a URL. This rewritten URL is used by the server-side JAX-RPC runtime to associate RPC invocations to the service endpoint with a session. The URL that is rewritten depends on the protocol binding in use.

    • SSL session may be used to associate multiple RPC invocations on a service endpoint as part of a single session.

    A session (in JAX-RPC) is initiated by the server-side JAX-RPC runtime system. The server-side JAX-RPC runtime system may use javax.servlet.http.HttpSession (defined in the Servlet specification) to implement support for the HTTP session management.

    A service client uses the javax.xml.rpc.session.maintain property (set using the Stub or Call interfaces) to indicate whether or not it wants to participate in a session with a service endpoint. By default, this property is False, so the client does not participate in a session by default. However, by setting javax.xml.rpc.session.maintain property to True, the client indicates that it wants to join the session initiated by the server. In the cookie case, the client runtime system accepts the cookie and returns the session tracking information to the server, thereby joining the session.

    The client code by setting the javax.xml.rpc.session.maintain property assumes that it would participate in a session if one is initiated by the server. The actual session management happens transparent to the client code in the client-side runtime system.

    Property javax.xml.rpc.session.maintain accepts objects of java.lang.Boolean class. This boolean property is used by a service client to indicate whether or not it wants to participate in a session with a service endpoint. If this property is set to True, the service client indicates that it wants the session to be maintained. If set to False, the session is not maintained. The default value for this property is False.

    package javax.xml.rpc;
    public interface Stub {
    	// ...
    	void _setProperty(String name, Object value);
    	Object _getProperty(String name);
    	java.util.Iterator _getPropertyNames();
    package javax.xml.rpc;
    public interface Call {
    	// ...
    	void setProperty(String name, Object value);
    	Object getProperty(String name);
    	boolean removeProperty(String name);
    	java.util.Iterator getPropertyNames();

    The service endpoint class may implement the following ServiceLifecycle interface:

    package javax.xml.rpc.server;
    public interface ServiceLifecycle {
    	void init(Object context) throws ServiceException;
    	void destroy();

    If the service endpoint class implements the ServiceLifecycle interface, the servlet container based JAX-RPC runtime system is required to manage the lifecycle of the corresponding service endpoint instances. The lifecycle of a service endpoint instance is realized through the implementation of the init and destroy methods of the ServiceLifecycle interface.

    For service endpoint components deployed on a servlet container based JAX-RPC runtime system, the context parameter in the ServiceLifecycle.init method is required to be of the Java type javax.xml.rpc.server.ServletEndpointContext. The ServletEndpointContext provides an endpoint context maintained by the underlying servlet container based JAX-RPC runtime system. Note that the JAX-RPC specification specifies the standard programming model for a servlet based endpoint. The goal of JAX-RPC specification is not to define a more generic abstraction for the endpoint context or session that is independent of any specific component model, container and protocol binding. Such generic abstractions and endpoint model are outside the scope of the JAX-RPC specification. The following code snippet shows the ServletEndpointContext interface:

    package javax.xml.rpc.server;
    public interface ServletEndpointContext {
    	public getUserPrincipal();
    	public boolean isUserInRole(String role);
    	public javax.xml.rpc.handler.MessageContext getMessageContext();
    	public javax.servlet.http.HttpSession getHttpSession();
    	public javax.servlet.ServletContext getServletContext();

    A servlet container based JAX-RPC runtime system is required to implement the ServletEndpointContext interface. The JAX-RPC runtime system is required to provide appropriate session, message context, servlet context and user principal information per method invocation on service endpoint instances.

    The getHttpSession method returns the current HTTP session (as a javax.servlet.http.HttpSession). When invoked by the service endpoint instance within a remote method implementation, the getHttpSession returns the HTTP session associated currently with this method invocation. This method is required to return null if there is no HTTP session currently active and associated with this service endpoint instance. An endpoint class should not rely on an active HTTP session being always there; the underlying JAX-RPC runtime system is responsible for managing whether or not there is an active HTTP session.

    The getHttpSession method throws JAXRPCException if it is invoked by a non HTTP bound endpoint. The JAX-RPC specification does not specify any transport level session abstraction for non-HTTP bound endpoints.

    HTTP sesion timeout

    To change the default session timeout globally, add the following element in your web.xml (service endpoint implementation deployment descriptor):

    		<!-- set global default timeout to 15 minutes -->

    The session-timeout element defines the default session timeout interval for all sessions created in this web application. The specified timeout must be expressed in a whole number of MINUTES. If the timeout is 0 or less, the container ensures the default behaviour of sessions is never to timeout. If this element is not specified, the container must set its default timeout period.

    The full syntax:

    The session-config element defines the session parameters for this
    web application.
    <!ELEMENT session-config (session-timeout?)>
    The session-timeout element defines the default session timeout
    interval for all sessions created in this web application.
    The specified timeout must be expressed in a whole number of minutes.
    <!ELEMENT session-timeout (#PCDATA)>

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