Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-862

after ThreadSetupAction deprecation can`t set deployment`s ThreadSetupActions and ThreadSetupHandlers through ServletExtension

XMLWordPrintable

    • Hide

      create ServletExtension and ThreadSetupAction like this:

      public class UndertowDeploymentExtension implements ServletExtension {
      
      	@Override
      	public void handleDeployment(final DeploymentInfo deploymentInfo, final ServletContext servletContext) {
      ...
      		deploymentInfo.addThreadSetupAction(new MyOldDeprecatedAction(servletContext));
      ..
      
      

      MyOldDeprecatedAction not call never because it will be ignored/

      Show
      create ServletExtension and ThreadSetupAction like this: public class UndertowDeploymentExtension implements ServletExtension { @Override public void handleDeployment( final DeploymentInfo deploymentInfo, final ServletContext servletContext) { ... deploymentInfo.addThreadSetupAction( new MyOldDeprecatedAction(servletContext)); .. MyOldDeprecatedAction not call never because it will be ignored/
    • Hide

      may be it possible to add ThreadSetupAction through UndertowDeploymentService which can be found by MSC, but this is too hard and not casual.

      Show
      may be it possible to add ThreadSetupAction through UndertowDeploymentService which can be found by MSC, but this is too hard and not casual.

      By commit e3e3b109b27e6f1e483802d1dc0d5ef36da32fe5 (UNDERTOW-781 Deprecate ThreadSetupAction) ordering in method DeploymentManagerImpl#deploy was changed.

      Now ThreadSetupActions from deploymentInfo accepting into deployment before #handleExtensions call, so our ThreadSetupActions, which we pass into deploymentInfo in our ServletExtension, is ignored:

      #deploy fragment
              final DeploymentInfo deploymentInfo = originalDeployment.clone();
      
              if (deploymentInfo.getServletStackTraces() == ServletStackTraces.ALL) {
                  UndertowServletLogger.REQUEST_LOGGER.servletStackTracesAll(deploymentInfo.getDeploymentName());
              }
      
              deploymentInfo.validate();
              final DeploymentImpl deployment = new DeploymentImpl(this, deploymentInfo, servletContainer);
              this.deployment = deployment;
      
              final List<ThreadSetupHandler> setup = new ArrayList<>();
              setup.add(ServletRequestContextThreadSetupAction.INSTANCE);
              setup.add(new ContextClassLoaderSetupAction(deploymentInfo.getClassLoader()));
              setup.addAll(deploymentInfo.getThreadSetupActions());
              deployment.setThreadSetupActions(setup); // !!!! this actions will work good after deploy
      
              final ServletContextImpl servletContext = new ServletContextImpl(servletContainer, deployment);
              deployment.setServletContext(servletContext);
              handleExtensions(deploymentInfo, servletContext); //!!! our actions, which accepts in extensions, will be ignored
      
      

      We still use old deprecated actions, but seems that problem also exists for new beauty handlers.

      sdouglas1@redhat.com, please check call ordering in #deploy or explain the right way to add ThreadSetupHandler to deployment, if the way through ServletExtension is no longer supported.

              sdouglas1@redhat.com Stuart Douglas (Inactive)
              kostd kostd kostd (Inactive)
              Viacheslav Astapkovich (Inactive), Vsevolod Golovanov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: