embedded-jetty

I-Jetty or Jetty

痴心易碎 提交于 2019-12-05 02:08:39
问题 I have a web application to be hosted on android device. I am currently using the emulator available with android sdk. My application will serve both static as well as dynamic data. I am currently using jetty version 6.1.22. I wanted to ask what will be a better option to be used. 1. Jetty webserver with stripped off code. 2. I-Jetty. My application uses following features- ResourceHandler to serve static resources. A Generic servlet to serve synchronous data requests. An extension to

How do I configure embedded jetty server to log all requests?

时间秒杀一切 提交于 2019-12-05 00:31:47
问题 I want to log all soap requests to my server. The server instance is an embedded jetty server. Is there a way to setup a handler to do this. I have access to the web.xml file 回答1: You'll want the following on your embedded jetty startup... (This is assuming Jetty 9) HandlerCollection handlers = new HandlerCollection(); ContextHandlerCollection contexts = new ContextHandlerCollection(); // your context specific handlers are added to "contexts" here server.setHandler(handlers); NCSARequestLog

Gradle embedded jetty plugin is not stopping automatically

拟墨画扇 提交于 2019-12-04 18:44:39
I am able to run embedded jetty with gradle jettyRunWar command. However, it is not automatically stopped on program termination. I tried below two code after searching the solution on stackoverflow and other forums. But none works. 1) build.gradle apply plugin: 'jetty' task runJetty() { jettyStop.stopPort = 8090 dependsOn jettyRunWar finalizedBy jettyStop } 2) build.gradle apply plugin: 'jetty' task runJetty() { doFirst { jettyRunWar.stopPort = 8090 jettyRunWar.stopKey = 'stopKey' jettyRunWar.daemon = true tasks.jettyRunWar.execute() } doLast { jettyStop.stopPort = 8090 jettyStop.stopKey =

embedding jetty server problems

早过忘川 提交于 2019-12-04 15:12:22
I am having some struggles embedding a jetty server into a java app. I am using spring to configure the actual objects and I can build the webapp no problems - but I get this problem when starting up the server... 0 [main] INFO test.Server - Starting server in 'c:/workspace/test/war/' on port 9090 34615 [main] INFO test.Server - Using resource base: src/main/webapp 34615 [main] INFO test.Server - Using descriptor file: src/main/webapp/WEB-INF/web.xml 2011-09-05 12:29:36.961:INFO::Logging to STDERR via org.mortbay.log.StdErrLog 36344 [main] INFO test.Server - Starting Server! 2011-09-05 12:29

Jetty 9: Setting up handlers and connectors

[亡魂溺海] 提交于 2019-12-04 14:42:09
I've looked at the documentation for Jetty 9 on the architecture ( http://www.eclipse.org/jetty/documentation/current/architecture.html ) but I am still confused about the relationship between handlers and connectors. Can you link a handler to a specific connector (if so, how? The connector doesn't seem to have a setHandler method)? Or does everything go to a main handler and then you distribute things from there? (i.e. You figure out form what connector it came from so then you forward it to a different handler or handle it yourself) Thanks a lot! Connectors are the components that listen for

How to set up SSL on an embedded Jetty?

限于喜欢 提交于 2019-12-04 13:59:04
问题 I've got jetty 7.x embedded. Basically just creating a SelectChannelConnector to listen on port 80 and WebAppContext to deploy a single WAR directory. I need to add SSL now (all the keystore stuff is done), and I would have guessed to just add an SslSelectChannelConnector, but all the methods are deprecated without any javadocs to explain why, and what to do instead. And the Jetty/SSL docs only show some XML without describing what to do with it. Can anyone get me the entry point here to

Enabling TLS-1.2 on embedded Jetty

为君一笑 提交于 2019-12-04 13:35:12
问题 Currently I am using this code which is enabling TLS 1.2: ServerConnector httpsConnector = new ServerConnector(server, new SslConnectionFactory(sslContextFactory, "http/1.1"), new HttpConnectionFactory(https_config)); httpsConnector.setPort(8443); httpsConnector.setIdleTimeout(50000) Now I am using TLS 1.1 and want to change it to TLS 1.2. 回答1: Java 8 is TLS/1.2 by default. https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls You can diagnose TLS in the JVM using the

How to configure cache for static resources in web.xml for Jetty?

旧城冷巷雨未停 提交于 2019-12-04 11:12:10
问题 I was reading this: http://docs.codehaus.org/display/JETTY/LastModifiedCacheControl It says The Jetty default servlet allows the cache control header to be set for static content by using the cacheControl init parameter using: <init-param> <param-name>cacheControl</param-name> <param-value>max-age=3600,public</param-value> </init-param> However, I am not sure that I am using the default servlet. At least such configuration is not in web.xml: <web-app> <display-name>Wicket QuickStart</display

Java embedded jetty is accepting HTTP TRACE method

六月ゝ 毕业季﹏ 提交于 2019-12-04 10:59:56
I'm trying to disable HTTP TRACE method in embedded Jetty. In Jetty doc's is info that HTTP trace is disabled by default, but for embedded it is still enabled. I was trying to disable trace as a security constraint as is done in jetty.xml. ServletContextHandler servletHandler = new ServletContextHandler(ServletContextHandler.SESSIONS | ServletContextHandler.SECURITY); servletHandler.setClassLoader(Server.class.getClassLoader()); servletHandler.setContextPath("/"); servletHandler.addEventListener(new ContextLoaderListener()); servletHandler.addServlet(new ServletHolder(new CXFServlet()), "/*");

Programmatic Jetty shutdown

纵然是瞬间 提交于 2019-12-04 09:45:05
问题 How to programmatically shutdown embedded jetty server? I start jetty server like this: Server server = new Server(8090); ... server.start(); server.join(); Now, I want to shut it down from a request, such as http://127.0.0.1:8090/shutdown How do I do it cleanly? The commonly proposed solution is to create a thread and call server.stop() from this thread. But I possibly need a call to Thread.sleep() to ensure that the servlet has finished processing the shutdown request. 回答1: I found a very