Skip to end of metadata
Go to start of metadata

Schedule for the Metro 2.1 Unified Configuration Feature


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


Milestone Start Date (mm/dd/yy) End Date (mm/dd/yy) Description
Milestone 3   7/19/2010 Most P1 features complete
Milestone 4   8/18/2010 SCF for cluster infrastructure and high availability, All P1 features complete, Low P1 bug count
Milestone 5   09/14/2010 SCF for remaining areas, All features complete, Zero P1 bug count
JavaOne break 09/19/2010 09/23/2010  
Milestone 6   11/22/2010 Hard code freeze (HCF), Zero P1-P3 bug count

Task List

Summary for GlassFish 3.1

Task Description

Parse metro-webservices.xml

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.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.