This web application demonstrates a bug with SessionScoped CDI beans
observed in Apache TomEE 1.5.1.  This web application contains an
unrestricted page and a secure page that requires logging in to view.
Both pages display a String "foo" property from a SessionScoped CDI bean.
All pages are JSP-only.

Logging into the secure page appears to start a new CDI session
scope, with the previous SessionScoped bean being lost.  It is dropped
again at the next page, after which it works correctly.

This application works as expected in the GlassFish and JBoss containers.

Demonstrating the bug:

1.  Get Apache TomEE 1.5.1.
2.  Install the role and user in tomcat-users.txt into the
    conf/tomcat-users.xml of TomEE then start it.
3.  Use Maven to build the application "mvn package".
4.  Deploy the resulting target/cdisessionbug.war file into TomEE.
5.  View http://localhost:8080/cdisessionbug/ then set the "foo" property
    on the web form.
6.  Follow the "secure" link, sign on as user cdisessionbug with password
    "password", then note that your change to "foo" is lost.  Set the
    "foo" property again.  The unrestricted page displays, and the "foo"
    value is retained.
7.  The log display at the bottom of the page shows three post-construction
    events of the SessionScoped PintoBean, each with a different hash code.
    In other containers, only a single event happens, and "foo" retains
    its value after the first change.
