It isn't exactly clear to me what you encountered here. I think that you are saying that you made changes to "services files" - meaning the service definition.
If that is the case then a simple redeploy of the topology will not be enough. You have to restart the gateway so that the service definitions are reloaded then unfortunately you have to touch the topology file/s that host the service that you changed the definition for. There is an undocumented config element in gateway-site.xml to force auto deployment on start for specific topologies - it is a comma separated list of topology name: gateway.auto.deploy.topologies It defaults to "manager,admin" You could add your topologies to that and have them redeployed at restart if you like - make sure to leave manager and admin in there though. If you would like a config item that redeploys each topology on startup then please feel free to file a JIRA for it and we can consider it for 1.3.0. On Wed, Nov 28, 2018 at 3:01 PM Lars Francke <[email protected]> wrote: > I was facing another weird issue today that took me a while to chase down. > > I didn't have the proper services directory in place when starting Knox for > the first time. This meant that a gateway.xml file was created in the > deployments dir for my topologies that was totally empty. It didn't have > any filters so all my tests returned a "Failed to match path" error. > > The problem here is that Knox checks on startup what the timestamp on the > topology is and only if that has changed does it create a new deployment. > If anything else changes this is not rewritten. So changes to the services > files will not be noticed by Knox and silently ignored. > > I understand that this is an edge-case but other than a slightly longer > startup would it hurt to recreate the deployments on every startup? > > Cheers, > Lars >
