[Apache Geronimo Wiki] Updated: Architecture/AOP
Date: 2004-03-02T01:05:35 Editor: 213.113.223.206 Wiki: Apache Geronimo Wiki Page: Architecture/AOP URL: http://wiki.apache.org/geronimo/Architecture/AOP no comment Change Log: -- @@ -23,7 +23,8 @@ Which concerns/system aspects should we focus on? -AspectWerkz is licensed under a QPL style licence. Isn't this incompatible the apache licence? +Q: AspectWerkz is licensed under a QPL style licence. Isn't this incompatible the apache licence? +A: Not anymore. AW is licensed under LGPL. = Definition =
[Apache Geronimo Wiki] Updated: Architecture/AOP
Date: 2004-03-02T01:06:50 Editor: 213.113.223.206 Wiki: Apache Geronimo Wiki Page: Architecture/AOP URL: http://wiki.apache.org/geronimo/Architecture/AOP no comment Change Log: -- @@ -24,6 +24,7 @@ Which concerns/system aspects should we focus on? Q: AspectWerkz is licensed under a QPL style licence. Isn't this incompatible the apache licence? + A: Not anymore. AW is licensed under LGPL. = Definition =
[Apache Geronimo Wiki] Updated: Architecture
Date: 2004-02-22T10:23:23 Editor: JeremyBoynes [EMAIL PROTECTED] Wiki: Apache Geronimo Wiki Page: Architecture URL: http://wiki.apache.org/geronimo/Architecture no comment Change Log: -- @@ -27,3 +27,4 @@ * [wiki:/Validator Validator] * [wiki:/WebContainer Web Container] * [wiki:/WebServices Web Services] + * [wiki:/WorkManager Work Manager]
[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/Management
Date: 2004-01-28T02:20:47 Editor: 193.172.11.178 Wiki: Apache Geronimo Wiki Page: Architecture/Management URL: http://wiki.apache.org/geronimo/Architecture/Management Just changed the Sun's JMX mailing list's name Change Log: -- @@ -49,4 +49,4 @@ One of the best places to learn the basics of JMX is Juha Lindfors' book _Managing J2EE with Java Managment Extensions_. The JMX specification is also the best, most definitive reference of what JMX is, but OReilly's got a good book out which covers it in more depth (and is more recent than Juha's book). Juha's is still a great reference, though. -You might also consider joining Sun's JMX-Discuss list and the [http://sourceforge.net/mail/?group_id=47745 MX4J] lists. +You might also consider joining Sun's JMX-Forum list and the [http://sourceforge.net/mail/?group_id=47745 MX4J] lists.
[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 =
[Apache Geronimo Wiki] Updated: Architecture/AOP
Date: 2003-12-29T13:00:01 Editor: 192.148.125.11 Wiki: Apache Geronimo Wiki Page: Architecture/AOP URL: http://wiki.apache.org/geronimo/Architecture/AOP no comment Change Log: -- @@ -22,6 +22,7 @@ = Concerns/system aspects = Which concerns/system aspects should we focus on? + AspectWerkz is licensed under a QPL style licence. Isn't this incompatible the apache licence? = Definition =
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T17:52:22
Editor: 66.187.3.41
Wiki: Apache Geronimo Wiki
Page: Architecture/Validator
URL: http://wiki.apache.org/geronimo/Architecture/Validator
no comment
Change Log:
--
@@ -1,4 +1,4 @@
-There is a validation framework under {{{org.apache.geronimo.validator}}}. A
validator would be used, for example, to make sure an EJB JAR, WAR, etc. has
all necessary classes, complies with all the spec rules, and so on. Each
validator would be run when a library of the appropriate type is deployed (or
could be run by tools at configuration time, etc.).
+There is a validation framework under {{{org.apache.geronimo.validator}}}
''(in modules/core)''. A validator would be used, for example, to make sure an
EJB JAR, WAR, etc. has all necessary classes, complies with all the spec rules,
and so on. Each validator would be run when a library of the appropriate type
is deployed (or could be run by tools at configuration time, etc.).
The idea here is that we define the individual validators, and then people can
write any number of tests for each one. The tests will work kind of like
JUnit, in that you can define a test class with many individual tests in it.
But there are a couple abstract methods to implement. Here's what a test class
looks like:
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T18:55:00 Editor: 66.187.3.41 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -84,9 +84,9 @@ A preliminary list of requirements: - * Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would '''ignore''' ''(or flag as errors/warnings?)'' '''known''' enhancements or modifications from other application servers (Websphere, Weblogic, Orion, ...). ''(The word known is there for a reason, tracking all the changes that Websphere puts in to allow porting from Websphere to Geronimo could be a problem.)'' + * Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would '''ignore''' ''(or flag as errors/warnings?)'' '''known''' enhancements or modifications from other application servers (Websphere, Weblogic, Orion, ...). ''(The word known is there for a reason, tracking all the changes that Websphere puts in to allow porting from Websphere to Geronimo could be a problem.)'' This allows existing applications to be ported/installed in Geronimo. - * Specifications supported ''(feel free to add or delete as appropriate)'': + * Specifications supported ''(feel free to add or delete as appropriate)'' ''See also the J2EE Specifications page'': * Deployment: JSR-88 1.1
[Apache Geronimo Wiki] Updated: Architecture/Configuration
Date: 2003-12-26T07:16:23 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Configuration URL: http://wiki.apache.org/geronimo/Architecture/Configuration no comment Change Log: -- @@ -3,7 +3,7 @@ = Overview = -This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see Configuration/AsFlatFile and Configuration/AsRegistry for two alternative approaches to how this can be achieved. +This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see ConfigurationAsFlatFile and ConfigurationAsRegistry for two alternative approaches to how this can be achieved. Some kind of ConfigurationAgent would probably be beneficial so that either ConfigurationAsFlatFile or ConfigurationAsRegistry could be used, and that early development could be achieved without relying on either approach to be taken.
[Apache Geronimo Wiki] Updated: Architecture/Configuration
Date: 2003-12-26T07:23:32 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Configuration URL: http://wiki.apache.org/geronimo/Architecture/Configuration no comment Change Log: -- @@ -3,7 +3,8 @@ = Overview = -This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see ConfigurationAsFlatFile and ConfigurationAsRegistry for two alternative approaches to how this can be achieved. +This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see [wiki:/Architecture/Configuration/AsFlatFile Configuration/AsFlatFile] + and ConfigurationAsRegistry for two alternative approaches to how this can be achieved. Some kind of ConfigurationAgent would probably be beneficial so that either ConfigurationAsFlatFile or ConfigurationAsRegistry could be used, and that early development could be achieved without relying on either approach to be taken.
[Apache Geronimo Wiki] Updated: Architecture/Configuration
Date: 2003-12-26T07:24:30 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Configuration URL: http://wiki.apache.org/geronimo/Architecture/Configuration no comment Change Log: -- @@ -3,7 +3,7 @@ = Overview = -This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see [wiki:/Architecture/Configuration/AsFlatFile Configuration/AsFlatFile] +This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see [wiki:/AsFlatFile Configuration/AsFlatFile] and ConfigurationAsRegistry for two alternative approaches to how this can be achieved. Some kind of ConfigurationAgent would probably be beneficial so that either ConfigurationAsFlatFile or ConfigurationAsRegistry could be used, and that early development could be achieved without relying on either approach to be taken.
[Apache Geronimo Wiki] Updated: Architecture/Configuration
Date: 2003-12-26T07:39:55 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Configuration URL: http://wiki.apache.org/geronimo/Architecture/Configuration no comment Change Log: -- @@ -3,16 +3,15 @@ = Overview = -This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see [wiki:/AsFlatFile Configuration/AsFlatFile] - and ConfigurationAsRegistry for two alternative approaches to how this can be achieved. +This page discusses some of the configuration options that can be used to configure Geronimo. In the first instance, this can be used to describe how configuration can be changed; see [wiki:/AsFlatFile Configuration/AsFlatFile] and [wiki:/AsRegistry Configuration/AsRegistry] for two alternative approaches to how this can be achieved. -Some kind of ConfigurationAgent would probably be beneficial so that either ConfigurationAsFlatFile or ConfigurationAsRegistry could be used, and that early development could be achieved without relying on either approach to be taken. +Some kind of ConfigurationAgent would probably be beneficial so that either [wiki:/AsFlatFile Configuration/AsFlatFile]or [wiki:/AsRegistry Configuration/AsRegistry] could be used, and that early development could be achieved without relying on either approach to be taken. -- AlexBlewitt Ultimately I think a hybrid of both systems combining their advantages may be the best solution. -Use the ConfigurationAsFlatFile approach to provide default configurations for components as they are being distributed. On deployment, the ConfigurationAsFlatFile config is imported into a ConfigurationAsRegistry which is used for online modifications. +Use the [wiki:/AsFlatFile Configuration/AsFlatFile]approach to provide default configurations for components as they are being distributed. On deployment, the [wiki:/AsFlatFile Configuration/AsFlatFile] config is imported into a [wiki:/AsRegistry Configuration/AsRegistry] which is used for online modifications. -- Jeremy Boynes
[Apache Geronimo Wiki] Updated: Architecture/Configuration
Date: 2003-12-26T07:41:48 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Configuration URL: http://wiki.apache.org/geronimo/Architecture/Configuration no comment Change Log: -- @@ -36,7 +36,7 @@ You then run into questions like whether the XML file is the main config, or whether the repository is the main config. If I restart the server, I expect it to see the same configuration it had when it went down, which means using the one with the most changes. If you re-load the XML file each time, it may over-write changes made by the server to the repository. -Note that some of these ideas can be persisted if you use a ConfigurationAsRegistry and it uses JNDI over a flat-file based storage system in any case. +Note that some of these ideas can be persisted if you use a [wiki:/AsRegistry Configuration/AsRegistry] and it uses JNDI over a flat-file based storage system in any case. -- AlexBlewitt
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T08:22:17 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -84,9 +84,9 @@ A preliminary list of requirements: -* Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (WebSphere, WebLogic, Orion, ...). +* Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). -* Validation will operate on applications (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator. +* Validation will operate on application components (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator. * Executing the validator will be available ''(mandatory?)'' as a part of the installation processs (presumably via the user interface in the Management Client).
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T08:32:42 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -84,7 +84,15 @@ A preliminary list of requirements: -* Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). +* Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). Specifically the list of specifications is ''(please add or delete as appropriate)'': + +* Enterprise Java Beans: EJB 2.1, ELB 1.1 + +* Java Message Service: JMS 1.1 + +* J2EE Connector Architecture: JCA 1.5 + +* Soap With Attachments: SAAJ 1.2 * Validation will operate on application components (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator.
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T08:33:41 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -84,7 +84,7 @@ A preliminary list of requirements: -* Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). Specifically the list of specifications is ''(please add or delete as appropriate)'': + * Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). Specifically the list of specifications is ''(please add or delete as appropriate)'': * Enterprise Java Beans: EJB 2.1, ELB 1.1 @@ -94,11 +94,11 @@ * Soap With Attachments: SAAJ 1.2 -* Validation will operate on application components (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator. + * Validation will operate on application components (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator. -* Executing the validator will be available ''(mandatory?)'' as a part of the installation processs (presumably via the user interface in the Management Client). + * Executing the validator will be available ''(mandatory?)'' as a part of the installation processs (presumably via the user interface in the Management Client). -* Errors and warnings would be collected inside the application server, and will be visible to the user interface of the Management Client. (Should errors and warnings persist? If so, where? - Probably not, if you want a current set of errors, rerun the validator.) + * Errors and warnings would be collected inside the application server, and will be visible to the user interface of the Management Client. (Should errors and warnings persist? If so, where? - Probably not, if you want a current set of errors, rerun the validator.) -- David Farb
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T08:40:35 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -84,7 +84,11 @@ A preliminary list of requirements: - * Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would specifically '''ignore''' ''(or flag as errors/warnings?)'' all configuration file enhancements from other application servers (Websphere, Weblogic, Orion, ...). Specifically the list of specifications is ''(please add or delete as appropriate)'': + * Validation will be supported for multiple versions of relevant specifications (EJB 2.1, EJB 1.1, ... ''list to be defined''), but would '''ignore''' ''(or flag as errors/warnings?)'' '''known''' enhancements or modifications from other application servers (Websphere, Weblogic, Orion, ...). ''(The word known is there for a reason, tracking all the changes that Websphere puts in to allow porting from Websphere to Gernonimo could be a problem.)'' + + * Specifications supported ''(feel free to add or delete as appropriate)'': + +* Deployment: JSR-88 1.1 * Enterprise Java Beans: EJB 2.1, ELB 1.1
[Apache Geronimo Wiki] Updated: Architecture/Validator
Date: 2003-12-26T09:00:44 Editor: 63.240.163.227 Wiki: Apache Geronimo Wiki Page: Architecture/Validator URL: http://wiki.apache.org/geronimo/Architecture/Validator no comment Change Log: -- @@ -100,9 +100,9 @@ * Validation will operate on application components (EJBs, WARs, ...) as well as system components (data sources, connectors, ...). Validation of the application server configuration is the responsibility of application server components, '''NOT''' the validator. - * Executing the validator will be available ''(mandatory?)'' as a part of the installation processs (presumably via the user interface in the Management Client). + * Executing the validator will be available ''(mandatory?)'' as a part of the installation processs (presumably via the user interface in the [wiki:Architecture/Management/Client Management/Client]). - * Errors and warnings would be collected inside the application server, and will be visible to the user interface of the Management Client. (Should errors and warnings persist? If so, where? - Probably not, if you want a current set of errors, rerun the validator.) + * Errors and warnings would be collected inside the application server, and will be visible to the user interface of the [wiki:Architecture/Management/Client Management/Client]. (Should errors and warnings persist? If so, where? - Probably not, if you want a current set of errors, rerun the validator.) -- David Farb
[Apache Geronimo Wiki] Updated: Architecture/Security/Communications
Date: 2003-12-21T15:24:43 Editor: 67.127.53.240 Wiki: Apache Geronimo Wiki Page: Architecture/Security/Communications URL: http://wiki.apache.org/geronimo/Architecture/Security/Communications no comment Change Log: -- @@ -43,4 +43,6 @@ Alan +The Liberty Alliance protocols embraced/extended SAML, and now much of the new functionality Liberty added will be put back into SAML v2. This is a good thing. +john beatty
