This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • KIP-5 Renaming of Knox Class Packages
Skip to end of metadata
Go to start of metadata

Status

Current stateComplete

Discussion thread

JIRAKNOX-998

Motivation

As we target a 1.0.0 release, it seems important to repackages in order to remove "hadoop" from the class packages throughout the Apache Knox codebase.
Currently, the package is some derivative of "org.apache.hadoop.gateway...". The intent of this improvement is to make the class packages rooted at "org.apache.knox.gateway...".
Doing this prior to or as part of a 1.0.0 release makes sense given backward compatibility commitments that should normally be associated with major release numbers.
In reality, Apache Knox has been committed to backward compatibility for a long time anyway.
We will have to determine what is needed to be backward compatible for any consumers that have extended our existing classes however.

Improvements

1. Rename class packages to org.apache.knox.gateway

Modules should reflect appropriate subpackages as well. Let's determine a convention for package naming based on the grouping of client facing services in Knox.

We can discuss whether the subpackage conventions are really necessary.

  1. Proxying Services
    1. services
    2. applications
    3. websockets
  2. Authentication Services
    1. providers
      1. authentication/federation
      2. authorization
      3. core
        1. identity assertion
        2. hostmapping
        3. webappsec
  3. Client Services
    1. shell
    2. sdk
    3. request
    4. response
    5. session
    6. collectors

2. Provide Adapter classes for any classes that have likely been extended by consumer

Determining the specific classes that are currently being extended by our consumers is going to be a bit tricky.

There are a number of classes that are explicitly intended to be extended and I will try and list a few here.

Tests should help identify others.

We will need to provide adapter classes and should deprecate them from the start in order to facilitate a migration away from the old packages.

 

 

  • No labels