zeroflag commented on a change in pull request #537:
URL: https://github.com/apache/knox/pull/537#discussion_r811844702



##########
File path: 
gateway-provider-identity-assertion-common/src/main/java/org/apache/knox/gateway/identityasserter/common/filter/CommonIdentityAssertionFilter.java
##########
@@ -59,6 +74,55 @@ public void init(FilterConfig filterConfig) throws 
ServletException {
         throw new ServletException("Unable to load principal mapping table.", 
e);
       }
     }
+    virtualGroupMapper = new 
VirtualGroupMapper(loadVirtualGroups(filterConfig));
+  }
+
+  private Map<String, Ast> loadVirtualGroups(FilterConfig filterConfig) {
+    Map<String, Ast> predicateToGroupMapping = new HashMap<>();
+    loadVirtualGroupConfig(filterConfig, predicateToGroupMapping);
+    if (predicateToGroupMapping.isEmpty() && filterConfig.getServletContext() 
!= null) {
+      loadVirtualGroupConfig(filterConfig.getServletContext(), 
predicateToGroupMapping);
+    }
+    if 
(predicateToGroupMapping.keySet().stream().anyMatch(StringUtils::isBlank)) {
+      LOG.missingVirtualGroupName();
+    }
+    return predicateToGroupMapping;
+  }
+
+  private void loadVirtualGroupConfig(FilterConfig config, Map<String, Ast> 
result) {
+    for (String paramName : 
virtualGroupParameterNames(config.getInitParameterNames())) {

Review comment:
       This happens only in deployment time once, so from performance point of 
view it's not a big problem.
   
   At first we try to load the groups from the FilterConfig then from the 
ServletContext (this is how we load other properties from other filters too).
   
   Unfortunately FilterConfig and ServletContext doesn't have the same 
interface, that's why we have this duplication. The 
`virtualGroupParameterNames` was an attempt to reduce the duplication so at 
least the `if` statement is not duplicated in both methods.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@knox.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to