Thomas, note that accessing the threadpool directly will give you threads, but it will not correctly set the context environment. Thus you may have classloader issues as the WEB-INF/lib will not be on the classpath as seen by those threads (and other JNDI/plus stuff may not be setup).
Using AsyncContext threads does give you that environment, so if you have to tunnel through with reflection, it is probably better to get the AsyncContext than the thread pool. On 26 November 2015 at 03:56, Joakim Erdfelt <[email protected]> wrote: > Again, strongly discourage the direct access to the server ThreadPool like > that. > Either use the AsyncContext or your own Executor/ThreadPool. > > Your implementation has none of the safety measures that are built into > the AsyncContext layer's use of the Server ThreadPool. > > > Joakim Erdfelt / [email protected] > > On Wed, Nov 25, 2015 at 9:54 AM, Joakim Erdfelt <[email protected]> > wrote: > >> Wouldn't this work? >> >> >> https://java.net/projects/jax-rs-spec/pages/AsyncServerProcessingModel/revisions/22 >> >> Joakim Erdfelt / [email protected] >> >> On Wed, Nov 25, 2015 at 8:50 AM, Thomas Meyer <[email protected]> wrote: >> >>> Am 25.11.2015 4:26 nachm. schrieb Joakim Erdfelt <[email protected]>: >>> > >>> > Manage your own ThreadPool, or use the Servlet AsyncContext features >>> for async processing of individual requests. >>> >>> Hi, >>> >>> Sadly in JAX-RS you don't have access to AsyncContext, here is my >>> solution. I had to use reflection because of classloader issues... >>> >>> Path("res") >>> public class TestResource { >>> >>> private Logger log; >>> >>> public TestResource() { >>> log = Logger.getLogger(TestResource.class.getName()); >>> } >>> >>> @GET >>> public void getResourceData(@Suspended AsyncResponse ar, >>> @Context ServletContext sc) throws NoSuchMethodException, >>> SecurityException, IllegalAccessException, IllegalArgumentException, >>> InvocationTargetException { >>> log.log(Level.INFO, "In thread {0}", >>> Thread.currentThread()); >>> >>> Method methodGetContextHandler = >>> sc.getClass().getMethod("getContextHandler"); >>> Object contextHandler = >>> methodGetContextHandler.invoke(sc, null); >>> Method methodGetServer = >>> contextHandler.getClass().getMethod("getServer"); >>> Object server = methodGetServer.invoke(contextHandler, >>> null); >>> Method methodGetThreadpool = >>> server.getClass().getMethod("getThreadPool"); >>> Executor threadPool = (Executor) >>> methodGetThreadpool.invoke(server, null); >>> >>> Runnable run = new Runnable() { >>> @Override >>> public void run() { >>> Logger log = Logger.getAnonymousLogger(); >>> log.log(Level.INFO, "In thread {0}", >>> Thread.currentThread()); >>> ar.resume("it works!"); >>> } >>> }; >>> threadPool.execute(run); >>> } >>> } >>> >>> The JPA context has a warp() function, it would be cool if >>> ServletContext could have something similar: sc.wrap(Server.class) to get >>> the underlying server class. >>> >>> > Joakim Erdfelt / [email protected] >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
