Hi Ed - The issue is more accurately described as the wrong method because contributeProvider is really part of the process of building the topology webapp not part of the webapp itself. Therefore, anything done inside of those methods are only invoked when a new version of the topology file is created or the file is touched to change the timestamp.
What we want to do is make the start part of the resulting webapp itself. In general, I think that this would be best accomplished by adding a servletContextListner class to the webapp that does the start. You can see an example of that in the ShiroDeploymentContributor: // add servletContextListener context.getWebAppDescriptor().createListener().listenerClass( LISTENER_CLASSNAME ); Inside the servletContextListener you would want to start your sshd service. This way, when the gateway processes are stopped and restarted it starts as part of the webapp and doesn't have to reprocess the topology file can recreate a new webapp just to start. Does that make sense? thanks, --larry On Thu, Jul 24, 2014 at 11:14 AM, Ed Kohlwey <[email protected]> wrote: > Hi, > I'm starting to work on KNOX-250 again, and will hopefully have something > pretty well-rounded posted and available next week. We are currently > running the SSH provider in our production environment, so we're looking > forward to getting this integrated. > > One comment Larry had made (offline) was that the contributeProvider method > was not necessarily the best place to start a long running process. Is > there a place where something like this should happen? Do we need to make > one? If so where? > > Thanks, > -Ed >
