Skip to content

Behavior Changes

Jump to bottom
Adam Yoho edited this page Jul 23, 2024 · 6 revisions

WebSphere policy is that we do not introduce behavior changes into the WebSphere Application Server traditional (tWAS) service stream or to existing Liberty features unless approved. In other words, you can only make behavior changes in a new tWAS major version, or in a new Liberty feature version.

Closely related to the zero-migration architecture of Open Liberty, behavior changes in existing features are not permitted outside of security fixes.

What is a behavior change?

A behavior change is a change in a piece of function where the new behavior is enabled by default and the old behavior is something a customer might reasonably be relying on.

Some examples of unacceptable behavior changes:

  1. Changes to any default behavior or non-default behavior controlled by published server configuration elements.

    Note: This applies even if the current behavior is not specification compliant.

  2. Changes to message identifiers (e.g. CWWKF0011I).

    ... But not message text.

  3. Changes in the type of exceptions returned in any API or SPI.

Notes

  1. Fixing functionality that is considered "broken" or "not working as designed" might still be considered a behavior change.

    Customers might have encountered the "wrong" behavior and coded their applications or environment to that behavior. Changing that behavior would then break those customers.

  2. If the new behavior does not occur automatically (such as if the new behavior is only enabled via a new property), then it is NOT a behavior change.

  3. If the new behavior occurs automatically, then consider whether the behavior is something a customer might reasonably be relying on.

What do I do if I think something is a behavior change?

If you have some concern that a change may be a breaking behavior change, open an issue to start a discussion and tag @OpenLiberty/admin.

FAQs

  1. Wouldn't all release bug issues that are fixed be considered behavior changes?

    No, at least not to the point of meriting this scrutiny.

    Easy example: There's a bug that causes the server to intermittently crash. You fix that bug such that the server no longer intermittently crashes. That fix is not considered a behavior change because there isn't a reasonable scenario where a customer could be relying on the server intermittently and arbitrarily crashing.

    Real Open Liberty example: JWK parsing does not tolerate leading whitespace #29086 was opened to track a bug where Liberty failed to correctly parse a JSON Web Key (JWK) document if that document had leading whitespace characters. To use this functionality, customers need to configure a jwkEndpointUrl configuration attribute. When configuring that attribute, customers have proactively directed Liberty to fetch and parse JWK documents, and they expect Liberty to correctly do so. A JWK document that happens to have extra whitespace at the beginning is not unreasonable. With the existing behavior, Liberty failed to parse the JWK document and emitted an error message. Updating Liberty to tolerate that whitespace and correctly parse the JWK document changes the behavior, yes, but it fixes behavior that a customer specifically configured Liberty to do.

Clone this wiki locally