Version 4x release notes

April 24, 2014 - March 6, 2014 

This date range is incorrect.

 


Release 4.1.5 (4/24/2014: SLF4j HTTP Logging filter)

Summary T P Status Resolution
Loading...
Refresh

New features

  1. New SLF4j HTTP Logging filter, this filter will replace the HTTP Logging filter as it does the same thing, but gives you significantly more flexibility. You can configure any Log4j appender to output the information from the filter. REP-11 - Getting issue details... STATUS
    1. The HTTP Logging Filter is now marked deprecated.
  2.  Non-Tenanted Authentication: Remove Tenant Exists check on Validate Token Call REP-4 - Getting issue details... STATUS
    1. Added <ignore-tenant-roles> to Client Authentication filter.
  3.  Non-Tenanted Authorization: Remove Tenant Comparison to URI for Users with a service-admin-roles REP-5 - Getting issue details... STATUS
  4. Removed some permissions and ownership changes that RPM's made on installation.   REP-15 - Getting issue details... STATUS

Bug fixes

  •  We no longer modify /usr/bin/ to tomcat:repose in the repose-cli-utils package. REP-15 - Getting issue details... STATUS

Known Issues

  1. Rate limiting data may be corrupted if multiple limits share the same limit ID value. To avoid this issue, all group IDs and limit IDs should be unique. See  REP-2233 - Getting issue details... STATUS

Release 4.0.0 (3/14/2014: Rate Limiting Structure Change, Health Check Service, Bug Fixes)

This release contains breaking changes, and is not backwards compatible with previous releases.

Rate Limiting now implements a time block approach rather than a sliding window. Users must re-evaluate their rate limiting configurations for this release.

API Validator Filter

  • Configuration File Versioning has been deprecated. Specifically, the API Validation configuration attribute "version" is no longer valid. Users without this attribute will not be affected.
  • XSL Engine configuration now only accepts "Xalan", "XalanC", "SaxonHE", "SaxonEE". The attribute "Saxon" has been removed for the more specific options.
  • The "use-saxon" attribute has been replaced with the "xsd-engine" attribute

New Features

  1. Rate Limiting - Now implements a time block approach rather than a sliding window. These changes bring greater consistency, more reliable rate limiting, performance and memory footprint improvements.
    1. Up to 2x-1 requests may pass through the rate-limiting filter during one random unit of time but the average rate of requests accepted will be less than or equal to x (where x is the configured limit)
    2. All limits in a limit group will be applied to each request. If a limit rejects the request, subsequent limits in the group will not apply. Precedent limits will have already been applied.
    3. Limits no longer require a unique combination of URI-regex and methods. Consequently, limits are more flexible, and may be defined however the user sees fit (as long as a unique ID is provided)
  2. Health Check Service - a centralized way for Repose to report and resolve issues

In-Flight Features

  1. Distributed Datastore Service - modularizing code to support future pluggability of new datastore implementations
    1. Replicated Datastore Filter - as of this release, this filter no longer exists in Repose.  Usage of this filter ("replicated-datastore") will cause Repose failures during startup.  Usage of this filter by the Rate Limiting filter (datastore="distributed/replicated") will cause Repose failures during startup.
  2. Flattening pom.xml files - We're simplifying the Maven pom files to reduce dependencies and make modules more flexible. This should not affect customers. (B-62766)

Bug Fixes

  1. API Validator Filter
    1. Versioning has been removed in response to (Versioning of the Api Validator filter currently does not work. To set the XSD engine, please use the 'xsd-engine' attribute instead of 'use-saxon')
  2. URI Stripper Filter
    1. It will now properly re-inject the stripped token back into the location header. Prior to this release, if the token is found somewhere else in the location header (/products/items/123, where 123 was stripped after products (token 2), it would not have been injected back into the location header, because it would've found the token after items.)

Known Issues

  1. Rate limiting data may be corrupted if multiple limits share the same limit ID value. To avoid this issue, all group IDs and limit IDs should be unique. See  REP-2233 - Getting issue details... STATUS