Q:

Jetty REST API to Dynamically adjust QueuedThreadPool maxThreads

It's easy to set min/max threads from jetty configuration:
<Configure id="server" class="org.eclipse.jetty.server.Server">   
<Set name="threadPool">
    <New class="org.eclipse.jetty.util.thread.QueuedThreadPool">
      <Set name="minThreads">10</Set>
      <Set name="maxThreads">1000</Set>
    </New>
</Set> 
</Configure>

I'm using Spring and I have a REST endpoint:
@RequestMapping("/setMaxThreads")
public void setMaxThreads(...) {
    ...
}

How do I access the Server/ThreadPool objects in order to adjust their parameters?
P.S. I understand that any solution likely won't be very generic since those are very implementation-specific parameters.

A:

You can't even do what you describe in your jetty.xml example anymore.
The ThreadPool for a Jetty Server is only set via its constructor now.
It cannot be adjusted during runtime.

This change from .setThreadPool(ThreadPool) to Server constructor based occurred at the start of Jetty 9.x, and was to address the threadpool needs of both Servlet 3.1 and HTTP/2 support.

The reason for this, is that the ThreadPool is injected into dozens of other layers during initialization of those layers, and even more during LifeCycle startup of the Server
If your goal is some sort of premature optimization on the upper limits of the thread pool size?
Stop now.
Since Servlet 3.0, bound (upper limited) thread pools make absolutely no sense for a publicly accessible Jetty Server.
You open yourself to trivial DoS attacks, failed selector processing, dead connections, seemingly random EOF exceptions, etc ... 
Don't optimize the thread pool upper ends and then expect Jetty to handle a high load scenario.
Under high load scenarios, its not uncommon for the QueuedThreadPool to spike (temporarily) to 20,000 or even 50,000 active threads.  When the server load subsides, so will the number of threads that the QueuedThreadPool is managing.  The QueuedThreadPool will grow thread counts quickly if needed, but the removal of threads from the pool is intentionally metered.
If you are a running Jetty on a very controlled, small load scenario, then feel free to just outright replace the QueuedThreadPool with your own declaration. We would suggest you use an ExecutorThreadPool which has a java.util.concurrent.ExecutorService implementation of your own choice. 
An ExecutorThreadPool example:
    int corePoolSize = 400;
    int maximumPoolSize = 1_000_000;
    long keepaliveTimeout = 60L;
    TimeUnit keepaliveUnit = TimeUnit.SECONDS;
    BlockingQueue<Runnable> workQueue = new SynchronousQueue<Runnable>();

    ExecutorService cachedExecutor = new ThreadPoolExecutor(
            corePoolSize, 
            maximumPoolSize,
            keepaliveTimeout,
            keepaliveUnit,
            workQueue);

    ExecutorThreadPool threadpool = new ExecutorThreadPool(cachedExecutor);
    Server server = new Server(threadpool);

