From bburke at redhat.com Mon Jun 2 09:44:35 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 02 Jun 2014 09:44:35 -0400 Subject: [undertow-dev] getting secure port In-Reply-To: <538C7AB8.1040009@redhat.com> References: <538C7AB8.1040009@redhat.com> Message-ID: <538C7FC3.7040901@redhat.com> Ugh, Just figured out that getConfidentialPort is to map an unsecure request to a secured one. And I'm making this call within a secure request. Thus there is no port mapping between 8443 and 8443 and thus...failure... My mistake. APologies for wasting your time. On 6/2/2014 9:23 AM, Bill Burke wrote: > I need to be able to resolve what port SSL is on. I'm getting an NPE, > am I doing something wrong? > > > I'm getting the port manager within a ServletExtension: > > deploymentInfo.getConfidentialPortManager() > > Then during requests I'm calling > > ConfidentialPortManager.getConfidentialPort(exchange) > > But I'm getting an NPE: > > 09:15:46,705 ERROR [io.undertow.request] (default task-96) UT005023: > Exception handling request to /customer-portal/index. html: > java.lang.NullPointerException > at > org.wildfly.extension.undertow.Server.lookupSecurePort(Server.java:113) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$2.getConfidentialPort(UndertowDeploymen > tInfoService.java:461) > > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jun 2 09:23:04 2014 From: bburke at redhat.com (Bill Burke) Date: Mon, 02 Jun 2014 09:23:04 -0400 Subject: [undertow-dev] getting secure port Message-ID: <538C7AB8.1040009@redhat.com> I need to be able to resolve what port SSL is on. I'm getting an NPE, am I doing something wrong? I'm getting the port manager within a ServletExtension: deploymentInfo.getConfidentialPortManager() Then during requests I'm calling ConfidentialPortManager.getConfidentialPort(exchange) But I'm getting an NPE: 09:15:46,705 ERROR [io.undertow.request] (default task-96) UT005023: Exception handling request to /customer-portal/index. html: java.lang.NullPointerException at org.wildfly.extension.undertow.Server.lookupSecurePort(Server.java:113) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$2.getConfidentialPort(UndertowDeploymen tInfoService.java:461) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ecki at zusammenkunft.net Mon Jun 2 18:55:20 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 3 Jun 2014 00:55:20 +0200 Subject: [undertow-dev] Date Handler time (optimisation) Message-ID: <20140603005520.000048f3.ecki@zusammenkunft.net> Hello, in Undertow 1.0.1 the DateHandler retrieves System.nanoTime() on each request and compares it against a deadline to decide if it should also query wallclock (via System.currentTimeMillis). I see two possible optimizations here: If the "Record request start time" option is set, the nanos value can be read from the exchange.getRequestStartTime and does not need another query. (Alternatively you can switch the record option off and make DateHandler write to exchange.setRequestStartTime() to make the syscall count: the additional time is available without specifying the RECORD option). The alternative optimization is about not using the nanos clock for determining if cached value is stale but directly requesting the wallclock millis. For one, I think the latency of nanoTime is not much better (on some systems worse) than System.currentTime (after all, it is an hotspot intrinsic) and every second both clocks would be asked (multiple times its a race). When having the current millis value, you could also check if actually the next second has started (and avoid the rouding problem with "nanos + 1000000000". (And again, if the wallclock time is determined this way, it would make sense to add it as a field on exchange?) The code+cache is BTW in two places: io.undertow.util.DateUtils.addDateHeaderIfRequired(HttpServerExchange) io.undertow.server.handlers.DateHandler.handleRequest(HttpServerExchange) BTW: I think the documentation should mention this. Here are some things which should be included (somewhere): "If you do not add the DateHandler Undertow might still add a Date: header if response does not have one and the ALWAYS_SET_DATE Header option is TRUE or missing. Using "ALWAYS_SET_DATE" is prefered, as it will use the latest possible time before the response entity is generated. The name of the option might be missleading, it does not ansure the header is always overwritten, it only ensures there is one set if there was not produced by the handlers." Once the above options are discussed and decided I can provide patches for the various doc locations. Bernd PS: I participated in an experiment* from Aleksey (of JMH fame) and had a few strange results where currentTime had high latency, on the other hand there are cases where nanoTime has high latency as well (see http://shipilev.net/blog/2014/nanotrusting-nanotime/). I think overall typical numbers show comparable latencies for both (<20ns). I asked him, if he can share his experiences. * https://github.com/shipilev/timers-bench From ecki at zusammenkunft.net Mon Jun 2 20:52:28 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 3 Jun 2014 02:52:28 +0200 Subject: [undertow-dev] Nit: MAX_ENTITY_SIZE, Default -1 vs. 0 Message-ID: <20140603025228.0000340e.ecki@zusammenkunft.net> Hello, (while researching some details for the pending documentation pull request I noticed): SpdyReceiveListener is using: this.maxEntitySize = undertowOptions.get(UndertowOptions.MAX_ENTITY_SIZE, UndertowOptions.DEFAULT_MAX_ENTITY_SIZE); While HTTPReadListener and AjpReadListener is using: this.maxEntitySize = connection.getUndertowOptions().get(UndertowOptions.MAX_ENTITY_SIZE, 0); The DEFAULT_MAX_ENTITY_SIZE is defined as -1. I think it would be good to use the constant in HTTP+AjpReadListener (and HttpServerExchange(ServerConnection)) as well. I think using -1 as the constant and in all places looks better, but more backward compatible would be 0. In HttpServerExchange#maxEntitySize for example it is documented as 0 means unlimited. The limit is checked here, and all accept 0 and -1 as unlimited: FixedLengthStreamSourceConduit#checkMaxSize() AjpServerRequestConduit#soRead() ChunkedStreamSourceConduit#updateRemainingAllowed() Gruss Bernd From sdouglas at redhat.com Wed Jun 4 11:24:32 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 04 Jun 2014 10:24:32 -0500 Subject: [undertow-dev] Nit: MAX_ENTITY_SIZE, Default -1 vs. 0 In-Reply-To: <20140603025228.0000340e.ecki@zusammenkunft.net> References: <20140603025228.0000340e.ecki@zusammenkunft.net> Message-ID: <538F3A30.6010306@redhat.com> I have changed them to all use the constant. Stuart Bernd Eckenfels wrote: > Hello, > > (while researching some details for the pending documentation pull > request I noticed): > > SpdyReceiveListener is using: > > this.maxEntitySize = > undertowOptions.get(UndertowOptions.MAX_ENTITY_SIZE, > UndertowOptions.DEFAULT_MAX_ENTITY_SIZE); > > While HTTPReadListener and AjpReadListener is using: > > this.maxEntitySize = > connection.getUndertowOptions().get(UndertowOptions.MAX_ENTITY_SIZE, > 0); > > The DEFAULT_MAX_ENTITY_SIZE is defined as -1. I think it would be good > to use the constant in HTTP+AjpReadListener (and > HttpServerExchange(ServerConnection)) as well. > > I think using -1 as the constant and in all places looks better, but > more backward compatible would be 0. In > HttpServerExchange#maxEntitySize for example it is documented as 0 > means unlimited. > > The limit is checked here, and all accept 0 and -1 as unlimited: > FixedLengthStreamSourceConduit#checkMaxSize() > AjpServerRequestConduit#soRead() > ChunkedStreamSourceConduit#updateRemainingAllowed() > > Gruss > Bernd > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Jun 4 11:36:26 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 04 Jun 2014 10:36:26 -0500 Subject: [undertow-dev] Date Handler time (optimisation) In-Reply-To: <20140603005520.000048f3.ecki@zusammenkunft.net> References: <20140603005520.000048f3.ecki@zusammenkunft.net> Message-ID: <538F3CFA.2030106@redhat.com> DateHandler is deprecated, it is only still present so old code that uses it will not fail, it will be removed at some point in the future. I have changed the way that DateUtils works to register a timer to invalidate the date string, so now in most cases no system call will be required. Stuart Bernd Eckenfels wrote: > Hello, > > in Undertow 1.0.1 the DateHandler retrieves System.nanoTime() on each > request and compares it against a deadline to decide if it should also > query wallclock (via System.currentTimeMillis). > > I see two possible optimizations here: > > If the "Record request start time" option is set, the nanos value > can be read from the exchange.getRequestStartTime and does not need > another query. (Alternatively you can switch the record option off > and make DateHandler write to exchange.setRequestStartTime() to make > the syscall count: the additional time is > available without specifying the RECORD option). > > > The alternative optimization is about not using the nanos clock for > determining if cached value is stale but directly requesting the > wallclock millis. For one, I think the latency of nanoTime is not much > better (on some systems worse) than System.currentTime (after all, it > is an hotspot intrinsic) and every second both clocks would be asked > (multiple times its a race). > > When having the current millis value, you could also check > if actually the next second has started (and avoid the rouding problem > with "nanos + 1000000000". > > (And again, if the wallclock time is determined this way, it would make > sense to add it as a field on exchange?) > > > The code+cache is BTW in two places: > > io.undertow.util.DateUtils.addDateHeaderIfRequired(HttpServerExchange) > io.undertow.server.handlers.DateHandler.handleRequest(HttpServerExchange) > > BTW: I think the documentation should mention this. Here are some > things which should be included (somewhere): > > "If you do not add the DateHandler Undertow might still add a Date: > header if response does not have one and the ALWAYS_SET_DATE > Header option is TRUE or missing. Using "ALWAYS_SET_DATE" is prefered, > as it will use the latest possible time before the response entity is > generated. The name of the option might be missleading, it does not > ansure the header is always overwritten, it only ensures there is one > set if there was not produced by the handlers." > > > Once the above options are discussed and decided I can provide patches > for the various doc locations. > > Bernd > > PS: I participated in an experiment* from Aleksey (of JMH fame) and had > a few strange results where currentTime had high latency, on the > other hand there are cases where nanoTime has high latency as > well (see > http://shipilev.net/blog/2014/nanotrusting-nanotime/). I think overall > typical numbers show comparable latencies for both (<20ns). I asked > him, if he can share his experiences. > > * https://github.com/shipilev/timers-bench > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From arjan.tijms at gmail.com Thu Jun 5 10:39:36 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 5 Jun 2014 16:39:36 +0200 Subject: [undertow-dev] Adding setResponseCookies method to HttpServerExchange? Message-ID: Hi, I'm trying to intercept the way that cookies are being written in Undertow. The idea is to do something like can be done with a cookie rewrite rule in Apache (like e.g. add or replace something to the domain attribute of each and every cookie being written). After some hacking on the Undertow code it became clear that HttpServerExchange#setResonseCookie is the central place where cookies arrive. However, HttpServerExchange is a final class, so can't (easily) be wrapped. If HttpServerExchange only had a setResponseCookies method then handlers could install a special map that does the rewriting, making this a fairly easy task. What do you think? Would it be a good idea to add such a method. or is there an other way to easily do something like this? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140605/3cdcc998/attachment.html From sdouglas at redhat.com Thu Jun 5 13:08:36 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 05 Jun 2014 12:08:36 -0500 Subject: [undertow-dev] Adding setResponseCookies method to HttpServerExchange? In-Reply-To: References: Message-ID: <5390A414.1030600@redhat.com> It is not obvious, but you can add a wrapper to io.undertow.server.HttpServerExchange#addResponseWrapper, which will then be called just before the response is written. Even though this primary purpose of this hook is to wrap the response channel, you can also use it to do actions that need to occur just before the response is written, such as modifying cookies. Stuart arjan tijms wrote: > Hi, > > I'm trying to intercept the way that cookies are being written in > Undertow. The idea is to do something like can be done with a cookie > rewrite rule in Apache (like e.g. add or replace something to the domain > attribute of each and every cookie being written). > > After some hacking on the Undertow code it became clear that > HttpServerExchange#setResonseCookie is the central place where cookies > arrive. > > However, HttpServerExchange is a final class, so can't (easily) be > wrapped. If HttpServerExchange only had a setResponseCookies method then > handlers could install a special map that does the rewriting, making > this a fairly easy task. > > What do you think? Would it be a good idea to add such a method. or is > there an other way to easily do something like this? > > Kind regards, > Arjan Tijms > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ecki at zusammenkunft.net Thu Jun 5 15:30:50 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 5 Jun 2014 21:30:50 +0200 Subject: [undertow-dev] Nonce Format of SimpleNonceManager (UTF8)? Message-ID: <20140605213050.00006ad2.ecki@zusammenkunft.net> Hello, I was a bit confused about the use of UTF-8 for converting a number to bytes, but when I looked more closely, it is even more confusing why a decimal number is used and converted here at all. If I understand it right the format of the bytes and the length is unconstrained? I would recommend to use 7 byte array with binary content. But even using Hex or radix=36 strings would reduce the byte[] size without losing entropy. private Nonce createNewNonce(NonceHolder previousNonce) { byte[] prefix = new byte[8]; random.nextBytes(prefix); long timeStamp = System.currentTimeMillis(); byte[] now = Long.toString(timeStamp).getBytes(UTF_8); String nonce = createNonce(prefix, now); -> byte[] now = Long.toString(timeStamp,36).getBytes(StandardCharsets.ISO_8859_1) This makes the byte array shorter and the conversion slightly faster, here are the timing for the various byte encoders on different string formats (base-10,16,32,36) (8threads): Benchmark (number) Mode Samples Score Score error Units n.e.t.l.MyBenchmark.testGetBytesASCII 1401994160926 thrpt 80 4932,143 41,752 ops/ms n.e.t.l.MyBenchmark.testGetBytesASCII 1466d5d2b1e thrpt 80 5270,165 64,343 ops/ms n.e.t.l.MyBenchmark.testGetBytesASCII 18pmlqaou thrpt 80 5521,322 119,856 ops/ms n.e.t.l.MyBenchmark.testGetBytesASCII hw2f4hzy thrpt 80 5929,315 62,562 ops/ms n.e.t.l.MyBenchmark.testGetBytesBase 1401994160926 thrpt 80 154669,919 3845,919 ops/ms n.e.t.l.MyBenchmark.testGetBytesBase 1466d5d2b1e thrpt 80 155290,761 1678,557 ops/ms n.e.t.l.MyBenchmark.testGetBytesBase 18pmlqaou thrpt 80 152989,174 5648,101 ops/ms n.e.t.l.MyBenchmark.testGetBytesBase hw2f4hzy thrpt 80 154360,497 3022,226 ops/ms n.e.t.l.MyBenchmark.testGetBytesDefault 1401994160926 thrpt 80 2319,440 47,902 ops/ms n.e.t.l.MyBenchmark.testGetBytesDefault 1466d5d2b1e thrpt 80 2648,794 29,700 ops/ms n.e.t.l.MyBenchmark.testGetBytesDefault 18pmlqaou thrpt 80 3098,998 36,169 ops/ms n.e.t.l.MyBenchmark.testGetBytesDefault hw2f4hzy thrpt 80 3364,678 33,274 ops/ms n.e.t.l.MyBenchmark.testGetBytesLATIN1 1401994160926 thrpt 80 5202,078 189,594 ops/ms n.e.t.l.MyBenchmark.testGetBytesLATIN1 1466d5d2b1e thrpt 80 6166,294 64,541 ops/ms n.e.t.l.MyBenchmark.testGetBytesLATIN1 18pmlqaou thrpt 80 6677,003 130,301 ops/ms n.e.t.l.MyBenchmark.testGetBytesLATIN1 hw2f4hzy thrpt 80 6293,458 331,745 ops/ms n.e.t.l.MyBenchmark.testGetBytesLower 1401994160926 thrpt 80 10332,605 114,527 ops/ms n.e.t.l.MyBenchmark.testGetBytesLower 1466d5d2b1e thrpt 80 10173,196 120,769 ops/ms n.e.t.l.MyBenchmark.testGetBytesLower 18pmlqaou thrpt 80 10392,109 150,898 ops/ms n.e.t.l.MyBenchmark.testGetBytesLower hw2f4hzy thrpt 80 10584,135 140,522 ops/ms n.e.t.l.MyBenchmark.testGetBytesUTF8 1401994160926 thrpt 80 4998,594 115,126 ops/ms n.e.t.l.MyBenchmark.testGetBytesUTF8 1466d5d2b1e thrpt 80 5184,154 72,303 ops/ms n.e.t.l.MyBenchmark.testGetBytesUTF8 18pmlqaou thrpt 80 5395,096 98,476 ops/ms n.e.t.l.MyBenchmark.testGetBytesUTF8 hw2f4hzy thrpt 80 5212,183 142,887 ops/ms (Lower=loop over char array and use lower byte) However I wonder if longToLower7Bytes(now) would be even more efficient? Both changes needs to be reflected in verifyUnknownNonce() as well. This would benefit from a byte nonce as well, as you could for example not anymore trigger NumberFormatException with invalid nonces. Want me to provide a binary version? How would the compatibility be handled? (Using base10+ASCII is compatible, all other changes not). The native version minimizes the GC load as well: Benchmark (number) Mode Samples Score Score error Units n.e.t.l.MyBenchmark.testGetBytesNative 1401994160926 thrpt 80 31669,314 260,181 ops/ms n.e.t.l.MyBenchmark.testGetBytesString 1401994160926 thrpt 80 2621,683 38,270 ops/ms @GenerateMicroBenchmark public byte[] testGetBytesNative() { byte[] res = new byte[8]; long num = number; for(int i=7;i>=0;i--) { res[i] = (byte)(num & 255); num >>= 8; } return res; } @GenerateMicroBenchmark public byte[] testGetBytesString() { return Long.toString(number).getBytes(StandardCharsets.ISO_8859_1); } Gruss Bernd From arjan.tijms at gmail.com Thu Jun 5 16:23:40 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 5 Jun 2014 22:23:40 +0200 Subject: [undertow-dev] Adding setResponseCookies method to HttpServerExchange? In-Reply-To: <5390A414.1030600@redhat.com> References: <5390A414.1030600@redhat.com> Message-ID: On Thu, Jun 5, 2014 at 7:08 PM, Stuart Douglas wrote: > It is not obvious, but you can add a wrapper to io.undertow.server. > HttpServerExchange#addResponseWrapper, which will then be called just > before the response is written. > Woh, that's indeed not entirely obvious! ;) I guess I'll just have to return factory.create(); then, and right before that iterate over the cookies and change their value. Well, I'll try it. Thanks! I currently solved the issue by setting the responseCookies instance variable of HttpServerExchange anyway by using reflection, but that's of course not so nice. Is there any reason there's isn't a setter? Lot's of other things are directly mutable it seems, like the relativePath and such (which is great for handlers that need to do request rewriting). Kind regards, Arjan > > Even though this primary purpose of this hook is to wrap the response > channel, you can also use it to do actions that need to occur just before > the response is written, such as modifying cookies. > > Stuart > > arjan tijms wrote: > >> Hi, >> >> I'm trying to intercept the way that cookies are being written in >> Undertow. The idea is to do something like can be done with a cookie >> rewrite rule in Apache (like e.g. add or replace something to the domain >> attribute of each and every cookie being written). >> >> After some hacking on the Undertow code it became clear that >> HttpServerExchange#setResonseCookie is the central place where cookies >> arrive. >> >> However, HttpServerExchange is a final class, so can't (easily) be >> wrapped. If HttpServerExchange only had a setResponseCookies method then >> handlers could install a special map that does the rewriting, making >> this a fairly easy task. >> >> What do you think? Would it be a good idea to add such a method. or is >> there an other way to easily do something like this? >> >> Kind regards, >> Arjan Tijms >> >> _______________________________________________ >> 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/20140605/a2670728/attachment.html From arjan.tijms at gmail.com Thu Jun 5 17:07:52 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 5 Jun 2014 23:07:52 +0200 Subject: [undertow-dev] Adding setResponseCookies method to HttpServerExchange? In-Reply-To: <5390D53E.7050009@redhat.com> References: <5390A414.1030600@redhat.com> <5390D53E.7050009@redhat.com> Message-ID: On Thu, Jun 5, 2014 at 10:38 PM, Stuart Douglas wrote: > > I could add some other interface+method that makes it more obvious, > although there would be a very slight performance impact as it means an > extra allocation (for the adaptor to go from the new interface to the > wrapper). Hmmm, it may not be worth it then especially since this is perhaps not about such a major use case. Some extra documentation somewhere that this would be the place to do "pre response write" operations would surely help. The map itself is directly mutable, is there any reason why you would need >> a whole new map vs just clearing the existing one? >> > To be absolutely sure that nothing else can possibly see the unmodified cookie. As an external user I don't know which code all over the place does a call to any of the getResponseCookies methods before I have had a chance to that do clearing or replacing/modifying. The new map I now set is a sub class of some map that modifies the cookie immediately in its put() method. Of course what I conceptually actually would like to do is wrap HttpServerExchange so that I could directly intercept its setResponseCookie method. Since that is rather hard with the current setup (HttpServerExchange is a final class and a huge one at that) the ability to set your own specialized map type seems to be the next best thing for this use case. Kind regards, Arjan > > Stuart > > >> Kind regards, >> Arjan >> >> >> Even though this primary purpose of this hook is to wrap the >> response channel, you can also use it to do actions that need to >> occur just before the response is written, such as modifying cookies. >> >> Stuart >> >> arjan tijms wrote: >> >> Hi, >> >> I'm trying to intercept the way that cookies are being written in >> Undertow. The idea is to do something like can be done with a >> cookie >> rewrite rule in Apache (like e.g. add or replace something to >> the domain >> attribute of each and every cookie being written). >> >> After some hacking on the Undertow code it became clear that >> HttpServerExchange#__setResonseCookie is the central place where >> >> cookies >> arrive. >> >> However, HttpServerExchange is a final class, so can't (easily) be >> wrapped. If HttpServerExchange only had a setResponseCookies >> method then >> handlers could install a special map that does the rewriting, >> making >> this a fairly easy task. >> >> What do you think? Would it be a good idea to add such a method. >> or is >> there an other way to easily do something like this? >> >> Kind regards, >> Arjan Tijms >> >> _________________________________________________ >> 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/20140605/f4b1677d/attachment.html From jason.greene at redhat.com Thu Jun 5 17:49:19 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 5 Jun 2014 16:49:19 -0500 Subject: [undertow-dev] JDK6 Support Message-ID: Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu Jun 5 17:49:19 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 5 Jun 2014 16:49:19 -0500 Subject: [undertow-dev] JDK6 Support Message-ID: <4AB82263-069C-4224-BD7D-70A269FBEF4B@redhat.com> Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From darran.lofthouse at jboss.com Fri Jun 6 10:54:51 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 06 Jun 2014 15:54:51 +0100 Subject: [undertow-dev] Nonce Format of SimpleNonceManager (UTF8)? In-Reply-To: <20140605213050.00006ad2.ecki@zusammenkunft.net> References: <20140605213050.00006ad2.ecki@zusammenkunft.net> Message-ID: <5391D63B.3040203@jboss.com> This class does need to be revisted for performance, if you have some optimisations feel free to send over a pull request. Regards, Darran Lofthouse. On 05/06/14 20:30, Bernd Eckenfels wrote: > Hello, > > I was a bit confused about the use of UTF-8 for converting a number to > bytes, but when I looked more closely, it is even more confusing why a > decimal number is used and converted here at all. If I understand it > right the format of the bytes and the length is unconstrained? I would > recommend to use 7 byte array with binary content. But even using Hex > or radix=36 strings would reduce the byte[] size without losing > entropy. > > private Nonce createNewNonce(NonceHolder previousNonce) { > byte[] prefix = new byte[8]; > random.nextBytes(prefix); > long timeStamp = System.currentTimeMillis(); > byte[] now = Long.toString(timeStamp).getBytes(UTF_8); > String nonce = createNonce(prefix, now); > -> > > byte[] now = > Long.toString(timeStamp,36).getBytes(StandardCharsets.ISO_8859_1) > > This makes the byte array shorter and the conversion slightly faster, > here are the timing for the various byte encoders on different string > formats (base-10,16,32,36) (8threads): > > Benchmark (number) Mode Samples Score Score error Units > n.e.t.l.MyBenchmark.testGetBytesASCII 1401994160926 thrpt 80 4932,143 41,752 ops/ms > n.e.t.l.MyBenchmark.testGetBytesASCII 1466d5d2b1e thrpt 80 5270,165 64,343 ops/ms > n.e.t.l.MyBenchmark.testGetBytesASCII 18pmlqaou thrpt 80 5521,322 119,856 ops/ms > n.e.t.l.MyBenchmark.testGetBytesASCII hw2f4hzy thrpt 80 5929,315 62,562 ops/ms > n.e.t.l.MyBenchmark.testGetBytesBase 1401994160926 thrpt 80 154669,919 3845,919 ops/ms > n.e.t.l.MyBenchmark.testGetBytesBase 1466d5d2b1e thrpt 80 155290,761 1678,557 ops/ms > n.e.t.l.MyBenchmark.testGetBytesBase 18pmlqaou thrpt 80 152989,174 5648,101 ops/ms > n.e.t.l.MyBenchmark.testGetBytesBase hw2f4hzy thrpt 80 154360,497 3022,226 ops/ms > n.e.t.l.MyBenchmark.testGetBytesDefault 1401994160926 thrpt 80 2319,440 47,902 ops/ms > n.e.t.l.MyBenchmark.testGetBytesDefault 1466d5d2b1e thrpt 80 2648,794 29,700 ops/ms > n.e.t.l.MyBenchmark.testGetBytesDefault 18pmlqaou thrpt 80 3098,998 36,169 ops/ms > n.e.t.l.MyBenchmark.testGetBytesDefault hw2f4hzy thrpt 80 3364,678 33,274 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLATIN1 1401994160926 thrpt 80 5202,078 189,594 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLATIN1 1466d5d2b1e thrpt 80 6166,294 64,541 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLATIN1 18pmlqaou thrpt 80 6677,003 130,301 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLATIN1 hw2f4hzy thrpt 80 6293,458 331,745 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLower 1401994160926 thrpt 80 10332,605 114,527 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLower 1466d5d2b1e thrpt 80 10173,196 120,769 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLower 18pmlqaou thrpt 80 10392,109 150,898 ops/ms > n.e.t.l.MyBenchmark.testGetBytesLower hw2f4hzy thrpt 80 10584,135 140,522 ops/ms > n.e.t.l.MyBenchmark.testGetBytesUTF8 1401994160926 thrpt 80 4998,594 115,126 ops/ms > n.e.t.l.MyBenchmark.testGetBytesUTF8 1466d5d2b1e thrpt 80 5184,154 72,303 ops/ms > n.e.t.l.MyBenchmark.testGetBytesUTF8 18pmlqaou thrpt 80 5395,096 98,476 ops/ms > n.e.t.l.MyBenchmark.testGetBytesUTF8 hw2f4hzy thrpt 80 5212,183 142,887 ops/ms > > (Lower=loop over char array and use lower byte) > > However I wonder if longToLower7Bytes(now) would be even more efficient? > > Both changes needs to be reflected in verifyUnknownNonce() as well. > This would benefit from a byte nonce as well, as you could for example > not anymore trigger NumberFormatException with invalid nonces. > > Want me to provide a binary version? How would the compatibility be > handled? (Using base10+ASCII is compatible, all other changes not). The native version minimizes the GC load as well: > > Benchmark (number) Mode Samples Score Score error Units > n.e.t.l.MyBenchmark.testGetBytesNative 1401994160926 thrpt 80 31669,314 260,181 ops/ms > n.e.t.l.MyBenchmark.testGetBytesString 1401994160926 thrpt 80 2621,683 38,270 ops/ms > > @GenerateMicroBenchmark > public byte[] testGetBytesNative() { > byte[] res = new byte[8]; > long num = number; > for(int i=7;i>=0;i--) > { > res[i] = (byte)(num & 255); > num >>= 8; > } > return res; > } > > @GenerateMicroBenchmark > public byte[] testGetBytesString() { > return Long.toString(number).getBytes(StandardCharsets.ISO_8859_1); > } > > > Gruss > Bernd > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From ecki at zusammenkunft.net Sat Jun 7 16:54:59 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 7 Jun 2014 22:54:59 +0200 Subject: [undertow-dev] [undertow] Change to using a timer to invalidate the date rather than calling nanoTime each request (07e3b93) In-Reply-To: References: Message-ID: <20140607225459.0000467a.ecki@zusammenkunft.net> Hello Stuart, yes I agree it is a good compromise. I do wonder however if you should use an atomic to set the new value to make sure you schedule only one timer. I could imagine that it creates an avalanch of timers if 2 requests at the same time race to set the next date (and start 2 timers) and then the next expire 2x2 timers, etc. (And I would also move the calculations for mod+togo after setting the new dateString to make the window smaller Gruss Bernd Am Wed, 04 Jun 2014 09:52:18 -0700 schrieb Stuart Douglas : > Stuart Douglas > To: undertow-io/undertow > Cc: Bernd > Subject: Re: [undertow] Change to using a timer to invalidate the > date rather than calling nanoTime each request (07e3b93) Date: Wed, > 04 Jun 2014 09:52:18 -0700 Reply-To: undertow-io/undertow > > > The main issue I had with that is that it will run even if your > server is completely idle, and also that it adds additional lifecycle > complexity into the connectors, as they would need to have their > timers explicitly stopped on teardown. I think this is a good > compromise. > > --- > Reply to this email directly or view it on GitHub: > https://github.com/undertow-io/undertow/commit/07e3b9315c3d87205ef5ac890767c277f29d9068#commitcomment-6555558 From sdouglas at redhat.com Sat Jun 7 17:58:49 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 07 Jun 2014 16:58:49 -0500 Subject: [undertow-dev] [undertow] Change to using a timer to invalidate the date rather than calling nanoTime each request (07e3b93) In-Reply-To: <20140607225459.0000467a.ecki@zusammenkunft.net> References: <20140607225459.0000467a.ecki@zusammenkunft.net> Message-ID: <53938B19.7050205@redhat.com> Bernd Eckenfels wrote: > Hello Stuart, > > yes I agree it is a good compromise. I do wonder however if you should > use an atomic to set the new value to make sure you schedule only one > timer. I could imagine that it creates an avalanch of timers if 2 > requests at the same time race to set the next date (and start 2 > timers) and then the next expire 2x2 timers, etc. Hmm, that is a good point. I think it should be ok, but it does seem safer to do a CAS. I will change it. Stuart > > (And I would also move the calculations for mod+togo after setting the > new dateString to make the window smaller > > Gruss > Bernd > > Am Wed, 04 Jun 2014 > 09:52:18 -0700 schrieb Stuart Douglas: > >> Stuart Douglas >> To: undertow-io/undertow >> Cc: Bernd >> Subject: Re: [undertow] Change to using a timer to invalidate the >> date rather than calling nanoTime each request (07e3b93) Date: Wed, >> 04 Jun 2014 09:52:18 -0700 Reply-To: undertow-io/undertow >> >> >> The main issue I had with that is that it will run even if your >> server is completely idle, and also that it adds additional lifecycle >> complexity into the connectors, as they would need to have their >> timers explicitly stopped on teardown. I think this is a good >> compromise. >> >> --- >> Reply to this email directly or view it on GitHub: >> https://github.com/undertow-io/undertow/commit/07e3b9315c3d87205ef5ac890767c277f29d9068#commitcomment-6555558 > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From ecki at zusammenkunft.net Sat Jun 7 18:10:03 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 8 Jun 2014 00:10:03 +0200 Subject: [undertow-dev] javadoc style Message-ID: <20140608001003.00007dec.ecki@zusammenkunft.net> Hallo, for the following minor JavaDoc pull request I wonder about the paragraph style: https://github.com/ecki/undertow/commit/9fae96a2d43dcd6de0be0755babd9c4620f8410b It seems that most, but not all other Javadocs use a "self closing" XHTML "

", whereas Oracle seems to go the HTML route and javadoclint regards them as error. I have also seen some javadoc comments with empty lines and no

at all. And finally there are some

line

, even for the first line. What is the prefered style? I personally like the html style: * First sentence. *

* More text on its own paragraph. * Can have line breaks which are ignored by Javadoc. *

* Just like this. *

* Linebreaks like these
* should be avoided. In case my

style is the problem which blocks the PR from beeing merged, let me known. Gruss Bernd From sdouglas at redhat.com Tue Jun 10 08:53:15 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 10 Jun 2014 07:53:15 -0500 Subject: [undertow-dev] javadoc style In-Reply-To: <20140608001003.00007dec.ecki@zusammenkunft.net> References: <20140608001003.00007dec.ecki@zusammenkunft.net> Message-ID: <5396FFBB.2000707@redhat.com> To be honest I have not really thought about it, I don't really have a strong preference either way, although it would be better if everything was consistent. The reason why your PR has not been merged yet was because I have been really busy these last few days, nothing to do with the javadoc style :-) Stuart Bernd Eckenfels wrote: > Hallo, > > for the following minor JavaDoc pull request I wonder about the > paragraph style: > > https://github.com/ecki/undertow/commit/9fae96a2d43dcd6de0be0755babd9c4620f8410b > > It seems that most, but not all other Javadocs use a "self closing" > XHTML "

", whereas Oracle seems to go the HTML route and javadoclint > regards them as error. > > I have also seen some javadoc comments with empty lines and no

at > all. And finally there are some

line

, even for the first line. > What is the prefered style? I personally like the html style: > > * First sentence. > *

> * More text on its own paragraph. > * Can have line breaks which are ignored by Javadoc. > *

> * Just like this. > *

> * Linebreaks like these
> * should be avoided. > > In case my

style is the problem which blocks the PR from beeing > merged, let me known. > > Gruss > Bernd > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Jun 11 11:24:34 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 11 Jun 2014 10:24:34 -0500 Subject: [undertow-dev] JDK6 Support In-Reply-To: References: Message-ID: <539874B2.7000004@redhat.com> Given that no one replied we have now moved to JDK7. Stuart Jason Greene wrote: > Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From arjan.tijms at gmail.com Wed Jun 11 12:31:08 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 11 Jun 2014 18:31:08 +0200 Subject: [undertow-dev] HttpServletRequestImpl.authenticate (incorrectly?) closes response upon false outcome Message-ID: Hi, When an authentication mechanism (e.g. a JASPIC SAM) did not actually authenticate following a call to HttpServletRequest#authenticate, Undertow closes the stream. This happens in io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletResponse) via the following code fragment: if (sc.authenticate()) { ... } else { // Not authenticated and response already sent. HttpServletResponseImpl responseImpl = exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY).getOriginalResponse(); responseImpl.closeStreamAndWriter(); return false; } I'm not 100% sure why it closes the response stream (or writer) here. The Javadoc for HttpServletRequest#authenticate doesn't say this happens and it's not in the Servlet spec either. Most importantly perhaps, it's not what JBoss AS 7/EAP 6 does. I don't think any other server actually does this (but have to investigate to be sure). It looks like Undertow assumes that the authentication mechanism always sets all headers and commits the response, but the contract as expressed in its Javadoc seems weaker: "Use the container login mechanism configured for the ServletContext to authenticate the user making this request. This method *may* modify and commit the argument HttpServletResponse." (note the phrasing "may") As with many things in Servlet it's not entirely clear whether for the case that the method returns "false" the response "must" have been modified and committed, but whether this is the case or not, I don't think it says anywhere that after a call to this method nothing can be written to the response any more. Furthermore, this also doesn't behave very well when a (wrapped) response is passed in, as it closes the original response, not the one passed in. Kind regards, Arjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140611/2468f56f/attachment.html From sdouglas at redhat.com Thu Jun 12 12:50:58 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 12 Jun 2014 11:50:58 -0500 Subject: [undertow-dev] HttpServletRequestImpl.authenticate (incorrectly?) closes response upon false outcome In-Reply-To: References: Message-ID: <5399DA72.9020209@redhat.com> Can you file a JIRA about this? Stuart arjan tijms wrote: > Hi, > > When an authentication mechanism (e.g. a JASPIC SAM) did not actually > authenticate following a call to HttpServletRequest#authenticate, > Undertow closes the stream. > > This happens in > io.undertow.servlet.spec.HttpServletRequestImpl.authenticate(HttpServletResponse) > via the following code fragment: > > if (sc.authenticate()) { > ... > } else { > // Not authenticated and response already sent. > HttpServletResponseImpl responseImpl = > exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY).getOriginalResponse(); > responseImpl.closeStreamAndWriter(); > return false; > } > > I'm not 100% sure why it closes the response stream (or writer) here. > The Javadoc for HttpServletRequest#authenticate doesn't say this happens > and it's not in the Servlet spec either. > > Most importantly perhaps, it's not what JBoss AS 7/EAP 6 does. I don't > think any other server actually does this (but have to investigate to be > sure). > > It looks like Undertow assumes that the authentication mechanism always > sets all headers and commits the response, but the contract as expressed > in its Javadoc seems weaker: > > "Use the container login mechanism configured for the ServletContext to > authenticate the user making this request. > > This method *may* modify and commit the argument HttpServletResponse." > > (note the phrasing "may") > > As with many things in Servlet it's not entirely clear whether for the > case that the method returns "false" the response "must" have been > modified and committed, but whether this is the case or not, I don't > think it says anywhere that after a call to this method nothing can be > written to the response any more. > > Furthermore, this also doesn't behave very well when a (wrapped) > response is passed in, as it closes the original response, not the one > passed in. > > Kind regards, > Arjan > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From Anil.Saldhana at redhat.com Thu Jun 12 13:13:26 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 12 Jun 2014 12:13:26 -0500 Subject: [undertow-dev] JDK6 Support In-Reply-To: <539874B2.7000004@redhat.com> References: <539874B2.7000004@redhat.com> Message-ID: <5399DFB6.3080701@redhat.com> The recent report from JRebel Labs that surveyed developers said that majority of the developers are already on JDK7 with a small footprint for JDK6. On 06/11/2014 10:24 AM, Stuart Douglas wrote: > Given that no one replied we have now moved to JDK7. > > Stuart > > Jason Greene wrote: >> Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> From machielg at gmail.com Wed Jun 18 16:21:44 2014 From: machielg at gmail.com (Machiel Groeneveld) Date: Wed, 18 Jun 2014 22:21:44 +0200 Subject: [undertow-dev] blocking IO Message-ID: I have a question about the blocking IO. In the documentation there is mention of the startBlocking call but not of spinning threads. I'm mentioning this because in the FileResource.java (a supplied handler in undertow) the file seems to be served from a new thread. I currently have this: public void handleRequest(HttpServerExchange exchange) throws Exception { if (exchange.isInIoThread()) { exchange.dispatch(this); return; } exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); exchange.startBlocking(); OutputStream out = exchange.getOutputStream(); writeToStream(out); //query database and write rows to out exchange.endExchange(); } is this the way to correctly write a chunked http response? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140618/aa9a181f/attachment-0001.html From sdouglas at redhat.com Fri Jun 20 09:04:23 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 20 Jun 2014 09:04:23 -0400 Subject: [undertow-dev] blocking IO In-Reply-To: References: Message-ID: <53A43157.8060105@redhat.com> Machiel Groeneveld wrote: > I have a question about the blocking IO. In the documentation there is > mention of the startBlocking call but not of spinning threads. I'm > mentioning this because in the FileResource.java (a supplied handler in > undertow) the file seems to be served from a new thread. The file is served from a new thread as reading the file from disk can block. > > I currently have this: > > public void handleRequest(HttpServerExchange exchange) throws Exception { > > if (exchange.isInIoThread()) { > > exchange.dispatch(this); > > return; > > } > > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); > > exchange.startBlocking(); > > OutputStream out = exchange.getOutputStream(); > > writeToStream(out); //query database and write rows to out > > exchange.endExchange(); > > } This looks fine, but there is no guarantee that the response will be chunked. The OutputStream has a buffer, so if the response is smaller than the buffer then it will set a content-length header, otherwise it will use chunked encoding. If you want to force chunked encoded you can just call flush() on the stream or set the Transfer-Encoding header, although in general fixed length will perform better. Stuart > > > is this the way to correctly write a chunked http response? > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From v64500 at gmail.com Thu Jun 19 23:57:33 2014 From: v64500 at gmail.com (junyi qin) Date: Fri, 20 Jun 2014 11:57:33 +0800 Subject: [undertow-dev] So many connection reset by peer exception and socket leak Message-ID: [XNIO-1 I/O-7] DEBUG io.undertow.request.io - Error reading request java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[na:1.7.0_60] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60] at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.7.0_60] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) ~[na:1.7.0_60] at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:280) [echo-1.0.5.jar:na] at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) ~[echo-1.0.5.jar:na] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:113) ~[echo-1.0.5.jar:na] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91) ~[echo-1.0.5.jar:na] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45) ~[echo-1.0.5.jar:na] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) ~[echo-1.0.5.jar:na] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [echo-1.0.5.jar:na] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [echo-1.0.5.jar:na] at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) [echo-1.0.5.jar:na] tcp state: TIME_WAIT 1 CLOSE_WAIT 8 ESTABLISHED 26774 SYN_RECV 6 LAST_ACK 37 Any advice is welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140620/bd7324ed/attachment.html From arjan.tijms at gmail.com Mon Jun 23 09:16:05 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 23 Jun 2014 15:16:05 +0200 Subject: [undertow-dev] JSESSIONID cookie path empty for root deployments Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140623/026ec527/attachment.html From tomaz.cerar at gmail.com Tue Jun 24 06:14:48 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 24 Jun 2014 12:14:48 +0200 Subject: [undertow-dev] JSESSIONID cookie path empty for root deployments In-Reply-To: References: Message-ID: Hi, 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? -- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140624/1fc0bae0/attachment.html From goldsmith.tee at gmail.com Wed Jun 25 17:56:53 2014 From: goldsmith.tee at gmail.com (Tom Goldsmith) Date: Wed, 25 Jun 2014 17:56:53 -0400 Subject: [undertow-dev] FixedLengthUnderflowException and TruncatedResponseException Message-ID: I am using undertow through immutant [org.immutant/immutant "2.x.incremental.148"] and am receiving the following exceptions: *17:27:47.670 [XNIO-2 task-4] DEBUG io.undertow.request.io - UT005013: An IOException occurred* *org.xnio.channels.FixedLengthUnderflowException: 16095 bytes remaining* * at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:204) ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) ~[xnio-api-3.2.0.Final.jar:3.2.0.Final]* * at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:60) ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1476) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1465) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.Connectors.executeRootHandler(Connectors.java:184) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_05]* * at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_05]* * at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]* *17:27:49.912 [XNIO-2 task-6] DEBUG io.undertow.request.io - UT005013: An IOException occurred* *io.undertow.server.TruncatedResponseException: null* * at io.undertow.server.protocol.http.HttpResponseConduit.truncateWrites(HttpResponseConduit.java:665) ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:206) ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) ~[xnio-api-3.2.0.Final.jar:3.2.0.Final]* * at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:60) ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1476) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1465) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at immutant.web.undertow$handle_request.invoke(undertow.clj:123) [na:na]* * at immutant.web.undertow$create_http_handler$reify__1051.handleRequest(undertow.clj:130) [na:na]* * at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.7.Final.jar:1.0.7.Final]* * at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_05]* * at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_05]* * at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]* I am making a GET request using Google's xhrio library, and the request works fine when I use a service such as Postman. However, when I make several simultaneous GET requests in javascript, undertow throws these exceptions and returns an empty response (net::ERR_EMPTY_RESPONSE in chrome). I'm wondering what might be causing these issues, and if there are certain HTTP headers I might be missing or need to remove from my requests. It looks like the requests are all getting cancelled when another request is received on the same channel, but it must be possible to fire multiple asynchronous requests so I must be missing something. Thanks! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140625/eabd99d0/attachment-0001.html From sdouglas at redhat.com Thu Jun 26 12:51:48 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 26 Jun 2014 12:51:48 -0400 Subject: [undertow-dev] FixedLengthUnderflowException and TruncatedResponseException In-Reply-To: References: Message-ID: <53AC4FA4.5030602@redhat.com> This exception is thrown if you have set a Content-Length header, and then you don't write out enough data. If this happens the connection is broken, as the client will be expecting data that will never arrive, and as a result Undertow will kill the connection. This sounds like an application problem. Stuart Tom Goldsmith wrote: > I am using undertow through immutant [org.immutant/immutant > "2.x.incremental.148"] and am receiving the following exceptions: > > *17:27:47.670 [XNIO-2 task-4] DEBUG io.undertow.request.io > - UT005013: An IOException occurred* > *org.xnio.channels.FixedLengthUnderflowException: 16095 bytes remaining* > *at > io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:204) > ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) > ~[xnio-api-3.2.0.Final.jar:3.2.0.Final]* > *at > io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:60) > ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1476) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1465) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:184) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_05]* > *at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_05]* > *at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]* > * > * > *17:27:49.912 [XNIO-2 task-6] DEBUG io.undertow.request.io > - UT005013: An IOException occurred* > *io.undertow.server.TruncatedResponseException: null* > *at > io.undertow.server.protocol.http.HttpResponseConduit.truncateWrites(HttpResponseConduit.java:665) > ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:206) > ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178) > ~[xnio-api-3.2.0.Final.jar:3.2.0.Final]* > *at > io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:60) > ~[undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1476) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1465) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at immutant.web.undertow$handle_request.invoke(undertow.clj:123) [na:na]* > *at > immutant.web.undertow$create_http_handler$reify__1051.handleRequest(undertow.clj:130) > [na:na]* > *at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > [undertow-core-1.0.7.Final.jar:1.0.7.Final]* > *at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [na:1.8.0_05]* > *at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [na:1.8.0_05]* > *at java.lang.Thread.run(Thread.java:745) [na:1.8.0_05]* > > I am making a GET request using Google's xhrio library, and the request > works fine when I use a service such as Postman. However, when I make > several simultaneous GET requests in javascript, undertow throws these > exceptions and returns an empty response (net::ERR_EMPTY_RESPONSEin chrome). > > I'm wondering what might be causing these issues, and if there are > certain HTTP headers I might be missing or need to remove from my > requests. It looks like the requests are all getting cancelled when > another request is received on the same channel, but it must be possible > to fire multiple asynchronous requests so I must be missing something. > > Thanks! > Tom > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From dariusz.borowski at stylight.com Fri Jun 27 11:03:49 2014 From: dariusz.borowski at stylight.com (Dariusz Borowski) Date: Fri, 27 Jun 2014 17:03:49 +0200 Subject: [undertow-dev] Rewrite with parameters in undertow Message-ID: Hi guys, I'm struggling getting this working. I need to implement rewrite rules in my application. It's somehow working. What I do have, is: undertow-handlers.conf under /WEB-INF/ trying to do simple rule: regex['^/Women/$'] -> rewrite['/Gender.action'] path-template['/Gender.action'] -> set[attribute='%{q,gender}', value='women'] regex['^/Men/$'] -> rewrite['/Gender.action'] path-template['/Gender.action'] -> set[attribute='%{q,gender}', value='men'] In both cases it should hit my "Gender.action", but with a different parameter! It always applies to the last set path-template and the gender is always: "men".... How can I pass different parameters to the same Action? Thanks! -- Dariusz Borowski STYLIGHT +49 (0) 89 - 1222 895 - 0 +49 (0) 89 - 1222 895 - 48 dariusz.borowski at stylight.com http://www.stylight.com/ Join us on Facebook: http://www.facebook.com/stylight Follow us on Twitter: http://www.twitter.com/stylight Follow us on Instagram: http://instagram.com/stylight -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140627/c26eb03a/attachment.html From sdouglas at redhat.com Sat Jun 28 00:36:39 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 28 Jun 2014 00:36:39 -0400 Subject: [undertow-dev] Rewrite with parameters in undertow In-Reply-To: References: Message-ID: <53AE4657.2010002@redhat.com> Dariusz Borowski wrote: The rules are applied one after the other, and it does not stop if one is matched, so both path-template['/Gender.action'] elements match, and the last one is the one that takes effect. regex['^/Women/$'] -> set[attribute='%{q,gender}', value='women'] regex['^/Women/$'] -> rewrite['/Gender.action'] regex['^/Men/$'] -> set[attribute='%{q,gender}', value='men'] regex['^/Men/$'] -> rewrite['/Gender.action'] Really you don't even need regex as it is just a literal match, and can just use path['/Men/'] which is more efficient. I have never been 100% happy with this syntax, and I do have plans to expand it in future, so you will be able to do something like: path[/Men] -> { set['%{q,gender}', 'women'] rewrite['/Gender.action'] } But I am still thinking about how the final syntax will turn out. Stuart > Hi guys, > > I'm struggling getting this working. I need to implement rewrite rules > in my application. It's somehow working. What I do have, is: > > undertow-handlers.conf under /WEB-INF/ > > > trying to do simple rule: > > > regex['^/Women/$'] -> rewrite['/Gender.action'] > path-template['/Gender.action'] -> set[attribute='%{q,gender}', > value='women'] > > > > In both cases it should hit my "Gender.action", but with a different > parameter! > > It always applies to the last set path-template and the gender is > always: "men".... > > How can I pass different parameters to the same Action? > > Thanks! > > > > > > -- > > Dariusz Borowski > > STYLIGHT > > +49 (0) 89 - 1222 895 - 0 > +49 (0) 89 - 1222 895 - 48 > dariusz.borowski at stylight.com > http://www.stylight.com/ > > > Join us on Facebook: http://www.facebook.com/stylight > Follow us on Twitter: http://www.twitter.com/stylight > Follow us on Instagram: http://instagram.com/stylight > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bill at dartalley.com Sat Jun 28 02:02:43 2014 From: bill at dartalley.com (Bill O'Neil) Date: Sat, 28 Jun 2014 02:02:43 -0400 Subject: [undertow-dev] Issues running unit tests in eclipse Message-ID: I am trying to run the unit tests in eclipse and get the following error. Do I need to turn on an annotation processor? java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ClassNotFoundException: io.undertow.server.protocol.http.HttpRequestParser$$generated at io.undertow.testutils.DefaultServer.runInternal(DefaultServer.java:328) at io.undertow.testutils.DefaultServer.run(DefaultServer.java:245) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run( TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( RemoteTestRunner.java:192) Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: io.undertow.server.protocol.http.HttpRequestParser$$generated at io.undertow.server.protocol.http.HttpRequestParser.instance( HttpRequestParser.java:190) at io.undertow.server.protocol.http.HttpOpenListener.( HttpOpenListener.java:63) at io.undertow.testutils.DefaultServer.runInternal(DefaultServer.java:307) ... 7 more Caused by: java.lang.ClassNotFoundException: io.undertow.server.protocol.http.HttpRequestParser$$generated at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at io.undertow.server.protocol.http.HttpRequestParser.instance( HttpRequestParser.java:185) ... 9 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140628/208455c1/attachment.html From bill at dartalley.com Sat Jun 28 02:43:40 2014 From: bill at dartalley.com (Bill O'Neil) Date: Sat, 28 Jun 2014 02:43:40 -0400 Subject: [undertow-dev] Issues running unit tests in eclipse In-Reply-To: References: Message-ID: Switching to java 7 fixed the issue. When running the tests with maven from the command line I would see an ssl related error. After some quick googling I realized this was related to me running java 8. Eclipse gave a less clear error. java.lang.NoSuchMethodError: sun.security.ssl.HandshakeHash.(ZZLjava/util/Set;) On Sat, Jun 28, 2014 at 2:02 AM, Bill O'Neil wrote: > I am trying to run the unit tests in eclipse and get the following error. > Do I need to turn on an annotation processor? > > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.ClassNotFoundException: > io.undertow.server.protocol.http.HttpRequestParser$$generated > > at io.undertow.testutils.DefaultServer.runInternal(DefaultServer.java:328) > > at io.undertow.testutils.DefaultServer.run(DefaultServer.java:245) > > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( > JUnit4TestReference.java:50) > > at org.eclipse.jdt.internal.junit.runner.TestExecution.run( > TestExecution.java:38) > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( > RemoteTestRunner.java:459) > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( > RemoteTestRunner.java:675) > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( > RemoteTestRunner.java:382) > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( > RemoteTestRunner.java:192) > > Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: > io.undertow.server.protocol.http.HttpRequestParser$$generated > > at io.undertow.server.protocol.http.HttpRequestParser.instance( > HttpRequestParser.java:190) > > at io.undertow.server.protocol.http.HttpOpenListener.( > HttpOpenListener.java:63) > > at io.undertow.testutils.DefaultServer.runInternal(DefaultServer.java:307) > > ... 7 more > > Caused by: java.lang.ClassNotFoundException: > io.undertow.server.protocol.http.HttpRequestParser$$generated > > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > > at io.undertow.server.protocol.http.HttpRequestParser.instance( > HttpRequestParser.java:185) > > ... 9 more > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140628/7eae93db/attachment-0001.html From dimaki at gmx.de Sun Jun 29 07:26:33 2014 From: dimaki at gmx.de (Dino Tsoumakis) Date: Sun, 29 Jun 2014 13:26:33 +0200 Subject: [undertow-dev] Port Reduction/Unification SSL/HTTP/MQTT Message-ID: Hello, I?m currently migrating Glassfish-based Products to Widfly 8.1. I used Grizzly-based Port Unification to tunnel MQTT-Protocol over SSL on Glassfish. Now I switched to Wildfly and I would love to switch the port unification from grizzly to undertow, too. I know there are similar concepts for doing this, but I do not know which way is the best using undertow. On Glassfish I simply start an embedded grizzly for SSL and implemented special handlers for splitting HTTP protocol from MQTT. I know it is possible to use undertow?s builder API, add a listener and write a custom handler for it. Is this the preferred way to do that? Or is there a possibility to simply register a custom handler implementation without starting a separat embedded server. I have a complete wildfly instance running anyway. That way it would be easier to use the already configured SSL stuff (like configured realm, etc). BTW: It would be possible to contribute this code. Best regards Dino From sdouglas at redhat.com Sun Jun 29 16:52:24 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 29 Jun 2014 16:52:24 -0400 Subject: [undertow-dev] Port Reduction/Unification SSL/HTTP/MQTT In-Reply-To: References: Message-ID: <53B07C88.2080409@redhat.com> There are a few approaches here, you can either use a ServletExtension (http://undertow.io/documentation/servlet/servlet-extensions.html) to register a handler that can do this. Servlet 3.1 also now provides a standard way to do this using the upgrade listener that should be portable amongst all servlet 3.1 containers. Stuart Dino Tsoumakis wrote: > Hello, > > I?m currently migrating Glassfish-based Products to Widfly 8.1. I used > Grizzly-based Port Unification to tunnel MQTT-Protocol over SSL on > Glassfish. Now I switched to Wildfly and I would love to switch the > port unification from grizzly to undertow, too. I know there are > similar concepts for doing this, but I do not know which way is the > best using undertow. On Glassfish I simply start an embedded grizzly > for SSL and implemented special handlers for splitting HTTP protocol > from MQTT. I know it is possible to use undertow?s builder API, add a > listener and write a custom handler for it. Is this the preferred way > to do that? Or is there a possibility to simply register a custom > handler implementation without starting a separat embedded server. I > have a complete wildfly instance running anyway. That way it would be > easier to use the already configured SSL stuff (like configured realm, > etc). > BTW: It would be possible to contribute this code. > > Best regards > Dino > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From jbartece at redhat.com Mon Jun 30 07:31:59 2014 From: jbartece at redhat.com (Jakub Bartecek) Date: Mon, 30 Jun 2014 13:31:59 +0200 Subject: [undertow-dev] JDK6 Support Message-ID: <53B14AAF.9020209@redhat.com> I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6? Jakub Bartecek > The recent report from JRebel Labs that surveyed developers said that > majority of the developers are > already on JDK7 with a small footprint for JDK6. > > >> On 06/11/2014 10:24 AM, Stuart Douglas wrote: >>/ Given that no one replied we have now moved to JDK7. />>/ />/> Stuart />>/ />>/> Jason Greene wrote: />>>/ Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. />>>/ />>>/ -- />>>/ 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/20140630/ce371ee2/attachment.html From tomaz.cerar at gmail.com Mon Jun 30 07:50:12 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 30 Jun 2014 13:50:12 +0200 Subject: [undertow-dev] JDK6 Support In-Reply-To: <53B14AAF.9020209@redhat.com> References: <53B14AAF.9020209@redhat.com> Message-ID: I think you missed that train for a bit... In any case, 1.0.x branch is and will stay on JDK6. Only master is on JDK7 now. I think that in near future also Jenkins will move to require JDK7 at that time you will be able to upgrade to Undertow 1.1+. -- tomaz On Mon, Jun 30, 2014 at 1:31 PM, Jakub Bartecek wrote: > I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just > considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6? > > Jakub Bartecek > > > The recent report from JRebel Labs that surveyed developers said that > > majority of the developers are > > already on JDK7 with a small footprint for JDK6. > > > > > >> On 06/11/2014 10:24 AM, Stuart Douglas wrote: > >>* Given that no one replied we have now moved to JDK7. > *>>>*> Stuart > *>>>>*> Jason Greene wrote: > *>>>* Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. > *>>>>>>* -- > *>>>* Jason T. Greene > *>>>* WildFly Lead / JBoss EAP Platform Architect > *>>>* JBoss, a division of Red Hat > *>>>>>> > > > _______________________________________________ > 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/20140630/4e9be75c/attachment.html From vtunka at redhat.com Mon Jun 30 08:07:46 2014 From: vtunka at redhat.com (Vaclav Tunka) Date: Mon, 30 Jun 2014 14:07:46 +0200 Subject: [undertow-dev] JDK6 Support In-Reply-To: References: <53B14AAF.9020209@redhat.com> Message-ID: <53B15312.8010505@redhat.com> Hi Tomaz, I think Jenkins will stay with JDK6 for some time. Jenkins is currently on 1.570 release and I think the compatibility could be broken maybe in Jenkins 2.x, which could take quite a while. Jenkins community is taking stability & contract on runtimes quite seriously. Undertow 1.0.x could be maybe used as tech preview in Jenkins alongside Jetty, but then it misses the point in my opinion. Jetty has advantage compared to Undertow for Jenkins users, that it supports SPDY, which is yet to be supported in Undertow. Anyway the time to react was quite small for this decision in my opinion (~4 days including TZ differences). Cheers, Vaclav On 06/30/2014 01:50 PM, Toma? Cerar wrote: > I think you missed that train for a bit... > > In any case, 1.0.x branch is and will stay on JDK6. > Only master is on JDK7 now. > I think that in near future also Jenkins will move to require JDK7 at > that time you will be able to upgrade to Undertow 1.1+. > > -- > tomaz > > > On Mon, Jun 30, 2014 at 1:31 PM, Jakub Bartecek > wrote: > > I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just > considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6? > > Jakub Bartecek > > > The recent report from JRebel Labs that surveyed developers said that > > majority of the developers are > > already on JDK7 with a small footprint for JDK6. > > > > > >> On 06/11/2014 10:24 AM, Stuart Douglas wrote: > >>/ Given that no one replied we have now moved to JDK7. > />>/ > />/> Stuart > />>/ > />>/> Jason Greene wrote: > />>>/ Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. > />>>/ > />>>/ -- > />>>/ Jason T. Greene > />>>/ WildFly Lead / JBoss EAP Platform Architect > />>>/ JBoss, a division of Red Hat > />>>/ > />>> > > > _______________________________________________ > 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 > -- Vaclav Tunka Enterprise Application Platforms JBoss by Red Hat From jason.greene at redhat.com Mon Jun 30 11:59:54 2014 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 30 Jun 2014 10:59:54 -0500 Subject: [undertow-dev] JDK6 Support In-Reply-To: <53B15312.8010505@redhat.com> References: <53B14AAF.9020209@redhat.com> <53B15312.8010505@redhat.com> Message-ID: <5C9966FF-77DD-4327-8F18-8FF1FFE89172@redhat.com> Does the Jetty support only use the Core API (and not servlet)? Part of the reason we dropped JDK6 support is because supporting it with servlet 3.1 would have required more work that was hard to justify. 3.1 is tied to JDK7 APIs, so we would have create a special hacked version for it to work. On Jun 30, 2014, at 7:07 AM, Vaclav Tunka wrote: > Hi Tomaz, > > I think Jenkins will stay with JDK6 for some time. Jenkins is currently > on 1.570 release and I think the compatibility could be broken maybe in > Jenkins 2.x, which could take quite a while. Jenkins community is taking > stability & contract on runtimes quite seriously. > > Undertow 1.0.x could be maybe used as tech preview in Jenkins alongside > Jetty, but then it misses the point in my opinion. > > Jetty has advantage compared to Undertow for Jenkins users, that it > supports SPDY, which is yet to be supported in Undertow. > > Anyway the time to react was quite small for this decision in my opinion > (~4 days including TZ differences). > > Cheers, > Vaclav > > On 06/30/2014 01:50 PM, Toma? Cerar wrote: >> I think you missed that train for a bit... >> >> In any case, 1.0.x branch is and will stay on JDK6. >> Only master is on JDK7 now. >> I think that in near future also Jenkins will move to require JDK7 at >> that time you will be able to upgrade to Undertow 1.1+. >> >> -- >> tomaz >> >> >> On Mon, Jun 30, 2014 at 1:31 PM, Jakub Bartecek > > wrote: >> >> I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just >> considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6? >> >> Jakub Bartecek >> >>> The recent report from JRebel Labs that surveyed developers said that >>> majority of the developers are >>> already on JDK7 with a small footprint for JDK6. >>> >>> >>>> On 06/11/2014 10:24 AM, Stuart Douglas wrote: >>>> / Given that no one replied we have now moved to JDK7. >> />>/ >> />/> Stuart >> />>/ >> />>/> Jason Greene wrote: >> />>>/ Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. >> />>>/ >> />>>/ -- >> />>>/ Jason T. Greene >> />>>/ WildFly Lead / JBoss EAP Platform Architect >> />>>/ JBoss, a division of Red Hat >> />>>/ >> />>> >> >> >> _______________________________________________ >> 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 >> > > -- > Vaclav Tunka > Enterprise Application Platforms > JBoss by Red Hat > _______________________________________________ > 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