I don't know why you would remove the data/services directory but this is essentially the same as what I described. Whether there are no service definitions or you have changed one and try to get the new version uptaken it is the same problem.
As I said, we could add an option to redeploy all topologies on startup but we would definitely not want to make this default setting. I know of some deployments that have LOTS of topologies and redeploying them all on every restart would be needlessly expensive. On Thu, Nov 29, 2018 at 6:27 PM Lars Francke <lars.fran...@gmail.com> wrote: > There's always a good chance that I misunderstood something as well. So > take it with a grain of salt. > > 1) Fresh Knox installation > 2) Remove data/services folder > 3) Start Knox > 4) Look > at /data/deployments/sandbox.topo.166f2486250/%2F/WEB-INF/gateway.xml > It'll contain only "<?xml version="1.0" encoding="UTF-8"?><gateway/>" > 5) Stop Knox > 6) Move data/services in place > 7) Start Knox again > > Knox now will _not_ update the generated gateway.xml file. To me, that is > unexpected. Especially because the whole generation stuff is not documented > while the services are. > This is because Knox looks at the timestamp of the topology file, generates > a hash out of it and if that's unchanged it keeps the old gateway.xml file. > > > On Wed, Nov 28, 2018 at 9:35 PM larry mccay <lmc...@apache.org> wrote: > > > 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 <lars.fran...@gmail.com> > > 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 > > > > > >
