[jira] [Updated] (KNOX-1149) HBase High Availability Fails with Kerberos Secured Cluster

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1149:
--
Fix Version/s: (was: 0.14.1)
   (was: 1.0.0)
   1.1.0

> HBase High Availability Fails with Kerberos Secured Cluster
> ---
>
> Key: KNOX-1149
> URL: https://issues.apache.org/jira/browse/KNOX-1149
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
> Fix For: 1.1.0
>
> Attachments: KNOX-1149.patch
>
>
> When HBase is run on a Kerberos secured cluster, the registration of the 
> Region Servers is stored in ZooKeeper under a different path.  The 
> HBaseZookeeperURLManager class used to support high availability in Knox 
> needs to be updated to look in both locations and then ping for availability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1149) HBase High Availability Fails with Kerberos Secured Cluster

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317606#comment-16317606
 ] 

Larry McCay commented on KNOX-1149:
---

Okay, I think that we should actually move it to Major as it is really broken.
Since there are a couple workarounds and you don't mind deferring it, I'll move 
it to 1.1.0 for now.

> HBase High Availability Fails with Kerberos Secured Cluster
> ---
>
> Key: KNOX-1149
> URL: https://issues.apache.org/jira/browse/KNOX-1149
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 1.0.0, 0.14.1
>
> Attachments: KNOX-1149.patch
>
>
> When HBase is run on a Kerberos secured cluster, the registration of the 
> Region Servers is stored in ZooKeeper under a different path.  The 
> HBaseZookeeperURLManager class used to support high availability in Knox 
> needs to be updated to look in both locations and then ping for availability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1149) HBase High Availability Fails with Kerberos Secured Cluster

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1149:
--
Priority: Major  (was: Minor)

> HBase High Availability Fails with Kerberos Secured Cluster
> ---
>
> Key: KNOX-1149
> URL: https://issues.apache.org/jira/browse/KNOX-1149
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
> Fix For: 1.0.0, 0.14.1
>
> Attachments: KNOX-1149.patch
>
>
> When HBase is run on a Kerberos secured cluster, the registration of the 
> Region Servers is stored in ZooKeeper under a different path.  The 
> HBaseZookeeperURLManager class used to support high availability in Knox 
> needs to be updated to look in both locations and then ping for availability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1149) HBase High Availability Fails with Kerberos Secured Cluster

[Rick Kellogg (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317591#comment-16317591
 ] 

Rick Kellogg commented on KNOX-1149:


I can state that under HDP 2.6, the HBase Region Servers are listed under a 
different path.  So it is fundamentally broken with HDP at least.  

If someone were to set the value explicitly in the hbase-site.xml file they 
could work around the issue.  Another option is explicitly listing the URLs 
under the service which defeats the HA feature.  No objections to deferral as I 
am testing another fix related to the ping operation with Kerberos as well.  
More to report tomorrow after I do some more testing.

> HBase High Availability Fails with Kerberos Secured Cluster
> ---
>
> Key: KNOX-1149
> URL: https://issues.apache.org/jira/browse/KNOX-1149
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 1.0.0, 0.14.1
>
> Attachments: KNOX-1149.patch
>
>
> When HBase is run on a Kerberos secured cluster, the registration of the 
> Region Servers is stored in ZooKeeper under a different path.  The 
> HBaseZookeeperURLManager class used to support high availability in Knox 
> needs to be updated to look in both locations and then ping for availability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1149) HBase High Availability Fails with Kerberos Secured Cluster

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317581#comment-16317581
 ] 

Larry McCay commented on KNOX-1149:
---

[~rkellogg] - we are descoping 1.0.0 to make sure it is as functionally similar 
to 0.14.0 as possible. I am curious whether your Minor priority here is 
accurate. It seems like it is pretty broken for secure clusters this way. 

Is there a workaround that I am unaware of?


> HBase High Availability Fails with Kerberos Secured Cluster
> ---
>
> Key: KNOX-1149
> URL: https://issues.apache.org/jira/browse/KNOX-1149
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 1.0.0, 0.14.1
>
> Attachments: KNOX-1149.patch
>
>
> When HBase is run on a Kerberos secured cluster, the registration of the 
> Region Servers is stored in ZooKeeper under a different path.  The 
> HBaseZookeeperURLManager class used to support high availability in Knox 
> needs to be updated to look in both locations and then ping for availability.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1150) Documentation - Hadoop Group Lookup Provider - Add Link to Hadoop Group Mappings

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1150:
--
Fix Version/s: 1.0.0

> Documentation - Hadoop Group Lookup Provider - Add Link to Hadoop Group 
> Mappings
> 
>
> Key: KNOX-1150
> URL: https://issues.apache.org/jira/browse/KNOX-1150
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.11.0, 0.12.0, 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Priority: Minor
> Fix For: 1.0.0
>
>
> The Knox User Guide, Hadoop Group Lookup Provider section should include a 
> mention/link to the Hadoop Group Mappings section of their documentation:
> https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/GroupsMapping.html
> There are lots of other providers supported.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1152) Guard Against Missing Subject in Identity Assertion

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1152:
--
Fix Version/s: (was: 0.14.1)
   (was: 1.0.0)
   1.1.0

> Guard Against Missing Subject in Identity Assertion
> ---
>
> Key: KNOX-1152
> URL: https://issues.apache.org/jira/browse/KNOX-1152
> Project: Apache Knox
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 0.11.0, 0.12.0, 0.13.0, 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: KNOX-1152B.patch
>
>
> Within the CommonIdentityAssertionFilter class, it is possible the evaluation 
> of the Subject can return null.  A check should be added for this, error 
> logged and IllegalStateException exception thrown.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1164) bug fix on oozieui rewrite rul

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1164:
--
Fix Version/s: 1.1.0

> bug fix on oozieui rewrite rul
> --
>
> Key: KNOX-1164
> URL: https://issues.apache.org/jira/browse/KNOX-1164
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Wei Han
> Fix For: 1.1.0
>
> Attachments: 0001-oozieUI-rewrite-rule-fix.patch
>
>
> Fix a bug introduced in https://issues.apache.org/jira/browse/KNOX-1106. The 
> issue is that pattern is always required at the top level definition 
> otherwise the rule won't be effective: 
> https://github.com/apache/knox/blob/5515056406afd48a6b55f4188fe80816c2133744/gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/api/UrlRewriteProcessor.java#L92



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1154) Dump Kerberos Configuration on Gateway Startup to Logs

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1154:
--
Fix Version/s: 1.1.0

> Dump Kerberos Configuration on Gateway Startup to Logs
> --
>
> Key: KNOX-1154
> URL: https://issues.apache.org/jira/browse/KNOX-1154
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.14.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
>  Labels: security
> Fix For: 1.1.0
>
> Attachments: KNOX-1154.patch
>
>
> Dump the following settings upon Gateway startup:
> gateway.hadoop.kerberos.secured
> java.security.krb5.conf
> sun.security.krb5.debug
> java.security.auth.login.config
> javax.security.auth.useSubjectCredsOnly



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1159) Create ".sha1" files when releasing instead of ".sha"

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317208#comment-16317208
 ] 

Colm O hEigeartaigh commented on KNOX-1159:
---

[~lmccay], yep 1.1.0 is fine for me.

> Create ".sha1" files when releasing instead of ".sha"
> -
>
> Key: KNOX-1159
> URL: https://issues.apache.org/jira/browse/KNOX-1159
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: KNOX-1159.patch
>
>
> Currently we create ".sha" files when creating the release artifacts. However 
> this contradicts the Apache guidelines (and the INFRA team contacted me about 
> this same issue for another Apache project):
> http://www.apache.org/dev/release-distribution#sigs-and-sums
> "An SHA checksum SHOULD also be created and MUST be suffixed as:
> .sha1 for a SHA-1 checksum"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1159) Create ".sha1" files when releasing instead of ".sha"

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated KNOX-1159:
--
Summary: Create ".sha1" files when releasing instead of ".sha"  (was: 
Create ".sha" files when releasing instead of ".sha")

> Create ".sha1" files when releasing instead of ".sha"
> -
>
> Key: KNOX-1159
> URL: https://issues.apache.org/jira/browse/KNOX-1159
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: KNOX-1159.patch
>
>
> Currently we create ".sha" files when creating the release artifacts. However 
> this contradicts the Apache guidelines (and the INFRA team contacted me about 
> this same issue for another Apache project):
> http://www.apache.org/dev/release-distribution#sigs-and-sums
> "An SHA checksum SHOULD also be created and MUST be suffixed as:
> .sha1 for a SHA-1 checksum"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1161) Update hadoop dependencies to Hadoop 3

[Sandeep More (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16317117#comment-16317117
 ] 

Sandeep More commented on KNOX-1161:


Thanks [~coheigea] The patch looks great, I was able to build it successfully. 
Since you provided the patch please feel free to commit it  :) 

> Update hadoop dependencies to Hadoop 3
> --
>
> Key: KNOX-1161
> URL: https://issues.apache.org/jira/browse/KNOX-1161
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Build
>Reporter: Sandeep More
>Assignee: Sandeep More
> Fix For: 1.0.0
>
> Attachments: KNOX-1161-revised.patch, KNOX-1161.001.patch
>
>
> With the release of Hadoop 3 the upcoming release of Knox 1.0.0 should use 
> Hadoop 3 dependencies. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1157) Scoped rewrite rules are treated as global rules in some cases

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316911#comment-16316911
 ] 

Larry McCay commented on KNOX-1157:
---

Going to move this out to 1.1.0 as it will possibly introduce behavioral 
differences between 1.0.0 and 0.14.0.

> Scoped rewrite rules are treated as global rules in some cases
> --
>
> Key: KNOX-1157
> URL: https://issues.apache.org/jira/browse/KNOX-1157
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Wei Han
>Assignee: Wei Han
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-bug-fix-use-a-map-to-store-all-rules-in-ScopedMatche.patch
>
>
> https://issues.apache.org/jira/browse/KNOX-711 introduced the concept of 
> 'scope' for rewrite rules. A rewrite rule can be applied to an input url only 
> if they share the same scope, unless the rule is explicitly defined as 
> 'global' rules. 
> However given the following rewrite.xml, and input url "/foo/bar" with role 
> service-1, the second rule(service-2) will win because the second rule is 
> more specific, even the scope is different from the input url. 
> 
> 
> 
> 
> 
> 
> The root cause is the templates for these two rules are different, so in 
> ScopedMatcher.java(https://github.com/apache/knox/commit/286e02a44dfb5f9ee101007b46bcb8ee47fa62d7#diff-6cffc9c391024e27c73a85ba8e736e60R118),
>  we don't create a separate matcher and the two rules share the same matcher 
> object. 
> My proposal is to change the implementation to create a brand new matcher for 
> each scope, and store them in a map keyed by scope name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1157) Scoped rewrite rules are treated as global rules in some cases

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1157:
--
Fix Version/s: (was: 1.0.0)
   1.1.0

> Scoped rewrite rules are treated as global rules in some cases
> --
>
> Key: KNOX-1157
> URL: https://issues.apache.org/jira/browse/KNOX-1157
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Wei Han
>Assignee: Wei Han
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-bug-fix-use-a-map-to-store-all-rules-in-ScopedMatche.patch
>
>
> https://issues.apache.org/jira/browse/KNOX-711 introduced the concept of 
> 'scope' for rewrite rules. A rewrite rule can be applied to an input url only 
> if they share the same scope, unless the rule is explicitly defined as 
> 'global' rules. 
> However given the following rewrite.xml, and input url "/foo/bar" with role 
> service-1, the second rule(service-2) will win because the second rule is 
> more specific, even the scope is different from the input url. 
> 
> 
> 
> 
> 
> 
> The root cause is the templates for these two rules are different, so in 
> ScopedMatcher.java(https://github.com/apache/knox/commit/286e02a44dfb5f9ee101007b46bcb8ee47fa62d7#diff-6cffc9c391024e27c73a85ba8e736e60R118),
>  we don't create a separate matcher and the two rules share the same matcher 
> object. 
> My proposal is to change the implementation to create a brand new matcher for 
> each scope, and store them in a map keyed by scope name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1159) Create ".sha" files when releasing instead of ".sha"

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316908#comment-16316908
 ] 

Larry McCay commented on KNOX-1159:
---

[~coheigea], the wording in this JIRA is confusing.
Are you simply saying that we should rename the suffix from "sha" to "sha1"?

That's what the patch looks like.

If so, and considering that we are descoping 1.0.0 to stay in line with 0.14.0, 
I am going to set this to 1.1.0 for now. If you think it should be done for 
1.0.0 we can move it back in.

> Create ".sha" files when releasing instead of ".sha"
> 
>
> Key: KNOX-1159
> URL: https://issues.apache.org/jira/browse/KNOX-1159
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: KNOX-1159.patch
>
>
> Currently we create ".sha" files when creating the release artifacts. However 
> this contradicts the Apache guidelines (and the INFRA team contacted me about 
> this same issue for another Apache project):
> http://www.apache.org/dev/release-distribution#sigs-and-sums
> "An SHA checksum SHOULD also be created and MUST be suffixed as:
> .sha1 for a SHA-1 checksum"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1159) Create ".sha" files when releasing instead of ".sha"

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1159:
--
Fix Version/s: (was: 1.0.0)
   1.1.0

> Create ".sha" files when releasing instead of ".sha"
> 
>
> Key: KNOX-1159
> URL: https://issues.apache.org/jira/browse/KNOX-1159
> Project: Apache Knox
>  Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: KNOX-1159.patch
>
>
> Currently we create ".sha" files when creating the release artifacts. However 
> this contradicts the Apache guidelines (and the INFRA team contacted me about 
> this same issue for another Apache project):
> http://www.apache.org/dev/release-distribution#sigs-and-sums
> "An SHA checksum SHOULD also be created and MUST be suffixed as:
> .sha1 for a SHA-1 checksum"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1160) Bug fixes to make spark history UI work

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1160:
--
Fix Version/s: 1.1.0

> Bug fixes to make spark history UI work
> ---
>
> Key: KNOX-1160
> URL: https://issues.apache.org/jira/browse/KNOX-1160
> Project: Apache Knox
>  Issue Type: Bug
>Reporter: Wei Han
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: sparkhistoryui.patch
>
>
> During my test of the spark history UI I found a couple of issues. The 
> attached patch fixes all of the issues I have seen



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KNOX-1162) Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316881#comment-16316881
 ] 

Larry McCay commented on KNOX-1162:
---

There is possibly some overlap or at least relationship between these two.

> Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration
> 
>
> Key: KNOX-1162
> URL: https://issues.apache.org/jira/browse/KNOX-1162
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.14.0
>Reporter: Kevin Minder
>Priority: Minor
> Fix For: 1.1.0
>
>
> When there is a misconfiguration in conf/krb5JAASLogin.conf the server fails 
> to start and the information in gateway.log isn't at all helpful.  So two 
> requests
> # Logging should indicate at a minimum what file contains the issue.
> # All fatal issues should log stack traces without requiring enabling debug 
> logging.
> This is the error shown in gateway.log
> {code}
> 2018-01-05 12:05:12,538 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> {code}
> When you enabled debug logging you get somewhat better information.
> {code}
> 2018-01-05 15:55:54,087 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> java.lang.SecurityException: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:137)
> at sun.security.provider.ConfigFile.(ConfigFile.java:102)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:255)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:247)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.Configuration.getConfiguration(Configuration.java:246)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.(RemoteConfigurationRegistryJAASConfig.java:52)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.configure(RemoteConfigurationRegistryJAASConfig.java:59)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.CuratorClientService.init(CuratorClientService.java:80)
> at 
> org.apache.hadoop.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:113)
> at 
> org.apache.hadoop.gateway.GatewayServer.main(GatewayServer.java:154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.hadoop.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:70)
> at org.apache.hadoop.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.hadoop.gateway.launcher.Command.run(Command.java:99)
> at org.apache.hadoop.gateway.launcher.Launcher.run(Launcher.java:69)
> at org.apache.hadoop.gateway.launcher.Launcher.main(Launcher.java:46)
> Caused by: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at 
> sun.security.provider.ConfigFile$Spi.ioException(ConfigFile.java:666)
> at sun.security.provider.ConfigFile$Spi.match(ConfigFile.java:572)
> at 
> sun.security.provider.ConfigFile$Spi.parseLoginEntry(ConfigFile.java:477)
> at 
> sun.security.provider.ConfigFile$Spi.readConfig(ConfigFile.java:427)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:329)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:271)
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:135)
> ... 24 more
> {code}
> Lastly the particular configuration error in conf/krb5JAASLogin.conf was 
> missing quotes for the keyTab and principal values.  Note, portions of the 
> principal have been scrubbed and replaced with tokens 

[jira] [Updated] (KNOX-1162) Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1162:
--
Fix Version/s: 1.1.0

> Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration
> 
>
> Key: KNOX-1162
> URL: https://issues.apache.org/jira/browse/KNOX-1162
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.14.0
>Reporter: Kevin Minder
>Priority: Minor
> Fix For: 1.1.0
>
>
> When there is a misconfiguration in conf/krb5JAASLogin.conf the server fails 
> to start and the information in gateway.log isn't at all helpful.  So two 
> requests
> # Logging should indicate at a minimum what file contains the issue.
> # All fatal issues should log stack traces without requiring enabling debug 
> logging.
> This is the error shown in gateway.log
> {code}
> 2018-01-05 12:05:12,538 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> {code}
> When you enabled debug logging you get somewhat better information.
> {code}
> 2018-01-05 15:55:54,087 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> java.lang.SecurityException: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:137)
> at sun.security.provider.ConfigFile.(ConfigFile.java:102)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:255)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:247)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.Configuration.getConfiguration(Configuration.java:246)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.(RemoteConfigurationRegistryJAASConfig.java:52)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.configure(RemoteConfigurationRegistryJAASConfig.java:59)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.CuratorClientService.init(CuratorClientService.java:80)
> at 
> org.apache.hadoop.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:113)
> at 
> org.apache.hadoop.gateway.GatewayServer.main(GatewayServer.java:154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.hadoop.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:70)
> at org.apache.hadoop.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.hadoop.gateway.launcher.Command.run(Command.java:99)
> at org.apache.hadoop.gateway.launcher.Launcher.run(Launcher.java:69)
> at org.apache.hadoop.gateway.launcher.Launcher.main(Launcher.java:46)
> Caused by: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at 
> sun.security.provider.ConfigFile$Spi.ioException(ConfigFile.java:666)
> at sun.security.provider.ConfigFile$Spi.match(ConfigFile.java:572)
> at 
> sun.security.provider.ConfigFile$Spi.parseLoginEntry(ConfigFile.java:477)
> at 
> sun.security.provider.ConfigFile$Spi.readConfig(ConfigFile.java:427)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:329)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:271)
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:135)
> ... 24 more
> {code}
> Lastly the particular configuration error in conf/krb5JAASLogin.conf was 
> missing quotes for the keyTab and principal values.  Note, portions of the 
> principal have been scrubbed and replaced with tokens (e.g. )
> {code}
> com.sun.security.jgss.initiate {
> 

[jira] [Commented] (KNOX-1162) Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316875#comment-16316875
 ] 

Larry McCay commented on KNOX-1162:
---

Hey [~kminder]!
Going to set this to 1.1.0 for now.

> Improve diagnostics for conf/krb5JAASLogin.conf misconfiguration
> 
>
> Key: KNOX-1162
> URL: https://issues.apache.org/jira/browse/KNOX-1162
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 0.14.0
>Reporter: Kevin Minder
>Priority: Minor
>
> When there is a misconfiguration in conf/krb5JAASLogin.conf the server fails 
> to start and the information in gateway.log isn't at all helpful.  So two 
> requests
> # Logging should indicate at a minimum what file contains the issue.
> # All fatal issues should log stack traces without requiring enabling debug 
> logging.
> This is the error shown in gateway.log
> {code}
> 2018-01-05 12:05:12,538 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> {code}
> When you enabled debug logging you get somewhat better information.
> {code}
> 2018-01-05 15:55:54,087 FATAL hadoop.gateway (GatewayServer.java:main(163)) - 
> Failed to start gateway: java.lang.SecurityException: java.io.IOException: 
> Configuration Error:
> Line 7: expected [option key]
> java.lang.SecurityException: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:137)
> at sun.security.provider.ConfigFile.(ConfigFile.java:102)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:255)
> at 
> javax.security.auth.login.Configuration$2.run(Configuration.java:247)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> javax.security.auth.login.Configuration.getConfiguration(Configuration.java:246)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.(RemoteConfigurationRegistryJAASConfig.java:52)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.RemoteConfigurationRegistryJAASConfig.configure(RemoteConfigurationRegistryJAASConfig.java:59)
> at 
> org.apache.hadoop.gateway.service.config.remote.zk.CuratorClientService.init(CuratorClientService.java:80)
> at 
> org.apache.hadoop.gateway.services.DefaultGatewayServices.init(DefaultGatewayServices.java:113)
> at 
> org.apache.hadoop.gateway.GatewayServer.main(GatewayServer.java:154)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.hadoop.gateway.launcher.Invoker.invokeMainMethod(Invoker.java:70)
> at org.apache.hadoop.gateway.launcher.Invoker.invoke(Invoker.java:39)
> at org.apache.hadoop.gateway.launcher.Command.run(Command.java:99)
> at org.apache.hadoop.gateway.launcher.Launcher.run(Launcher.java:69)
> at org.apache.hadoop.gateway.launcher.Launcher.main(Launcher.java:46)
> Caused by: java.io.IOException: Configuration Error:
> Line 7: expected [option key]
> at 
> sun.security.provider.ConfigFile$Spi.ioException(ConfigFile.java:666)
> at sun.security.provider.ConfigFile$Spi.match(ConfigFile.java:572)
> at 
> sun.security.provider.ConfigFile$Spi.parseLoginEntry(ConfigFile.java:477)
> at 
> sun.security.provider.ConfigFile$Spi.readConfig(ConfigFile.java:427)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:329)
> at sun.security.provider.ConfigFile$Spi.init(ConfigFile.java:271)
> at sun.security.provider.ConfigFile$Spi.(ConfigFile.java:135)
> ... 24 more
> {code}
> Lastly the particular configuration error in conf/krb5JAASLogin.conf was 
> missing quotes for the keyTab and principal values.  Note, portions of the 
> principal have been scrubbed and replaced with tokens (e.g. )
> {code}
> com.sun.security.jgss.initiate {
>  

[jira] [Commented] (KNOX-1148) Fix Livy Service Definition to align with Livy API (Spark REST Service)

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316839#comment-16316839
 ] 

Larry McCay commented on KNOX-1148:
---

Moving this out to 1.1.0.
We will need to ensure that whatever change is made here is done so with 
backward compatibility in mind. Either through versioning of the service 
definition or by allowing both paths within the same service def. Where the 
former is probably preferred though will break any topologies from 0.14.0 and 
1.0.0.

Perhaps, we make some statement of deprecation for the current service def in 
1.0.0?

> Fix Livy Service Definition to align with Livy API (Spark REST Service) 
> 
>
> Key: KNOX-1148
> URL: https://issues.apache.org/jira/browse/KNOX-1148
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Larry McCay
>Assignee: Larry McCay
> Fix For: 1.1.0
>
>
> http://livy.io/
> The initial contribution for Livy REST API includes a deviation from the 
> actual Livy server API in that it requires a "v1" where the actual API does 
> not. This may cause confusion for end users and possible incompatibilities 
> with existing Livy clients that don't expect that.
> We need to remove the need for the "v1" for the 1.0.0 release as it implies 
> an extended level of backward compatibility commitment.
> Here is an example of a Livy Knox service implementation:
> https://community.hortonworks.com/articles/70499/adding-livy-server-as-service-to-apache-knox.html
> The Livy service will need to support Kerberos and load balancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1143) Add MR job history ws rest api rewrite rule to jobhistoryui

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1143:
--
Fix Version/s: (was: 0.14.1)
   (was: 1.0.0)
   1.1.0

> Add MR job history ws rest api rewrite rule to jobhistoryui
> ---
>
> Key: KNOX-1143
> URL: https://issues.apache.org/jira/browse/KNOX-1143
> Project: Apache Knox
>  Issue Type: Improvement
>Affects Versions: Future
>Reporter: Guang Yang
>  Labels: features
> Fix For: 1.1.0
>
> Attachments: KNOX-jhs.patch
>
>
> Currently, there is no url rewrite rule for mapreduce job history server ws 
> rest api calls, like http://0:19888/ws/v1/history/mapreduce/jobs/job_id. We 
> need to add such rewrite rules.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1148) Fix Livy Service Definition to align with Livy API (Spark REST Service)

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1148:
--
Fix Version/s: (was: 0.14.1)
   (was: 1.0.0)
   1.1.0

> Fix Livy Service Definition to align with Livy API (Spark REST Service) 
> 
>
> Key: KNOX-1148
> URL: https://issues.apache.org/jira/browse/KNOX-1148
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Server
>Reporter: Larry McCay
>Assignee: Larry McCay
> Fix For: 1.1.0
>
>
> http://livy.io/
> The initial contribution for Livy REST API includes a deviation from the 
> actual Livy server API in that it requires a "v1" where the actual API does 
> not. This may cause confusion for end users and possible incompatibilities 
> with existing Livy clients that don't expect that.
> We need to remove the need for the "v1" for the 1.0.0 release as it implies 
> an extended level of backward compatibility commitment.
> Here is an example of a Livy Knox service implementation:
> https://community.hortonworks.com/articles/70499/adding-livy-server-as-service-to-apache-knox.html
> The Livy service will need to support Kerberos and load balancing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KNOX-1163) Add rewrite rule for presto (new service)

[Larry McCay (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Larry McCay updated KNOX-1163:
--
Fix Version/s: (was: 1.0.0)
   (was: 0.15.0)
   1.1.0

> Add rewrite rule for presto (new service)
> -
>
> Key: KNOX-1163
> URL: https://issues.apache.org/jira/browse/KNOX-1163
> Project: Apache Knox
>  Issue Type: New Feature
>  Components: Server
>Reporter: Guang Yang
> Fix For: 1.1.0
>
> Attachments: KNOX-presto.patch
>
>
> Currently there is no support for Presto. This change add such kind of 
> support.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Descoping of Apache Knox 1.0.0

[larry mccay]

Just got done reviewing them and I agree, Phil.
We should be able to spin a 1.0.0 this week if we do that.


On Mon, Jan 8, 2018 at 1:23 PM, Philip Zampino  wrote:

> +1
>
> IMO, KNOX-998  and
> KNOX-1101
>  are the only remaining
> ones that seem like they should be included in 1.0.0; the rest are bug
> fixes or additions, which could be pushed to a 1.1.0 release.
>
> On Mon, Jan 8, 2018 at 12:37 PM, Sandeep More 
> wrote:
>
> > +1
> > Sounds good !
> >
> > On Mon, Jan 8, 2018 at 12:27 PM, larry mccay  wrote:
> >
> > > All -
> > >
> > > I think that we have allowed scope creep to affect the ability to spin
> > > 1.0.0 as quickly as we can after 0.14.0.
> > >
> > > I propose that a descoping effort is required in order to keep 1.0.0
> > > functionally in line with 0.14.0.
> > >
> > > Even though many of the current 13 JIRAs have patches available and
> don't
> > > necessarily add risk, we should keep in mind the testing requirements
> for
> > > things like new service definitions.
> > >
> > > Also, I would like be able to use the 1.0.0 release as a natural
> boundary
> > > for uptaking Hadoop 3 libraries for our Hadoop based providers as well
> as
> > > the class repackaging.
> > >
> > > We would then have 1.0.0 as a choice for those deployments that are
> > > comfortable with Hadoop 3 uptake and 0.14.0 for those that are in a
> wait
> > > and see mode - without a difference in feature sets.
> > >
> > > With that said, I am proposing to move the vast majority of the 1.0.0
> > JIRAs
> > > back out to a 1.1.0 fix version.
> > >
> > > Thoughts?
> > >
> > > --larry
> > >
> >
>

[jira] [Created] (KNOX-1164) bug fix on oozieui rewrite rul

[Wei Han (JIRA)]

Wei Han created KNOX-1164:
-

 Summary: bug fix on oozieui rewrite rul
 Key: KNOX-1164
 URL: https://issues.apache.org/jira/browse/KNOX-1164
 Project: Apache Knox
  Issue Type: Bug
Reporter: Wei Han
 Attachments: 0001-oozieUI-rewrite-rule-fix.patch

Fix a bug introduced in https://issues.apache.org/jira/browse/KNOX-1106. The 
issue is that pattern is always required at the top level definition otherwise 
the rule won't be effective: 
https://github.com/apache/knox/blob/5515056406afd48a6b55f4188fe80816c2133744/gateway-provider-rewrite/src/main/java/org/apache/hadoop/gateway/filter/rewrite/api/UrlRewriteProcessor.java#L92



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Descoping of Apache Knox 1.0.0

[Philip Zampino]

+1

IMO, KNOX-998  and KNOX-1101
 are the only remaining
ones that seem like they should be included in 1.0.0; the rest are bug
fixes or additions, which could be pushed to a 1.1.0 release.

On Mon, Jan 8, 2018 at 12:37 PM, Sandeep More  wrote:

> +1
> Sounds good !
>
> On Mon, Jan 8, 2018 at 12:27 PM, larry mccay  wrote:
>
> > All -
> >
> > I think that we have allowed scope creep to affect the ability to spin
> > 1.0.0 as quickly as we can after 0.14.0.
> >
> > I propose that a descoping effort is required in order to keep 1.0.0
> > functionally in line with 0.14.0.
> >
> > Even though many of the current 13 JIRAs have patches available and don't
> > necessarily add risk, we should keep in mind the testing requirements for
> > things like new service definitions.
> >
> > Also, I would like be able to use the 1.0.0 release as a natural boundary
> > for uptaking Hadoop 3 libraries for our Hadoop based providers as well as
> > the class repackaging.
> >
> > We would then have 1.0.0 as a choice for those deployments that are
> > comfortable with Hadoop 3 uptake and 0.14.0 for those that are in a wait
> > and see mode - without a difference in feature sets.
> >
> > With that said, I am proposing to move the vast majority of the 1.0.0
> JIRAs
> > back out to a 1.1.0 fix version.
> >
> > Thoughts?
> >
> > --larry
> >
>

[jira] [Updated] (KNOX-1161) Update hadoop dependencies to Hadoop 3

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated KNOX-1161:
--
Attachment: KNOX-1161-revised.patch

Hi [~moresandeep],

Please see attached for some proposed changes (feel free to ignore any of 
them). The changes are:

 - Re-used the core Mockito/Jackson versions in gateway-test-release for 
consistency
 - Use the Hadoop 3.0.0 minikdc in gateway-test-release instead of the alpha 
version, and remove the dependency on Kerby.
 - Remove unused "jackson2.version" declaration in root pom
 - Remove Kerby exclusions and subsequent dependency in the root pom.

All tests pass with this patch. Let me know what you think!

BTW there are two outstanding issues I noticed with the distribution:

a) We are now shipping all of the kerby jars...probably these should be 
excluded as I don't think they're needed by Knox.
b) We're also shipping re2j with is BSD 3-clause...we need to acknowledge this 
as such in our LICENSE/NOTICE.
 - 

> Update hadoop dependencies to Hadoop 3
> --
>
> Key: KNOX-1161
> URL: https://issues.apache.org/jira/browse/KNOX-1161
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Build
>Reporter: Sandeep More
>Assignee: Sandeep More
> Fix For: 1.0.0
>
> Attachments: KNOX-1161-revised.patch, KNOX-1161.001.patch
>
>
> With the release of Hadoop 3 the upcoming release of Knox 1.0.0 should use 
> Hadoop 3 dependencies. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Descoping of Apache Knox 1.0.0

[Sandeep More]

+1
Sounds good !

On Mon, Jan 8, 2018 at 12:27 PM, larry mccay  wrote:

> All -
>
> I think that we have allowed scope creep to affect the ability to spin
> 1.0.0 as quickly as we can after 0.14.0.
>
> I propose that a descoping effort is required in order to keep 1.0.0
> functionally in line with 0.14.0.
>
> Even though many of the current 13 JIRAs have patches available and don't
> necessarily add risk, we should keep in mind the testing requirements for
> things like new service definitions.
>
> Also, I would like be able to use the 1.0.0 release as a natural boundary
> for uptaking Hadoop 3 libraries for our Hadoop based providers as well as
> the class repackaging.
>
> We would then have 1.0.0 as a choice for those deployments that are
> comfortable with Hadoop 3 uptake and 0.14.0 for those that are in a wait
> and see mode - without a difference in feature sets.
>
> With that said, I am proposing to move the vast majority of the 1.0.0 JIRAs
> back out to a 1.1.0 fix version.
>
> Thoughts?
>
> --larry
>

Re: knox git commit: KNOX-1161 - Update hadoop dependencies to hadoop 3

[Colm O hEigeartaigh]

Thanks guys for the follow up. I'm fine with upgrading to Hadoop 3.0.0 for
1.0.0 given the explanations you have given. I'll provide further feedback
about amending the patch a bit on the JIRA.

Colm.

On Mon, Jan 8, 2018 at 5:03 PM, larry mccay  wrote:

> Hi Colm -
>
> I just responded to a similar question on the KNOX-1161 JIRA itself.
> I think we probably should have had a DISCUSS thread on this upgrade but
> we can discuss here or on the JIRA.
>
> To me, the fact that the two releases 0.14.0 and 1.0.0 will largely be the
> same feature set that are differentiated by an uptake of Hadoop 3 is really
> natural.
> It gives folks the opportunity to migrate to Hadoop 3 or not depending on
> their comfort with doing so and not miss out on new features in Knox.
>
> I definitely agree on the points about the pom cleanup.
> I don't believe that jackson2.version is required either - that should be
> removed.
>
> The other cleanup tasks/questions seem valid and likely just a result of
> growing needs and not realizing that there were previous action being taken
> on the same dependencies - such as Kirby.
>
> KNOX-1161 could certainly be reopened to do something of this cleanup.
>
> Please let me know what you think about my assertion regarding the version
> boundary of the 1.0.0 release is a natural place to do this split.
>
> thanks,
>
> --larry
>
>
> On Mon, Jan 8, 2018 at 8:41 AM, Sandeep More 
> wrote:
>
>> Hello Colm,
>>
>> Interesting, I think of this patch as an maintenance upgrade  to Knox
>> 1.0.0
>> build, this should not affect the way Knox works, infact there was just
>> one
>> line trivial code change in this patch. The rational behind this is to
>> upgrade Hadoop dependencies that Knox uses to be in-line with the latest
>> Hadoop release so we can easily leverage new features and improvements
>> going forward. Also, feature wise 1.0.0 is still close to 0.14.0, this
>> patch does not add, remove or improve any feature.
>>
>> About jackson 2.2.2 in root pom, you might be right, this could be an
>> artifact of my testing, let me try removing it again and see.
>>
>> The Kerby version rolled with Hadoop 3 has some significant api changes,
>> which if included would likely have us revisit the SecureClusterTest code.
>> So the patch uses the version of Kerby that does not need code changes to
>> our test classes. My aim was to keep Knox code changes as minimum as
>> possible.
>>
>> "Beanutils is downgraded from 1.9.3 to 1.9.2."
>> On the contrary Beanutils was upgraded from 1.9.2  to 1.9.3 [1]
>>
>> -1.9.2
>> +${commons-beanutils-version}
>>
>>
>> "Also we are defining lower versions of Jackson and Mockito in the
>> gateway-test-release pom."
>>
>> Do you mean lower version than before ? I do recall I had trouble with
>> higher version of jackson with our tests. Through trial and error I found
>> these were the versions that played nice with our tests.
>>
>> I decided to stick with these versions since I did not think changing the
>> Unit tests was a good idea at this point.
>>
>> Thanks for taking a look at the patch and let me know your thoughts.
>>
>> Best,
>> Sandeep
>>
>> [1]
>> https://git1-us-west.apache.org/repos/asf?p=knox.git;a=blob;
>> f=pom.xml;h=6bd93962f30fb52fb2273ba5294bae3140eb9119;hb=772bc33d#l125
>>
>>
>>
>> On Mon, Jan 8, 2018 at 4:52 AM, Colm O hEigeartaigh 
>> wrote:
>>
>> > Hi Sandeep,
>> >
>> > I'm wondering if this (major) upgrade is not breaking the idea of
>> trying to
>> > change as little as possible for 1.0.0 from 0.14.0?
>> >
>> > I think "jackson2.version" added to the root pom with version 2.2.2
>> could
>> > be removed, as it is not used anywhere. Why do we exclude Kerby from the
>> > Hadoop pom and then include it as a dependency again?
>> >
>> > Also, is it really necessary to "downgrade" various dependencies just
>> > because they are used by Hadoop? Beanutils is downgraded from 1.9.3 to
>> > 1.9.2. Also we are defining lower versions of Jackson and Mockito in the
>> > gateway-test-release pom.
>> >
>> > Colm.
>> >
>> > On Fri, Jan 5, 2018 at 7:40 PM,  wrote:
>> >
>> > > Repository: knox
>> > > Updated Branches:
>> > >   refs/heads/master 6d4756f3d -> 772bc33d4
>> > >
>> > >
>> > > KNOX-1161 - Update hadoop dependencies to hadoop 3
>> > >
>> > >
>> > > Project: http://git-wip-us.apache.org/repos/asf/knox/repo
>> > > Commit: http://git-wip-us.apache.org/repos/asf/knox/commit/772bc33d
>> > > Tree: http://git-wip-us.apache.org/repos/asf/knox/tree/772bc33d
>> > > Diff: http://git-wip-us.apache.org/repos/asf/knox/diff/772bc33d
>> > >
>> > > Branch: refs/heads/master
>> > > Commit: 772bc33d48dd37be5cd098992df3e50db24326f3
>> > > Parents: 6d4756f
>> > > Author: Sandeep More 
>> > > Authored: Fri Jan 5 14:38:24 2018 -0500
>> > > Committer: Sandeep More 
>> > > Committed: Fri Jan 5 14:38:24 2018 -0500
>> > >
>> > > 

[DISCUSS] Descoping of Apache Knox 1.0.0

[larry mccay]

All -

I think that we have allowed scope creep to affect the ability to spin
1.0.0 as quickly as we can after 0.14.0.

I propose that a descoping effort is required in order to keep 1.0.0
functionally in line with 0.14.0.

Even though many of the current 13 JIRAs have patches available and don't
necessarily add risk, we should keep in mind the testing requirements for
things like new service definitions.

Also, I would like be able to use the 1.0.0 release as a natural boundary
for uptaking Hadoop 3 libraries for our Hadoop based providers as well as
the class repackaging.

We would then have 1.0.0 as a choice for those deployments that are
comfortable with Hadoop 3 uptake and 0.14.0 for those that are in a wait
and see mode - without a difference in feature sets.

With that said, I am proposing to move the vast majority of the 1.0.0 JIRAs
back out to a 1.1.0 fix version.

Thoughts?

--larry

[jira] [Reopened] (KNOX-1161) Update hadoop dependencies to Hadoop 3

[Sandeep More (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KNOX-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep More reopened KNOX-1161:


Reopening the bug to address the [concerns | 
https://lists.apache.org/api/source.lua/1a9a2febffb177e9fa0de8851b46fe69c71ccb993e1a29e1c056a95e@%3Cdev.knox.apache.org%3E]
 raised by [~coheigea] 

> Update hadoop dependencies to Hadoop 3
> --
>
> Key: KNOX-1161
> URL: https://issues.apache.org/jira/browse/KNOX-1161
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Build
>Reporter: Sandeep More
>Assignee: Sandeep More
> Fix For: 1.0.0
>
> Attachments: KNOX-1161.001.patch
>
>
> With the release of Hadoop 3 the upcoming release of Knox 1.0.0 should use 
> Hadoop 3 dependencies. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: knox git commit: KNOX-1161 - Update hadoop dependencies to hadoop 3

[larry mccay]

Hi Colm -

I just responded to a similar question on the KNOX-1161 JIRA itself.
I think we probably should have had a DISCUSS thread on this upgrade but we
can discuss here or on the JIRA.

To me, the fact that the two releases 0.14.0 and 1.0.0 will largely be the
same feature set that are differentiated by an uptake of Hadoop 3 is really
natural.
It gives folks the opportunity to migrate to Hadoop 3 or not depending on
their comfort with doing so and not miss out on new features in Knox.

I definitely agree on the points about the pom cleanup.
I don't believe that jackson2.version is required either - that should be
removed.

The other cleanup tasks/questions seem valid and likely just a result of
growing needs and not realizing that there were previous action being taken
on the same dependencies - such as Kirby.

KNOX-1161 could certainly be reopened to do something of this cleanup.

Please let me know what you think about my assertion regarding the version
boundary of the 1.0.0 release is a natural place to do this split.

thanks,

--larry


On Mon, Jan 8, 2018 at 8:41 AM, Sandeep More  wrote:

> Hello Colm,
>
> Interesting, I think of this patch as an maintenance upgrade  to Knox 1.0.0
> build, this should not affect the way Knox works, infact there was just one
> line trivial code change in this patch. The rational behind this is to
> upgrade Hadoop dependencies that Knox uses to be in-line with the latest
> Hadoop release so we can easily leverage new features and improvements
> going forward. Also, feature wise 1.0.0 is still close to 0.14.0, this
> patch does not add, remove or improve any feature.
>
> About jackson 2.2.2 in root pom, you might be right, this could be an
> artifact of my testing, let me try removing it again and see.
>
> The Kerby version rolled with Hadoop 3 has some significant api changes,
> which if included would likely have us revisit the SecureClusterTest code.
> So the patch uses the version of Kerby that does not need code changes to
> our test classes. My aim was to keep Knox code changes as minimum as
> possible.
>
> "Beanutils is downgraded from 1.9.3 to 1.9.2."
> On the contrary Beanutils was upgraded from 1.9.2  to 1.9.3 [1]
>
> -1.9.2
> +${commons-beanutils-version}
>
>
> "Also we are defining lower versions of Jackson and Mockito in the
> gateway-test-release pom."
>
> Do you mean lower version than before ? I do recall I had trouble with
> higher version of jackson with our tests. Through trial and error I found
> these were the versions that played nice with our tests.
>
> I decided to stick with these versions since I did not think changing the
> Unit tests was a good idea at this point.
>
> Thanks for taking a look at the patch and let me know your thoughts.
>
> Best,
> Sandeep
>
> [1]
> https://git1-us-west.apache.org/repos/asf?p=knox.git;a=blob;f=pom.xml;h=
> 6bd93962f30fb52fb2273ba5294bae3140eb9119;hb=772bc33d#l125
>
>
>
> On Mon, Jan 8, 2018 at 4:52 AM, Colm O hEigeartaigh 
> wrote:
>
> > Hi Sandeep,
> >
> > I'm wondering if this (major) upgrade is not breaking the idea of trying
> to
> > change as little as possible for 1.0.0 from 0.14.0?
> >
> > I think "jackson2.version" added to the root pom with version 2.2.2 could
> > be removed, as it is not used anywhere. Why do we exclude Kerby from the
> > Hadoop pom and then include it as a dependency again?
> >
> > Also, is it really necessary to "downgrade" various dependencies just
> > because they are used by Hadoop? Beanutils is downgraded from 1.9.3 to
> > 1.9.2. Also we are defining lower versions of Jackson and Mockito in the
> > gateway-test-release pom.
> >
> > Colm.
> >
> > On Fri, Jan 5, 2018 at 7:40 PM,  wrote:
> >
> > > Repository: knox
> > > Updated Branches:
> > >   refs/heads/master 6d4756f3d -> 772bc33d4
> > >
> > >
> > > KNOX-1161 - Update hadoop dependencies to hadoop 3
> > >
> > >
> > > Project: http://git-wip-us.apache.org/repos/asf/knox/repo
> > > Commit: http://git-wip-us.apache.org/repos/asf/knox/commit/772bc33d
> > > Tree: http://git-wip-us.apache.org/repos/asf/knox/tree/772bc33d
> > > Diff: http://git-wip-us.apache.org/repos/asf/knox/diff/772bc33d
> > >
> > > Branch: refs/heads/master
> > > Commit: 772bc33d48dd37be5cd098992df3e50db24326f3
> > > Parents: 6d4756f
> > > Author: Sandeep More 
> > > Authored: Fri Jan 5 14:38:24 2018 -0500
> > > Committer: Sandeep More 
> > > Committed: Fri Jan 5 14:38:24 2018 -0500
> > >
> > > --
> > >  .../filter/PortMappingHelperHandler.java|  2 +-
> > >  gateway-test-release/pom.xml| 77
> > 
> > >  pom.xml | 31 +++-
> > >  3 files changed, 107 insertions(+), 3 deletions(-)
> > > --
> > >
> > >
> > > 

[jira] [Commented] (KNOX-1161) Update hadoop dependencies to Hadoop 3

[Larry McCay (JIRA)]

[ 
https://issues.apache.org/jira/browse/KNOX-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316578#comment-16316578
 ] 

Larry McCay commented on KNOX-1161:
---

+1 to [~smore]'s assertion here.

We do not have the same sort of compatibility issues that others do which 
require shims and the like.
Our use of the hadoop common functionality doesn't really have wire level 
compatibility issues like APIs.

The Hadoop Auth Provider can leverage the Hadoop 3 facilities without having a 
compatibility issue with Hadoop 2.x clusters - as the authentication is 
encapsulated within the Knox process itself and identity is typically asserted 
via doas/user.name params - which remains compatible.

Same dynamic for the Hadoop Groups Mapping integration in the Hadoop Group 
Lookup Provider.

I also know of downstream testing of Knox 0.14.0 with Hadoop 3 dependencies.
We should be fine.

Also, I think the separation of 0.14.0 and 1.0.0 on the Hadoop version boundary 
makes a lot of sense.
Functionality will be largely the same therefore one can put off uptake of 
1.0.0 until there is comfort with Hadoop 3 migration - if so desired.


> Update hadoop dependencies to Hadoop 3
> --
>
> Key: KNOX-1161
> URL: https://issues.apache.org/jira/browse/KNOX-1161
> Project: Apache Knox
>  Issue Type: Improvement
>  Components: Build
>Reporter: Sandeep More
>Assignee: Sandeep More
> Fix For: 1.0.0
>
> Attachments: KNOX-1161.001.patch
>
>
> With the release of Hadoop 3 the upcoming release of Knox 1.0.0 should use 
> Hadoop 3 dependencies. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Commit Messages

[larry mccay]

Ahhh - I was wondering when I checked whether someone beat me to it -
thanks!
:)

On Mon, Jan 8, 2018 at 11:41 AM, Philip Zampino 
wrote:

> I’ve added notes about the commit message format to the committer
> workflows described in the contribution page (https://cwiki.apache.org/
> confluence/display/KNOX/Contribution+Process).
>
> --
> Phil
>
>
> On 1/6/18, 9:40 AM, "larry mccay"  wrote:
>
> All -
>
> Just as a reminder to all committers, when pushing a patch please make
> sure
> to include the JIRA number and description as part of the commit
> message.
>
> We use the following format which is close enough to the CHANGES file
> that
> it takes little adjustment at release time to get all the CHANGES noted
> properly:
>
> KNOX-{} - {JIRA-TITLE} [(contributor via committer)]
>
> Also, with this in mind it is a good idea to keep the JIRA title short
> enough to appear in the CHANGES file without wrapping too badly.
>
> For the handful of commits that were recently added without proper
> messages, we can easily address that for CHANGES updates but going
> forward
> we should revert the patch and repush with a proper message.
>
> I will try and make sure that we have the following documented more
> clearly
> in the contribution page.
>
> Thanks,
>
> --larry
>
>
>

Re: Commit Messages

[Philip Zampino]

I’ve added notes about the commit message format to the committer workflows 
described in the contribution page 
(https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process).

-- 
Phil
 

On 1/6/18, 9:40 AM, "larry mccay"  wrote:

All -

Just as a reminder to all committers, when pushing a patch please make sure
to include the JIRA number and description as part of the commit message.

We use the following format which is close enough to the CHANGES file that
it takes little adjustment at release time to get all the CHANGES noted
properly:

KNOX-{} - {JIRA-TITLE} [(contributor via committer)]

Also, with this in mind it is a good idea to keep the JIRA title short
enough to appear in the CHANGES file without wrapping too badly.

For the handful of commits that were recently added without proper
messages, we can easily address that for CHANGES updates but going forward
we should revert the patch and repush with a proper message.

I will try and make sure that we have the following documented more clearly
in the contribution page.

Thanks,

--larry

Re: knox git commit: KNOX-1161 - Update hadoop dependencies to hadoop 3

[Sandeep More]

Hello Colm,

Interesting, I think of this patch as an maintenance upgrade  to Knox 1.0.0
build, this should not affect the way Knox works, infact there was just one
line trivial code change in this patch. The rational behind this is to
upgrade Hadoop dependencies that Knox uses to be in-line with the latest
Hadoop release so we can easily leverage new features and improvements
going forward. Also, feature wise 1.0.0 is still close to 0.14.0, this
patch does not add, remove or improve any feature.

About jackson 2.2.2 in root pom, you might be right, this could be an
artifact of my testing, let me try removing it again and see.

The Kerby version rolled with Hadoop 3 has some significant api changes,
which if included would likely have us revisit the SecureClusterTest code.
So the patch uses the version of Kerby that does not need code changes to
our test classes. My aim was to keep Knox code changes as minimum as
possible.

"Beanutils is downgraded from 1.9.3 to 1.9.2."
On the contrary Beanutils was upgraded from 1.9.2  to 1.9.3 [1]

-1.9.2
+${commons-beanutils-version}


"Also we are defining lower versions of Jackson and Mockito in the
gateway-test-release pom."

Do you mean lower version than before ? I do recall I had trouble with
higher version of jackson with our tests. Through trial and error I found
these were the versions that played nice with our tests.

I decided to stick with these versions since I did not think changing the
Unit tests was a good idea at this point.

Thanks for taking a look at the patch and let me know your thoughts.

Best,
Sandeep

[1]
https://git1-us-west.apache.org/repos/asf?p=knox.git;a=blob;f=pom.xml;h=6bd93962f30fb52fb2273ba5294bae3140eb9119;hb=772bc33d#l125



On Mon, Jan 8, 2018 at 4:52 AM, Colm O hEigeartaigh 
wrote:

> Hi Sandeep,
>
> I'm wondering if this (major) upgrade is not breaking the idea of trying to
> change as little as possible for 1.0.0 from 0.14.0?
>
> I think "jackson2.version" added to the root pom with version 2.2.2 could
> be removed, as it is not used anywhere. Why do we exclude Kerby from the
> Hadoop pom and then include it as a dependency again?
>
> Also, is it really necessary to "downgrade" various dependencies just
> because they are used by Hadoop? Beanutils is downgraded from 1.9.3 to
> 1.9.2. Also we are defining lower versions of Jackson and Mockito in the
> gateway-test-release pom.
>
> Colm.
>
> On Fri, Jan 5, 2018 at 7:40 PM,  wrote:
>
> > Repository: knox
> > Updated Branches:
> >   refs/heads/master 6d4756f3d -> 772bc33d4
> >
> >
> > KNOX-1161 - Update hadoop dependencies to hadoop 3
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/knox/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/knox/commit/772bc33d
> > Tree: http://git-wip-us.apache.org/repos/asf/knox/tree/772bc33d
> > Diff: http://git-wip-us.apache.org/repos/asf/knox/diff/772bc33d
> >
> > Branch: refs/heads/master
> > Commit: 772bc33d48dd37be5cd098992df3e50db24326f3
> > Parents: 6d4756f
> > Author: Sandeep More 
> > Authored: Fri Jan 5 14:38:24 2018 -0500
> > Committer: Sandeep More 
> > Committed: Fri Jan 5 14:38:24 2018 -0500
> >
> > --
> >  .../filter/PortMappingHelperHandler.java|  2 +-
> >  gateway-test-release/pom.xml| 77
> 
> >  pom.xml | 31 +++-
> >  3 files changed, 107 insertions(+), 3 deletions(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/knox/blob/772bc33d/
> > gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> > PortMappingHelperHandler.java
> > --
> > diff --git a/gateway-server/src/main/java/org/apache/hadoop/
> > gateway/filter/PortMappingHelperHandler.java b/gateway-server/src/main/
> > java/org/apache/hadoop/gateway/filter/PortMappingHelperHandler.java
> > index ea3efc4..06d9668 100644
> > --- a/gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> > PortMappingHelperHandler.java
> > +++ b/gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> > PortMappingHelperHandler.java
> > @@ -96,7 +96,7 @@ public class PortMappingHelperHandler extends
> > HandlerWrapper {
> >throws IOException, ServletException {
> >
> >  String newTarget = target;
> > -String baseURI = baseRequest.getUri().toString();
> > +String baseURI = baseRequest.getRequestURI();
> >
> >  // If Port Mapping feature enabled
> >  if (config.isGatewayPortMappingEnabled()) {
> >
> > http://git-wip-us.apache.org/repos/asf/knox/blob/772bc33d/
> > gateway-test-release/pom.xml
> > --
> > diff --git a/gateway-test-release/pom.xml 

Re: knox git commit: KNOX-1161 - Update hadoop dependencies to hadoop 3

[Colm O hEigeartaigh]

Hi Sandeep,

I'm wondering if this (major) upgrade is not breaking the idea of trying to
change as little as possible for 1.0.0 from 0.14.0?

I think "jackson2.version" added to the root pom with version 2.2.2 could
be removed, as it is not used anywhere. Why do we exclude Kerby from the
Hadoop pom and then include it as a dependency again?

Also, is it really necessary to "downgrade" various dependencies just
because they are used by Hadoop? Beanutils is downgraded from 1.9.3 to
1.9.2. Also we are defining lower versions of Jackson and Mockito in the
gateway-test-release pom.

Colm.

On Fri, Jan 5, 2018 at 7:40 PM,  wrote:

> Repository: knox
> Updated Branches:
>   refs/heads/master 6d4756f3d -> 772bc33d4
>
>
> KNOX-1161 - Update hadoop dependencies to hadoop 3
>
>
> Project: http://git-wip-us.apache.org/repos/asf/knox/repo
> Commit: http://git-wip-us.apache.org/repos/asf/knox/commit/772bc33d
> Tree: http://git-wip-us.apache.org/repos/asf/knox/tree/772bc33d
> Diff: http://git-wip-us.apache.org/repos/asf/knox/diff/772bc33d
>
> Branch: refs/heads/master
> Commit: 772bc33d48dd37be5cd098992df3e50db24326f3
> Parents: 6d4756f
> Author: Sandeep More 
> Authored: Fri Jan 5 14:38:24 2018 -0500
> Committer: Sandeep More 
> Committed: Fri Jan 5 14:38:24 2018 -0500
>
> --
>  .../filter/PortMappingHelperHandler.java|  2 +-
>  gateway-test-release/pom.xml| 77 
>  pom.xml | 31 +++-
>  3 files changed, 107 insertions(+), 3 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/knox/blob/772bc33d/
> gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> PortMappingHelperHandler.java
> --
> diff --git a/gateway-server/src/main/java/org/apache/hadoop/
> gateway/filter/PortMappingHelperHandler.java b/gateway-server/src/main/
> java/org/apache/hadoop/gateway/filter/PortMappingHelperHandler.java
> index ea3efc4..06d9668 100644
> --- a/gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> PortMappingHelperHandler.java
> +++ b/gateway-server/src/main/java/org/apache/hadoop/gateway/filter/
> PortMappingHelperHandler.java
> @@ -96,7 +96,7 @@ public class PortMappingHelperHandler extends
> HandlerWrapper {
>throws IOException, ServletException {
>
>  String newTarget = target;
> -String baseURI = baseRequest.getUri().toString();
> +String baseURI = baseRequest.getRequestURI();
>
>  // If Port Mapping feature enabled
>  if (config.isGatewayPortMappingEnabled()) {
>
> http://git-wip-us.apache.org/repos/asf/knox/blob/772bc33d/
> gateway-test-release/pom.xml
> --
> diff --git a/gateway-test-release/pom.xml b/gateway-test-release/pom.xml
> index e61e0c8..48def02 100644
> --- a/gateway-test-release/pom.xml
> +++ b/gateway-test-release/pom.xml
> @@ -34,7 +34,62 @@
>  webhdfs-test
>  
>
> +
> +9.3.19.v20170502
> +1.8.4
> +2.7.8
> +
> +
> +
>  
> +
> +
> +com.fasterxml.jackson.core
> +jackson-databind
> +${jackson2.version}
> +
> +
> +
> +org.mockito
> +mockito-all
> +${mockito.version}
> +test
> +
> +
> +
> +org.eclipse.jetty
> +jetty-server
> +${jetty.version}
> +
> +
> +org.eclipse.jetty
> +javax.servlet-api
> +
> +
> +
> +
> +org.eclipse.jetty
> +jetty-util
> +${jetty.version}
> +
> +
> +org.eclipse.jetty
> +jetty-servlet
> +${jetty.version}
> +
> +
> +org.eclipse.jetty
> +jetty-webapp
> +${jetty.version}
> +
> +
> +org.eclipse.jetty
> +jetty-util-ajax
> +${jetty.version}
> +
> +
> +
> +
>  
>  javax.servlet
>  javax.servlet-api
> @@ -118,10 +173,27 @@
>  org.apache.directory.server
>  apacheds-all
>  
> +
> +
> +commons-configuration
> +commons-configuration
> +
> +
> +
> +com.fasterxml.jackson.core
> +jackson-databind
> +
> +
>  
>  
>
>  
> +commons-configuration
> +commons-configuration
> +1.10
> +
> +
> +
>  org.hamcrest
>