From sdouglas at redhat.com Sat Nov 1 23:24:56 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 1 Nov 2014 23:24:56 -0400 (EDT) Subject: [undertow-dev] Changing headers on proxy response In-Reply-To: References: Message-ID: <983018580.4273408.1414898696728.JavaMail.zimbra@redhat.com> You can set them in a response wrapper (io.undertow.server.HttpServerExchange#addResponseWrapper) and they should not be overriden, although this is not ideal. If you file a JIRA I will look at adding better support for this into the proxy. Stuart ----- Original Message ----- > From: "Jeff Williams" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 1 November, 2014 12:43:38 AM > Subject: [undertow-dev] Changing headers on proxy response > > Hi, > > I am currently using a customer handler wrapping the proxy handler. I want to > set some response headers from my handler, but if they exist in the response > from the proxy's backend, they are overridden. Example code: > > Undertow.builder() > .addHttpListener(8080, "localhost") > .setHandler(new MyHandler(new ProxyHandler(proxy, 30000, ResponseCodeHandler. > HANDLE_404 ))).build(); > > class MyHandler extends HttpHandler { > private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new > HttpString("Access-Control-Expose-Headers"); > private HTTPHandler next; > public MyHandler(HttpHandler next) { > this.next = next; > } > p ublic void handleRequest(HttpServerExchange exchange ) throws Exception { > exchange .getResponseHeaders().put( ACCESS_CONTROL_EXPOSE_HEADERS , " new > ACEH" ); > } > } > > The problem here is that the backend server responds with an > Access-Control-Expose-Headers header and that replaces the one I set in > MyHandler. > > Is there any way I can change headers after proxy has received the response > from backend and before it starts sending the response to the client? > > Regards, > Jeff > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ralf_boogie_blues at bluewin.ch Sun Nov 2 10:30:40 2014 From: ralf_boogie_blues at bluewin.ch (ralf_boogie_blues at bluewin.ch) Date: Sun, 2 Nov 2014 15:30:40 +0000 (GMT) Subject: [undertow-dev] ResponseRateLimitingHandler questions Message-ID: <33325628.16400.1414942240626.JavaMail.webmail@bluewin.ch> Hi Stuart Thanks a lot for the ResponseRateLimitingHandler. I played a little bit with this handler and do have some questions. I added some trace logs in order to understand the logic. Of course, I didn't understand everything;-) May you will correct me. First, I tested the download response with a 1 MBytes file. The response limit was set to 100000 Bytes/s. This should download the whole file in about 10s but the result was 18s. Then, I started to dig into the handler. How I cReated the handler. final ResponseRateLimitingHandler responseLimiter = new ResponseRateLimitingHandler(proxy, 100000, 1, TimeUnit.SECONDS); The trace logs showed me this (with the settings above): the handler writes chunks as big as the buffer is defined, I think on my machine 16KBytes. it repeats this until the bytes written are greater than the rate limit. then, the handler calculates the time to sleep until the next chunks can be written. Problem 1: The handler writes always more than the specified limit. Because of this, the handler calculates n * units for the time to sleep. So, in my test the handler slept always 2s instead of 1s. Problem 2: The size of the chunks is probably too static. I think the chunks should be size relatively to the rate limit. I changed the handler slightly in this way: I introduced along to the existing parameters also a chunkSize. canSend(): if (byteCount < (bytes - chunks)) { return true; } // it doesn't write anymore than allowed handleWritten(long written): nextSendTime = startTime + time; // instead of: nextSendTime = startTime + (units * time); writeFinal and transferFrom writes not more than bytes <= chunkSize. This changes gave me the expected result of about 10s download time. This is quite a long mail :-) It could be still a mistake I did. Let me know what you think. Regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141102/b8151106/attachment.html From sdouglas at redhat.com Sun Nov 2 18:09:50 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 2 Nov 2014 18:09:50 -0500 (EST) Subject: [undertow-dev] ResponseRateLimitingHandler questions In-Reply-To: <33325628.16400.1414942240626.JavaMail.webmail@bluewin.ch> References: <33325628.16400.1414942240626.JavaMail.webmail@bluewin.ch> Message-ID: <1077810839.4332731.1414969790398.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "ralf boogie blues" > To: undertow-dev at lists.jboss.org > Sent: Monday, 3 November, 2014 2:30:40 AM > Subject: [undertow-dev] ResponseRateLimitingHandler questions > Hi Stuart > Thanks a lot for the ResponseRateLimitingHandler. I played a little bit with > this handler and do have some questions. > I added some trace logs in order to understand the logic. Of course, I didn't > understand everything;-) May you will correct me. > First, I tested the download response with a 1 MBytes file. The response > limit was set to 100000 Bytes/s. This should download the whole file in > about 10s but the result was 18s. > Then, I started to dig into the handler. > How I cReated the handler. > final ResponseRateLimitingHandler responseLimiter = new > ResponseRateLimitingHandler(proxy, 100000, 1, TimeUnit.SECONDS); > The trace logs showed me this (with the settings above): > * the handler writes chunks as big as the buffer is defined, I think on my > machine 16KBytes. > * it repeats this until the bytes written are greater than the rate limit. > * then, the handler calculates the time to sleep until the next chunks can be > written. > Problem 1: The handler writes always more than the specified limit. Because > of this, the handler calculates n * units for the time to sleep. So, in my > test the handler slept always 2s instead of 1s. I think this is a bug, for larger unit times I should pro-rata the wait time. If you use a smaller step time (e.g. 10k bytes per 100ms ) this effect will be less pronounced. > Problem 2: The size of the chunks is probably too static. I think the chunks > should be size relatively to the rate limit. This can result in lots more write() calls, which are expensive, so if you are using this because you have a server under heavy load you could potentially increase the load significantly. One option would be to cut down the size of the buffer if it is going to go over the limit, so it will never write more than the specified maximum in the time period. Stuart > I changed the handler slightly in this way: > * I introduced along to the existing parameters also a chunkSize. > * canSend(): if (byteCount < (bytes - chunks)) { return true; } // it doesn't > write anymore than allowed > * handleWritten(long written): nextSendTime = startTime + time; // instead > of: nextSendTime = startTime + (units * time); > * writeFinal and transferFrom writes not more than bytes <= chunkSize. > This changes gave me the expected result of about 10s download time. > This is quite a long mail :-) It could be still a mistake I did. Let me know > what you think. > Regards, Ralf > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141102/5de6b11f/attachment.html From jeffw at wherethebitsroam.com Mon Nov 3 02:34:28 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Mon, 3 Nov 2014 08:34:28 +0100 Subject: [undertow-dev] Changing headers on proxy response In-Reply-To: <983018580.4273408.1414898696728.JavaMail.zimbra@redhat.com> References: <983018580.4273408.1414898696728.JavaMail.zimbra@redhat.com> Message-ID: Stuart, Thanks for that. I'm guessing I can just extend org.xnio.conduits.AbstractStreamSinkConduit and just pass everything through to next? Since there is not much information around about the StreamSinkConduit, where would be the best place to add the headers? In the first call to one of the transferFrom methods? I've added a JIRA for this: https://issues.jboss.org/browse/UNDERTOW-340 Regards, Jeff On 2 November 2014 04:24, Stuart Douglas wrote: > You can set them in a response wrapper > (io.undertow.server.HttpServerExchange#addResponseWrapper) and they should > not be overriden, although this is not ideal. > > If you file a JIRA I will look at adding better support for this into the > proxy. > > Stuart > > ----- Original Message ----- > > From: "Jeff Williams" > > To: undertow-dev at lists.jboss.org > > Sent: Saturday, 1 November, 2014 12:43:38 AM > > Subject: [undertow-dev] Changing headers on proxy response > > > > Hi, > > > > I am currently using a customer handler wrapping the proxy handler. I > want to > > set some response headers from my handler, but if they exist in the > response > > from the proxy's backend, they are overridden. Example code: > > > > Undertow.builder() > > .addHttpListener(8080, "localhost") > > .setHandler(new MyHandler(new ProxyHandler(proxy, 30000, > ResponseCodeHandler. > > HANDLE_404 ))).build(); > > > > class MyHandler extends HttpHandler { > > private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new > > HttpString("Access-Control-Expose-Headers"); > > private HTTPHandler next; > > public MyHandler(HttpHandler next) { > > this.next = next; > > } > > p ublic void handleRequest(HttpServerExchange exchange ) throws > Exception { > > exchange .getResponseHeaders().put( ACCESS_CONTROL_EXPOSE_HEADERS , " new > > ACEH" ); > > } > > } > > > > The problem here is that the backend server responds with an > > Access-Control-Expose-Headers header and that replaces the one I set in > > MyHandler. > > > > Is there any way I can change headers after proxy has received the > response > > from backend and before it starts sending the response to the client? > > > > Regards, > > Jeff > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141103/dc7bd1bc/attachment-0001.html From sdouglas at redhat.com Mon Nov 3 02:57:48 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 3 Nov 2014 02:57:48 -0500 (EST) Subject: [undertow-dev] Changing headers on proxy response In-Reply-To: References: <983018580.4273408.1414898696728.JavaMail.zimbra@redhat.com> Message-ID: <1338366422.4456588.1415001468225.JavaMail.zimbra@redhat.com> You just return the original conduit, but set the headers in the wrapper class itself. Stuart ----- Original Message ----- > From: "Jeff Williams" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Monday, 3 November, 2014 6:34:28 PM > Subject: Re: [undertow-dev] Changing headers on proxy response > > Stuart, > > Thanks for that. I'm guessing I can just extend > org.xnio.conduits.AbstractStreamSinkConduit and just > pass everything through to next? Since there is not much information around > about the StreamSinkConduit, where would be the best place to add the > headers? In the first call to one of the transferFrom methods? > > I've added a JIRA for this: https://issues.jboss.org/browse/UNDERTOW-340 > > Regards, > Jeff > > On 2 November 2014 04:24, Stuart Douglas wrote: > > > You can set them in a response wrapper > > (io.undertow.server.HttpServerExchange#addResponseWrapper) and they should > > not be overriden, although this is not ideal. > > > > If you file a JIRA I will look at adding better support for this into the > > proxy. > > > > Stuart > > > > ----- Original Message ----- > > > From: "Jeff Williams" > > > To: undertow-dev at lists.jboss.org > > > Sent: Saturday, 1 November, 2014 12:43:38 AM > > > Subject: [undertow-dev] Changing headers on proxy response > > > > > > Hi, > > > > > > I am currently using a customer handler wrapping the proxy handler. I > > want to > > > set some response headers from my handler, but if they exist in the > > response > > > from the proxy's backend, they are overridden. Example code: > > > > > > Undertow.builder() > > > .addHttpListener(8080, "localhost") > > > .setHandler(new MyHandler(new ProxyHandler(proxy, 30000, > > ResponseCodeHandler. > > > HANDLE_404 ))).build(); > > > > > > class MyHandler extends HttpHandler { > > > private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new > > > HttpString("Access-Control-Expose-Headers"); > > > private HTTPHandler next; > > > public MyHandler(HttpHandler next) { > > > this.next = next; > > > } > > > p ublic void handleRequest(HttpServerExchange exchange ) throws > > Exception { > > > exchange .getResponseHeaders().put( ACCESS_CONTROL_EXPOSE_HEADERS , " new > > > ACEH" ); > > > } > > > } > > > > > > The problem here is that the backend server responds with an > > > Access-Control-Expose-Headers header and that replaces the one I set in > > > MyHandler. > > > > > > Is there any way I can change headers after proxy has received the > > response > > > from backend and before it starts sending the response to the client? > > > > > > Regards, > > > Jeff > > > > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From jeffw at wherethebitsroam.com Mon Nov 3 04:44:58 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Mon, 3 Nov 2014 10:44:58 +0100 Subject: [undertow-dev] Changing headers on proxy response In-Reply-To: <1338366422.4456588.1415001468225.JavaMail.zimbra@redhat.com> References: <983018580.4273408.1414898696728.JavaMail.zimbra@redhat.com> <1338366422.4456588.1415001468225.JavaMail.zimbra@redhat.com> Message-ID: Thanks, that worked perfectly for now. Jeff On 3 November 2014 08:57, Stuart Douglas wrote: > You just return the original conduit, but set the headers in the wrapper > class itself. > > Stuart > > ----- Original Message ----- > > From: "Jeff Williams" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org > > Sent: Monday, 3 November, 2014 6:34:28 PM > > Subject: Re: [undertow-dev] Changing headers on proxy response > > > > Stuart, > > > > Thanks for that. I'm guessing I can just extend > > org.xnio.conduits.AbstractStreamSinkConduit and just > > pass everything through to next? Since there is not much information > around > > about the StreamSinkConduit, where would be the best place to add the > > headers? In the first call to one of the transferFrom methods? > > > > I've added a JIRA for this: https://issues.jboss.org/browse/UNDERTOW-340 > > > > Regards, > > Jeff > > > > On 2 November 2014 04:24, Stuart Douglas wrote: > > > > > You can set them in a response wrapper > > > (io.undertow.server.HttpServerExchange#addResponseWrapper) and they > should > > > not be overriden, although this is not ideal. > > > > > > If you file a JIRA I will look at adding better support for this into > the > > > proxy. > > > > > > Stuart > > > > > > ----- Original Message ----- > > > > From: "Jeff Williams" > > > > To: undertow-dev at lists.jboss.org > > > > Sent: Saturday, 1 November, 2014 12:43:38 AM > > > > Subject: [undertow-dev] Changing headers on proxy response > > > > > > > > Hi, > > > > > > > > I am currently using a customer handler wrapping the proxy handler. I > > > want to > > > > set some response headers from my handler, but if they exist in the > > > response > > > > from the proxy's backend, they are overridden. Example code: > > > > > > > > Undertow.builder() > > > > .addHttpListener(8080, "localhost") > > > > .setHandler(new MyHandler(new ProxyHandler(proxy, 30000, > > > ResponseCodeHandler. > > > > HANDLE_404 ))).build(); > > > > > > > > class MyHandler extends HttpHandler { > > > > private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new > > > > HttpString("Access-Control-Expose-Headers"); > > > > private HTTPHandler next; > > > > public MyHandler(HttpHandler next) { > > > > this.next = next; > > > > } > > > > p ublic void handleRequest(HttpServerExchange exchange ) throws > > > Exception { > > > > exchange .getResponseHeaders().put( ACCESS_CONTROL_EXPOSE_HEADERS , > " new > > > > ACEH" ); > > > > } > > > > } > > > > > > > > The problem here is that the backend server responds with an > > > > Access-Control-Expose-Headers header and that replaces the one I set > in > > > > MyHandler. > > > > > > > > Is there any way I can change headers after proxy has received the > > > response > > > > from backend and before it starts sending the response to the client? > > > > > > > > Regards, > > > > Jeff > > > > > > > > > > > > _______________________________________________ > > > > undertow-dev mailing list > > > > undertow-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141103/1211d798/attachment.html From jeffw at wherethebitsroam.com Mon Nov 3 07:48:10 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Mon, 3 Nov 2014 13:48:10 +0100 Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit Message-ID: Hi, I have written a StreamSinkConduit which buffers content in a pooled buffer. I am having an issue with AbstractFixedLengthStreamSinkConduit throwing a FixedLengthUnderflowException exception. If I have content left in my buffer which I have not yet been able to write to the next conduit when terminateWrites is called, the exception is thrown. Even though this content would have been written in the subsequent call to flush. Shouldn't the bytes remaining be checked after a successful flush rather than in terminateWrites? Or am I missing something? For the time being I am flushing my local buffer in terminateWrites, but this seems wrong! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141103/c87a2cfc/attachment.html From sdouglas at redhat.com Mon Nov 3 15:10:53 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 3 Nov 2014 15:10:53 -0500 (EST) Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit In-Reply-To: References: Message-ID: <799967324.4907688.1415045453307.JavaMail.zimbra@redhat.com> You need to not pass on the terminateWrites() call to the delegate until your have written all your data. Once terminateWrites is called on your channel set some kind of boolean flag to indicate that this is shutdown, and then when the user calls flush() write out the buffer (using writeFinal for best performance). If you are not using writeFinal() then you need to call terminateWrites() once you succeed in flushing, and then pass further flush calls to the delegate. Stuart ----- Original Message ----- > From: "Jeff Williams" > To: undertow-dev at lists.jboss.org > Sent: Monday, 3 November, 2014 11:48:10 PM > Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit > > Hi, > > I have written a StreamSinkConduit which buffers content in a pooled buffer. > I am having an issue with AbstractFixedLengthStreamSinkConduit throwing a > FixedLengthUnderflowException exception. > > If I have content left in my buffer which I have not yet been able to write > to the next conduit when terminateWrites is called, the exception is thrown. > Even though this content would have been written in the subsequent call to > flush. Shouldn't the bytes remaining be checked after a successful flush > rather than in terminateWrites? Or am I missing something? > > For the time being I am flushing my local buffer in terminateWrites, but this > seems wrong! > > Jeff > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Mon Nov 3 15:11:42 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 3 Nov 2014 15:11:42 -0500 (EST) Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit In-Reply-To: <799967324.4907688.1415045453307.JavaMail.zimbra@redhat.com> References: <799967324.4907688.1415045453307.JavaMail.zimbra@redhat.com> Message-ID: <1090372355.4908087.1415045502959.JavaMail.zimbra@redhat.com> org.xnio.conduits.BufferedStreamSinkConduit is probably a good example, although it does not use writeFinal(). Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Jeff Williams" > Cc: undertow-dev at lists.jboss.org > Sent: Tuesday, 4 November, 2014 7:10:53 AM > Subject: Re: [undertow-dev] AbstractFixedLengthStreamSinkConduit > > You need to not pass on the terminateWrites() call to the delegate until your > have written all your data. > > Once terminateWrites is called on your channel set some kind of boolean flag > to indicate that this is shutdown, and then when the user calls flush() > write out the buffer (using writeFinal for best performance). If you are not > using writeFinal() then you need to call terminateWrites() once you succeed > in flushing, and then pass further flush calls to the delegate. > > Stuart > > ----- Original Message ----- > > From: "Jeff Williams" > > To: undertow-dev at lists.jboss.org > > Sent: Monday, 3 November, 2014 11:48:10 PM > > Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit > > > > Hi, > > > > I have written a StreamSinkConduit which buffers content in a pooled > > buffer. > > I am having an issue with AbstractFixedLengthStreamSinkConduit throwing a > > FixedLengthUnderflowException exception. > > > > If I have content left in my buffer which I have not yet been able to write > > to the next conduit when terminateWrites is called, the exception is > > thrown. > > Even though this content would have been written in the subsequent call to > > flush. Shouldn't the bytes remaining be checked after a successful flush > > rather than in terminateWrites? Or am I missing something? > > > > For the time being I am flushing my local buffer in terminateWrites, but > > this > > seems wrong! > > > > Jeff > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev From jeffw at wherethebitsroam.com Mon Nov 3 16:15:00 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Mon, 3 Nov 2014 22:15:00 +0100 Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit In-Reply-To: <1090372355.4908087.1415045502959.JavaMail.zimbra@redhat.com> References: <799967324.4907688.1415045453307.JavaMail.zimbra@redhat.com> <1090372355.4908087.1415045502959.JavaMail.zimbra@redhat.com> Message-ID: Thanks for the tips. My local flush was actually based on org.xnio.conduits.BufferedStreamSinkConduit including a terminated flag, except that i was also passing terminateWrites() on to the delegate. I'll try it with writeFinal() instead. Jeff On 03/11/2014 9:11 PM, "Stuart Douglas" wrote: > org.xnio.conduits.BufferedStreamSinkConduit is probably a good example, > although it does not use writeFinal(). > > Stuart > > ----- Original Message ----- > > From: "Stuart Douglas" > > To: "Jeff Williams" > > Cc: undertow-dev at lists.jboss.org > > Sent: Tuesday, 4 November, 2014 7:10:53 AM > > Subject: Re: [undertow-dev] AbstractFixedLengthStreamSinkConduit > > > > You need to not pass on the terminateWrites() call to the delegate until > your > > have written all your data. > > > > Once terminateWrites is called on your channel set some kind of boolean > flag > > to indicate that this is shutdown, and then when the user calls flush() > > write out the buffer (using writeFinal for best performance). If you are > not > > using writeFinal() then you need to call terminateWrites() once you > succeed > > in flushing, and then pass further flush calls to the delegate. > > > > Stuart > > > > ----- Original Message ----- > > > From: "Jeff Williams" > > > To: undertow-dev at lists.jboss.org > > > Sent: Monday, 3 November, 2014 11:48:10 PM > > > Subject: [undertow-dev] AbstractFixedLengthStreamSinkConduit > > > > > > Hi, > > > > > > I have written a StreamSinkConduit which buffers content in a pooled > > > buffer. > > > I am having an issue with AbstractFixedLengthStreamSinkConduit > throwing a > > > FixedLengthUnderflowException exception. > > > > > > If I have content left in my buffer which I have not yet been able to > write > > > to the next conduit when terminateWrites is called, the exception is > > > thrown. > > > Even though this content would have been written in the subsequent > call to > > > flush. Shouldn't the bytes remaining be checked after a successful > flush > > > rather than in terminateWrites? Or am I missing something? > > > > > > For the time being I am flushing my local buffer in terminateWrites, > but > > > this > > > seems wrong! > > > > > > Jeff > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141103/3ca36aaa/attachment-0001.html From ungarida at gmail.com Wed Nov 12 02:47:54 2014 From: ungarida at gmail.com (Davide Ungari) Date: Wed, 12 Nov 2014 08:47:54 +0100 Subject: [undertow-dev] ServletContext.getResource() and FileNotFound Message-ID: Hi everybody, I'm trying to migrate my webapp from Jetty to Undertow. The stack is composed by Undertow Guice and Struts2. I developed the following class to configure undertow: package com.billdrawer.website.server; > > import io.undertow.Undertow; > import io.undertow.predicate.Predicates; > import io.undertow.server.HandlerWrapper; > import io.undertow.server.HttpHandler; > import io.undertow.server.HttpServerExchange; > import io.undertow.server.handlers.PathHandler; > import io.undertow.server.handlers.PredicateHandler; > import io.undertow.server.handlers.resource.ResourceHandler; > import io.undertow.servlet.api.ConfidentialPortManager; > import io.undertow.servlet.api.Deployment; > import io.undertow.servlet.api.DeploymentInfo; > import io.undertow.servlet.api.DeploymentManager; > import io.undertow.servlet.api.FilterInfo; > import io.undertow.servlet.api.ListenerInfo; > import io.undertow.servlet.api.LoginConfig; > import io.undertow.servlet.api.SecurityConstraint; > import io.undertow.servlet.api.ServletContainer; > import io.undertow.servlet.api.WebResourceCollection; > > import java.net.URL; > import java.nio.file.Files; > import java.nio.file.Paths; > import java.util.EnumSet; > > import javax.inject.Inject; > import javax.inject.Named; > import javax.servlet.DispatcherType; > import javax.servlet.ServletContext; > import javax.servlet.ServletException; > > import org.apache.log4j.Logger; > import org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter; > import org.keycloak.adapters.AdapterConstants; > import org.keycloak.adapters.undertow.KeycloakServletExtension; > > import com.billdrawer.website.common.Config; > import com.billdrawer.website.listener.WebsiteServletContextListener; > import com.google.inject.servlet.GuiceFilter; > > public class UndertowServer implements Server { > private Logger _logger = Logger.getLogger(UndertowServer.class); > private Undertow _server; > private DeploymentManager _manager; > private int _port; > private String _host; > > @Inject > public UndertowServer(@Named(Config.STAGE) String stage, @Named(Config.SERVER_HOST) String host, @Named(Config.SERVER_PORT) int port, > @Named(Config.SERVER_TIMEOUT) int timeout) { > _port = port; > _host = host; > > DeploymentInfo deploymentInfo = getDeploymentInfo(stage); > > ServletContainer _container = ServletContainer.Factory.newInstance(); > _manager = _container.addDeployment(deploymentInfo); > _manager.deploy(); > > Deployment deployment = _manager.getDeployment(); > > KeycloakServletExtension keycloak = new KeycloakServletExtension(); > deploymentInfo.addServletExtension(keycloak); > deploymentInfo.addInitParameter(AdapterConstants.AUTH_DATA_PARAM_NAME, getKeyloakJson()); > keycloak.handleDeployment(deploymentInfo, _manager.getDeployment().getServletContext()); > > final ServletContext servletContext = deployment.getServletContext(); > _logger.debug("Context initialized:"+servletContext.getContextPath()); > } > > protected String getKeyloakJson() { > String keycloak = ""; > URL url = getClassLoader().getResource("keycloak.json"); > if (url != null) { > try { > byte[] encoded = Files.readAllBytes(Paths.get(url.toURI())); > keycloak = new String(encoded, "utf-8"); > } catch (Exception e) { > _logger.error("Can't read keycloak.json", e); > } > } > return keycloak; > } > > protected DeploymentInfo getDeploymentInfo(String stage) { > final DeploymentInfo deploymentInfo = new DeploymentInfo(); > deploymentInfo.setClassLoader(getClassLoader()); > deploymentInfo.setContextPath("/"); > deploymentInfo.setDefaultEncoding("UTF-8"); > deploymentInfo.setDeploymentName("website.war"); > deploymentInfo.setDisplayName("WebsiteServer"); > deploymentInfo.setUrlEncoding("UTF-8"); > > deploymentInfo.addListener(new ListenerInfo(WebsiteServletContextListener.class)); > > FilterInfo guiceFilter = new FilterInfo("GuiceFilter", GuiceFilter.class); > deploymentInfo.addFilter(guiceFilter); > for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { > deploymentInfo.addFilterUrlMapping(guiceFilter.getName(), "/*", dispatcher); > } > > FilterInfo strutsPrepareAndExecuteFilter = new FilterInfo("StrutsFilter", StrutsPrepareAndExecuteFilter.class); > deploymentInfo.addFilter(strutsPrepareAndExecuteFilter); > for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { > deploymentInfo.addFilterUrlMapping(strutsPrepareAndExecuteFilter.getName(), "/*", dispatcher); > } > > deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { > @Override > public HttpHandler wrap(final HttpHandler handler) { > final ResourceHandler resourceHandler = new ResourceHandler(deploymentInfo.getResourceManager()); > PredicateHandler predicateHandler = new PredicateHandler(Predicates.suffixes(".css",".html",".js"),resourceHandler, handler); > return predicateHandler; > } > }); > > configureSecurity(deploymentInfo); > > return deploymentInfo; > } > > protected void configureSecurity(DeploymentInfo deploymentInfo) { > deploymentInfo.setLoginConfig(new LoginConfig("KEYCLOAK", "billdrawer")); > deploymentInfo.setConfidentialPortManager(new ConfidentialPortManager() { > @Override > public int getConfidentialPort(HttpServerExchange exchange) { > return _port; > } > }); > SecurityConstraint securityConstraint = new SecurityConstraint(); > WebResourceCollection webResourceCollection = new WebResourceCollection(); > webResourceCollection.addUrlPattern("/dashboard/*"); > securityConstraint.addWebResourceCollection(webResourceCollection); > securityConstraint.addRoleAllowed("user"); > deploymentInfo.addSecurityConstraint(securityConstraint); > } > > protected ClassLoader getClassLoader() { > return getClass().getClassLoader(); > } > > public void start() { > _logger.debug("starting..."); > try { > Undertow.Builder builder = Undertow.builder(); > builder.addHttpListener(_port, _host); > > final PathHandler rootHandler = new PathHandler(); > rootHandler.addPrefixPath(_manager.getDeployment().getDeploymentInfo().getContextPath(), _manager.start()); > > builder.setHandler(rootHandler); > _server = builder.build(); > _server.start(); > } catch (ServletException e) { > _logger.error("Unexpected exception", e); > } > _logger.info("###START###"); > } > > public void stop() { > _logger.debug("stopping..."); > try { > _manager.stop(); > _server.stop(); > } catch (ServletException e) { > _logger.error("Unexpected exception", e); > } > _logger.info("###STOP###"); > } > } > > Everything is working until I do not try to load resources from context. I need some help before rollback to Jetty :( -- Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141112/2574e3cd/attachment.html From ungarida at gmail.com Wed Nov 12 04:56:28 2014 From: ungarida at gmail.com (Davide Ungari) Date: Wed, 12 Nov 2014 10:56:28 +0100 Subject: [undertow-dev] ServletContext.getResource() and FileNotFound In-Reply-To: References: Message-ID: Hi, I'm using version 1.1.0.CR8. -- Davide On Wed, Nov 12, 2014 at 8:47 AM, Davide Ungari wrote: > Hi everybody, > I'm trying to migrate my webapp from Jetty to Undertow. > > The stack is composed by Undertow Guice and Struts2. > > I developed the following class to configure undertow: > > package com.billdrawer.website.server; >> >> import io.undertow.Undertow; >> import io.undertow.predicate.Predicates; >> import io.undertow.server.HandlerWrapper; >> import io.undertow.server.HttpHandler; >> import io.undertow.server.HttpServerExchange; >> import io.undertow.server.handlers.PathHandler; >> import io.undertow.server.handlers.PredicateHandler; >> import io.undertow.server.handlers.resource.ResourceHandler; >> import io.undertow.servlet.api.ConfidentialPortManager; >> import io.undertow.servlet.api.Deployment; >> import io.undertow.servlet.api.DeploymentInfo; >> import io.undertow.servlet.api.DeploymentManager; >> import io.undertow.servlet.api.FilterInfo; >> import io.undertow.servlet.api.ListenerInfo; >> import io.undertow.servlet.api.LoginConfig; >> import io.undertow.servlet.api.SecurityConstraint; >> import io.undertow.servlet.api.ServletContainer; >> import io.undertow.servlet.api.WebResourceCollection; >> >> import java.net.URL; >> import java.nio.file.Files; >> import java.nio.file.Paths; >> import java.util.EnumSet; >> >> import javax.inject.Inject; >> import javax.inject.Named; >> import javax.servlet.DispatcherType; >> import javax.servlet.ServletContext; >> import javax.servlet.ServletException; >> >> import org.apache.log4j.Logger; >> import org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter; >> import org.keycloak.adapters.AdapterConstants; >> import org.keycloak.adapters.undertow.KeycloakServletExtension; >> >> import com.billdrawer.website.common.Config; >> import com.billdrawer.website.listener.WebsiteServletContextListener; >> import com.google.inject.servlet.GuiceFilter; >> >> public class UndertowServer implements Server { >> private Logger _logger = Logger.getLogger(UndertowServer.class); >> private Undertow _server; >> private DeploymentManager _manager; >> private int _port; >> private String _host; >> >> @Inject >> public UndertowServer(@Named(Config.STAGE) String stage, @Named(Config.SERVER_HOST) String host, @Named(Config.SERVER_PORT) int port, >> @Named(Config.SERVER_TIMEOUT) int timeout) { >> _port = port; >> _host = host; >> >> DeploymentInfo deploymentInfo = getDeploymentInfo(stage); >> >> ServletContainer _container = ServletContainer.Factory.newInstance(); >> _manager = _container.addDeployment(deploymentInfo); >> _manager.deploy(); >> >> Deployment deployment = _manager.getDeployment(); >> >> KeycloakServletExtension keycloak = new KeycloakServletExtension(); >> deploymentInfo.addServletExtension(keycloak); >> deploymentInfo.addInitParameter(AdapterConstants.AUTH_DATA_PARAM_NAME, getKeyloakJson()); >> keycloak.handleDeployment(deploymentInfo, _manager.getDeployment().getServletContext()); >> >> final ServletContext servletContext = deployment.getServletContext(); >> _logger.debug("Context initialized:"+servletContext.getContextPath()); >> } >> >> protected String getKeyloakJson() { >> String keycloak = ""; >> URL url = getClassLoader().getResource("keycloak.json"); >> if (url != null) { >> try { >> byte[] encoded = Files.readAllBytes(Paths.get(url.toURI())); >> keycloak = new String(encoded, "utf-8"); >> } catch (Exception e) { >> _logger.error("Can't read keycloak.json", e); >> } >> } >> return keycloak; >> } >> >> protected DeploymentInfo getDeploymentInfo(String stage) { >> final DeploymentInfo deploymentInfo = new DeploymentInfo(); >> deploymentInfo.setClassLoader(getClassLoader()); >> deploymentInfo.setContextPath("/"); >> deploymentInfo.setDefaultEncoding("UTF-8"); >> deploymentInfo.setDeploymentName("website.war"); >> deploymentInfo.setDisplayName("WebsiteServer"); >> deploymentInfo.setUrlEncoding("UTF-8"); >> >> deploymentInfo.addListener(new ListenerInfo(WebsiteServletContextListener.class)); >> >> FilterInfo guiceFilter = new FilterInfo("GuiceFilter", GuiceFilter.class); >> deploymentInfo.addFilter(guiceFilter); >> for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { >> deploymentInfo.addFilterUrlMapping(guiceFilter.getName(), "/*", dispatcher); >> } >> >> FilterInfo strutsPrepareAndExecuteFilter = new FilterInfo("StrutsFilter", StrutsPrepareAndExecuteFilter.class); >> deploymentInfo.addFilter(strutsPrepareAndExecuteFilter); >> for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { >> deploymentInfo.addFilterUrlMapping(strutsPrepareAndExecuteFilter.getName(), "/*", dispatcher); >> } >> >> deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { >> @Override >> public HttpHandler wrap(final HttpHandler handler) { >> final ResourceHandler resourceHandler = new ResourceHandler(deploymentInfo.getResourceManager()); >> PredicateHandler predicateHandler = new PredicateHandler(Predicates.suffixes(".css",".html",".js"),resourceHandler, handler); >> return predicateHandler; >> } >> }); >> >> configureSecurity(deploymentInfo); >> >> return deploymentInfo; >> } >> >> protected void configureSecurity(DeploymentInfo deploymentInfo) { >> deploymentInfo.setLoginConfig(new LoginConfig("KEYCLOAK", "billdrawer")); >> deploymentInfo.setConfidentialPortManager(new ConfidentialPortManager() { >> @Override >> public int getConfidentialPort(HttpServerExchange exchange) { >> return _port; >> } >> }); >> SecurityConstraint securityConstraint = new SecurityConstraint(); >> WebResourceCollection webResourceCollection = new WebResourceCollection(); >> webResourceCollection.addUrlPattern("/dashboard/*"); >> securityConstraint.addWebResourceCollection(webResourceCollection); >> securityConstraint.addRoleAllowed("user"); >> deploymentInfo.addSecurityConstraint(securityConstraint); >> } >> >> protected ClassLoader getClassLoader() { >> return getClass().getClassLoader(); >> } >> >> public void start() { >> _logger.debug("starting..."); >> try { >> Undertow.Builder builder = Undertow.builder(); >> builder.addHttpListener(_port, _host); >> >> final PathHandler rootHandler = new PathHandler(); >> rootHandler.addPrefixPath(_manager.getDeployment().getDeploymentInfo().getContextPath(), _manager.start()); >> >> builder.setHandler(rootHandler); >> _server = builder.build(); >> _server.start(); >> } catch (ServletException e) { >> _logger.error("Unexpected exception", e); >> } >> _logger.info("###START###"); >> } >> >> public void stop() { >> _logger.debug("stopping..."); >> try { >> _manager.stop(); >> _server.stop(); >> } catch (ServletException e) { >> _logger.error("Unexpected exception", e); >> } >> _logger.info("###STOP###"); >> } >> } >> >> Everything is working until I do not try to load resources from context. > I need some help before rollback to Jetty :( > > -- > Davide > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141112/31fc0320/attachment-0001.html From tomaz.cerar at gmail.com Wed Nov 12 07:47:01 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 12 Nov 2014 13:47:01 +0100 Subject: [undertow-dev] ServletContext.getResource() and FileNotFound In-Reply-To: References: Message-ID: I think you are missing configuration for resourceManager, as if not set it defaults to empty resource manager. add something like this to getDeploymentInfo ResourceManager resourceManager = new ServletResourceManager(deploymentRoot, overlays, explodedDeployment); //this is not needed, but it good for performance resourceManager = new CachingResourceManager(100, 10 * 1024 * 1024, servletContainer.getBufferCache(), resourceManager, explodedDeployment ? 2000 : -1); deploymentInfo.setResourceManager(resourceManager); -- tomaz On Wed, Nov 12, 2014 at 10:56 AM, Davide Ungari wrote: > Hi, > I'm using version 1.1.0.CR8. > > -- > Davide > > On Wed, Nov 12, 2014 at 8:47 AM, Davide Ungari wrote: > >> Hi everybody, >> I'm trying to migrate my webapp from Jetty to Undertow. >> >> The stack is composed by Undertow Guice and Struts2. >> >> I developed the following class to configure undertow: >> >> package com.billdrawer.website.server; >>> >>> import io.undertow.Undertow; >>> import io.undertow.predicate.Predicates; >>> import io.undertow.server.HandlerWrapper; >>> import io.undertow.server.HttpHandler; >>> import io.undertow.server.HttpServerExchange; >>> import io.undertow.server.handlers.PathHandler; >>> import io.undertow.server.handlers.PredicateHandler; >>> import io.undertow.server.handlers.resource.ResourceHandler; >>> import io.undertow.servlet.api.ConfidentialPortManager; >>> import io.undertow.servlet.api.Deployment; >>> import io.undertow.servlet.api.DeploymentInfo; >>> import io.undertow.servlet.api.DeploymentManager; >>> import io.undertow.servlet.api.FilterInfo; >>> import io.undertow.servlet.api.ListenerInfo; >>> import io.undertow.servlet.api.LoginConfig; >>> import io.undertow.servlet.api.SecurityConstraint; >>> import io.undertow.servlet.api.ServletContainer; >>> import io.undertow.servlet.api.WebResourceCollection; >>> >>> import java.net.URL; >>> import java.nio.file.Files; >>> import java.nio.file.Paths; >>> import java.util.EnumSet; >>> >>> import javax.inject.Inject; >>> import javax.inject.Named; >>> import javax.servlet.DispatcherType; >>> import javax.servlet.ServletContext; >>> import javax.servlet.ServletException; >>> >>> import org.apache.log4j.Logger; >>> import org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter; >>> import org.keycloak.adapters.AdapterConstants; >>> import org.keycloak.adapters.undertow.KeycloakServletExtension; >>> >>> import com.billdrawer.website.common.Config; >>> import com.billdrawer.website.listener.WebsiteServletContextListener; >>> import com.google.inject.servlet.GuiceFilter; >>> >>> public class UndertowServer implements Server { >>> private Logger _logger = Logger.getLogger(UndertowServer.class); >>> private Undertow _server; >>> private DeploymentManager _manager; >>> private int _port; >>> private String _host; >>> >>> @Inject >>> public UndertowServer(@Named(Config.STAGE) String stage, @Named(Config.SERVER_HOST) String host, @Named(Config.SERVER_PORT) int port, >>> @Named(Config.SERVER_TIMEOUT) int timeout) { >>> _port = port; >>> _host = host; >>> >>> DeploymentInfo deploymentInfo = getDeploymentInfo(stage); >>> >>> ServletContainer _container = ServletContainer.Factory.newInstance(); >>> _manager = _container.addDeployment(deploymentInfo); >>> _manager.deploy(); >>> >>> Deployment deployment = _manager.getDeployment(); >>> >>> KeycloakServletExtension keycloak = new KeycloakServletExtension(); >>> deploymentInfo.addServletExtension(keycloak); >>> deploymentInfo.addInitParameter(AdapterConstants.AUTH_DATA_PARAM_NAME, getKeyloakJson()); >>> keycloak.handleDeployment(deploymentInfo, _manager.getDeployment().getServletContext()); >>> >>> final ServletContext servletContext = deployment.getServletContext(); >>> _logger.debug("Context initialized:"+servletContext.getContextPath()); >>> } >>> >>> protected String getKeyloakJson() { >>> String keycloak = ""; >>> URL url = getClassLoader().getResource("keycloak.json"); >>> if (url != null) { >>> try { >>> byte[] encoded = Files.readAllBytes(Paths.get(url.toURI())); >>> keycloak = new String(encoded, "utf-8"); >>> } catch (Exception e) { >>> _logger.error("Can't read keycloak.json", e); >>> } >>> } >>> return keycloak; >>> } >>> >>> protected DeploymentInfo getDeploymentInfo(String stage) { >>> final DeploymentInfo deploymentInfo = new DeploymentInfo(); >>> deploymentInfo.setClassLoader(getClassLoader()); >>> deploymentInfo.setContextPath("/"); >>> deploymentInfo.setDefaultEncoding("UTF-8"); >>> deploymentInfo.setDeploymentName("website.war"); >>> deploymentInfo.setDisplayName("WebsiteServer"); >>> deploymentInfo.setUrlEncoding("UTF-8"); >>> >>> deploymentInfo.addListener(new ListenerInfo(WebsiteServletContextListener.class)); >>> >>> FilterInfo guiceFilter = new FilterInfo("GuiceFilter", GuiceFilter.class); >>> deploymentInfo.addFilter(guiceFilter); >>> for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { >>> deploymentInfo.addFilterUrlMapping(guiceFilter.getName(), "/*", dispatcher); >>> } >>> >>> FilterInfo strutsPrepareAndExecuteFilter = new FilterInfo("StrutsFilter", StrutsPrepareAndExecuteFilter.class); >>> deploymentInfo.addFilter(strutsPrepareAndExecuteFilter); >>> for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) { >>> deploymentInfo.addFilterUrlMapping(strutsPrepareAndExecuteFilter.getName(), "/*", dispatcher); >>> } >>> >>> deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { >>> @Override >>> public HttpHandler wrap(final HttpHandler handler) { >>> final ResourceHandler resourceHandler = new ResourceHandler(deploymentInfo.getResourceManager()); >>> PredicateHandler predicateHandler = new PredicateHandler(Predicates.suffixes(".css",".html",".js"),resourceHandler, handler); >>> return predicateHandler; >>> } >>> }); >>> >>> configureSecurity(deploymentInfo); >>> >>> return deploymentInfo; >>> } >>> >>> protected void configureSecurity(DeploymentInfo deploymentInfo) { >>> deploymentInfo.setLoginConfig(new LoginConfig("KEYCLOAK", "billdrawer")); >>> deploymentInfo.setConfidentialPortManager(new ConfidentialPortManager() { >>> @Override >>> public int getConfidentialPort(HttpServerExchange exchange) { >>> return _port; >>> } >>> }); >>> SecurityConstraint securityConstraint = new SecurityConstraint(); >>> WebResourceCollection webResourceCollection = new WebResourceCollection(); >>> webResourceCollection.addUrlPattern("/dashboard/*"); >>> securityConstraint.addWebResourceCollection(webResourceCollection); >>> securityConstraint.addRoleAllowed("user"); >>> deploymentInfo.addSecurityConstraint(securityConstraint); >>> } >>> >>> protected ClassLoader getClassLoader() { >>> return getClass().getClassLoader(); >>> } >>> >>> public void start() { >>> _logger.debug("starting..."); >>> try { >>> Undertow.Builder builder = Undertow.builder(); >>> builder.addHttpListener(_port, _host); >>> >>> final PathHandler rootHandler = new PathHandler(); >>> rootHandler.addPrefixPath(_manager.getDeployment().getDeploymentInfo().getContextPath(), _manager.start()); >>> >>> builder.setHandler(rootHandler); >>> _server = builder.build(); >>> _server.start(); >>> } catch (ServletException e) { >>> _logger.error("Unexpected exception", e); >>> } >>> _logger.info("###START###"); >>> } >>> >>> public void stop() { >>> _logger.debug("stopping..."); >>> try { >>> _manager.stop(); >>> _server.stop(); >>> } catch (ServletException e) { >>> _logger.error("Unexpected exception", e); >>> } >>> _logger.info("###STOP###"); >>> } >>> } >>> >>> Everything is working until I do not try to load resources from context. >> I need some help before rollback to Jetty :( >> >> -- >> Davide >> > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141112/50d9e28d/attachment.html From sdouglas at redhat.com Wed Nov 12 15:12:16 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 12 Nov 2014 15:12:16 -0500 (EST) Subject: [undertow-dev] ServletContext.getResource() and FileNotFound In-Reply-To: References: Message-ID: <242624529.9277525.1415823136132.JavaMail.zimbra@redhat.com> ServletResourceManager is only really relevant to Wildfly. You will want to use either FileResourceManager or ClassPathResourceManager. Stuart ----- Original Message ----- > From: "Toma? Cerar" > To: "Davide Ungari" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 12 November, 2014 11:47:01 PM > Subject: Re: [undertow-dev] ServletContext.getResource() and FileNotFound > > I think you are missing configuration for resourceManager, as if not set it > defaults to empty resource manager. > > > add something like this to getDeploymentInfo > ResourceManager resourceManager = new ServletResourceManager( deploymentRoot > , overlays , explodedDeployment ); > //this is not needed, but it good for performance > resourceManager = new CachingResourceManager( 100 , 10 * 1024 * 1024 , > servletContainer.getBufferCache(), resourceManager, explodedDeployment ? > 2000 : - 1 ); > deploymentInfo.setResourceManager(resourceManager); > -- > tomaz > > On Wed, Nov 12, 2014 at 10:56 AM, Davide Ungari < ungarida at gmail.com > wrote: > > > > Hi, > I'm using version 1.1.0.CR8. > > -- > Davide > > On Wed, Nov 12, 2014 at 8:47 AM, Davide Ungari < ungarida at gmail.com > wrote: > > > > Hi everybody, > I'm trying to migrate my webapp from Jetty to Undertow. > > The stack is composed by Undertow Guice and Struts2. > > I developed the following class to configure undertow: > > > > > package com.billdrawer.website.server; > > import io.undertow.Undertow; > import io.undertow.predicate.Predicates; > import io.undertow.server.HandlerWrapper; > import io.undertow.server.HttpHandler; > import io.undertow.server.HttpServerExchange; > import io.undertow.server.handlers.PathHandler; > import io.undertow.server.handlers.PredicateHandler; > import io.undertow.server.handlers.resource.ResourceHandler; > import io.undertow.servlet.api.ConfidentialPortManager; > import io.undertow.servlet.api.Deployment; > import io.undertow.servlet.api.DeploymentInfo; > import io.undertow.servlet.api.DeploymentManager; > import io.undertow.servlet.api.FilterInfo; > import io.undertow.servlet.api.ListenerInfo; > import io.undertow.servlet.api.LoginConfig; > import io.undertow.servlet.api.SecurityConstraint; > import io.undertow.servlet.api.ServletContainer; > import io.undertow.servlet.api.WebResourceCollection; > > import java.net.URL; > import java.nio.file.Files; > import java.nio.file.Paths; > import java.util.EnumSet; > > import javax.inject.Inject; > import javax.inject.Named; > import javax.servlet.DispatcherType; > import javax.servlet.ServletContext; > import javax.servlet.ServletException; > > import org.apache.log4j.Logger; > import org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter; > import org.keycloak.adapters.AdapterConstants; > import org.keycloak.adapters.undertow.KeycloakServletExtension; > > import com.billdrawer.website.common.Config; > import com.billdrawer.website.listener.WebsiteServletContextListener; > import com.google.inject.servlet.GuiceFilter; > > public class UndertowServer implements Server { > private Logger _logger = Logger.getLogger(UndertowServer.class); > private Undertow _server; > private DeploymentManager _manager; > private int _port; > private String _host; > > @Inject > public UndertowServer(@Named(Config.STAGE) String stage, > @Named(Config.SERVER_HOST) String host, @Named(Config.SERVER_PORT) int > port, > @Named(Config.SERVER_TIMEOUT) int timeout) { > _port = port; > _host = host; > > DeploymentInfo deploymentInfo = getDeploymentInfo(stage); > > ServletContainer _container = ServletContainer.Factory.newInstance(); > _manager = _container.addDeployment(deploymentInfo); > _manager.deploy(); > > Deployment deployment = _manager.getDeployment(); > > KeycloakServletExtension keycloak = new KeycloakServletExtension(); > deploymentInfo.addServletExtension(keycloak); > deploymentInfo.addInitParameter(AdapterConstants.AUTH_DATA_PARAM_NAME, > getKeyloakJson()); > keycloak.handleDeployment(deploymentInfo, > _manager.getDeployment().getServletContext()); > > final ServletContext servletContext = deployment.getServletContext(); > _logger.debug("Context > initialized:"+servletContext.getContextPath()); > } > > protected String getKeyloakJson() { > String keycloak = ""; > URL url = getClassLoader().getResource("keycloak.json"); > if (url != null) { > try { > byte[] encoded = Files.readAllBytes(Paths.get(url.toURI())); > keycloak = new String(encoded, "utf-8"); > } catch (Exception e) { > _logger.error("Can't read keycloak.json", e); > } > } > return keycloak; > } > > protected DeploymentInfo getDeploymentInfo(String stage) { > final DeploymentInfo deploymentInfo = new DeploymentInfo(); > deploymentInfo.setClassLoader(getClassLoader()); > deploymentInfo.setContextPath("/"); > deploymentInfo.setDefaultEncoding("UTF-8"); > deploymentInfo.setDeploymentName("website.war"); > deploymentInfo.setDisplayName("WebsiteServer"); > deploymentInfo.setUrlEncoding("UTF-8"); > > deploymentInfo.addListener(new > ListenerInfo(WebsiteServletContextListener.class)); > > FilterInfo guiceFilter = new FilterInfo("GuiceFilter", > GuiceFilter.class); > deploymentInfo.addFilter(guiceFilter); > for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) > { > deploymentInfo.addFilterUrlMapping(guiceFilter.getName(), "/*", > dispatcher); > } > > FilterInfo strutsPrepareAndExecuteFilter = new > FilterInfo("StrutsFilter", StrutsPrepareAndExecuteFilter.class); > deploymentInfo.addFilter(strutsPrepareAndExecuteFilter); > for (DispatcherType dispatcher : EnumSet.allOf(DispatcherType.class)) > { > deploymentInfo.addFilterUrlMapping(strutsPrepareAndExecuteFilter.getName(), > "/*", dispatcher); > } > > deploymentInfo.addInitialHandlerChainWrapper(new HandlerWrapper() { > @Override > public HttpHandler wrap(final HttpHandler handler) { > final ResourceHandler resourceHandler = new > ResourceHandler(deploymentInfo.getResourceManager()); > PredicateHandler predicateHandler = new > PredicateHandler(Predicates.suffixes(".css",".html",".js"),resourceHandler, > handler); > return predicateHandler; > } > }); > > configureSecurity(deploymentInfo); > > return deploymentInfo; > } > > protected void configureSecurity(DeploymentInfo deploymentInfo) { > deploymentInfo.setLoginConfig(new LoginConfig("KEYCLOAK", > "billdrawer")); > deploymentInfo.setConfidentialPortManager(new > ConfidentialPortManager() { > @Override > public int getConfidentialPort(HttpServerExchange exchange) { > return _port; > } > }); > SecurityConstraint securityConstraint = new SecurityConstraint(); > WebResourceCollection webResourceCollection = new > WebResourceCollection(); > webResourceCollection.addUrlPattern("/dashboard/*"); > securityConstraint.addWebResourceCollection(webResourceCollection); > securityConstraint.addRoleAllowed("user"); > deploymentInfo.addSecurityConstraint(securityConstraint); > } > > protected ClassLoader getClassLoader() { > return getClass().getClassLoader(); > } > > public void start() { > _logger.debug("starting..."); > try { > Undertow.Builder builder = Undertow.builder(); > builder.addHttpListener(_port, _host); > > final PathHandler rootHandler = new PathHandler(); > rootHandler.addPrefixPath(_manager.getDeployment().getDeploymentInfo().getContextPath(), > _manager.start()); > > builder.setHandler(rootHandler); > _server = builder.build(); > _server.start(); > } catch (ServletException e) { > _logger.error("Unexpected exception", e); > } > _ logger.info ("###START###"); > } > > public void stop() { > _logger.debug("stopping..."); > try { > _manager.stop(); > _server.stop(); > } catch (ServletException e) { > _logger.error("Unexpected exception", e); > } > _ logger.info ("###STOP###"); > } > } > Everything is working until I do not try to load resources from context. > I need some help before rollback to Jetty :( > > -- > Davide > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ungarida at gmail.com Wed Nov 12 16:47:34 2014 From: ungarida at gmail.com (Davide Ungari) Date: Wed, 12 Nov 2014 22:47:34 +0100 Subject: [undertow-dev] ServletContext.getResource() and FileNotFound In-Reply-To: <242624529.9277525.1415823136132.JavaMail.zimbra@redhat.com> References: <242624529.9277525.1415823136132.JavaMail.zimbra@redhat.com> Message-ID: Hi Stuart, Toma? warned me by IRC chat about that. At the end I developed like this: URL rootUrl = getClassLoader().getResource("."); File root = new File(rootUrl.getFile()); ResourceManager resourceManager = new FileResourceManager(root, 1024 * 1024); deploymentInfo.setResourceManager(resourceManager); It works, and now I will try to experiment better perfomance using CachingResourceManager as suggested by Toma?. Thanks everybody! -- Davide On Wed, Nov 12, 2014 at 9:12 PM, Stuart Douglas wrote: > ServletResourceManager is only really relevant to Wildfly. You will want > to use either FileResourceManager or ClassPathResourceManager. > > Stuart > > ----- Original Message ----- > > From: "Toma? Cerar" > > To: "Davide Ungari" > > Cc: undertow-dev at lists.jboss.org > > Sent: Wednesday, 12 November, 2014 11:47:01 PM > > Subject: Re: [undertow-dev] ServletContext.getResource() and FileNotFound > > > > I think you are missing configuration for resourceManager, as if not set > it > > defaults to empty resource manager. > > > > > > add something like this to getDeploymentInfo > > ResourceManager resourceManager = new ServletResourceManager( > deploymentRoot > > , overlays , explodedDeployment ); > > //this is not needed, but it good for performance > > resourceManager = new CachingResourceManager( 100 , 10 * 1024 * 1024 , > > servletContainer.getBufferCache(), resourceManager, explodedDeployment ? > > 2000 : - 1 ); > > deploymentInfo.setResourceManager(resourceManager); > > -- > > tomaz > > > > On Wed, Nov 12, 2014 at 10:56 AM, Davide Ungari < ungarida at gmail.com > > wrote: > > > > > > > > Hi, > > I'm using version 1.1.0.CR8. > > > > -- > > Davide > > > > On Wed, Nov 12, 2014 at 8:47 AM, Davide Ungari < ungarida at gmail.com > > wrote: > > > > > > > > Hi everybody, > > I'm trying to migrate my webapp from Jetty to Undertow. > > > > The stack is composed by Undertow Guice and Struts2. > > > > I developed the following class to configure undertow: > > > > > > > > > > package com.billdrawer.website.server; > > > > import io.undertow.Undertow; > > import io.undertow.predicate.Predicates; > > import io.undertow.server.HandlerWrapper; > > import io.undertow.server.HttpHandler; > > import io.undertow.server.HttpServerExchange; > > import io.undertow.server.handlers.PathHandler; > > import io.undertow.server.handlers.PredicateHandler; > > import io.undertow.server.handlers.resource.ResourceHandler; > > import io.undertow.servlet.api.ConfidentialPortManager; > > import io.undertow.servlet.api.Deployment; > > import io.undertow.servlet.api.DeploymentInfo; > > import io.undertow.servlet.api.DeploymentManager; > > import io.undertow.servlet.api.FilterInfo; > > import io.undertow.servlet.api.ListenerInfo; > > import io.undertow.servlet.api.LoginConfig; > > import io.undertow.servlet.api.SecurityConstraint; > > import io.undertow.servlet.api.ServletContainer; > > import io.undertow.servlet.api.WebResourceCollection; > > > > import java.net.URL; > > import java.nio.file.Files; > > import java.nio.file.Paths; > > import java.util.EnumSet; > > > > import javax.inject.Inject; > > import javax.inject.Named; > > import javax.servlet.DispatcherType; > > import javax.servlet.ServletContext; > > import javax.servlet.ServletException; > > > > import org.apache.log4j.Logger; > > import > org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter; > > import org.keycloak.adapters.AdapterConstants; > > import org.keycloak.adapters.undertow.KeycloakServletExtension; > > > > import com.billdrawer.website.common.Config; > > import com.billdrawer.website.listener.WebsiteServletContextListener; > > import com.google.inject.servlet.GuiceFilter; > > > > public class UndertowServer implements Server { > > private Logger _logger = Logger.getLogger(UndertowServer.class); > > private Undertow _server; > > private DeploymentManager _manager; > > private int _port; > > private String _host; > > > > @Inject > > public UndertowServer(@Named(Config.STAGE) String stage, > > @Named(Config.SERVER_HOST) String host, @Named(Config.SERVER_PORT) > int > > port, > > @Named(Config.SERVER_TIMEOUT) int timeout) { > > _port = port; > > _host = host; > > > > DeploymentInfo deploymentInfo = getDeploymentInfo(stage); > > > > ServletContainer _container = > ServletContainer.Factory.newInstance(); > > _manager = _container.addDeployment(deploymentInfo); > > _manager.deploy(); > > > > Deployment deployment = _manager.getDeployment(); > > > > KeycloakServletExtension keycloak = new > KeycloakServletExtension(); > > deploymentInfo.addServletExtension(keycloak); > > > deploymentInfo.addInitParameter(AdapterConstants.AUTH_DATA_PARAM_NAME, > > getKeyloakJson()); > > keycloak.handleDeployment(deploymentInfo, > > _manager.getDeployment().getServletContext()); > > > > final ServletContext servletContext = > deployment.getServletContext(); > > _logger.debug("Context > > initialized:"+servletContext.getContextPath()); > > } > > > > protected String getKeyloakJson() { > > String keycloak = ""; > > URL url = getClassLoader().getResource("keycloak.json"); > > if (url != null) { > > try { > > byte[] encoded = > Files.readAllBytes(Paths.get(url.toURI())); > > keycloak = new String(encoded, "utf-8"); > > } catch (Exception e) { > > _logger.error("Can't read keycloak.json", e); > > } > > } > > return keycloak; > > } > > > > protected DeploymentInfo getDeploymentInfo(String stage) { > > final DeploymentInfo deploymentInfo = new DeploymentInfo(); > > deploymentInfo.setClassLoader(getClassLoader()); > > deploymentInfo.setContextPath("/"); > > deploymentInfo.setDefaultEncoding("UTF-8"); > > deploymentInfo.setDeploymentName("website.war"); > > deploymentInfo.setDisplayName("WebsiteServer"); > > deploymentInfo.setUrlEncoding("UTF-8"); > > > > deploymentInfo.addListener(new > > ListenerInfo(WebsiteServletContextListener.class)); > > > > FilterInfo guiceFilter = new FilterInfo("GuiceFilter", > > GuiceFilter.class); > > deploymentInfo.addFilter(guiceFilter); > > for (DispatcherType dispatcher : > EnumSet.allOf(DispatcherType.class)) > > { > > deploymentInfo.addFilterUrlMapping(guiceFilter.getName(), > "/*", > > dispatcher); > > } > > > > FilterInfo strutsPrepareAndExecuteFilter = new > > FilterInfo("StrutsFilter", StrutsPrepareAndExecuteFilter.class); > > deploymentInfo.addFilter(strutsPrepareAndExecuteFilter); > > for (DispatcherType dispatcher : > EnumSet.allOf(DispatcherType.class)) > > { > > > deploymentInfo.addFilterUrlMapping(strutsPrepareAndExecuteFilter.getName(), > > "/*", dispatcher); > > } > > > > deploymentInfo.addInitialHandlerChainWrapper(new > HandlerWrapper() { > > @Override > > public HttpHandler wrap(final HttpHandler handler) { > > final ResourceHandler resourceHandler = new > > ResourceHandler(deploymentInfo.getResourceManager()); > > PredicateHandler predicateHandler = new > > > PredicateHandler(Predicates.suffixes(".css",".html",".js"),resourceHandler, > > handler); > > return predicateHandler; > > } > > }); > > > > configureSecurity(deploymentInfo); > > > > return deploymentInfo; > > } > > > > protected void configureSecurity(DeploymentInfo deploymentInfo) { > > deploymentInfo.setLoginConfig(new LoginConfig("KEYCLOAK", > > "billdrawer")); > > deploymentInfo.setConfidentialPortManager(new > > ConfidentialPortManager() { > > @Override > > public int getConfidentialPort(HttpServerExchange exchange) { > > return _port; > > } > > }); > > SecurityConstraint securityConstraint = new SecurityConstraint(); > > WebResourceCollection webResourceCollection = new > > WebResourceCollection(); > > webResourceCollection.addUrlPattern("/dashboard/*"); > > > securityConstraint.addWebResourceCollection(webResourceCollection); > > securityConstraint.addRoleAllowed("user"); > > deploymentInfo.addSecurityConstraint(securityConstraint); > > } > > > > protected ClassLoader getClassLoader() { > > return getClass().getClassLoader(); > > } > > > > public void start() { > > _logger.debug("starting..."); > > try { > > Undertow.Builder builder = Undertow.builder(); > > builder.addHttpListener(_port, _host); > > > > final PathHandler rootHandler = new PathHandler(); > > > rootHandler.addPrefixPath(_manager.getDeployment().getDeploymentInfo().getContextPath(), > > _manager.start()); > > > > builder.setHandler(rootHandler); > > _server = builder.build(); > > _server.start(); > > } catch (ServletException e) { > > _logger.error("Unexpected exception", e); > > } > > _ logger.info ("###START###"); > > } > > > > public void stop() { > > _logger.debug("stopping..."); > > try { > > _manager.stop(); > > _server.stop(); > > } catch (ServletException e) { > > _logger.error("Unexpected exception", e); > > } > > _ logger.info ("###STOP###"); > > } > > } > > Everything is working until I do not try to load resources from context. > > I need some help before rollback to Jetty :( > > > > -- > > Davide > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141112/5f9d0e32/attachment.html From efraim.gentil at gmail.com Mon Nov 17 21:59:05 2014 From: efraim.gentil at gmail.com (Efraim Gentil) Date: Mon, 17 Nov 2014 23:59:05 -0300 Subject: [undertow-dev] PathHandler and HANDLE_404,HANDLE_500 Message-ID: Hi guys, i?m working on some specs in my app and i?m trying to specify a 404 error handler and 500 error handler in my PathHandler, apparently that?s not possible, i tried to use default handler as Handles.path(//MyDefaultHandlerHere), for 404 handler works fine, but what about 500 error handler ? there is any way to specify this ? Simple test: Undertow.builder().addHttpListener( 8080 , "localhost" ) .setHandler(path(new HttpHandler() { public void handleRequest(HttpServerExchange exchange) throws Exception { System.out.println( "DEFAULT"); } }) .addExactPath("/hi", new HttpHandler() { public void handleRequest(HttpServerExchange exchange) throws Exception { System.out.println( "HI"); }}) .addExactPath("/hi2", new HttpHandler() { public void handleRequest(HttpServerExchange exchange) throws Exception { System.out.println( "HI2"); throw new RuntimeException(); }}) ).build(); Maybe in the builder we can have something like Undertow.builder() .setNotFoundHandler( notFoundHandlerImpl ) .setServerErrorHandler( serverErrorHandlerImpl ) ... ? Thanks -- Atenciosamente, Efraim Gentil - @efraimgentil Github LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141117/9fcd8f07/attachment-0001.html From sdouglas at redhat.com Mon Nov 17 22:47:45 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 17 Nov 2014 22:47:45 -0500 (EST) Subject: [undertow-dev] PathHandler and HANDLE_404,HANDLE_500 In-Reply-To: References: Message-ID: <1143669895.350969.1416282465422.JavaMail.zimbra@redhat.com> Have a look at io.undertow.server.handlers.error.FileErrorPageHandler. Basically you can use io.undertow.server.HttpServerExchange#addDefaultResponseListener to generate default responses. Stuart ----- Original Message ----- > From: "Efraim Gentil" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 18 November, 2014 1:59:05 PM > Subject: [undertow-dev] PathHandler and HANDLE_404,HANDLE_500 > > > > Hi guys, i?m working on some specs in my app and i?m trying to specify a 404 > error handler and 500 error handler in my PathHandler, apparently that?s not > possible, i tried to use default handler as > Handles.path(//MyDefaultHandlerHere), for 404 handler works fine, but what > about 500 error handler ? there is any way to specify this ? > > Simple test: > Undertow.builder().addHttpListener( 8080 , "localhost" ) > .setHandler(path( new HttpHandler() { public void handleRequest > (HttpServerExchange exchange) throws Exception { > System.out.println( "DEFAULT" ); > } > }) > .addExactPath( "/hi" , new HttpHandler() { public void handleRequest > (HttpServerExchange exchange) throws Exception { > System.out.println( "HI" ); > }}) > .addExactPath( "/hi2" , new HttpHandler() { public void handleRequest > (HttpServerExchange exchange) throws Exception { > System.out.println( "HI2" ); throw new RuntimeException () ; > }}) > ).build(); > > > Maybe in the builder we can have something like > Undertow.builder() > .setNotFoundHandler( notFoundHandlerImpl ) > .setServerErrorHandler( serverErrorHandlerImpl ) > ... > ? > Thanks > > -- > Atenciosamente, > Efraim Gentil - @efraimgentil > Github > LinkedIn > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ungarida at gmail.com Tue Nov 18 06:57:49 2014 From: ungarida at gmail.com (Davide Ungari) Date: Tue, 18 Nov 2014 12:57:49 +0100 Subject: [undertow-dev] Async proxy to Async API Message-ID: Hi everybody, this is the big picture: a. frontend application with Undertow b. backend application with Undertow and Resteasy for REST API A serves JS,HTML,CSS and exposes B's REST API with a proxy servlet ( https://github.com/mitre/HTTP-Proxy-Servlet). Since one method of my backend API does some image processing, I'm wondering how to implement this method in an asynchronous way. On B side I'm reading Resteasy documentation http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#Asynchronous_HTTP_Request_Processing On A side is there something could help me from undertow to proxy in async way the requests to this method of B? -- Davide -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141118/ccc69043/attachment.html From efraim.gentil at gmail.com Tue Nov 18 14:35:41 2014 From: efraim.gentil at gmail.com (Efraim Gentil) Date: Tue, 18 Nov 2014 17:35:41 -0200 Subject: [undertow-dev] PathHandler and HANDLE_404,HANDLE_500 In-Reply-To: <1143669895.350969.1416282465422.JavaMail.zimbra@redhat.com> References: <1143669895.350969.1416282465422.JavaMail.zimbra@redhat.com> Message-ID: Thanks Stuart, in the both ways worked pretty fine, the FileErrorPageHandler is not exactly what i need but it gives the hints that i needed. Thanks 2014-11-18 1:47 GMT-02:00 Stuart Douglas : > Have a look at io.undertow.server.handlers.error.FileErrorPageHandler. > > Basically you can use > io.undertow.server.HttpServerExchange#addDefaultResponseListener to > generate default responses. > > Stuart > > ----- Original Message ----- > > From: "Efraim Gentil" > > To: undertow-dev at lists.jboss.org > > Sent: Tuesday, 18 November, 2014 1:59:05 PM > > Subject: [undertow-dev] PathHandler and HANDLE_404,HANDLE_500 > > > > > > > > Hi guys, i?m working on some specs in my app and i?m trying to specify a > 404 > > error handler and 500 error handler in my PathHandler, apparently that?s > not > > possible, i tried to use default handler as > > Handles.path(//MyDefaultHandlerHere), for 404 handler works fine, but > what > > about 500 error handler ? there is any way to specify this ? > > > > Simple test: > > Undertow.builder().addHttpListener( 8080 , "localhost" ) > > .setHandler(path( new HttpHandler() { public void handleRequest > > (HttpServerExchange exchange) throws Exception { > > System.out.println( "DEFAULT" ); > > } > > }) > > .addExactPath( "/hi" , new HttpHandler() { public void handleRequest > > (HttpServerExchange exchange) throws Exception { > > System.out.println( "HI" ); > > }}) > > .addExactPath( "/hi2" , new HttpHandler() { public void handleRequest > > (HttpServerExchange exchange) throws Exception { > > System.out.println( "HI2" ); throw new RuntimeException () ; > > }}) > > ).build(); > > > > > > Maybe in the builder we can have something like > > Undertow.builder() > > .setNotFoundHandler( notFoundHandlerImpl ) > > .setServerErrorHandler( serverErrorHandlerImpl ) > > ... > > ? > > Thanks > > > > -- > > Atenciosamente, > > Efraim Gentil - @efraimgentil > > Github > > LinkedIn > > > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Atenciosamente, Efraim Gentil - @efraimgentil Github LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141118/50d40560/attachment.html From sdouglas at redhat.com Tue Nov 18 15:24:49 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 18 Nov 2014 15:24:49 -0500 (EST) Subject: [undertow-dev] Async proxy to Async API In-Reply-To: References: Message-ID: <1672169711.950710.1416342289079.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Davide Ungari" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 18 November, 2014 10:57:49 PM > Subject: [undertow-dev] Async proxy to Async API > > Hi everybody, > this is the big picture: > a. frontend application with Undertow > b. backend application with Undertow and Resteasy for REST API > > A serves JS,HTML,CSS and exposes B's REST API with a proxy servlet ( > https://github.com/mitre/HTTP-Proxy-Servlet ). > > Since one method of my backend API does some image processing, I'm wondering > how to implement this method in an asynchronous way. > > On B side I'm reading Resteasy documentation > http://docs.jboss.org/resteasy/docs/3.0.9.Final/userguide/html_single/#Asynchronous_HTTP_Request_Processing > > On A side is there something could help me from undertow to proxy in async > way the requests to this method of B? Use org.wildfly.extension.undertow.handlers.ReverseProxyHandler The example io.undertow.examples.reverseproxy.ReverseProxyServer shows you how to use it. Basically it works in the IO thread, so there is no dispatch to an executor required, and both the incoming requests and async client connection both use the same thread for maximum efficiency. Stuart > > -- > Davide > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bburke at redhat.com Thu Nov 20 22:13:03 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 20 Nov 2014 22:13:03 -0500 Subject: [undertow-dev] awesome Message-ID: <546EADBF.7040709@redhat.com> I couldn't believe how easy it was to create an http security proxy for Keycloak using undertow. Undertow was insanely modular and easy to piece together how I wanted. Great work guys. Thanks -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From rdavies at redhat.com Fri Nov 21 02:32:45 2014 From: rdavies at redhat.com (Rob Davies) Date: Fri, 21 Nov 2014 02:32:45 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <546EADBF.7040709@redhat.com> References: <546EADBF.7040709@redhat.com> Message-ID: <1260818744.3177201.1416555165746.JavaMail.zimbra@redhat.com> Can we use raw tcp sockets with undertow ? ----- Original Message ----- > From: "Bill Burke" > To: undertow-dev at lists.jboss.org > Sent: Friday, November 21, 2014 3:13:03 AM > Subject: [undertow-dev] awesome > > I couldn't believe how easy it was to create an http security proxy for > Keycloak using undertow. Undertow was insanely modular and easy to > piece together how I wanted. Great work guys. > > Thanks > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Fri Nov 21 03:06:43 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 21 Nov 2014 03:06:43 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <546EADBF.7040709@redhat.com> References: <546EADBF.7040709@redhat.com> Message-ID: <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: undertow-dev at lists.jboss.org > Sent: Friday, 21 November, 2014 2:13:03 PM > Subject: [undertow-dev] awesome > > I couldn't believe how easy it was to create an http security proxy for > Keycloak using undertow. Undertow was insanely modular and easy to > piece together how I wanted. Great work guys. Awesome :-) Stuart > > Thanks > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Fri Nov 21 03:07:21 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 21 Nov 2014 03:07:21 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <1260818744.3177201.1416555165746.JavaMail.zimbra@redhat.com> References: <546EADBF.7040709@redhat.com> <1260818744.3177201.1416555165746.JavaMail.zimbra@redhat.com> Message-ID: <426451306.2282933.1416557241841.JavaMail.zimbra@redhat.com> You can do HTTP upgrade, what exactly are you after? Stuart ----- Original Message ----- > From: "Rob Davies" > To: "Bill Burke" > Cc: undertow-dev at lists.jboss.org > Sent: Friday, 21 November, 2014 6:32:45 PM > Subject: Re: [undertow-dev] awesome > > Can we use raw tcp sockets with undertow ? > > > ----- Original Message ----- > > From: "Bill Burke" > > To: undertow-dev at lists.jboss.org > > Sent: Friday, November 21, 2014 3:13:03 AM > > Subject: [undertow-dev] awesome > > > > I couldn't believe how easy it was to create an http security proxy for > > Keycloak using undertow. Undertow was insanely modular and easy to > > piece together how I wanted. Great work guys. > > > > Thanks > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From rdavies at redhat.com Fri Nov 21 03:54:23 2014 From: rdavies at redhat.com (Rob Davies) Date: Fri, 21 Nov 2014 08:54:23 +0000 Subject: [undertow-dev] awesome In-Reply-To: <426451306.2282933.1416557241841.JavaMail.zimbra@redhat.com> References: <546EADBF.7040709@redhat.com> <1260818744.3177201.1416555165746.JavaMail.zimbra@redhat.com> <426451306.2282933.1416557241841.JavaMail.zimbra@redhat.com> Message-ID: <546EFDBF.3000602@redhat.com> I was wondering if you had any plans to expose raw tcp. Currently we use vert.x to power a reverse proxy in fabric8 (as it provides a really nice abstraction over sockets). We also have a requirement to run servlets, so I'm wondering about consolidating around one thing, as we yet need all the awesome features and functionality that vert.x has. > Stuart Douglas > 21 November 2014 08:07 > You can do HTTP upgrade, what exactly are you after? > > Stuart > > ----- Original Message ----- > Rob Davies > 21 November 2014 07:32 > Can we use raw tcp sockets with undertow ? > > > ----- Original Message ----- > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > Bill Burke > 21 November 2014 03:13 > I couldn't believe how easy it was to create an http security proxy for > Keycloak using undertow. Undertow was insanely modular and easy to > piece together how I wanted. Great work guys. > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141121/b9cb8b2f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20141121/b9cb8b2f/attachment-0002.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1265 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20141121/b9cb8b2f/attachment-0003.jpg From sdouglas at redhat.com Fri Nov 21 07:00:34 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 21 Nov 2014 07:00:34 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> References: <546EADBF.7040709@redhat.com> <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> Message-ID: <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> Also do you have any details posted somewhere about how you did it? Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Bill Burke" > Cc: undertow-dev at lists.jboss.org > Sent: Friday, 21 November, 2014 7:06:43 PM > Subject: Re: [undertow-dev] awesome > > > > ----- Original Message ----- > > From: "Bill Burke" > > To: undertow-dev at lists.jboss.org > > Sent: Friday, 21 November, 2014 2:13:03 PM > > Subject: [undertow-dev] awesome > > > > I couldn't believe how easy it was to create an http security proxy for > > Keycloak using undertow. Undertow was insanely modular and easy to > > piece together how I wanted. Great work guys. > > Awesome :-) > > Stuart > > > > > Thanks > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From bburke at redhat.com Fri Nov 21 08:36:55 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 08:36:55 -0500 Subject: [undertow-dev] awesome In-Reply-To: <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> References: <546EADBF.7040709@redhat.com> <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> Message-ID: <546F3FF7.8050808@redhat.com> just code. It's functional, but still a work in progress. All i did was set up a handler chain that re-used our existing Undertow auth mechanism, with the last handler being a SimpleProxyClientProvider. I also forked your servlet constraint matching logic so that I could define role mappings in the proxy layer. https://github.com/keycloak/keycloak/tree/master/proxy/proxy-server https://github.com/keycloak/keycloak/tree/master/testsuite/proxy BTW, do you know any standard headers I could use to forward security information? On 11/21/2014 7:00 AM, Stuart Douglas wrote: > Also do you have any details posted somewhere about how you did it? > > Stuart > > ----- Original Message ----- >> From: "Stuart Douglas" >> To: "Bill Burke" >> Cc: undertow-dev at lists.jboss.org >> Sent: Friday, 21 November, 2014 7:06:43 PM >> Subject: Re: [undertow-dev] awesome >> >> >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: undertow-dev at lists.jboss.org >>> Sent: Friday, 21 November, 2014 2:13:03 PM >>> Subject: [undertow-dev] awesome >>> >>> I couldn't believe how easy it was to create an http security proxy for >>> Keycloak using undertow. Undertow was insanely modular and easy to >>> piece together how I wanted. Great work guys. >> >> Awesome :-) >> >> Stuart >> >>> >>> Thanks >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Nov 21 09:18:39 2014 From: bburke at redhat.com (Bill Burke) Date: Fri, 21 Nov 2014 09:18:39 -0500 Subject: [undertow-dev] awesome In-Reply-To: <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> References: <546EADBF.7040709@redhat.com> <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> Message-ID: <546F49BF.8040109@redhat.com> BTW I occasionally get these errors, but things still work: 09:13:26,568 ERROR [io.undertow.request] Blocking request failed HttpServerExchange{ GET /customer-portal/users} java.lang.NullPointerException at io.undertow.client.http.HttpRequestConduit.processWrite(HttpRequestConduit.java:337) at io.undertow.client.http.HttpRequestConduit.flush(HttpRequestConduit.java:573) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) at io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:282) at io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:215) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:355) at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:17) at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:712) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:232) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:227) at io.undertow.server.handlers.proxy.SimpleProxyClientProvider.getConnection(SimpleProxyClientProvider.java:48) at io.undertow.server.handlers.proxy.ProxyHandler$3.run(ProxyHandler.java:154) On 11/21/2014 7:00 AM, Stuart Douglas wrote: > Also do you have any details posted somewhere about how you did it? > > Stuart > > ----- Original Message ----- >> From: "Stuart Douglas" >> To: "Bill Burke" >> Cc: undertow-dev at lists.jboss.org >> Sent: Friday, 21 November, 2014 7:06:43 PM >> Subject: Re: [undertow-dev] awesome >> >> >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: undertow-dev at lists.jboss.org >>> Sent: Friday, 21 November, 2014 2:13:03 PM >>> Subject: [undertow-dev] awesome >>> >>> I couldn't believe how easy it was to create an http security proxy for >>> Keycloak using undertow. Undertow was insanely modular and easy to >>> piece together how I wanted. Great work guys. >> >> Awesome :-) >> >> Stuart >> >>> >>> Thanks >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ryan.hermanson at gmail.com Fri Nov 21 17:46:58 2014 From: ryan.hermanson at gmail.com (Ryan Hermanson) Date: Fri, 21 Nov 2014 15:46:58 -0700 Subject: [undertow-dev] modifyHandshake dilemma Message-ID: Programmatically, I want the ability to reject/deny inbound websocket connections within my application based on some criteria. The most obvious approach to me is to implement Configurator and override the modifyHandshake method. HandshakeResponse only exposes the SEC_WEBSOCKET_ACCEPT property key. When I set this value as an empty list, the behavior is not as I was hoping (not sure what I was expecting). Inline with undertow convention/preference, how can I force a response to the connecting client endpoint that resembles a 405 or 403? Thank you, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141121/97b8c710/attachment.html From rob.nikander at gmail.com Sat Nov 22 09:03:31 2014 From: rob.nikander at gmail.com (Robert Nikander) Date: Sat, 22 Nov 2014 09:03:31 -0500 Subject: [undertow-dev] Undertow + modules = Wildfly? Message-ID: Hi, I?m looking for a minimal webapp server, like Undertow, but I also want JBoss modules (or something with that kind of classloading). Any thoughts on the differences between? 1. Using Wildfly and learning to turn stuff off. I don?t care about most of J2EE. 2. Using only Undertow + the jars for JBoss modules. Specifically, I?m wondering if there will be much difference in RAM usage, and whether I could still write native Undertow handlers [1] if I go with #1. Rob [1] http://undertow.io/documentation/core/undertow-handler-guide.html From sdouglas at redhat.com Sun Nov 23 17:52:44 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 23 Nov 2014 17:52:44 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <546F49BF.8040109@redhat.com> References: <546EADBF.7040709@redhat.com> <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> <546F49BF.8040109@redhat.com> Message-ID: <1351971189.2903894.1416783164795.JavaMail.zimbra@redhat.com> That error should be fixed in the recently released 1.1.0.Final. The only thing is that 1.1.0.Final requires Java 7, and looking at your build it looks like you are targeting 1.6. This will still work if you build with Java 7, however it will cause problems if you try and build with 1.6 (and obviously the undertow specific features will need JDK7). The main reason for this is that Servlet 3.1 relies on some JDK7 classes. If you really need full JDK6 support we could potentially use David's seven2six tool to produce JDK6 compatible artefacts. Stuart ----- Original Message ----- > From: "Bill Burke" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Saturday, 22 November, 2014 1:18:39 AM > Subject: Re: [undertow-dev] awesome > > BTW I occasionally get these errors, but things still work: > > 09:13:26,568 ERROR [io.undertow.request] Blocking request failed > HttpServerExchange{ GET /customer-portal/users} > java.lang.NullPointerException > at > io.undertow.client.http.HttpRequestConduit.processWrite(HttpRequestConduit.java:337) > at > io.undertow.client.http.HttpRequestConduit.flush(HttpRequestConduit.java:573) > at > io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205) > at > org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) > at > io.undertow.client.http.HttpClientConnection.initiateRequest(HttpClientConnection.java:282) > at > io.undertow.client.http.HttpClientConnection.sendRequest(HttpClientConnection.java:215) > at > io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:355) > at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:17) > at > io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:712) > at > io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:232) > at > io.undertow.server.handlers.proxy.ProxyHandler$ProxyClientHandler.completed(ProxyHandler.java:227) > at > io.undertow.server.handlers.proxy.SimpleProxyClientProvider.getConnection(SimpleProxyClientProvider.java:48) > at > io.undertow.server.handlers.proxy.ProxyHandler$3.run(ProxyHandler.java:154) > > > On 11/21/2014 7:00 AM, Stuart Douglas wrote: > > Also do you have any details posted somewhere about how you did it? > > > > Stuart > > > > ----- Original Message ----- > >> From: "Stuart Douglas" > >> To: "Bill Burke" > >> Cc: undertow-dev at lists.jboss.org > >> Sent: Friday, 21 November, 2014 7:06:43 PM > >> Subject: Re: [undertow-dev] awesome > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: undertow-dev at lists.jboss.org > >>> Sent: Friday, 21 November, 2014 2:13:03 PM > >>> Subject: [undertow-dev] awesome > >>> > >>> I couldn't believe how easy it was to create an http security proxy for > >>> Keycloak using undertow. Undertow was insanely modular and easy to > >>> piece together how I wanted. Great work guys. > >> > >> Awesome :-) > >> > >> Stuart > >> > >>> > >>> Thanks > >>> > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> undertow-dev mailing list > >>> undertow-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >>> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From sdouglas at redhat.com Sun Nov 23 17:56:58 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 23 Nov 2014 17:56:58 -0500 (EST) Subject: [undertow-dev] awesome In-Reply-To: <546F3FF7.8050808@redhat.com> References: <546EADBF.7040709@redhat.com> <932826437.2282884.1416557203681.JavaMail.zimbra@redhat.com> <419915290.2384870.1416571234536.JavaMail.zimbra@redhat.com> <546F3FF7.8050808@redhat.com> Message-ID: <1342193280.2904544.1416783418341.JavaMail.zimbra@redhat.com> > BTW, do you know any standard headers I could use to forward security > information? Not really. We use SSL_CLIENT_CERT, SSL_CIPHER and SSL_SESSION_ID to forward certificate information to back end servers, but that is in no way standard (basically I just used the same headers that JBoss Web did). Stuart > > On 11/21/2014 7:00 AM, Stuart Douglas wrote: > > Also do you have any details posted somewhere about how you did it? > > > > Stuart > > > > ----- Original Message ----- > >> From: "Stuart Douglas" > >> To: "Bill Burke" > >> Cc: undertow-dev at lists.jboss.org > >> Sent: Friday, 21 November, 2014 7:06:43 PM > >> Subject: Re: [undertow-dev] awesome > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: undertow-dev at lists.jboss.org > >>> Sent: Friday, 21 November, 2014 2:13:03 PM > >>> Subject: [undertow-dev] awesome > >>> > >>> I couldn't believe how easy it was to create an http security proxy for > >>> Keycloak using undertow. Undertow was insanely modular and easy to > >>> piece together how I wanted. Great work guys. > >> > >> Awesome :-) > >> > >> Stuart > >> > >>> > >>> Thanks > >>> > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> undertow-dev mailing list > >>> undertow-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >>> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From sdouglas at redhat.com Sun Nov 23 18:02:31 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 23 Nov 2014 18:02:31 -0500 (EST) Subject: [undertow-dev] modifyHandshake dilemma In-Reply-To: References: Message-ID: <686993643.2904761.1416783751525.JavaMail.zimbra@redhat.com> Looking at the websocket API's there does not really appear to be a way to set a specific response code. One option could be to just use a Servlet filter. Undertow's Websocket upgrade is handled by a filter that should be installed after all user defined filters, so your filter will run first. You could just look for the appropriate headers in your filter, and make a decision there. It would probably be good to address this in the next revision of the spec, can you create a spec issue with your use case at https://java.net/jira/browse/WEBSOCKET_SPEC ? Stuart ----- Original Message ----- > From: "Ryan Hermanson" > To: undertow-dev at lists.jboss.org > Sent: Saturday, 22 November, 2014 9:46:58 AM > Subject: [undertow-dev] modifyHandshake dilemma > > Programmatically, I want the ability to reject/deny inbound websocket > connections within my application based on some criteria. The most obvious > approach to me is to implement Configurator and override the modifyHandshake > method. HandshakeResponse only exposes the SEC_WEBSOCKET_ACCEPT property > key. When I set this value as an empty list, the behavior is not as I was > hoping (not sure what I was expecting). > > Inline with undertow convention/preference, how can I force a response to the > connecting client endpoint that resembles a 405 or 403? > > Thank you, > > -Ryan > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Sun Nov 23 18:24:59 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 23 Nov 2014 18:24:59 -0500 (EST) Subject: [undertow-dev] Undertow + modules = Wildfly? In-Reply-To: References: Message-ID: <2038053216.2906186.1416785099640.JavaMail.zimbra@redhat.com> We have actually split up the wildfly code base recently, and the result of this is that we now have 3 different Wildfly artifacts: - Wildfly Core: The core platform (classloading, management etc) - Wildfly Web: Core + Undertow - Wildfly Full: everything else It sounds like you want Wildfly Web, which is basically just a Servlet container, with our modular class loading and management. You can get it from maven central: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22wildfly-web-dist%22 We have not really talked about / promoted this much yet, I should be writing more about it over the coming months. Stuart ----- Original Message ----- > From: "Robert Nikander" > To: undertow-dev at lists.jboss.org > Sent: Sunday, 23 November, 2014 1:03:31 AM > Subject: [undertow-dev] Undertow + modules = Wildfly? > > Hi, > > I?m looking for a minimal webapp server, like Undertow, but I also want JBoss > modules (or something with that kind of classloading). Any thoughts on the > differences between? > > 1. Using Wildfly and learning to turn stuff off. I don?t care about most of > J2EE. > 2. Using only Undertow + the jars for JBoss modules. > > Specifically, I?m wondering if there will be much difference in RAM usage, > and whether I could still write native Undertow handlers [1] if I go with > #1. > > Rob > > [1] http://undertow.io/documentation/core/undertow-handler-guide.html > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jason.greene at redhat.com Mon Nov 24 11:35:43 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 24 Nov 2014 10:35:43 -0600 Subject: [undertow-dev] awesome In-Reply-To: <546EFDBF.3000602@redhat.com> References: <546EADBF.7040709@redhat.com> <1260818744.3177201.1416555165746.JavaMail.zimbra@redhat.com> <426451306.2282933.1416557241841.JavaMail.zimbra@redhat.com> <546EFDBF.3000602@redhat.com> Message-ID: <4966DCE7-12AC-4FE5-8522-31FAFDB0FB86@redhat.com> Are you looking to do something not HTTP at all, so like just a straight TCP socket proxy? Or do you use HTTP upgrade to reuse the same port, and delegate the socket to another framework. > On Nov 21, 2014, at 2:54 AM, Rob Davies wrote: > > I was wondering if you had any plans to expose raw tcp. Currently we use vert.x to power a reverse proxy in fabric8 (as it provides a really nice abstraction over sockets). We also have a requirement to run servlets, so I'm wondering about consolidating around one thing, as we yet need all the awesome features and functionality that vert.x has. >> Stuart Douglas 21 November 2014 08:07 >> You can do HTTP upgrade, what exactly are you after? >> >> Stuart >> >> ----- Original Message ----- >> Rob Davies 21 November 2014 07:32 >> Can we use raw tcp sockets with undertow ? >> >> >> ----- Original Message ----- >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> Bill Burke 21 November 2014 03:13 >> I couldn't believe how easy it was to create an http security proxy for >> Keycloak using undertow. Undertow was insanely modular and easy to >> piece together how I wanted. Great work guys. >> >> Thanks >> > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141124/2b81f982/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20141124/2b81f982/attachment.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: postbox-contact.jpg Type: image/jpeg Size: 1265 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20141124/2b81f982/attachment-0001.jpg From bburke at redhat.com Tue Nov 25 11:30:41 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 25 Nov 2014 11:30:41 -0500 Subject: [undertow-dev] req.authenticate() problems 1.1.0 Message-ID: <5474AEB1.8030405@redhat.com> When upgrading from Undertow 1.0.15 to 1.1.0 our HttpServleRequest.authenticate() unit test is failing. An exception is being thrown in HttpServletRequestImpl.authenticate() line 416. Our auth mechanism is being called correctly. It sets the status code (302) and the Location header within a challenge object. It looks like exchange.isResponseStarted() is returning false even though my challenge object is setting up the resposne correctly. Am I supposed to call exchange.endExchange() or something within my Challenge object? I tried doing that, but Undertow is now spitting out exception messages: java.lang.IllegalStateException: UT000002: The response has already been started at io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246) at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355) at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314) at io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) at io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sdouglas at redhat.com Tue Nov 25 14:19:41 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 25 Nov 2014 14:19:41 -0500 (EST) Subject: [undertow-dev] req.authenticate() problems 1.1.0 In-Reply-To: <5474AEB1.8030405@redhat.com> References: <5474AEB1.8030405@redhat.com> Message-ID: <1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com> Is the code up on Github anywhere? If so I can take a look. Stuart ----- Original Message ----- > From: "Bill Burke" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 26 November, 2014 3:30:41 AM > Subject: [undertow-dev] req.authenticate() problems 1.1.0 > > When upgrading from Undertow 1.0.15 to 1.1.0 our > HttpServleRequest.authenticate() unit test is failing. An exception is > being thrown in HttpServletRequestImpl.authenticate() line 416. > > Our auth mechanism is being called correctly. It sets the status code > (302) and the Location header within a challenge object. It looks like > exchange.isResponseStarted() is returning false even though my challenge > object is setting up the resposne correctly. Am I supposed to call > exchange.endExchange() or something within my Challenge object? I tried > doing that, but Undertow is now spitting out exception messages: > > java.lang.IllegalStateException: UT000002: The response has already been > started > at > io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246) > at > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355) > at > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) > at > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) > at > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314) > at > io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) > at > io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404) > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From bburke at redhat.com Tue Nov 25 14:50:11 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 25 Nov 2014 14:50:11 -0500 Subject: [undertow-dev] req.authenticate() problems 1.1.0 In-Reply-To: <1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com> References: <5474AEB1.8030405@redhat.com> <1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com> Message-ID: <5474DD73.2040204@redhat.com> The old implementation of HttpServletRequest.authenticate() would just assume that a challenge was set up in the exchange. For Undertow 1.1, again, take a look at HttpServletRequestImpl.java lines 411-416. The problem is that my challenge did not commit the request and line 411 is returning false. I tried to fix it by calling HttpServerExchange.endExchange(), got success, but got the stack trace shown earlier.... If you *really* want to look the code it is here: https://github.com/keycloak/keycloak/tree/master/integration/undertow Its a bit of a mess mainly because we have common adapter code that is shared between Undertow, Tomcat 6-8, Jetty 8-9, and JBossWeb. If you pull the whole project and bring it up in an IDE, you can try the test: org.keycloak.testsuite.adapter.AdapterTest#testAuthenticated() "master" uses 1.0.15 of Undertow. Just change it to use 1.1.0.Final (in the master pom.xml) and you'll see the failure. On 11/25/2014 2:19 PM, Stuart Douglas wrote: > Is the code up on Github anywhere? If so I can take a look. > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" >> To: undertow-dev at lists.jboss.org >> Sent: Wednesday, 26 November, 2014 3:30:41 AM >> Subject: [undertow-dev] req.authenticate() problems 1.1.0 >> >> When upgrading from Undertow 1.0.15 to 1.1.0 our >> HttpServleRequest.authenticate() unit test is failing. An exception is >> being thrown in HttpServletRequestImpl.authenticate() line 416. >> >> Our auth mechanism is being called correctly. It sets the status code >> (302) and the Location header within a challenge object. It looks like >> exchange.isResponseStarted() is returning false even though my challenge >> object is setting up the resposne correctly. Am I supposed to call >> exchange.endExchange() or something within my Challenge object? I tried >> doing that, but Undertow is now spitting out exception messages: >> >> java.lang.IllegalStateException: UT000002: The response has already been >> started >> at >> io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246) >> at >> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355) >> at >> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) >> at >> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) >> at >> io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314) >> at >> io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) >> at >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) >> at >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) >> at >> io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404) >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sdouglas at redhat.com Tue Nov 25 15:41:55 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 25 Nov 2014 15:41:55 -0500 (EST) Subject: [undertow-dev] req.authenticate() problems 1.1.0 In-Reply-To: <1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com> References: <5474AEB1.8030405@redhat.com> <1213568871.4222684.1416943181289.JavaMail.zimbra@redhat.com> Message-ID: <88575048.4255911.1416948115410.JavaMail.zimbra@redhat.com> This should be fixed upstream, I will do a 1.1.1 release shortly, so if you discover any other issues let me know and I will try and get them into this release. Stuart ----- Original Message ----- > From: "Stuart Douglas" > To: "Bill Burke" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 26 November, 2014 6:19:41 AM > Subject: Re: [undertow-dev] req.authenticate() problems 1.1.0 > > Is the code up on Github anywhere? If so I can take a look. > > Stuart > > ----- Original Message ----- > > From: "Bill Burke" > > To: undertow-dev at lists.jboss.org > > Sent: Wednesday, 26 November, 2014 3:30:41 AM > > Subject: [undertow-dev] req.authenticate() problems 1.1.0 > > > > When upgrading from Undertow 1.0.15 to 1.1.0 our > > HttpServleRequest.authenticate() unit test is failing. An exception is > > being thrown in HttpServletRequestImpl.authenticate() line 416. > > > > Our auth mechanism is being called correctly. It sets the status code > > (302) and the Location header within a challenge object. It looks like > > exchange.isResponseStarted() is returning false even though my challenge > > object is setting up the resposne correctly. Am I supposed to call > > exchange.endExchange() or something within my Challenge object? I tried > > doing that, but Undertow is now spitting out exception messages: > > > > java.lang.IllegalStateException: UT000002: The response has already been > > started > > at > > io.undertow.server.HttpServerExchange.setResponseCode(HttpServerExchange.java:1246) > > at > > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:355) > > at > > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) > > at > > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349) > > at > > io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314) > > at > > io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) > > at > > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) > > at > > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) > > at > > io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletRequestImpl.java:404) > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From vladimirmanolov at hotmail.com Tue Nov 25 17:23:07 2014 From: vladimirmanolov at hotmail.com (Vladimir Manolov) Date: Tue, 25 Nov 2014 23:23:07 +0100 Subject: [undertow-dev] GateIn WCI for Undertow Message-ID: Dear Undertow-Team, I am interested in running portlets on a WildFly application server and need to get GateIn integrated inside. For that I assume a GateIn WCI is required to hook into Undertow. I am not quite sure how to do that. A GateIn WCI integration used to be done by implementing this type of class: import org.apache.catalina.ContainerListener; import org.apache.catalina.LifecycleListener; import org.gatein.wci.spi.ServletContainerContext; public class MyServletContainerContext implements ServletContainerContext, ContainerListener, LifecycleListener I am looking for a the classes in Undertow that provide the same type of functionality: hook into the container lifecycle and react on container events. As a reference I am using the gatein-wci project on github: https://github.com/gatein/gatein-wci or https://github.com/gatein/gatein-wci/blob/master/jboss/jboss7/src/main/java/org/gatein/wci/jboss/JB7ServletContainerContext.java It would great if you could just help me get started. Best regards, Vladimir Manolov PS: I found this jira-task which is still open: https://issues.jboss.org/browse/GTNWCI-48 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141125/1945c8ca/attachment-0001.html From tomaz.cerar at gmail.com Wed Nov 26 10:37:37 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 26 Nov 2014 16:37:37 +0100 Subject: [undertow-dev] GateIn WCI for Undertow In-Reply-To: References: Message-ID: Hey, There is no direct mapping available but most of the stuff you are mentioning is available as part of servlet spec. so no need for some special servlet container specific classes. Except maybe ContainerListener as Undertow has no such facility or at least not in such format. Also take a look at ServletExtension http://undertow.io/documentation/servlet/servlet-extensions.html as it provides a entry point for extending standard servlet deployments with undetrow specifics. -- tomaz On Tue, Nov 25, 2014 at 11:23 PM, Vladimir Manolov < vladimirmanolov at hotmail.com> wrote: > Dear Undertow-Team, > > I am interested in running portlets on a WildFly application server and > need to get GateIn integrated inside. For that I assume a GateIn WCI is > required to hook into Undertow. I am not quite sure how to do that. A > GateIn WCI integration used to be done by implementing this type of class: > > import org.apache.catalina.ContainerListener; > import org.apache.catalina.LifecycleListener; > import org.gatein.wci.spi.ServletContainerContext; > > public class *MyServletContainerContext* implements > *ServletContainerContext*, *ContainerListener*, *LifecycleListener* > > > I am looking for a the classes in Undertow that provide the same type of > functionality: hook into the container lifecycle and react on container > events. > > As a reference I am using the gatein-wci project on github: > https://github.com/gatein/gatein-wci or > https://github.com/gatein/gatein-wci/blob/master/jboss/jboss7/src/main/java/org/gatein/wci/jboss/JB7ServletContainerContext.java > > It would great if you could just help me get started. > > Best regards, > Vladimir Manolov > > PS: I found this jira-task which is still open: > https://issues.jboss.org/browse/GTNWCI-48 > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141126/05e43d67/attachment.html From arjan.tijms at gmail.com Thu Nov 27 08:31:19 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 27 Nov 2014 14:31:19 +0100 Subject: [undertow-dev] JSESSIONID cookie path empty for root deployments In-Reply-To: References: Message-ID: Hi, On Tue, Jun 24, 2014 at 12:14 PM, Toma? Cerar wrote: > I think this might be fixed in master, at least this commit > https://github.com/wildfly/wildfly/commit/fe642cd253dc91febed2f763a48853aa200a1bd5 > was changing this exact behavior. > > can you try with wildfly master if it is still the same? Sorry, never replied to this, but it was indeed fixed in master (and now in Undertow 1.1.0 final as well). Kind regards, Arjan > > -- > tomaz > > > On Mon, Jun 23, 2014 at 3:16 PM, arjan tijms wrote: >> >> Hi, >> >> For a root deployment, Undertow by default writes the JSESSIONID cookie >> with an empty path. I.e. in the response header the following appears: >> >> SET-COOKIE: JSESSIONID=FhgSh... path=; ... >> >> An empty path causes browsers to set the cookie on whatever path was used >> for the request URI. In effect, this causes multiple JSESSIONIDs to be >> created while browsing through an app deployed to WildFly, and thus multiple >> JSESSIONIDs being posted back when other paths are accessed (leading to many >> issues). >> >> The cause of this seems to be in >> io.undertow.servlet.spec.ServletContextImpl#ServletContextImpl and >> io.undertow.servlet.core.DeploymentManagerImpl#handleDeploymentSessionConfig, >> where the cookie path is set to deploymentInfo#getContextPath, which in both >> cases returns the empty string. >> >> See: >> >> >> io.undertow.servlet.spec.ServletContextImpl.ServletContextImpl(ServletContainer, >> Deployment) >> >> sessionCookieConfig = new SessionCookieConfigImpl(this); >> sessionCookieConfig.setPath(deploymentInfo.getContextPath()); >> >> and: >> >> >> io.undertow.servlet.core.DeploymentManagerImpl.handleDeploymentSessionConfig(DeploymentInfo, >> ServletContextImpl) >> if(sc.getPath() != null) { >> sessionCookieConfig.setPath(sc.getPath()); >> } else { >> sessionCookieConfig.setPath(deploymentInfo.getContextPath()); >> } >> >> I'm not sure if deploymentInfo#getContextPath should indeed return the >> empty string for a root deployment or not, but I think setting the cookie >> path to the empty string is not really correct and should be "/" in that >> case. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > >