embedded-jetty | 易学教程

Keycloak logout does not end session

阅读更多关于 Keycloak logout does not end session

I am using Keycloak 3.4 in a Java Application using Spring Framework and Jetty 8.1 with Keycloak Jetty-81-Adapter 3.4. According to the Keycloak documentation I should be able to use the HttpServletRequest in a Java EE application to logout from Keycloak. However, this does not work in my case, even though Jetty supports HttpServletRequests. You can log out of a web application in multiple ways. For Java EE servlet containers, you can call HttpServletRequest.logout().. If I try to logout this way, I get redirected to keycloak (login screen with option to choose from multiple realm logins).

Gradle embedded jetty plugin is not stopping automatically

阅读更多关于 Gradle embedded jetty plugin is not stopping automatically

问题 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'

embedding jetty server problems

阅读更多关于 embedding jetty server problems

问题 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

Reverse Proxy Java

阅读更多关于 Reverse Proxy Java

I am working with a Java web application and I would like to have a reverse proxy masking some of my internal endpoints. Requirements 1. The reverse proxy maps need to be modifiable at runtime e.g if we move some components to another server we should be able to modify the mapping such that new requests are routed to this endpoint. 2. This must be embeddable to a standard servlet container like Jetty. Most of the Java Reverse Proxies out there such as J2EP require mapping information available prior to starting the application. As far as I can see, http://www.membrane-soa.org/service-proxy/

Embedded Jetty 9 handle one request at a time

阅读更多关于 Embedded Jetty 9 handle one request at a time

问题 I am using jetty 9 in embedded mode and even though i have given a threadpool of 500 the server still just handle one request at a time. What am i missing ? JAVA CODE: // here i expect all thread name log to print instantaneously but they print one by one public class Main { public static void main(String[] arg) throws Exception { ExecutorThreadPool executorThreadPool = new ExecutorThreadPool(Executors.newFixedThreadPool(500)); final Server server = new Server(executorThreadPool); final

Embedded Jetty: In secure https server, ContextHandler redirects to http URI

阅读更多关于 Embedded Jetty: In secure https server, ContextHandler redirects to http URI

I'm building a sandbox RESTful API using embedded Jetty. My Proof-of-Concept design: a simple embedded jetty server that (1) accepts connections on an SSL port and (2) uses a ContextHandlerCollection to invoke the proper Handler based on the URI prefix. My original test, using a simple non-SSL connection, seemed to work perfectly (note, code for imports and helper HelloHandler class in APPENDIX). public static void main(String[] args) throws Exception { Server server = new Server(12000); ContextHandler test1Context = new ContextHandler(); test1Context.setContextPath("/test1"); test1Context

Understanding Jetty's “Closed while Pending/Unready” warning

阅读更多关于 Understanding Jetty's “Closed while Pending/Unready” warning

We have an asynchronous servlet which produces the following warning log from Jetty: java.io.IOException: Closed while Pending/Unready After enabling debug logs I got the following stacktrace: WARN [jetty-25948] (HttpOutput.java:278) - java.io.IOException: Closed while Pending/Unready DEBUG [jetty-25948] (HttpOutput.java:279) - java.io.IOException: Closed while Pending/Unready at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:277) ~[jetty-server.jar:9.4.8.v20171121] at org.eclipse.jetty.server.Response.closeOutput(Response.java:1044) [jetty-server.jar:9.4.8.v20171121] at org.eclipse

Java embedded jetty is accepting HTTP TRACE method

阅读更多关于 Java embedded jetty is accepting HTTP TRACE method

问题 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

How can i deliver jetty with many webapps via jnlp?

阅读更多关于 How can i deliver jetty with many webapps via jnlp?

i have a webapp ( http://sourceforge.net/projects/sf-mvn-plugins/files/m2-repo/net/sf/maven/plugins/example-captaincasa-jnlp/0.1-SNAPSHOT/example-captaincasa-jnlp-0.1-SNAPSHOT.war/download ) wich use jsf in a servlet container. This works fine with jetty-maven-plugin run-war target at my local pc. In the future i would like make more of this kind of weapps. Now i am looking for a way to deliver this webapps with jetty via jnlp. The end user should be have a zero installation but the webapps needs servlet container and my hoster does not support a servlet container or application server or so

Exclude Gradle classpath runtime when launching JettyRun

阅读更多关于 Exclude Gradle classpath runtime when launching JettyRun

问题 I have your basic run of the mill Gradle web application project and it works ok but I noticed that Gradle's runtime classpath is being included in the jetty one which has the potential to conflict with the web applications. Notice below that gradle is using a slightly older version of logback and that SL4J is warning that it found multiple bindings in the classpath. :jettyRun SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/C:/dev/java/tools/gradle-1.0