[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T17:05:08 Editor: GregWilkins [EMAIL PROTECTED] Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -14,9 +14,12 @@ A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. -An optional WEB-INF/geronimo-web.xml deployment will be required to configure any additional jndi resources and resource-refs. The context path will be set by the EAR application.xml, the WAR filename, the directory filename or by a geronimo configuration element. +Any geronimo specific configuration will be done via the JSR88 deployment plan associated with +the deployment. The deployment plan will include any mappings required to JNDI resources +or specific web container configurations. -Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases. +Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases. Instead, implementation specific configuration should either be done via an extensible deployment plan or avoided by integration +into common geronimo services. == Connector Configuration ==
[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T17:14:03 Editor: GregWilkins [EMAIL PROTECTED] Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -14,9 +14,8 @@ A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. -Any geronimo specific configuration will be done via the JSR88 deployment plan associated with -the deployment. The deployment plan will include any mappings required to JNDI resources -or specific web container configurations. +Any geronimo specific configuration will be done via a JSR88 deployment plan associated with +the deployed webapplication or EAR. The deployment plan will include any mappings required to JNDI resources or references to specific web container configurations. Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases. Instead, implementation specific configuration should either be done via an extensible deployment plan or avoided by integration into common geronimo services. @@ -41,8 +40,7 @@ host and/or domain names. Virtual hosts may be configured for logging, security, statistics, etc. A webapp may be targetted to a specific virtual host at deployment time. If a targeted virtual -host does not exist, this may result in either a validation error or the creation of a -dynamic virtual host with default configuration. +host has not been configured and started on the server, this will result in a error when the webapp is started. == Physical hosts == @@ -141,8 +139,12 @@ == Configuration == -Web applications will use a geronimo-web.xml file for their geronimo specific configuration. They -may also have impl-web.xml for implementation dependent configuration, but this is to be discouraged -in all but exceptional cases. +Web applications should be deployed with only the standard deployment descriptors in their +WEB-INF directories. Geronimo will use the associated JSR88 deployment plan to +provide geronimo and extensible implementation configuration. + +The use of impl-web.xml for implementation dependent configuration may be supported but this +is to be discouraged in all but exceptional cases. + The other web components will be configured via the GBean mechanism which may use *-service.xml files.
[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T13:35:53 Editor: 203.45.72.167 Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -2,58 +2,123 @@ [[TableOfContents]] = Overview = +The implementation of the Geronimo web tier will be guided by the use cases outlined below. It is +the intent of this project to meet these use-cases without resorting to implementation specific +configuration. -The notes on this page have been put together by [EMAIL PROTECTED], based on a posting to geronimo-dev, with a few notes added. += Use Cases = +== Webapp Deployment == +A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. -I would like to see the container, the connectors and webapplications as all top level geronimo components (aka services). +All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. -[ NB. It looks like the initial geronimo code supports nested services - so perhaps the top level description is not valid and webcontainer component can be the container for the webconnectors and webapplications ] +An optional WEB-INF/geronimo-web.xml deployment will be required to configure any additional jndi resources and resource-refs. -They would all have independant lifecycles - create, start, stop, destroy that can be controlled by the normal container mechanisms - with the exception that both connectors and webapps depend on having a container deployed. +The context path will be set by the EAR application.xml, the WAR filename, the directory filename or by a geronimo configuration element. -I would like to support multiple containers, so you can have isolated collections of connectors and webapps (eg for security and/or admin) +Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases. -The deployment would go something like as follows: +== Connector Configuration == +The default and/or additional HTTP connectors for the default geronimo web container will be configured +and managed via standard geronimo mechanisms. The majority of common parameters, statistics and JSR77 lifecycle +commands for HTTP connectors will be able to be managed without using implementation specific configuration or +tools. This will include: -== A web container is deployed == + * Protocol: http, https, ajp, etc. + * Ports: listening and security redirections) + * Interface: Optional host and/or IP interfaces to bind to. + * Threads: Min, Max, aging, etc. + * Timeouts: Persist and Idle times. -This should have no dependancies, but will lazily discover JNDI services etc as needed. The container configuration would include such things as a default web.xml to load for all webapps. -== A web connector is deployed == +== Virtual hosts == +Virtual hosts must be able to be defined within geronimo web containers, defined by one or more +host and/or domain names. Virtual hosts may be configured for logging, security, statistics, etc. -This will depend on a webcontainer being deployed. The exact way one of multiple containers is selected is yet to be determined - but there will be a default method, plus an option to be specific in the configuration. The configuration of the web connector will contain many common parameters: +A webapp may be targetted to a specific virtual host at deployment time. If a targeted virtual +host does not exist, this may result in either a validation error or the creation of a +dynamic virtual host with default configuration. - protocol name:: http, https, ajp, etc. - port:: to listen on - interface:: optional interface to listen on - max connection:: ??? - max idle persistance time:: ??? - required contexts:: names of contexts that must be registered and started with container before the connector accepts any connections -But it will also need to allow configuration for connector specific parameters. I assume this can be done by a getInitParameter style map - but maybe something more typed or verifiable can be used - I'll wait and see how the service configuraton mechanism develops. +== Physical hosts == +The deployment of a web app may be targetted deploy against a specific subset of web connectors, +so that it will be available only on specific physical interfaces, ports, protocols etc. +Typically this will be to allow additional network security to be applied to administration +and/or web services interfaces. -I don't expect the webconnector service to actually implement the connector - as JMX is not really the right sort of bus to push HTTP
[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T13:38:58 Editor: 203.45.72.167 Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -2,12 +2,15 @@ [[TableOfContents]] = Overview = + The implementation of the Geronimo web tier will be guided by the use cases outlined below. It is the intent of this project to meet these use-cases without resorting to implementation specific configuration. = Use Cases = + == Webapp Deployment == + A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. @@ -19,6 +22,7 @@ Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases. == Connector Configuration == + The default and/or additional HTTP connectors for the default geronimo web container will be configured and managed via standard geronimo mechanisms. The majority of common parameters, statistics and JSR77 lifecycle commands for HTTP connectors will be able to be managed without using implementation specific configuration or @@ -32,6 +36,7 @@ == Virtual hosts == + Virtual hosts must be able to be defined within geronimo web containers, defined by one or more host and/or domain names. Virtual hosts may be configured for logging, security, statistics, etc. @@ -41,6 +46,7 @@ == Physical hosts == + The deployment of a web app may be targetted deploy against a specific subset of web connectors, so that it will be available only on specific physical interfaces, ports, protocols etc. Typically this will be to allow additional network security to be applied to administration @@ -48,13 +54,16 @@ == Web Component Dependencies == + It will be possible to define dependencies between web components and web applications: + * A web connector may be dependent one or more web applications. Thus until all the webapps are started, a dependent web connector will not be started. If the web application is stopped, then the dependent web connector will also be stopped and the node will be unavailable. This will allow a geronimo node to enter/leave a web cluster based on application availability rather than connector availability. * A webapp may be dependent on another webapp, so that a webapp that uses the resources of another will only be started if the webapp on which it depends is started. == Web Services == + Other geronimo components may define a web service interfaces. In order to deploy these components, some web infrastructure (connectors, SOAP servlet) may need to be initialized, perhaps dynamically. Ideally this will not be within the default web container, as this is unlikely to have desirable @@ -67,8 +76,10 @@ == Components == + The geronimo web tier will be composed of JSR77 components that may be aggregated into various configurations. These subservices will include: + * Web applications: Directories, WARs, WARs within EARs, dynamically created * Web connectors: HTTP, HTTPS, AJP, etc. * Web request logs: NCSA format, file, DB, etc. @@ -76,6 +87,7 @@ * Realms: JACC, Single sign on. * Web container: A collection of other web components. * Virtual host: A partitioning of a web container + These components may be implemented as components only for the purposes of Geronimo configuration and management. The actual implementation may actually be decomposed differently (or not at all), but such details will be hidden from the average @@ -83,6 +95,7 @@ == Web Container == + A web container is the deployment target of a webapplication. All webapplications that are deployed in the same web container will share the following services and configuration: @@ -92,17 +105,16 @@ * realm * session manager * collection of virtual hosts -A Geronimo server may have multiple web containers deployed. A single web container may -be configured as the default web container for the server. -All web components may optionally name (by ObjectName) the web container they are for. If +A Geronimo server may have multiple web containers deployed. A single web container may +be configured as the default web container for the server. All web components may optionally name (by ObjectName) the web container they are for. If a web component does not name a web container, then it is for the default container. - Only ServletContexts deployed within the same web container are visible to the ServletContext.getContext() API. == Virtual Host == + A web container may be
[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T13:40:44 Editor: 203.45.72.167 Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -11,13 +11,9 @@ == Webapp Deployment == -A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. +A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container. All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. -All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor. EJBs deployed within an EAR that use link resolution should also be able to be resolved. - -An optional WEB-INF/geronimo-web.xml deployment will be required to configure any additional jndi resources and resource-refs. - -The context path will be set by the EAR application.xml, the WAR filename, the directory filename or by a geronimo configuration element. +An optional WEB-INF/geronimo-web.xml deployment will be required to configure any additional jndi resources and resource-refs. The context path will be set by the EAR application.xml, the WAR filename, the directory filename or by a geronimo configuration element. Optional WEB-INF/impl-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases.
[Apache Geronimo Wiki] Updated: Architecture/WebContainer
Date: 2004-01-27T14:04:43 Editor: 203.45.72.167 Wiki: Apache Geronimo Wiki Page: Architecture/WebContainer URL: http://wiki.apache.org/geronimo/Architecture/WebContainer no comment Change Log: -- @@ -5,7 +5,8 @@ The implementation of the Geronimo web tier will be guided by the use cases outlined below. It is the intent of this project to meet these use-cases without resorting to implementation specific -configuration. +configuration. Specifically, these are actions that typical geronimo users are likely to perform and should be able to be documented, supported and managed as geronimo actions, rather than anything +specific to the underlying implementation of the web container. = Use Cases = @@ -46,7 +47,11 @@ The deployment of a web app may be targetted deploy against a specific subset of web connectors, so that it will be available only on specific physical interfaces, ports, protocols etc. Typically this will be to allow additional network security to be applied to administration -and/or web services interfaces. +and/or web services interfaces. + +For good default security, the default geronimo configuration should start administrative +interfaces such as the jmx console are only available on localhost and on a port that is +distinct from the default web application deployment. == Web Component Dependencies == @@ -64,6 +69,13 @@ some web infrastructure (connectors, SOAP servlet) may need to be initialized, perhaps dynamically. Ideally this will not be within the default web container, as this is unlikely to have desirable default security implications. + +== Run states == + +Management of a cluster may need additional run states than those defined in JSR77. Gentle shutdown of +nodes may required modes where no new requests/connections/sessions are accepted by a node, while +existing requests/connections/sessions are allowed to complete. These modes may need to be applied +to web connectors and/or webapplications. = Architecture =
