Schedule for the Metro 2.1 Unified Configuration Feature

Description

As part of this feature we plan to introduce a new single configuration file for all domains and all configuration options of the Metro stack as opposed to current approach that may require users to use multiple configuration files to configure a single web service. The new configuration file format should also be better aligned with the standard webservices.xml format as defined in JSR 109. As part of the feature we plan to design mechanisms that would allow us to provide unified support for other deployment descriptors, with an initial focus on the support for the WebLogic Web Services deployment descriptors.

GlassFish 3.1 Target Milestones

GlassFishV3Schedule#GlassFishV3Schedule-GlassFishServerOpenSourceEdition3.1

Task List

Summary for GlassFish 3.1

Task Description

Parse metro-webservices.xml

• Implement parsing code using StAX. JAXB is not an option because the schema should be easily extensible (see also SPI to Allow Addition of New Elements to metro-webservices.xml ).
• Use a RelaxNG schema to validate the document. A XML schema can be generated automatically from RelaxNG using Trang.

Provide Configuration as WebServiceFeatures

• Translate configuration elements into WebServiceFeatures.
• Introduce WebServiceFeatures that can be assigned to operations and messages. Currently, WebServiceFeatures are designed for an entire port/endpoint.

SPI to Allow Addition of New Elements to metro-webservices.xml

• Both for internal development and eventually for external developers extending the Metro implementation, it is impractical to hardwire all the configuration settings in metro-webservices.xml. It should be possible to add new code to handle new settings using the META-INF service lookup mechanism.

Parse webservices.xml

• Even in non-JSR 109 deployments, we want to allow the use of webservices.xml. This way we don't have to duplicate settings in metro-webservices.xml. It still needs to be investigated if we can copy or reuse code from GlassFish. If we have to write our own code, we could parse using StAX or JAXB. The webservices.xml schema is fixed and we don't need to provide an extension mechanism.

Enforce Order of Precedence When Initializing WebServiceFeatures

• metro-webservices.xml takes precedence over other configuration files. This precedence does not necessarily need to be expressed in the API but the implementation must enforce it without having to add new code when new configuration settings are added.

Migrate metro.xml Into metro-webservices.xml

• metro-webservices.xml will incorporate the tubeline settings that are now done through metro.xml.
• metro.xml must be ignored when metro-webservices.xml is present.

Migrate WSIT Config Files Into metro-webservices.xml

• metro-webservices.xml will incorporate the settings that are now done through WS-Policies in wsit-<endpoint>.xml, wsit-client.xml and WSDL.
• The WSIT WS-Policies must be ignored when metro-webservices.xml is present.

Use WebServiceFeatures

• WSIT relies mostly on the PolicyMap for the configuration of its features. Where feasible, the WSIT module implementations should use the corresponding WebServiceFeatures instead. The security policy module will for now still rely on WS-Policy since changing that layer would be too much work.

Migrate JAX-WS RI Config Files into metro-webservices.xml

• sun-jaxws.xml shall be superseded by metro-webservices.xml.

Change JAX-WS RI to Generate New WS-Policies in WSDL

• Right now, JAX-WS tries to publish WSDL as is (with a few necessary adjustments like the port address and removal of private policies). We want to change that so that the WSDL published by JAX-WS always contains the policies that reflect the internal configuration state.