| GlassFish Server Open Source Edition 3.1 Webtier 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: Name: GlassFish webtier team (webtier@glassfish.java.net), Rajiv Mordani (rajiv.mordani@oracle.com) 1.3. Date of This Document: 05/12/2010 2. Project Summary 2.1. Project Description: The webtier for GlassFish Server Open Source Editiion 3.1 is based on a subset of the Java EE 6 specifications namely Servlet 3.0, JSP 2.2, JSTL 1.1, EL 2.2 and JSF 2.1. In addition to the main specifications the implementation will also provide support for clustering and HA.
See below for a longer, more detailed technical description. 2.2. Risks and Assumptions:
- Assumptions
- HA / Clustering infrastructure will be available in time for us to integrate / use in the web container
- Some of the weblogic deployment descriptor elements that, if we were to support, would need help from security team.
3. Problem Summary 3.1. Problem Area: The web tier of GlassFish provides the required Java EE 6 functionality for the web container for the full and web profiles. In the v3 release, the implementation provided all the core services that were needed for developing Java EE 6 web applications. In this release - 3.1 Open source edition, we need to add high availability and clustering features to the web container. 3.2. Justification: The web tier provides core web container pieces for writing Java EE 6 web applications and we need to ensure HA support in the container. 4. Technical Description: 4.1. Details: The work in this release builds on the work that was done for the v3 release of GlassFish. Please see [ v3 one pager for web container |V3FinalWebtierFunctionalSpec]. The focus of this release is HA and clustering and in order to support the functionality in the web container the following are the features that must be implemented in the web container of GlassFish 3.1 -
- HA SPI integration
- Create a new module in web - web-ha for high availability related functionality
- Bring code over where appropriate from v2.1
- Use the SPI from v3.1
- Session management high availability will support only session, modified-session and modified-attributes at the end of request.
- StrategyBuilder changes
In v2 for session management in the web container, the builder pattern was used to derive the PersistenceStrategyBuilder implementation class name from the configured session persistence type, and scope. The PersistenceStrategyBuilder is responsible for setting the appropriate org.apache.catalina.session.Manager and possibly the org.apache.catalina.session.Store. In v2 the way the StrategyBuilder works is based on the persistence type (and optionally other properties under store specified in the sun-web.xml For example if in the sun-web.xml you have the following
<sun-web-app>
<session-config>
<session-manager persistence-type="replicated">
<manager-properties>
<property name="persistenceFrequency" value="web-method"/>
</manager-properties>
<store-properties>
<property name="persistenceScope" value="modified-attribute"/>
</store-properties>
</session-manager>
</session-config>
</sun-web-app>
The effective class name would be
→ com.sun.enterprise.ee.web.initialization.ReplicatedWebmethodModifiedattributeStrategyBuilder
The fully qualified class name is hard coded in the web container in v2 and is not extensible. Every time you want to add a different type of SessionManager the web container needs to be updated to know what the effective class name is based on the configuration defined in the web.xml. We had to do this for Coherence Web and if we continue to use the old scheme and if we use the old scheme, it will break for 3.1 as the code for in memory replication which will now be in shoal in a different package name. The proposal below is to use hk2 services to make the session manager more pluggable. We will provide a
package org.glassfish.web.ha
@Contract
public abstract StrategyBuilder {
public org.apache.catalina.session.Manager getManager() {
return new PersistentManager();
}
public abstract void init(StandardContext ctx, SessionManager sessionManager);
}
Implementors would implement
@Service(name="xyz")
public class XYZStrategyBuilder extends StrategyBuilder {
public org.apache.catalina.session.Manager getManager() {
Manager manager = super.getManager();
manager.setStore(MyStore);
//MyStore could delegate to for example the BackingStore in the case of our in memory replication
return manager;
or
//Create a new manager, set the appropriate Store and return it
return XYZManager;
}
public void init(StandardContext ctx, SessionManager sessionManager) {
add listeners, valves etc to the ctx,
}
}
If a Manager is provided - it will be used. It is the responsibility of the Manager to make sure that findSession etc uses the right Store, if required, that it provides. This does away with two things -
- The magic for creating an instance of a StrategyBuilder
- The need to modify our code (web container) everytime we need support a new persistence type.
Example with Coherence Web
@Service(name="coherence-web")
public class CoherenceWebStrategyBuilder extends StrategyBuilder {
public org.apache.catalina.session.Manager getManager() {
return new CoherenceManager();
}
public void init(StandardContext ctx, SessionManager sessionManager) {
// add listeners, valves etc to the ctx,
}
}
and the configuration in the sun-web.xml
<sun-web-app>
<session-config>
<session-manager persistence-type="coherence-web"/>
</session-config>
</sun-web-app>
Based on the domain.xml / sun-web.xml settings the container will look up the appropriate StrategyBuilder
in the Habitat and use it.
- Weblogic deployment descriptor support See mappings [ here |SupportWLDDInContainers]. What is marked as "Yes" in comments will be done. The rest is being scoped to see what can and can't be done in the time frame. For things that are dependent on the Security team, have been tagged with "SECURITY" in the comments section.
- Need to identify the subset of elements that we will support in this release.
- CLI working in a clustered environment.
- Verify --target works for
- create-virtual-server
- delete-virtual-server
- list-virtual-servers
- create-http
- delete-http
- create-http-listener
- delete-http-listener
- list-http-listeners
- create-threadpool
- delete-threadpool
- list-threadpools
- create-ssl
- delete-ssl
- create-protocol
- delete-protocol
- list-protocols
- create-protocol-filter
- delete-protocol-filter
- list-protocol-filters
- create-protocol-finder
- delete-protocol-finder
- list-protocol-finders
- create-transport
- delete-transport
- list-transports
- create-network-listener
- delete-network-listener
- list-network-listeners
- Finalize web embedded APIs. Most of the web embedded APIs were done for the v3 release. However we still need to tweak and better integrate better with the overall embedded APIs and close out the implementation.
- Coherence Web
- Add support for glassfish-web.xml in addition to sun-web.xml
- Port unification in Grizzly at least for the web container (http and https).
- Bug fixes from Tomcat (including security related fixes)
- Include JSF 2.1
- Cross Site Scripting protection built in
- Bug fixes
- Performance improvements
4.2. Bug/RFE Number(s): List any Bug(s)/RFE(s) which will be addressed by this proposed change.
4.3. In Scope: Aspects that are in scope of this proposal if not obvious from above. 4.4. Out of Scope:
- Grizzly 2.0 will not be integrated in this release.
- Time based session persistence will not be supported in this release.
4.5. Interfaces: 4.5.1 Public Interfaces
- New Grizzly related CLIs
- create-protocol-filter
- delete-protocol-filter
- list-protocol-filters
- create-protocol-finder
- delete-protocol-finder
- list-protocol-finders
-
described above (package name TBD)
4.5.2 Private Interfaces None 4.5.3 Deprecated/Removed Interfaces: None 4.6. Doc Impact: High availability and clustering features need to be documented. A lot of v2 documentation for the features should be re-usable. 4.7. Admin/Config Impact:
- There will be new Admin CLI commmand for Grizzly port unification. We would like to see the console add support for it too.
- Need to verify that --target works for the various CLI commands related to the web container
4.7.1 Port Unification Commands asadmin commands will be added to expose support for port unification in 3.1. Commands will be added create/delete protocol-finder and protocol-filter elements. There are some elements are that are largely placeholders related to port unification (port-unification, protocol-chain-instance-handler, and protocol-chain). These elments will be implicitly created and deleted as necessary in conjunction with the lifecycles of protocol-filters and protocol-finders. Some validation requiring an existing network-listener has been removed from cases such as create-ssl as such restrictions make no sense with port unification and leaving them in place makes for an incredibly awkward work effort to configure port unification. 4.8. HA Impact: Need to implement the HA SPI. 4.9. I18N/L10N Impact: No 4.10. Packaging, Delivery & Upgrade: 4.10.1. Packaging Packaged as part of GlassFish Sub-module packages delivered to Glassfish:
4.10.2. Delivery None 4.10.3. Upgrade and Migration: None 4.11. Security Impact: None 4.12. Compatibility Impact None 4.13. Dependencies: HA SPI dependency
Clustering framework dependency
Admin CLI / GUI dependency 4.14. Testing Impact: Dev tests for webtier exist since a long time and they are automated and will continue to be run against the development work on a continuous basis. New tests will be written for new functionality that will be part of the continuous runs. QA will need to test the clustering aspects and HA aspects of web container. 5. Reference Documents: Web Tier sub-project planning page 6. Schedule: 6.1. Projected Availability: See task list in the sub-project planning page |
