Webtier One Pager [
Unknown macro: {TableOfContents title='Webtier '}
|(TableOfContentstitle='Webtier')] 1. Introduction 1.1. Project/Component Working Name: GlassFish Webtier 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: The individual who are wrote this document Rajiv Mordani (Rajiv.Mordani@sun.com) 1.3. Date of This Document: 06/30/2008 2. Project Summary 2.1. Project Description: The webtier for GlassFish v3 Prelude is based on the Java EE 5 specifications
namely Servlet 2.5, JSP 2.1, JSTL 1.1 and JSF 1.2. In addition to the main
specifications the implementation will also provide support for new web
2.0 features like Comet and AJAX. See below for a longer, more detailed technical description. 2.2. Risks and Assumptions: The risks associated with this release are the resources needed to
implement monitoring support in the webtier. It also poses some amount
of risk to the work that needs to be done for Java EE 6 implementation. 3. Problem Summary 3.1. Problem Area: What problem or need does this project solve?
The core part of the v3 Prelude release is the web container and it's
associate pieces. The container needs to be competitive with some of
the other light weight containers like Tomcat and Jetty. Also the
support for scripting languages that help build web applications using
these languages on top of GlassFish / Java VM are gaining popularity
and need to be supported. In addition to being part of the v3 Prelude release a separate but
related goal is to make the web container embeddable so that
applications can bundle a web container without having to worry too
much about the size of the container. 3.2. Justification: Why is it important to do this project?
The webtier projects provide the core web container of Java EE 5 and
support for web 2.0 style of programming. 4. Technical Description: 4.1. Details: Since forking from Tomcat to create the GlassFish webtier there is a
lot of legacy code from Tomcat that is carried forward but never really
used in GlassFish. As part of an effort to clean up the code and make
the web container embeddable there is effort on the way to refactor the
web container. Following are the high level list of things that are
being targeted for web container for v3 Prelude release.
- Web container refactoring
- Separate core servlet container into new web-core module
- Remove dependency of web-core on com.sun renamed Apache commons modules
- Remove dependency of web-core on commons-logging from servlet container
- Remove dependency of web-core on commons-logging from Jasper
- Remove dependency of web-core on commons-modeler
- Remove connector related code duplication in web-core and Grizzly
- Remove request double-mapping
- Remove dependency of Jasper on GlassFish API
- Restore setDtdResourcePrefix(), setSchemaResourcePrefix(), and MyEntityResolver in org.apache.jasper.xmlparser.ParserUtils
- Add setEntityResolver() to org.apache.jasper.xmlparser.ParserUtils
- Separate java.net projects JSTL, EL and JSP
- OSGi binary bundles will be integrated into GlassFish.
- Tomcat alignment
- Support for Tomcat valve in addition to the flattened valve architecture in GlassFish
- Relevant bug fixes from Tomcat will also be ported over.
- Support for latest version of mod_jk will be available
- WebDAV, SSI and CGI support.
- Advanced features
- Dynamic reconfiguration, which was available in v2 but didn't make it into the TP2 release of GlassFish v3 will be done in time for the v3 Prelude release.
- Monitoring support
- Changes for Grizzly config. See Grizzly config one pager.
- Comet support via Atmosphere (a sub-project of Grizzly) will also be available.
- JSF 1.2 will be integrated into v3 Prelude. There aren't any new features being added for the release. Mostly just bug fixes.
4.2. Bug/RFE Number(s): 4.3. In Scope: 4.4. Out of Scope: Tomcat style of directory deployment under a special directory like "webapps" is not targeted for the v3 Prelude release. 4.5. Interfaces: Servlet 2.5: Committed
JSP 2.1: Committed
JSTL 1.1: Committed
EL 1.1: Committed
JSF 1.2: Committed
Atmosphere: Volatile. (Put pointer to Javadocs)
Valve: Committed 4.5.1 Exported Interfaces Disclose all interfaces that this project exports.
- Interface: Atmosphere
- Stability: Volatile
- Former Stability (if changing): N/A
- Comments:
- Interface: Grizzly Config
- Stability: Volatile
- Former Stability (if changing): N/A (previously mostly properties in domain.xml)
- Comments:
4.5.2 Imported interfaces Disclose interfaces this project imports.
- Interface: GlassFish API
- Stability: Committed (need to double check)
- Exporting Project: Name, Specification or other Link.
- Comments:
- Interface: Monitoring framework (gProbes)
- Stability: Committed
- Exporting Project: Name, Specification or other Link.
- Comments:
4.5.3 Other interfaces (Optional) Any private interfaces that may be of interest?
- Interface:
- Stability:
- Exporting Project: Name, Specification or other Link.
- Comments:
- Interface:
- Stability:
- Exporting Project: Name, Specification or other Link.
- Comments:
4.6. Doc Impact: In addition to documenting standard features that are part of the Java EE specification, the documentation should also cover AJAX via jMaki and JSF, Comet features, use of mod_jk, WebDAV, SSI and CGI features that will be available in the v3 Prelude release. 4.7. Admin/Config Impact: How will this change impact the administration of the product? Dynamic reconfiguration support via admin console. Already planned. Please see the admin one pager. 4.8. HA Impact: What new requirements does this proposal place on the High Availability or Clustering aspects of the component? 4.9. I18N/L10N Impact: Does this proposal impact internationalization or localization? 4.10. Packaging & Delivery: What packages, clusters or metaclusters does this proposal impact? What is its impact on install/upgrade? 4.11. Security Impact: How does this proposal interact with security-related APIs or interfaces? Does it rely on any Java policy or platform user/permissions implication? If the feature exposes any new ports, Or any similar communication points which may have security implications, note these here. 4.12. Compatibility Impact
- Grizzly configuration, which is new, can now live in a separate file is replacing some of the properties that existed in GlassFish v2. The new elements in Grizzly configuration will be the recommended way. No decision is made yet about supporting the properties that were used in GlassFish v2 to enable Comet features using Grizzly.
- Appserver 8.x changed Tomcat's <code>org.apache.catalina.Valve</code> interface to reduce the number of frames on the stack when processing a web request and invoking a servlet: Instead of having one valve in the pipeline invoke the next valve, the container became responsible for invoking one valve at a time, and deciding whether to invoke the next valve by examining the return value of the current valve invocation. See CR 4665318 for details. The change to the <code>Valve</code> interface was considered an implementation detail, because the appserver did not support adding custom valves. GlassFish V2 has allowed developers to add their own custom valves, by specifying the class names of their valves as <code>virtual-server</code> or <code>web-module</code> properties in <code>domain.xml</code>, or as properties within their webapp's <code>sun-web.xml</code> descriptor. The specified valves would have to implement the modified <code>Valve</code> interface from GlassFish instead of that from Tomcat. Develpers who wanted to migrate from Tomcat to GlassFish would have to convert their valves by following these instructions. In order to better align with Tomcat, GlassFish V3 is going to rename the GlassFish <code>Valve</code> interface and change <code>org.apache.catalina.Valve</code> to match the Tomcat definition. All GlassFish container implementation valves will be turned into hybrid valves that implement both the GlassFish <code>Valve</code> interface as well as the latest <code>Valve</code> interface from Tomcat, so they may be invoked both in a stacked as well as in the more optimal flattened fashion (they will be invoked in the flattened fashion as long as no developer valves have been configured). This means that any developer valves configured in GlassFish V2 (that implement the GlassFish <code>Valve</code> interface) will no longer work in V3, and will have to be adjusted to implement the latest Tomcat <code>Valve</code> interface. This seems acceptable because we have not heard of any developers who have actually implemented the modified GlassFish <code>Valve</code> interface. On the other hand, there is a large developer base that has implemented valves using the Tomcat definition, and it is important that V3 support those developers.
4.13. Dependencies:
- Monitoring framework - gProbes
- Admin for dynamic reconfiguration
- GlassFish API for the embeddable web container
5. Reference Documents: List of related documents, if any (BugID's, RFP's, papers). Explain how/where to obtain the documents, and what each contains, not just their titles. 6. Schedule: 6.1. Projected Availability: Aligned with the GlassFish v3 Prelude release.
|
