code: private void doLaunchContainer(Class<?> containerClass, Method mainMethod, String[] arguments) throws Exception {
          if (logger.isInfoEnabled()) {
              logger.info("Launching container for " + containerClass.getName()
                      + " with arguments: " + Arrays.asList(arguments));
          }
  
          try {
              mainMethod.invoke(null, (Object) arguments);
              logger.info("Keeping " + containerClass.getName() + " process alive");
              LockSupport.park();
          }
          catch (SystemExitException e) {
              logger.warn("Ignoring System.exit(..) call in " + containerClass.getName());
          }
          if (logger.isInfoEnabled()) {
              logger.warn("Container " + containerClass.getName() + " is finished");
          }
      }
docs: Will invoke Container's main method blocking if necessary. This method
  contains a hack that I am not proud of it, but given the fact that some
  containers rely on System.exit to manage its life-cycle instead of proper
  exit this will ensure that together with the
  SystemExitDisallowingSecurityManager (see constructor of this class) this
  method will block until such container invokes System.exit
  
  ByteCodeUtils.hasSystemExit(..) will check if a container that was invoked
  has calls to System.exit and if it does it will block this thread until
  SystemExitException is thrown which will be caught allowing this method to
  exit normally.
  
  Of course this doesn't guarantee anything since the underlying
  implementation of the container may still be implemented in such way where
  it exits gracefully while also has some shortcut method for some
  exceptional conditions where System.exit is called and if that's the case
  this process will block infinitely.
  
  The bottom line: DON'T USE System.exit when implementing application
  containers!!!