That stacktrace is telling you that
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:85) is attempting to create a context on a server.
The fact that it attempts to .setExecutor() means that it created a new server at the point of ServerMgr.createContext().
But what is odd is that this attempt to .setExecutor() occurred on an already started server. (which is a no-no, and the cause of the error).
You might want to enable java.util.logging and set the logger named "com.sun.xml.internal.ws" to level FINEST and see what its attempting to do.
Some thoughts, because you are using JettyhttpServerProvider.setServer(server), you are essentially wanting to use a shared server instance, regardless of subsequent HttpServer.createHttpServer() calls.
This might be tripping up the WS implementation.
You'll either want to manage the server entirely yourself, or use the http-spi functions in a non-shared mode.
So that simplifies your codebase to the following ....
--(snip)--
System.setProperty("com.sun.net.httpserver.HttpServerProvider",
"org.eclipse.jetty.http.spi.JettyHttpServerProvider");
InetSocketAddress addr = new InetSocketAddress("localhost", 8080);
HttpServer server = new JettyHttpServerProvider.createHttpServer(addr, 10);
Endpoint endpoint = Endpoint.publish(endpointURL, myWebServices);
server.start();
--(snip)--
This is using the http-spi directly, allowing it to manage the http server state and whatnot.
Not the hybrid approach that you were working with.
It seems that the WS implementation you are using requires this approach.