Re: [Pki-devel] patch for review : https://bugzilla.redhat.com/show_bug.cgi?id=712931

I'm strill tracking down why the install failed. So far, I can just determine that the CS DirSrv is not running when the ldap modify command comes through, but I am not sure why. base/ca/shared/conf/proxy.conf while it is a proxy to tomcat, from the apache perspective, tomcat is a subordinate. It might not be the clearest name. Perhaps proxy-tomcat.conf or proxy-dogtag.conf, although I thought dogtag.conf was a fairly descriptive name. All of the stanzas now appear identical with the exception of the LocationMatch and one with NSSVerifyClient require. Can the 3 NSSVerifyClient stanzas be collapsed be collapsed into one? ImportCAChainPanel.java:display if this line fails: context.put("machineName", cs.getString("machineName")); The processing continue on, but the next two lines: context.put("https_port", cs.getString("pkicreate.ee_secure_port")); context.put("http_port", cs.getString("pkicreate.unsecure_port")); Will never get executed. THat doesn't seem like the intention we want. These two lines should probable be outside the catch block, and trigger an exception that stops processing, as it seems like things are significantly broken at this point. AdminRequestFilter.java Drop the bad_port boolean and move the conditional code up to where bad_port is set. if (bad_port) { CMS.debug( filterName + ": " + msg ); CMS.debug( filterName + ": uri is " + uri); if ((param_active != null) &&(param_active.equals("false"))) { CMS.debug("Filter is disabled .. continuing"); } else { resp.sendError( HttpServletResponse.SC_NOT_FOUND, msg ); return; } } AgentRequestFilter.java EEClientAuthRequestFilter.java EERequestFilter.java Code is duplicate of the code in the AdminRequest\Filter. refactor to a common method. Comment from above applies here as well re: bad_port fixProxyPorts: Why catch the exception and continue. Wouldn't it be better to throw the exception? Do we really want to continue if this code does not succeed? Relative paths in html files: seesm like we should specify a place for the helper files to live, instead of assuming they will be in ../cms-funcs.js as that is a little on the fragile side. I am guessing that it can no longer be just /ee/ since we might be coming from /eeca/ Probably OK as is for this commit, but lets figure out what we'd ideally want to do. I'm guessing that the eeca approach is really not what we want, and this is a work around for it, too. I didn't give the perl code a thorough a look as the Java code, but it looked OK.