pzampino commented on code in PR #929:
URL: https://github.com/apache/knox/pull/929#discussion_r1724039838
##########
gateway-server/src/main/java/org/apache/knox/gateway/GatewayServer.java:
##########
@@ -962,10 +985,32 @@ private void processApplicationPathAliases(File warDir,
Topology topology) {
});
}
+ private void addInactiveTopology(final String topologyName) {
+ synchronized (inactiveTopologies) {
+ inactiveTopologies.add(topologyName);
+ }
+ }
+
+ private void removeInactiveTopology(final String topologyName) {
+ synchronized (inactiveTopologies) {
+ inactiveTopologies.remove(topologyName);
+ }
+ }
+
+ private boolean isInactiveTopology(final String topologyName) {
+ boolean result = false;
+ synchronized (inactiveTopologies) {
+ result = inactiveTopologies.contains(topologyName);
+ }
+ return result;
+ }
+
private synchronized void internalDeactivateTopology( Topology topology ) {
Review Comment:
Automated testing will be tricky given the small window of time when this is
an issue. I'm open to suggestions though.
When you ask "Does this get called for the first deployment...", what is
"this"? On first deployment, there had not been any opportunity for it to have
been marked as inactive, so I think the answer is "no".
The topology gets marked active upon activation (see
internalActivateTopology method). This is not connected to discovery because
we're dealing directly with topologies here. Discovery will have happened prior
to this, and the undeployment won't happen until the new version of the
topology is written out.
I thought about that, but
1. The source of the 404 responses is Jetty, so overriding them seems
appropriate to do with Jetty facilities.
2. It seems best to do it as close to the activation/deactivation logic as
possible.
--
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
