Session Servlet Example: Difference between revisions
Line 81: | Line 81: | ||
Note that the attribute count is displayed as part of the <tt>describe-session</tt> command output. | Note that the attribute count is displayed as part of the <tt>describe-session</tt> command output. | ||
===Enable HTTP Session Replication=== | ===Enable HTTP Session Replication=== | ||
Line 94: | Line 93: | ||
:[[HTTP_Session_Replication#WildFly-Specific_Configuration|HTTP Session Replication - WildFly-Specific Configuration]] | :[[HTTP_Session_Replication#WildFly-Specific_Configuration|HTTP Session Replication - WildFly-Specific Configuration]] | ||
</blockquote> | </blockquote> | ||
===Application Type=== | |||
The synthetic 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. | |||
=Root Context= | =Root Context= |
Revision as of 03:11, 16 June 2016
Internal
Overview
A simple JEE 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. One of the design constraints was to avoid container-specific dependencies. Its only dependencies are slf4j for logging and the Servlet API.
Source Code
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.
Enable HTTP Session Replication
The syntactic 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.
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:
Application Type
The synthetic application allows for experiments with an application type, represented by the ApplicationType class.
Root Context
You can change the root context as follows:
On JBoss
Method One
Simply deploy the WAR under the desired name.
Method Two
TODO: use jboss-web.xml and root-context.
On Tomcat
Simply deploy the WAR under the desired name.
Test Plan
1. Simple Availability
Build and deploy.
Go to http://<server-address>:<server-port>/session-servlet
It will return a simple HTTP page listing relevant information regarding the execution.
2. Session Experiments
Establish a session with http://<server-address>:<server-port>/session-servlet?establish-session
Then drop the parameter, the browser/server should maintain the session until it expires.