Session Servlet Example: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(27 intermediate revisions by the same user not shown)
Line 6: Line 6:
=Overview=
=Overview=


A simple JEE servlet that can be deployed within a JEE container and used to test continuity, load balancing, failover, session stickiness, etc. It has been tested to work with WildFly/EAP and with Tomcat. One of the design constraints was to avoid container-specific dependencies.
A simple servlet that can be deployed within a JEE container and used to test continuity, load balancing, failover, session stickiness, session replication, etc. It has been tested to work with WildFly/EAP and with Tomcat. It was written to avoid container-specific dependencies. Its only dependencies are slf4j for logging and the Servlet API.


=Source Code=
=Source Code=


<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;">
{{External|https://github.com/NovaOrdis/novaordis-session-servlet}}
:https://github.com/NovaOrdis/playground/tree/master/jee/servlet/session-servlet
</blockquote>


=Build=
=Build=
Line 26: Line 24:
=Usage=
=Usage=


For more details, see [[#HTTP_Session_Support|HTTP Session Support]].
==Authentication==
      
      
=Authentication=
The default build produces a servlet that ''does NOT require authentication''.
   
The default build produces a servlet that *does NOT require authentication*.
      
      
If you want authentication, do this (JBoss 5 procedure, may need to be updated for WildFly):
If you want authentication, do this (JBoss 5 procedure, may need to be updated for WildFly):
      
      
1. Un-comment <tt>web.xml</tt> section starting with <security-constraint> and ending with </security-role>.
1. Un-comment <tt>web.xml</tt> section starting with <tt><security-constraint></tt> and ending with <tt></security-role></tt>.
      
      
2. Replace "admin" with a valid role. The replacement must be done in both places where <role-name> is mentioned. For example, if deployed on JBoss 5, pick up an appropriate role from <tt>$JBOSS_HOME/server/$JBOSS_PROFILE/conf/props/jmx-console-roles.properties</tt>.
2. Replace "admin" with a valid role. The replacement must be done in both places where <tt><role-name></tt> is mentioned. For example, if deployed on JBoss 5, pick up an appropriate role from <tt>$JBOSS_HOME/server/$JBOSS_PROFILE/conf/props/jmx-console-roles.properties</tt>.
      
      
3. Enable <security-domain> in <tt>jboss-web.xml</tt> and make sure it points to the correct one on the server.
3. Enable <tt><security-domain></tt> in <tt>jboss-web.xml</tt> and make sure it points to the correct one on the server.
   
 
=HTTP Session Support=
==HTTP Session Support==


The servlet will NOT establish a HTTP session by default.
The servlet will NOT establish a HTTP session by default.


If you wish it to establish a session, call it with "establish-session" parameter on the first request.
If you wish it to establish a session, call the /establish-session URL:
 
<pre>
http://localhost:8080/session-servlet/establish-session
</pre>
 
This will create a HTTP session and send the Set-Cookie JSESSIONID back to browser. If /establish-session is called repeatedly on an already established session, the application will warn, but otherwise nothing else will happen; enable-session is idempotent.
 
To get more information about the current session, use:
 
<pre>
http://localhost:8080/session-servlet/describe-session
</pre>
 
To invalidate the current session, use:
 
<pre>
http://localhost:8080/session-servlet/invalidate-session
</pre>
 
To write a String attribute into the session use:
 
<pre>
http://localhost:8080/session-servlet/write/<attribute-name>/<attribute-value>
</pre>
 
To read the value corresponding to previously written String attribute:
 
<pre>
http://localhost:8080/session-servlet/read/<attribute-name>
</pre>
 
To get the names of all attributes stored into the session, use:


Example: http://locahost:8080/session-servlet?establish-session
<pre>
http://localhost:8080/session-servlet/attributes
</pre>


After the first request, obviously there's no need for "establish-session" anymore, the browser/server ensemble maintain the one that was established. The current implementation will throw an exception if it sees "?establish-session" again.
Note that the attribute count is displayed as part of the <tt>describe-session</tt> command output.


In order to store a key/value pair into the session, use http://locahost:8080/session-servlet/put?key=something&value=somethingelse. In order to retrieve a key/value pair from the session, use http://locahost:8080/session-servlet/get?key=something
===Application Type===


==Enable HTTP Session Replication==
The session servlet application allows for experiments with an application type, represented by the [https://github.com/NovaOrdis/playground/blob/master/jee/servlet/session-servlet/src/main/java/io/novaordis/playground/jee/servlet/session/applicaton/ApplicationType.java ApplicationType]  class. The <tt>ApplicationType</tt> can be modified into a backward compatible new version, incompatible new version, etc.


=Root Context=
To write a String into ApplicationType instance, that will be in turn written into the session, use:
 
<pre>
http://localhost:8080/session-servlet/write/apptype/<string-value>
</pre>


You can change the root context as follows:
To read the String value from the ApplicationType instance maintained by the session:


==On JBoss==
<pre>
http://localhost:8080/session-servlet/read/apptype
</pre>


===Method One===
===Enable HTTP Session Replication===


Simply deploy the WAR under the desired name.
The application allows for experiments with distributable sessions. To enable session replication:


===Method Two===
1. Uncomment the <tt><distributable></tt> configuration element in <tt>src/main/webapp/WEB-INF/web.xml</tt>. For more details on web.xml, see:


TODO: use jboss-web.xml and root-context.
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[web.xml]]
</blockquote>


==On Tomcat==
2. Uncomment the <tt><replication-config></tt> section in <tt>src/main/webapp/WEB-INF/jboss-web.xml</tt> and configure the cache name, replication trigger and replication granularity. For more details about configuring WildFly session replication see: 


Simply deploy the WAR under the desired name.
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[HTTP_Session_Replication#WildFly-Specific_Configuration|HTTP Session Replication - WildFly-Specific Configuration]]
</blockquote>


=Test Plan=
For more details on <tt>jboss-web.xml</tt> see:


==1. Simple Availability==
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[jboss-web.xml]]
</blockquote>


Build and deploy.
==Root Context==


Go to http://<server-address>:<server-port>/session-servlet
You can change the root context as follows:


It will return a simple HTTP page listing relevant information regarding the execution.
===On JBoss===


==2. Session Experiments==
Simply deploy the WAR under the desired name or change the root context in <tt>jboss-web.xml</tt>. For more details on how to do that see [[Jboss-web.xml#Root_Context|<tt>jboss-web.xml</tt> root context]].


Establish a session with http://<server-address>:<server-port>/session-servlet?establish-session
===On Tomcat===


Then drop the parameter, the browser/server should maintain the session until it expires.
Simply deploy the WAR under the desired name.

Latest revision as of 18:11, 27 November 2017

Internal

Overview

A simple servlet that can be deployed within a JEE container and used to test continuity, load balancing, failover, session stickiness, session replication, etc. It has been tested to work with WildFly/EAP and with Tomcat. It was written to avoid container-specific dependencies. Its only dependencies are slf4j for logging and the Servlet API.

Source Code

https://github.com/NovaOrdis/novaordis-session-servlet

Build

mvn clean package

Deploy

Copy ./target/session-servlet.war into the deployment directory of the application server.

Usage

Authentication

The default build produces a servlet that does NOT require authentication.

If you want authentication, do this (JBoss 5 procedure, may need to be updated for WildFly):

1. Un-comment web.xml section starting with <security-constraint> and ending with </security-role>.

2. Replace "admin" with a valid role. The replacement must be done in both places where <role-name> is mentioned. For example, if deployed on JBoss 5, pick up an appropriate role from $JBOSS_HOME/server/$JBOSS_PROFILE/conf/props/jmx-console-roles.properties.

3. Enable <security-domain> in jboss-web.xml and make sure it points to the correct one on the server.

HTTP Session Support

The servlet will NOT establish a HTTP session by default.

If you wish it to establish a session, call the /establish-session URL:

http://localhost:8080/session-servlet/establish-session

This will create a HTTP session and send the Set-Cookie JSESSIONID back to browser. If /establish-session is called repeatedly on an already established session, the application will warn, but otherwise nothing else will happen; enable-session is idempotent.

To get more information about the current session, use:

http://localhost:8080/session-servlet/describe-session

To invalidate the current session, use:

http://localhost:8080/session-servlet/invalidate-session

To write a String attribute into the session use:

http://localhost:8080/session-servlet/write/<attribute-name>/<attribute-value>

To read the value corresponding to previously written String attribute:

http://localhost:8080/session-servlet/read/<attribute-name>

To get the names of all attributes stored into the session, use:

http://localhost:8080/session-servlet/attributes

Note that the attribute count is displayed as part of the describe-session command output.

Application Type

The session servlet application allows for experiments with an application type, represented by the ApplicationType class. The ApplicationType can be modified into a backward compatible new version, incompatible new version, etc.

To write a String into ApplicationType instance, that will be in turn written into the session, use:

http://localhost:8080/session-servlet/write/apptype/<string-value>

To read the String value from the ApplicationType instance maintained by the session:

http://localhost:8080/session-servlet/read/apptype

Enable HTTP Session Replication

The application allows for experiments with distributable sessions. To enable session replication:

1. Uncomment the <distributable> configuration element in src/main/webapp/WEB-INF/web.xml. For more details on web.xml, see:

web.xml

2. Uncomment the <replication-config> section in src/main/webapp/WEB-INF/jboss-web.xml and configure the cache name, replication trigger and replication granularity. For more details about configuring WildFly session replication see:

HTTP Session Replication - WildFly-Specific Configuration

For more details on jboss-web.xml see:

jboss-web.xml

Root Context

You can change the root context as follows:

On JBoss

Simply deploy the WAR under the desired name or change the root context in jboss-web.xml. For more details on how to do that see jboss-web.xml root context.

On Tomcat

Simply deploy the WAR under the desired name.