From stuart.w.douglas at gmail.com Wed Jun 1 19:22:00 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 2 Jun 2016 09:22:00 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 Message-ID: Hi All, I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. At the moment there are two main barriers to getting HTTP/2 two work: - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). I am proposing that we do the following to address these issues: - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. Thoughts? Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/35bb0e68/attachment.html From jperkins at redhat.com Wed Jun 1 20:29:03 2016 From: jperkins at redhat.com (James Perkins) Date: Wed, 1 Jun 2016 17:29:03 -0700 Subject: [wildfly-dev] WildFly Plugin Core Project Message-ID: Hello All, I've been asked a few times about creating a WildFly Plugin Core project with some of the utilities from the wildfly-maven-plugin. Since it came up twice today alone I'm wondering if we should have a separate wildfly-plugin-core project. This would be useful if we wanted to have a Gradle or SBT plugin as well. Maybe it's useful for JBoss Tools too. WildFly Arquillian could use it too. The idea would be to separate out the code that creates the deployment operations as well as the code that creates and launches a container process (maybe). Also expose of the helper stuff done to check the status of a sever, get all the server groups of a managed domain, etc. It would probably be fairly small overall. Essentially just some utilities that create some common operations so consumers don't need to know how the operation needs to be constructed. If it sounds reasonable the next step would be to determine if it should be it's own project or just a maven module in the wildfly-maven-plugin. The only reason I'd lean towards it's own project is to keep the release stream separate from the wildfly-maven-plugin. Thoughts? -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160601/778df5c1/attachment.html From jason.greene at redhat.com Wed Jun 1 21:23:43 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 1 Jun 2016 21:23:43 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: You know my opinion on this, but just to share with everyone else, I think these are huge usability improvements and IMO a high priority for 10.1. > On Jun 1, 2016, at 6:22 PM, Stuart Douglas wrote: > > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. > > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. > > Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. > > I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. > > Thoughts? > > Stuart > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mazz at redhat.com Wed Jun 1 22:18:43 2016 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 1 Jun 2016 22:18:43 -0400 (EDT) Subject: [wildfly-dev] WildFly Plugin Core Project In-Reply-To: References: Message-ID: <374944110.1645183.1464833923459.JavaMail.zimbra@redhat.com> I'm one of those in desperate need of this. :) James - if you need help, feel free to enlist me to help code this up. Shouldn't be too hard. For the record, I would like a separate artifact built by a maven module inside wildfly-maven-plugin - all I need is some small third-party library with this functionality and that would fit the bill. For me, I also need at least two enhancements to the org.wildfly.plugin.deployment.Deployment.Deployment API (or more technically, to its Builder which in turn passes to that object's constructor): 1) Rather than passing in a File, I would need to pass in an InputStream to Deployment() constructor 2) I would need to be able to pass in an "enabled" boolean to the Deployment constructor, and in the places where you now hardcode set the ENABLE attribute to "true", it would need to be that value passed to the constructor (thus, allowing the user to deploy something but not have them automatically enabled). --John Mazz ----- Original Message ----- > Hello All, > I've been asked a few times about creating a WildFly Plugin Core project with > some of the utilities from the wildfly-maven-plugin. Since it came up twice > today alone I'm wondering if we should have a separate wildfly-plugin-core > project. > > This would be useful if we wanted to have a Gradle or SBT plugin as well. > Maybe it's useful for JBoss Tools too. WildFly Arquillian could use it too. > > The idea would be to separate out the code that creates the deployment > operations as well as the code that creates and launches a container process > (maybe). Also expose of the helper stuff done to check the status of a > sever, get all the server groups of a managed domain, etc. It would probably > be fairly small overall. Essentially just some utilities that create some > common operations so consumers don't need to know how the operation needs to > be constructed. > > If it sounds reasonable the next step would be to determine if it should be > it's own project or just a maven module in the wildfly-maven-plugin. The > only reason I'd lean towards it's own project is to keep the release stream > separate from the wildfly-maven-plugin. > > Thoughts? > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ehugonne at redhat.com Thu Jun 2 03:28:21 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 2 Jun 2016 09:28:21 +0200 Subject: [wildfly-dev] WildFly Plugin Core Project In-Reply-To: References: Message-ID: <574FE015.5030203@redhat.com> Hi, I think this could also be usefull from any tool (read IDE) point of view too. Emmanuel On 02/06/2016 02:29, James Perkins wrote: > Hello All, > I've been asked a few times about creating a WildFly Plugin Core project with some of the utilities from the wildfly-maven-plugin. Since it > came up twice today alone I'm wondering if we should have a separate wildfly-plugin-core project. > > This would be useful if we wanted to have a Gradle or SBT plugin as well. Maybe it's useful for JBoss Tools too. WildFly Arquillian could > use it too. > > The idea would be to separate out the code that creates the deployment operations as well as the code that creates and launches a container > process (maybe). Also expose of the helper stuff done to check the status of a sever, get all the server groups of a managed domain, etc. It > would probably be fairly small overall. Essentially just some utilities that create some common operations so consumers don't need to know > how the operation needs to be constructed. > > If it sounds reasonable the next step would be to determine if it should be it's own project or just a maven module in the > wildfly-maven-plugin. The only reason I'd lean towards it's own project is to keep the release stream separate from the wildfly-maven-plugin. > > Thoughts? > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/a090aaed/attachment.bin From ehugonne at redhat.com Thu Jun 2 03:30:25 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 2 Jun 2016 09:30:25 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <574FE091.8070505@redhat.com> Hum, What about domain mode, should the self-signed certificate be shared among the domain or one per HC/server ? Emmanuel On 02/06/2016 01:22, Stuart Douglas wrote: > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. > > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies > the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will > stop working (JDK9 has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a > working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed > certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate > the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL > Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so > the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. > > Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a > drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I > don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. > > I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. > > Thoughts? > > Stuart > > > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/27f4954c/attachment.bin From jcosta at redhat.com Thu Jun 2 04:05:27 2016 From: jcosta at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 2 Jun 2016 10:05:27 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <076a0f4a-1e07-d3aa-9346-77382bf5a9c3@redhat.com> On 02.06.2016 01:22, Stuart Douglas wrote: > I think this would be a great usability feature, allowing developers to > get started with HTTPS and HTTP/2 straight away. This sounds absolutely fantastic. We were starting to figure out a way to do this for Hawkular and would be awesome to have this handled in Wildfly instead. - Juca. From hbraun at redhat.com Thu Jun 2 04:26:50 2016 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 2 Jun 2016 10:26:50 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> +1 This would be a great step forward. On a related note: I was looking into gRPC [1] for Swarm the other day, and it seems this would be pre-requisite. Regards, Heiko [1] http://www.grpc.io/ > On 02 Jun 2016, at 01:22, Stuart Douglas wrote: > > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. > > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. > > Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. > > I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. > > Thoughts? > > Stuart > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/91025bfc/attachment.html From stuart.w.douglas at gmail.com Thu Jun 2 06:05:39 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 2 Jun 2016 20:05:39 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> Message-ID: I am not sure how gRPC comes into it? Stuart On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun wrote: > +1 > > This would be a great step forward. > > On a related note: I was looking into gRPC [1] for Swarm the other day, > and it seems this would be pre-requisite. > > > Regards, Heiko > > > [1] http://www.grpc.io/ > > On 02 Jun 2016, at 01:22, Stuart Douglas > wrote: > > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in > Wildfly 10.1. > > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. For > new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it to > your boot class path. This is essentially a hack that modifies the JDK SSL > classes to allow them to support ALPN. A new version is needed for every > JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 > has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include > this in the default config. This would mean that we would have a working > HTTPS connector in the default config, although the first request would be > a bit slow as it would need to generate a new self signed certificate for > localhost. This allows for SSL out of the box, without any impact on > startup time or any need for an installer to generate the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based > hack. I have created some code that parses and modifies the SSL > Server/Client hello messages to add/read APLN information, and I then use > reflection to update the HandshakeHash maintained by the engine so the > engines internal hash state used to generate the Finished frames matches > the data that was actually sent over the wire. > > Yes I am aware that this is a massive hack, however I think it is > preferable to the current boot classpath hack, which has a lot of a > drawbacks. If this ever stops working at some point due to internal JDK > changes the boot classpath hack would still be usable, however I don't > think this is particularly likely, as the part of the JDK that this > modifies seems unlikely to change. > > I think this would be a great usability feature, allowing developers to > get started with HTTPS and HTTP/2 straight away. > > Thoughts? > > Stuart > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/ebdea072/attachment-0001.html From darran.lofthouse at jboss.com Thu Jun 2 06:18:25 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Jun 2016 11:18:25 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> Not a fan of dynamically generated self signed certificates - a recipe for leading users into shooting themselves in the foot. I say that after witnessing myself a user tricking themselves with their own man in the middle attack. Darran. On 02/06/16 00:22, Stuart Douglas wrote: > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in > Wildfly 10.1. > > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. > For new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it > to your boot class path. This is essentially a hack that modifies the > JDK SSL classes to allow them to support ALPN. A new version is needed > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop > working (JDK9 has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include > this in the default config. This would mean that we would have a working > HTTPS connector in the default config, although the first request would > be a bit slow as it would need to generate a new self signed certificate > for localhost. This allows for SSL out of the box, without any impact on > startup time or any need for an installer to generate the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based > hack. I have created some code that parses and modifies the SSL > Server/Client hello messages to add/read APLN information, and I then > use reflection to update the HandshakeHash maintained by the engine so > the engines internal hash state used to generate the Finished frames > matches the data that was actually sent over the wire. > > Yes I am aware that this is a massive hack, however I think it is > preferable to the current boot classpath hack, which has a lot of a > drawbacks. If this ever stops working at some point due to internal JDK > changes the boot classpath hack would still be usable, however I don't > think this is particularly likely, as the part of the JDK that this > modifies seems unlikely to change. > > I think this would be a great usability feature, allowing developers to > get started with HTTPS and HTTP/2 straight away. > > Thoughts? > > Stuart > > > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From stuart.w.douglas at gmail.com Thu Jun 2 06:38:04 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 2 Jun 2016 20:38:04 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> References: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> Message-ID: You are always going to be able to MITM with self signed certs though, dynamically generated or not. Stuart On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse wrote: > Not a fan of dynamically generated self signed certificates - a recipe > for leading users into shooting themselves in the foot. > > I say that after witnessing myself a user tricking themselves with their > own man in the middle attack. > > Darran. > > > On 02/06/16 00:22, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box in > > Wildfly 10.1. > > > > At the moment there are two main barriers to getting HTTP/2 two work: > > > > - You need to set up a HTTPS connector, including generating keys etc. > > For new users this is not as straightforward as it could be. > > - You need to find the correct version of the Jetty ALPN jar and add it > > to your boot class path. This is essentially a hack that modifies the > > JDK SSL classes to allow them to support ALPN. A new version is needed > > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop > > working (JDK9 has support for ALPN so this is not nessesary). > > > > I am proposing that we do the following to address these issues: > > > > - Add support for lazily generated self signed certificates, and include > > this in the default config. This would mean that we would have a working > > HTTPS connector in the default config, although the first request would > > be a bit slow as it would need to generate a new self signed certificate > > for localhost. This allows for SSL out of the box, without any impact on > > startup time or any need for an installer to generate the certificate. > > > > - I have dealt with the ALPN issue in Undertow using a reflection based > > hack. I have created some code that parses and modifies the SSL > > Server/Client hello messages to add/read APLN information, and I then > > use reflection to update the HandshakeHash maintained by the engine so > > the engines internal hash state used to generate the Finished frames > > matches the data that was actually sent over the wire. > > > > Yes I am aware that this is a massive hack, however I think it is > > preferable to the current boot classpath hack, which has a lot of a > > drawbacks. If this ever stops working at some point due to internal JDK > > changes the boot classpath hack would still be usable, however I don't > > think this is particularly likely, as the part of the JDK that this > > modifies seems unlikely to change. > > > > I think this would be a great usability feature, allowing developers to > > get started with HTTPS and HTTP/2 straight away. > > > > Thoughts? > > > > Stuart > > > > > > > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/183c2662/attachment.html From darran.lofthouse at jboss.com Thu Jun 2 07:03:18 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Jun 2016 07:03:18 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> Message-ID: <1045828518.19122410.1464865398479.JavaMail.zimbra@redhat.com> The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains. Probably not the end of the world though, we will still be able to guide them in the future to do it properly. Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11. Darran. ----- Original Message ----- From: "Stuart Douglas" To: "Darran Lofthouse" Cc: wildfly-dev at lists.jboss.org Sent: Thursday, 2 June, 2016 11:38:04 AM Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 You are always going to be able to MITM with self signed certs though, dynamically generated or not. Stuart On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse wrote: > Not a fan of dynamically generated self signed certificates - a recipe > for leading users into shooting themselves in the foot. > > I say that after witnessing myself a user tricking themselves with their > own man in the middle attack. > > Darran. > > > On 02/06/16 00:22, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box in > > Wildfly 10.1. > > > > At the moment there are two main barriers to getting HTTP/2 two work: > > > > - You need to set up a HTTPS connector, including generating keys etc. > > For new users this is not as straightforward as it could be. > > - You need to find the correct version of the Jetty ALPN jar and add it > > to your boot class path. This is essentially a hack that modifies the > > JDK SSL classes to allow them to support ALPN. A new version is needed > > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop > > working (JDK9 has support for ALPN so this is not nessesary). > > > > I am proposing that we do the following to address these issues: > > > > - Add support for lazily generated self signed certificates, and include > > this in the default config. This would mean that we would have a working > > HTTPS connector in the default config, although the first request would > > be a bit slow as it would need to generate a new self signed certificate > > for localhost. This allows for SSL out of the box, without any impact on > > startup time or any need for an installer to generate the certificate. > > > > - I have dealt with the ALPN issue in Undertow using a reflection based > > hack. I have created some code that parses and modifies the SSL > > Server/Client hello messages to add/read APLN information, and I then > > use reflection to update the HandshakeHash maintained by the engine so > > the engines internal hash state used to generate the Finished frames > > matches the data that was actually sent over the wire. > > > > Yes I am aware that this is a massive hack, however I think it is > > preferable to the current boot classpath hack, which has a lot of a > > drawbacks. If this ever stops working at some point due to internal JDK > > changes the boot classpath hack would still be usable, however I don't > > think this is particularly likely, as the part of the JDK that this > > modifies seems unlikely to change. > > > > I think this would be a great usability feature, allowing developers to > > get started with HTTPS and HTTP/2 straight away. > > > > Thoughts? > > > > Stuart > > > > > > > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Thu Jun 2 07:21:15 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 2 Jun 2016 06:21:15 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <575016AB.3070908@redhat.com> On 06/01/2016 06:22 PM, Stuart Douglas wrote: > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box in > Wildfly 10.1. +1 from me. > At the moment there are two main barriers to getting HTTP/2 two work: > > - You need to set up a HTTPS connector, including generating keys etc. > For new users this is not as straightforward as it could be. > - You need to find the correct version of the Jetty ALPN jar and add it > to your boot class path. This is essentially a hack that modifies the > JDK SSL classes to allow them to support ALPN. A new version is needed > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop > working (JDK9 has support for ALPN so this is not nessesary). > > I am proposing that we do the following to address these issues: > > - Add support for lazily generated self signed certificates, and include > this in the default config. This would mean that we would have a working > HTTPS connector in the default config, although the first request would > be a bit slow as it would need to generate a new self signed certificate > for localhost. This allows for SSL out of the box, without any impact on > startup time or any need for an installer to generate the certificate. > > - I have dealt with the ALPN issue in Undertow using a reflection based > hack. I have created some code that parses and modifies the SSL > Server/Client hello messages to add/read APLN information, and I then > use reflection to update the HandshakeHash maintained by the engine so > the engines internal hash state used to generate the Finished frames > matches the data that was actually sent over the wire. Nice. I think this is a pretty decent interim solution (though I think we'll want to verify that this works on IBM too, and maybe come up with a parallel code path for that case; also we'll want to be JDK 9 compatible ASAP so we should detect that too). Yeah it's kind of ugly, but not so much when you compare it against the alternatives of using the boot classpath for the Jetty kludge or writing our own JSSE. -- - DML From hbraun at redhat.com Thu Jun 2 07:44:02 2016 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 2 Jun 2016 13:44:02 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> Message-ID: gRPC requires http/2 > On 02 Jun 2016, at 12:05, Stuart Douglas wrote: > > I am not sure how gRPC comes into it? > > Stuart > > On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun > wrote: > +1 > > This would be a great step forward. > > On a related note: I was looking into gRPC [1] for Swarm the other day, > and it seems this would be pre-requisite. > > > Regards, Heiko > > > [1] http://www.grpc.io/ > >> On 02 Jun 2016, at 01:22, Stuart Douglas > wrote: >> >> Hi All, >> >> I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. >> >> At the moment there are two main barriers to getting HTTP/2 two work: >> >> - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. >> - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). >> >> I am proposing that we do the following to address these issues: >> >> - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. >> >> - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. >> >> Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. >> >> I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. >> >> Thoughts? >> >> Stuart >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/72b23793/attachment-0001.html From stuart.w.douglas at gmail.com Thu Jun 2 07:54:30 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 2 Jun 2016 21:54:30 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> Message-ID: Ah, sorry, I miss read your original email. You can do HTTP/2 at the moment, it is just a bit of a pain to set up. Stuart On Thu, Jun 2, 2016 at 9:44 PM, Heiko Braun wrote: > gRPC requires http/2 > > On 02 Jun 2016, at 12:05, Stuart Douglas > wrote: > > I am not sure how gRPC comes into it? > > Stuart > > On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun wrote: > >> +1 >> >> This would be a great step forward. >> >> On a related note: I was looking into gRPC [1] for Swarm the other day, >> and it seems this would be pre-requisite. >> >> >> Regards, Heiko >> >> >> [1] http://www.grpc.io/ >> >> On 02 Jun 2016, at 01:22, Stuart Douglas >> wrote: >> >> Hi All, >> >> I would like to propose that we add support for HTTP/2 out of the box in >> Wildfly 10.1. >> >> At the moment there are two main barriers to getting HTTP/2 two work: >> >> - You need to set up a HTTPS connector, including generating keys etc. >> For new users this is not as straightforward as it could be. >> - You need to find the correct version of the Jetty ALPN jar and add it >> to your boot class path. This is essentially a hack that modifies the JDK >> SSL classes to allow them to support ALPN. A new version is needed for >> every JDK8 release, so if you ever update the JVM HTTP/2 will stop working >> (JDK9 has support for ALPN so this is not nessesary). >> >> I am proposing that we do the following to address these issues: >> >> - Add support for lazily generated self signed certificates, and include >> this in the default config. This would mean that we would have a working >> HTTPS connector in the default config, although the first request would be >> a bit slow as it would need to generate a new self signed certificate for >> localhost. This allows for SSL out of the box, without any impact on >> startup time or any need for an installer to generate the certificate. >> >> - I have dealt with the ALPN issue in Undertow using a reflection based >> hack. I have created some code that parses and modifies the SSL >> Server/Client hello messages to add/read APLN information, and I then use >> reflection to update the HandshakeHash maintained by the engine so the >> engines internal hash state used to generate the Finished frames matches >> the data that was actually sent over the wire. >> >> Yes I am aware that this is a massive hack, however I think it is >> preferable to the current boot classpath hack, which has a lot of a >> drawbacks. If this ever stops working at some point due to internal JDK >> changes the boot classpath hack would still be usable, however I don't >> think this is particularly likely, as the part of the JDK that this >> modifies seems unlikely to change. >> >> I think this would be a great usability feature, allowing developers to >> get started with HTTPS and HTTP/2 straight away. >> >> Thoughts? >> >> Stuart >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/aa20aa80/attachment.html From stuart.w.douglas at gmail.com Thu Jun 2 08:02:24 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 2 Jun 2016 22:02:24 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <575016AB.3070908@redhat.com> References: <575016AB.3070908@redhat.com> Message-ID: We are already JDK9 compatible, if the JDK9 API's are present they will be used. I have not tested on IBM, although AFAIK the Jetty hack does not work there at the moment, so we are no worse off that what we currently are. If the ALPN reflection hack is disabled (either via system property or because a reflection lookup fails due to structural changes in the JDK) it will revert to trying to use the boot classpath hack. Stuart On Thu, Jun 2, 2016 at 9:21 PM, David M. Lloyd wrote: > On 06/01/2016 06:22 PM, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box in > > Wildfly 10.1. > > +1 from me. > > > At the moment there are two main barriers to getting HTTP/2 two work: > > > > - You need to set up a HTTPS connector, including generating keys etc. > > For new users this is not as straightforward as it could be. > > - You need to find the correct version of the Jetty ALPN jar and add it > > to your boot class path. This is essentially a hack that modifies the > > JDK SSL classes to allow them to support ALPN. A new version is needed > > for every JDK8 release, so if you ever update the JVM HTTP/2 will stop > > working (JDK9 has support for ALPN so this is not nessesary). > > > > I am proposing that we do the following to address these issues: > > > > - Add support for lazily generated self signed certificates, and include > > this in the default config. This would mean that we would have a working > > HTTPS connector in the default config, although the first request would > > be a bit slow as it would need to generate a new self signed certificate > > for localhost. This allows for SSL out of the box, without any impact on > > startup time or any need for an installer to generate the certificate. > > > > - I have dealt with the ALPN issue in Undertow using a reflection based > > hack. I have created some code that parses and modifies the SSL > > Server/Client hello messages to add/read APLN information, and I then > > use reflection to update the HandshakeHash maintained by the engine so > > the engines internal hash state used to generate the Finished frames > > matches the data that was actually sent over the wire. > > Nice. I think this is a pretty decent interim solution (though I think > we'll want to verify that this works on IBM too, and maybe come up with > a parallel code path for that case; also we'll want to be JDK 9 > compatible ASAP so we should detect that too). Yeah it's kind of ugly, > but not so much when you compare it against the alternatives of using > the boot classpath for the Jetty kludge or writing our own JSSE. > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/af7d1280/attachment.html From hbraun at redhat.com Thu Jun 2 08:02:53 2016 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 2 Jun 2016 14:02:53 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> Message-ID: yes, that?s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc. But I don?t want to hijack this thread. When the time comes I get back to this in a separate thread. [1] https://github.com/grpc/grpc-java > On 02 Jun 2016, at 13:54, Stuart Douglas wrote: > > Ah, sorry, I miss read your original email. > > You can do HTTP/2 at the moment, it is just a bit of a pain to set up. > > Stuart > > On Thu, Jun 2, 2016 at 9:44 PM, Heiko Braun > wrote: > gRPC requires http/2 > >> On 02 Jun 2016, at 12:05, Stuart Douglas > wrote: >> >> I am not sure how gRPC comes into it? >> >> Stuart >> >> On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun > wrote: >> +1 >> >> This would be a great step forward. >> >> On a related note: I was looking into gRPC [1] for Swarm the other day, >> and it seems this would be pre-requisite. >> >> >> Regards, Heiko >> >> >> [1] http://www.grpc.io/ >> >>> On 02 Jun 2016, at 01:22, Stuart Douglas > wrote: >>> >>> Hi All, >>> >>> I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. >>> >>> At the moment there are two main barriers to getting HTTP/2 two work: >>> >>> - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. >>> - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). >>> >>> I am proposing that we do the following to address these issues: >>> >>> - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. >>> >>> - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. >>> >>> Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. >>> >>> I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. >>> >>> Thoughts? >>> >>> Stuart >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/cbbafec6/attachment-0001.html From jason.greene at redhat.com Thu Jun 2 08:21:42 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Thu, 2 Jun 2016 08:21:42 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <1045828518.19122410.1464865398479.JavaMail.zimbra@redhat.com> References: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> <1045828518.19122410.1464865398479.JavaMail.zimbra@redhat.com> Message-ID: IMO it's no different than ssh keys. Also we could just leave localhost as the default bind, and they are likely to add the browser exception before moving the bind address. > On Jun 2, 2016, at 6:04 AM, Darran Lofthouse wrote: > > The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains. > > Probably not the end of the world though, we will still be able to guide them in the future to do it properly. Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11. > > Darran. > > > > ----- Original Message ----- > From: "Stuart Douglas" > To: "Darran Lofthouse" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, 2 June, 2016 11:38:04 AM > Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 > > You are always going to be able to MITM with self signed certs though, > dynamically generated or not. > > Stuart > > On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse > wrote: > >> Not a fan of dynamically generated self signed certificates - a recipe >> for leading users into shooting themselves in the foot. >> >> I say that after witnessing myself a user tricking themselves with their >> own man in the middle attack. >> >> Darran. >> >> >>> On 02/06/16 00:22, Stuart Douglas wrote: >>> Hi All, >>> >>> I would like to propose that we add support for HTTP/2 out of the box in >>> Wildfly 10.1. >>> >>> At the moment there are two main barriers to getting HTTP/2 two work: >>> >>> - You need to set up a HTTPS connector, including generating keys etc. >>> For new users this is not as straightforward as it could be. >>> - You need to find the correct version of the Jetty ALPN jar and add it >>> to your boot class path. This is essentially a hack that modifies the >>> JDK SSL classes to allow them to support ALPN. A new version is needed >>> for every JDK8 release, so if you ever update the JVM HTTP/2 will stop >>> working (JDK9 has support for ALPN so this is not nessesary). >>> >>> I am proposing that we do the following to address these issues: >>> >>> - Add support for lazily generated self signed certificates, and include >>> this in the default config. This would mean that we would have a working >>> HTTPS connector in the default config, although the first request would >>> be a bit slow as it would need to generate a new self signed certificate >>> for localhost. This allows for SSL out of the box, without any impact on >>> startup time or any need for an installer to generate the certificate. >>> >>> - I have dealt with the ALPN issue in Undertow using a reflection based >>> hack. I have created some code that parses and modifies the SSL >>> Server/Client hello messages to add/read APLN information, and I then >>> use reflection to update the HandshakeHash maintained by the engine so >>> the engines internal hash state used to generate the Finished frames >>> matches the data that was actually sent over the wire. >>> >>> Yes I am aware that this is a massive hack, however I think it is >>> preferable to the current boot classpath hack, which has a lot of a >>> drawbacks. If this ever stops working at some point due to internal JDK >>> changes the boot classpath hack would still be usable, however I don't >>> think this is particularly likely, as the part of the JDK that this >>> modifies seems unlikely to change. >>> >>> I think this would be a great usability feature, allowing developers to >>> get started with HTTPS and HTTP/2 straight away. >>> >>> Thoughts? >>> >>> Stuart >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Thu Jun 2 08:30:38 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 2 Jun 2016 13:30:38 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <26099508-a418-a006-9b28-b8179cc46860@jboss.com> <1045828518.19122410.1464865398479.JavaMail.zimbra@redhat.com> Message-ID: In both cases users should be provided with the signatures before their first attempt at connecting so they can verify they are genuine. On 02/06/16 13:21, Jason T. Greene wrote: > > IMO it's no different than ssh keys. Also we could just leave localhost as the default bind, and they are likely to add the browser exception before moving the bind address. > >> On Jun 2, 2016, at 6:04 AM, Darran Lofthouse wrote: >> >> The dynamically generated is the worst part of it though as they have no certificate information to compare when the browser complains. >> >> Probably not the end of the world though, we will still be able to guide them in the future to do it properly. Location wise I think we should see if the generation can be wrapped in the legacy security realms to minimise compatibility issues once we get to WildFly 11. >> >> Darran. >> >> >> >> ----- Original Message ----- >> From: "Stuart Douglas" >> To: "Darran Lofthouse" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Thursday, 2 June, 2016 11:38:04 AM >> Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 >> >> You are always going to be able to MITM with self signed certs though, >> dynamically generated or not. >> >> Stuart >> >> On Thu, Jun 2, 2016 at 8:18 PM, Darran Lofthouse >> wrote: >> >>> Not a fan of dynamically generated self signed certificates - a recipe >>> for leading users into shooting themselves in the foot. >>> >>> I say that after witnessing myself a user tricking themselves with their >>> own man in the middle attack. >>> >>> Darran. >>> >>> >>>> On 02/06/16 00:22, Stuart Douglas wrote: >>>> Hi All, >>>> >>>> I would like to propose that we add support for HTTP/2 out of the box in >>>> Wildfly 10.1. >>>> >>>> At the moment there are two main barriers to getting HTTP/2 two work: >>>> >>>> - You need to set up a HTTPS connector, including generating keys etc. >>>> For new users this is not as straightforward as it could be. >>>> - You need to find the correct version of the Jetty ALPN jar and add it >>>> to your boot class path. This is essentially a hack that modifies the >>>> JDK SSL classes to allow them to support ALPN. A new version is needed >>>> for every JDK8 release, so if you ever update the JVM HTTP/2 will stop >>>> working (JDK9 has support for ALPN so this is not nessesary). >>>> >>>> I am proposing that we do the following to address these issues: >>>> >>>> - Add support for lazily generated self signed certificates, and include >>>> this in the default config. This would mean that we would have a working >>>> HTTPS connector in the default config, although the first request would >>>> be a bit slow as it would need to generate a new self signed certificate >>>> for localhost. This allows for SSL out of the box, without any impact on >>>> startup time or any need for an installer to generate the certificate. >>>> >>>> - I have dealt with the ALPN issue in Undertow using a reflection based >>>> hack. I have created some code that parses and modifies the SSL >>>> Server/Client hello messages to add/read APLN information, and I then >>>> use reflection to update the HandshakeHash maintained by the engine so >>>> the engines internal hash state used to generate the Finished frames >>>> matches the data that was actually sent over the wire. >>>> >>>> Yes I am aware that this is a massive hack, however I think it is >>>> preferable to the current boot classpath hack, which has a lot of a >>>> drawbacks. If this ever stops working at some point due to internal JDK >>>> changes the boot classpath hack would still be usable, however I don't >>>> think this is particularly likely, as the part of the JDK that this >>>> modifies seems unlikely to change. >>>> >>>> I think this would be a great usability feature, allowing developers to >>>> get started with HTTPS and HTTP/2 straight away. >>>> >>>> Thoughts? >>>> >>>> Stuart >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Thu Jun 2 08:44:02 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Thu, 2 Jun 2016 08:44:02 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> Message-ID: <913E72EE-618E-4AD2-88D6-58532F8C0508@redhat.com> If you want to capitalize on all of the capabilities of the undertow web server (which is likely user expectation) then really it needs to be the one providing http instead of splicing in a different web server, which has a completely different feature set, and mechanism of configuration. However, it would be possible to do so. > On Jun 2, 2016, at 7:03 AM, Heiko Braun wrote: > > yes, that?s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc. > > But I don?t want to hijack this thread. When the time comes I get back to this in a separate thread. > > [1] https://github.com/grpc/grpc-java > >> On 02 Jun 2016, at 13:54, Stuart Douglas wrote: >> >> Ah, sorry, I miss read your original email. >> >> You can do HTTP/2 at the moment, it is just a bit of a pain to set up. >> >> Stuart >> >>> On Thu, Jun 2, 2016 at 9:44 PM, Heiko Braun wrote: >>> gRPC requires http/2 >>> >>>> On 02 Jun 2016, at 12:05, Stuart Douglas wrote: >>>> >>>> I am not sure how gRPC comes into it? >>>> >>>> Stuart >>>> >>>>> On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun wrote: >>>>> +1 >>>>> >>>>> This would be a great step forward. >>>>> >>>>> On a related note: I was looking into gRPC [1] for Swarm the other day, >>>>> and it seems this would be pre-requisite. >>>>> >>>>> >>>>> Regards, Heiko >>>>> >>>>> >>>>> [1] http://www.grpc.io/ >>>>> >>>>>> On 02 Jun 2016, at 01:22, Stuart Douglas wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. >>>>>> >>>>>> At the moment there are two main barriers to getting HTTP/2 two work: >>>>>> >>>>>> - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. >>>>>> - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). >>>>>> >>>>>> I am proposing that we do the following to address these issues: >>>>>> >>>>>> - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. >>>>>> >>>>>> - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. >>>>>> >>>>>> Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. >>>>>> >>>>>> I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/c7ece13d/attachment-0001.html From hbraun at redhat.com Thu Jun 2 09:24:39 2016 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 2 Jun 2016 15:24:39 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <913E72EE-618E-4AD2-88D6-58532F8C0508@redhat.com> References: <4681D0D6-0E2D-47FE-AF86-E340F862FD89@redhat.com> <913E72EE-618E-4AD2-88D6-58532F8C0508@redhat.com> Message-ID: <7F87DD04-FD62-48CF-9369-F1109DF78A2F@redhat.com> Yes, thats what meant saying it needs a server transport (grpc term) based on undertow. > Am 02.06.2016 um 14:44 schrieb Jason T. Greene : > > If you want to capitalize on all of the capabilities of the undertow web server (which is likely user expectation) then really it needs to be the one providing http instead of splicing in a different web server, which has a completely different feature set, and mechanism of configuration. However, it would be possible to do so. > >> On Jun 2, 2016, at 7:03 AM, Heiko Braun wrote: >> >> yes, that?s what i was referring to. if HTTP/2 becomes the default, then we are one step closer to utilise gRPC in Swarm. But there are still many related issues that need to be solved. I.e. it would require server transport based on undertow. Currently gRPC only provides netty [1]. And we would need to discuss how this then integrates with the HTTP upgrade, etc. >> >> But I don?t want to hijack this thread. When the time comes I get back to this in a separate thread. >> >> [1] https://github.com/grpc/grpc-java >> >>> On 02 Jun 2016, at 13:54, Stuart Douglas wrote: >>> >>> Ah, sorry, I miss read your original email. >>> >>> You can do HTTP/2 at the moment, it is just a bit of a pain to set up. >>> >>> Stuart >>> >>>> On Thu, Jun 2, 2016 at 9:44 PM, Heiko Braun wrote: >>>> gRPC requires http/2 >>>> >>>>> On 02 Jun 2016, at 12:05, Stuart Douglas wrote: >>>>> >>>>> I am not sure how gRPC comes into it? >>>>> >>>>> Stuart >>>>> >>>>>> On Thu, Jun 2, 2016 at 6:26 PM, Heiko Braun wrote: >>>>>> +1 >>>>>> >>>>>> This would be a great step forward. >>>>>> >>>>>> On a related note: I was looking into gRPC [1] for Swarm the other day, >>>>>> and it seems this would be pre-requisite. >>>>>> >>>>>> >>>>>> Regards, Heiko >>>>>> >>>>>> >>>>>> [1] http://www.grpc.io/ >>>>>> >>>>>>> On 02 Jun 2016, at 01:22, Stuart Douglas wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I would like to propose that we add support for HTTP/2 out of the box in Wildfly 10.1. >>>>>>> >>>>>>> At the moment there are two main barriers to getting HTTP/2 two work: >>>>>>> >>>>>>> - You need to set up a HTTPS connector, including generating keys etc. For new users this is not as straightforward as it could be. >>>>>>> - You need to find the correct version of the Jetty ALPN jar and add it to your boot class path. This is essentially a hack that modifies the JDK SSL classes to allow them to support ALPN. A new version is needed for every JDK8 release, so if you ever update the JVM HTTP/2 will stop working (JDK9 has support for ALPN so this is not nessesary). >>>>>>> >>>>>>> I am proposing that we do the following to address these issues: >>>>>>> >>>>>>> - Add support for lazily generated self signed certificates, and include this in the default config. This would mean that we would have a working HTTPS connector in the default config, although the first request would be a bit slow as it would need to generate a new self signed certificate for localhost. This allows for SSL out of the box, without any impact on startup time or any need for an installer to generate the certificate. >>>>>>> >>>>>>> - I have dealt with the ALPN issue in Undertow using a reflection based hack. I have created some code that parses and modifies the SSL Server/Client hello messages to add/read APLN information, and I then use reflection to update the HandshakeHash maintained by the engine so the engines internal hash state used to generate the Finished frames matches the data that was actually sent over the wire. >>>>>>> >>>>>>> Yes I am aware that this is a massive hack, however I think it is preferable to the current boot classpath hack, which has a lot of a drawbacks. If this ever stops working at some point due to internal JDK changes the boot classpath hack would still be usable, however I don't think this is particularly likely, as the part of the JDK that this modifies seems unlikely to change. >>>>>>> >>>>>>> I think this would be a great usability feature, allowing developers to get started with HTTPS and HTTP/2 straight away. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160602/36424833/attachment.html From hcamp at muerte.net Thu Jun 2 12:29:44 2016 From: hcamp at muerte.net (Harold Campbell) Date: Thu, 02 Jun 2016 11:29:44 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: Message-ID: <1464884984.2997.3.camel@muerte.net> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > Hi All, > > I would like to propose that we add support for HTTP/2 out of the box > in Wildfly 10.1. > This lowly user desperately wants a release containing the fix to?WFLY- 6283 sooner rather than later. I'm sure other people have other pet bugs awaiting release. I have no opinion on HTTP/2 being added other than to ask that pent up bug fixes be kept in mind. -- Harold Campbell Roses are red; Violets are blue. I'm schizophrenic, And so am I. From jason.greene at redhat.com Thu Jun 2 13:19:52 2016 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 2 Jun 2016 12:19:52 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <1464884984.2997.3.camel@muerte.net> References: <1464884984.2997.3.camel@muerte.net> Message-ID: > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >> Hi All, >> >> I would like to propose that we add support for HTTP/2 out of the box >> in Wildfly 10.1. >> > > This lowly user desperately wants a release containing the fix to WFLY- > 6283 sooner rather than later. I'm sure other people have other pet > bugs awaiting release. > > I have no opinion on HTTP/2 being added other than to ask that pent up > bug fixes be kept in mind. Hi Harold, That fix is already in master, so it will be included in 10.1. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From stuart.w.douglas at gmail.com Thu Jun 2 16:01:06 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 3 Jun 2016 06:01:06 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: So I guess we should talk about how this should actually work. In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. Stuart On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: > > > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: > > > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > >> Hi All, > >> > >> I would like to propose that we add support for HTTP/2 out of the box > >> in Wildfly 10.1. > >> > > > > This lowly user desperately wants a release containing the fix to WFLY- > > 6283 sooner rather than later. I'm sure other people have other pet > > bugs awaiting release. > > > > I have no opinion on HTTP/2 being added other than to ask that pent up > > bug fixes be kept in mind. > > > Hi Harold, > > That fix is already in master, so it will be included in 10.1. > > -- > 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/wildfly-dev/attachments/20160603/cdb7ba51/attachment.html From nickarls at gmail.com Fri Jun 3 00:12:04 2016 From: nickarls at gmail.com (nickarls at gmail.com) Date: Fri, 3 Jun 2016 07:12:04 +0300 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <575103c9.230ec20a.83572.4c73@mx.google.com> On a side note, it might be nice if the console would have support for CSR generation. If possible, why not for the whole process... Sent from my Windows Phone -----Original Message----- From: "Stuart Douglas" Sent: ?6/?2/?2016 23:01 To: "Jason Greene" Cc: "wildfly-dev at lists.jboss.org" Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 So I guess we should talk about how this should actually work. In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. Stuart On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >> Hi All, >> >> I would like to propose that we add support for HTTP/2 out of the box >> in Wildfly 10.1. >> > > This lowly user desperately wants a release containing the fix to WFLY- > 6283 sooner rather than later. I'm sure other people have other pet > bugs awaiting release. > > I have no opinion on HTTP/2 being added other than to ask that pent up > bug fixes be kept in mind. Hi Harold, That fix is already in master, so it will be included in 10.1. -- 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/wildfly-dev/attachments/20160603/c8b35070/attachment-0001.html From mchoma at redhat.com Fri Jun 3 03:18:42 2016 From: mchoma at redhat.com (Martin Choma) Date: Fri, 3 Jun 2016 09:18:42 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: Hi Stuart, I have couple of questions regarding self-signed certificate autogeneration: What happens, when autogenerated certificate expires? How it will be decided if certificate should be autogenerate or not? What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: > So I guess we should talk about how this should actually work. > > In terms of auto generating the key I was thinking we would need to add a > new attribute to the 'keystore' element under the security realm, something > like 'auto-generate-cert-host="localhost"'. I am not sure what other > options we would need, or how configurable we should make it, but as this > is for testing/development purposes I don't think we need to expose full > control over the certificate generation process. > > In terms of the implementation we could just implement an SSLContext > wrapper, that can do the generation and then create a 'real' SSLContext the > first time it is asked to create and SSLEngine. > > Stuart > > On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene > wrote: > >> >> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >> > >> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >> >> Hi All, >> >> >> >> I would like to propose that we add support for HTTP/2 out of the box >> >> in Wildfly 10.1. >> >> >> > >> > This lowly user desperately wants a release containing the fix to WFLY- >> > 6283 sooner rather than later. I'm sure other people have other pet >> > bugs awaiting release. >> > >> > I have no opinion on HTTP/2 being added other than to ask that pent up >> > bug fixes be kept in mind. >> >> >> Hi Harold, >> >> That fix is already in master, so it will be included in 10.1. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160603/2d0bd246/attachment.html From stuart.w.douglas at gmail.com Fri Jun 3 03:28:51 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 03 Jun 2016 07:28:51 +0000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: On Fri, 3 Jun 2016, 17:18 Martin Choma wrote: > Hi Stuart, > > I have couple of questions regarding self-signed certificate > autogeneration: > > What happens, when autogenerated certificate expires? > I think we would go for ten year expiry so that would not be an issue. The developer could just delete the store and generate a new one anyway. How it will be decided if certificate should be autogenerate or not? > An attribute in the management model would be needed to explicitly enable it. What will be default keysize? It has to be probably choosen to work also > without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction > Policy" > Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. Stuart > > > > On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> So I guess we should talk about how this should actually work. >> >> In terms of auto generating the key I was thinking we would need to add a >> new attribute to the 'keystore' element under the security realm, something >> like 'auto-generate-cert-host="localhost"'. I am not sure what other >> options we would need, or how configurable we should make it, but as this >> is for testing/development purposes I don't think we need to expose full >> control over the certificate generation process. >> >> In terms of the implementation we could just implement an SSLContext >> wrapper, that can do the generation and then create a 'real' SSLContext the >> first time it is asked to create and SSLEngine. >> >> Stuart >> >> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >> wrote: >> >>> >>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>> > >>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>> >> Hi All, >>> >> >>> >> I would like to propose that we add support for HTTP/2 out of the box >>> >> in Wildfly 10.1. >>> >> >>> > >>> > This lowly user desperately wants a release containing the fix to WFLY- >>> > 6283 sooner rather than later. I'm sure other people have other pet >>> > bugs awaiting release. >>> > >>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>> > bug fixes be kept in mind. >>> >>> >>> Hi Harold, >>> >>> That fix is already in master, so it will be included in 10.1. >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160603/674c3bc9/attachment.html From darran.lofthouse at jboss.com Fri Jun 3 05:02:29 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 3 Jun 2016 10:02:29 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <575103c9.230ec20a.83572.4c73@mx.google.com> References: <1464884984.2997.3.camel@muerte.net> <575103c9.230ec20a.83572.4c73@mx.google.com> Message-ID: <7ae4cdee-6c12-df61-8eea-598166ecdc7a@jboss.com> Yes we do have plans for full CSR generation and the import step for the signed certificate at a later point, this would be integrated with the management tools to simplify SSL set up. Darran. On 03/06/16 05:12, nickarls at gmail.com wrote: > On a side note, it might be nice if the console would have support for > CSR generation. If possible, why not for the whole process... > > Sent from my Windows Phone > ------------------------------------------------------------------------ > From: Stuart Douglas > Sent: ?6/?2/?2016 23:01 > To: Jason Greene > Cc: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 > > So I guess we should talk about how this should actually work. > > In terms of auto generating the key I was thinking we would need to add > a new attribute to the 'keystore' element under the security realm, > something like 'auto-generate-cert-host="localhost"'. I am not sure what > other options we would need, or how configurable we should make it, but > as this is for testing/development purposes I don't think we need to > expose full control over the certificate generation process. > > In terms of the implementation we could just implement an SSLContext > wrapper, that can do the generation and then create a 'real' SSLContext > the first time it is asked to create and SSLEngine. > > Stuart > > On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene > wrote: > > > > On Jun 2, 2016, at 11:29 AM, Harold Campbell > wrote: > > > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > >> Hi All, > >> > >> I would like to propose that we add support for HTTP/2 out of the box > >> in Wildfly 10.1. > >> > > > > This lowly user desperately wants a release containing the fix to WFLY- > > 6283 sooner rather than later. I'm sure other people have other pet > > bugs awaiting release. > > > > I have no opinion on HTTP/2 being added other than to ask that pent up > > bug fixes be kept in mind. > > > Hi Harold, > > That fix is already in master, so it will be included in 10.1. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Fri Jun 3 05:52:56 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 3 Jun 2016 11:52:56 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <1464884984.2997.3.camel@muerte.net> References: <1464884984.2997.3.camel@muerte.net> Message-ID: This is completely off topic for this thread, there was one earlier about what should go into 10.x.... Anywho, issue you mention was already resolved and hibernate updated in master some time ago. which means it will be in next release, whatever that release will be. -- tomaz On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell wrote: > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box > > in Wildfly 10.1. > > > > This lowly user desperately wants a release containing the fix to WFLY- > 6283 sooner rather than later. I'm sure other people have other pet > bugs awaiting release. > > I have no opinion on HTTP/2 being added other than to ask that pent up > bug fixes be kept in mind. > > -- > Harold Campbell > > Roses are red; > Violets are blue. > I'm schizophrenic, > And so am I. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160603/5d56cb27/attachment-0001.html From jason.greene at redhat.com Fri Jun 3 10:09:47 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Fri, 3 Jun 2016 10:09:47 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> >> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" > > > Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. > > Stuart > >> >> >> >> >>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >> >>> So I guess we should talk about how this should actually work. >>> >>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>> >>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>> >>> Stuart >>> >>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>> >>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>> > >>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>> >> Hi All, >>>> >> >>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>> >> in Wildfly 10.1. >>>> >> >>>> > >>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>> > bugs awaiting release. >>>> > >>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>> > bug fixes be kept in mind. >>>> >>>> >>>> Hi Harold, >>>> >>>> That fix is already in master, so it will be included in 10.1. >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>> >>> >> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160603/5ad46a21/attachment.html From jorsol at gmail.com Fri Jun 3 10:28:02 2016 From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=) Date: Fri, 3 Jun 2016 08:28:02 -0600 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: IMO this feature should be oriented to sysadmins not just developers. Is there really added value for developers to use HTTPS or HTTPS/2? It should be easy for sysadmins to setup TLS/SSL with "production" quality, from the gereration of the CSR that has to be send to the CA to the generation of the keystore. BTW... how is the performance of HTTPS using pure Java vs Apache for example? is this feature oriented for developers because for use in production is not recommended? *Ing. Jorge Sol?rzano* about.me/jorsol On Fri, Jun 3, 2016 at 3:52 AM, Toma? Cerar wrote: > This is completely off topic for this thread, there was one earlier about > what should go into 10.x.... > > Anywho, issue you mention was already resolved and hibernate updated in > master some time ago. > which means it will be in next release, whatever that release will be. > > -- > tomaz > > On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell wrote: > >> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >> > Hi All, >> > >> > I would like to propose that we add support for HTTP/2 out of the box >> > in Wildfly 10.1. >> > >> >> This lowly user desperately wants a release containing the fix to WFLY- >> 6283 sooner rather than later. I'm sure other people have other pet >> bugs awaiting release. >> >> I have no opinion on HTTP/2 being added other than to ask that pent up >> bug fixes be kept in mind. >> >> -- >> Harold Campbell >> >> Roses are red; >> Violets are blue. >> I'm schizophrenic, >> And so am I. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160603/1562a497/attachment.html From darran.lofthouse at jboss.com Fri Jun 3 12:11:38 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 3 Jun 2016 17:11:38 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <098c8edd-3abb-0458-7cd4-c193ca789c7d@jboss.com> Enhancing TLS set up with features such as CSR generation and the importing of the resulting signed certificates is something we are working on. Regards, Darran Lofthouse. On 03/06/16 15:28, Jorge Sol?rzano wrote: > IMO this feature should be oriented to sysadmins not just developers. Is > there really added value for developers to use HTTPS or HTTPS/2? > > It should be easy for sysadmins to setup TLS/SSL with "production" > quality, from the gereration of the CSR that has to be send to the CA to > the generation of the keystore. > > BTW... how is the performance of HTTPS using pure Java vs Apache for > example? is this feature oriented for developers because for use in > production is not recommended? > > * > Ing. Jorge Sol?rzano* > about.me/jorsol > > > On Fri, Jun 3, 2016 at 3:52 AM, Toma? Cerar > wrote: > > This is completely off topic for this thread, there was one earlier > about what should go into 10.x.... > > Anywho, issue you mention was already resolved and hibernate updated > in master some time ago. > which means it will be in next release, whatever that release will be. > > -- > tomaz > > On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell > wrote: > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box > > in Wildfly 10.1. > > > > This lowly user desperately wants a release containing the fix > to WFLY- > 6283 sooner rather than later. I'm sure other people have other pet > bugs awaiting release. > > I have no opinion on HTTP/2 being added other than to ask that > pent up > bug fixes be kept in mind. > > -- > Harold Campbell > > > Roses are red; > Violets are blue. > I'm schizophrenic, > And so am I. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From hcamp at muerte.net Fri Jun 3 13:12:44 2016 From: hcamp at muerte.net (Harold Campbell) Date: Fri, 03 Jun 2016 12:12:44 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <1464973964.3092.7.camel@muerte.net> On Fri, 2016-06-03 at 11:52 +0200, Toma? Cerar wrote: > This is completely off topic for this thread, there was one earlier > about what should go into 10.x.... > Really? A week or so back there was talk of getting 10.1 out in the next week or two. This feature looks like something which could put that timing at risk. > Anywho, issue you mention was already resolved and hibernate updated > in master some time ago. > which means it will be in next release, whatever that release will > be. All I'm saying is I'd really like to have a proper release containing this fix, so I don't have to explain to my boss why we are using a SNAPSHOT. It's obviously not up to me when a release gets done. I'm just throwing out there that some of us end users could really use a proper release containing the bug fixes that affect us. Bringing in new features probably means we don't get one for a while longer. -- Harold Campbell Change your thoughts and you change your world. From jason.greene at redhat.com Fri Jun 3 14:06:44 2016 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 3 Jun 2016 13:06:44 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: > On Jun 3, 2016, at 9:28 AM, Jorge Sol?rzano wrote: > > IMO this feature should be oriented to sysadmins not just developers. Is there really added value for developers to use HTTPS or HTTPS/2? Yeah, server push is an example, we have an API where you can push resources to the client before they are requested. Although we have a learning handler that can try to do it for you, but thats not as good as something designed for it. It also has different characteristics that you can exploit (e.g. being able to create a lot of streams without impacting connection count) that you might want to do if you are building an HTTP/2 centric application. Of course, not everyone will fall into this category because they will need to support both h2 and h1. > > It should be easy for sysadmins to setup TLS/SSL with "production" quality, from the gereration of the CSR that has to be send to the CA to the generation of the keystone. Agreed. What Stuart meant was that out of the box auto-generation was a development focused feature. Obviously in production you don?t need /want keys automatically generated, you want to use your publicly signed cert. > > BTW... how is the performance of HTTPS using pure Java vs Apache for example? is this feature oriented for developers because for use in production is not recommended? Java based SSL is certainly usable and performant in production, many people deploy on it. > > > Ing. Jorge Sol?rzano > about.me/jorsol > > On Fri, Jun 3, 2016 at 3:52 AM, Toma? Cerar > wrote: > This is completely off topic for this thread, there was one earlier about what should go into 10.x.... > > Anywho, issue you mention was already resolved and hibernate updated in master some time ago. > which means it will be in next release, whatever that release will be. > > -- > tomaz > > On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell > wrote: > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > > Hi All, > > > > I would like to propose that we add support for HTTP/2 out of the box > > in Wildfly 10.1. > > > > This lowly user desperately wants a release containing the fix to WFLY- > 6283 sooner rather than later. I'm sure other people have other pet > bugs awaiting release. > > I have no opinion on HTTP/2 being added other than to ask that pent up > bug fixes be kept in mind. > > -- > Harold Campbell > > > Roses are red; > Violets are blue. > I'm schizophrenic, > And so am I. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160603/207706c8/attachment-0001.html From jason.greene at redhat.com Fri Jun 3 14:11:11 2016 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 3 Jun 2016 13:11:11 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <1464973964.3092.7.camel@muerte.net> References: <1464884984.2997.3.camel@muerte.net> <1464973964.3092.7.camel@muerte.net> Message-ID: <26F6918F-FBE6-48EC-907C-FF5DE20EF535@redhat.com> > On Jun 3, 2016, at 12:12 PM, Harold Campbell wrote: > > On Fri, 2016-06-03 at 11:52 +0200, Toma? Cerar wrote: >> This is completely off topic for this thread, there was one earlier >> about what should go into 10.x.... >> > > Really? A week or so back there was talk of getting 10.1 out in the > next week or two. This feature looks like something which could put > that timing at risk. It sounds complicated, but the feature isn?t too hard. The situation is we really want to get going on 11, but before we diverge too much we have a good opportunity to deliver usability improvements and nice additions for everyone deploying on 10. > >> Anywho, issue you mention was already resolved and hibernate updated >> in master some time ago. >> which means it will be in next release, whatever that release will >> be. > > All I'm saying is I'd really like to have a proper release containing > this fix, so I don't have to explain to my boss why we are using a > SNAPSHOT. > > It's obviously not up to me when a release gets done. I'm just throwing > out there that some of us end users could really use a proper release > containing the bug fixes that affect us. Bringing in new features > probably means we don't get one for a while longer. Yeah I hear you, and totally understand, time is certainly a priority. > > -- > Harold Campbell > > Change your thoughts and you change your world. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From stuart.w.douglas at gmail.com Sun Jun 5 18:57:57 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Jun 2016 08:57:57 +1000 Subject: [wildfly-dev] JavaMail provider module and jboss-deployment-structure.xml In-Reply-To: <6C07EF89-6E6C-4EA3-ADE0-684770EC80A2@me.com> References: <6C07EF89-6E6C-4EA3-ADE0-684770EC80A2@me.com> Message-ID: At a guess I would say it is because modules import the META-INF directory by default, while when using jboss-deployment-structure.xml you need to explicitly add meta-inf="true". Stuart On Sat, May 21, 2016 at 11:47 PM, Carl Harris wrote: > I have a custom JavaMail provider installed as a module in Wildfly 10. > > In the configuration, I specify a mail session using the custom provider > like this: > > > > > > > > > If I make the provider a global module in the configuration, a deployment > can successfully use the provider. > > However, if I specify the provider as module dependency in > jboss-deployment-structure.xml, when trying to create a javax.mail.Session > using the provider, a NoSuchProviderException is thrown (as though the base > Session implementation cannot find a META-INF/javamail.providers mapping > that identifies the custom provider). > > I don't know whether specifying the provider as a deployment structure > dependency should work or not, but it seems like it should. > > Can someone please explain? > > carl > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/405a0f61/attachment.html From stuart.w.douglas at gmail.com Sun Jun 5 21:57:06 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Jun 2016 11:57:06 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> Message-ID: So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. Stuart On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: > > What will be default keysize? It has to be probably choosen to work also >> without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction >> Policy" >> > > Probably the largest that is supported without JCE. It does not matter > that much, self signed certs are inherently insecure, this is a developer > usability feature, not something that can be used in production. > > > IIRC there is actually no limit on RSA key size, it's only symmetric algs > that are limited, so we could use a standard 2048 bit key without issue. > > > > Stuart > > >> >> >> >> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >> stuart.w.douglas at gmail.com> wrote: >> >>> So I guess we should talk about how this should actually work. >>> >>> In terms of auto generating the key I was thinking we would need to add >>> a new attribute to the 'keystore' element under the security realm, >>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>> other options we would need, or how configurable we should make it, but as >>> this is for testing/development purposes I don't think we need to expose >>> full control over the certificate generation process. >>> >>> In terms of the implementation we could just implement an SSLContext >>> wrapper, that can do the generation and then create a 'real' SSLContext the >>> first time it is asked to create and SSLEngine. >>> >>> Stuart >>> >>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >>> wrote: >>> >>>> >>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>> wrote: >>>> > >>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>> >> Hi All, >>>> >> >>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>> >> in Wildfly 10.1. >>>> >> >>>> > >>>> > This lowly user desperately wants a release containing the fix to >>>> WFLY- >>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>> > bugs awaiting release. >>>> > >>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>> > bug fixes be kept in mind. >>>> >>>> >>>> Hi Harold, >>>> >>>> That fix is already in master, so it will be included in 10.1. >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/08674742/attachment.html From jason.greene at redhat.com Sun Jun 5 22:27:17 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Sun, 5 Jun 2016 22:27:17 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> Message-ID: <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> We should really be generating 2048 bit keys. I don't like adding to our boot time, we have already seen it grow and this would be yet another case. > On Jun 5, 2016, at 8:57 PM, Stuart Douglas wrote: > > So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. > > I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. > > Stuart > >> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: >> >>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>> >>> >>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >> >> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >> >> >>> >>> Stuart >>> >>>> >>>> >>>> >>>> >>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >>>> >>>>> So I guess we should talk about how this should actually work. >>>>> >>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>> >>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>> >>>>> Stuart >>>>> >>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160605/1cdf03c3/attachment-0001.html From stuart.w.douglas at gmail.com Sun Jun 5 22:31:17 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Jun 2016 12:31:17 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> Message-ID: 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. Stuart On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene wrote: > We should really be generating 2048 bit keys. > > I don't like adding to our boot time, we have already seen it grow and > this would be yet another case. > > On Jun 5, 2016, at 8:57 PM, Stuart Douglas > wrote: > > So I just did up a very quick prototype that generates self signed > certificates on startup and it looks like the difference in startup time is > negligible (at least when generating 1024 bit RSA keys). Even if the > difference is measurable it only affects the very first startup. > > I think that in order to simplify the implementation of this it may be > better to simply generate the key of first startup, instead of attempting > to do it lazily. > > Stuart > > On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene > wrote: > >> >> What will be default keysize? It has to be probably choosen to work also >>> without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction >>> Policy" >>> >> >> Probably the largest that is supported without JCE. It does not matter >> that much, self signed certs are inherently insecure, this is a developer >> usability feature, not something that can be used in production. >> >> >> IIRC there is actually no limit on RSA key size, it's only symmetric algs >> that are limited, so we could use a standard 2048 bit key without issue. >> >> >> >> Stuart >> >> >>> >>> >>> >>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>> stuart.w.douglas at gmail.com> wrote: >>> >>>> So I guess we should talk about how this should actually work. >>>> >>>> In terms of auto generating the key I was thinking we would need to add >>>> a new attribute to the 'keystore' element under the security realm, >>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>> other options we would need, or how configurable we should make it, but as >>>> this is for testing/development purposes I don't think we need to expose >>>> full control over the certificate generation process. >>>> >>>> In terms of the implementation we could just implement an SSLContext >>>> wrapper, that can do the generation and then create a 'real' SSLContext the >>>> first time it is asked to create and SSLEngine. >>>> >>>> Stuart >>>> >>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >>>> wrote: >>>> >>>>> >>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>> wrote: >>>>> > >>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>> >> Hi All, >>>>> >> >>>>> >> I would like to propose that we add support for HTTP/2 out of the >>>>> box >>>>> >> in Wildfly 10.1. >>>>> >> >>>>> > >>>>> > This lowly user desperately wants a release containing the fix to >>>>> WFLY- >>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>> > bugs awaiting release. >>>>> > >>>>> > I have no opinion on HTTP/2 being added other than to ask that pent >>>>> up >>>>> > bug fixes be kept in mind. >>>>> >>>>> >>>>> Hi Harold, >>>>> >>>>> That fix is already in master, so it will be included in 10.1. >>>>> >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform Architect >>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/27064bd2/attachment.html From jason.greene at redhat.com Sun Jun 5 22:45:22 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Sun, 5 Jun 2016 22:45:22 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> Message-ID: <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help > On Jun 5, 2016, at 9:31 PM, Stuart Douglas wrote: > > 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). > > This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. > > Stuart > >> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene wrote: >> We should really be generating 2048 bit keys. >> >> I don't like adding to our boot time, we have already seen it grow and this would be yet another case. >> >>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas wrote: >>> >>> So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. >>> >>> I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. >>> >>> Stuart >>> >>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: >>>> >>>>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>>>> >>>>> >>>>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >>>> >>>> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >>>> >>>> >>>>> >>>>> Stuart >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >>>>>> >>>>>>> So I guess we should talk about how this should actually work. >>>>>>> >>>>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>>>> >>>>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>>>>>> >>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>>>>>> > >>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>> >> Hi All, >>>>>>>> >> >>>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>> >> in Wildfly 10.1. >>>>>>>> >> >>>>>>>> > >>>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>> > bugs awaiting release. >>>>>>>> > >>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>> > bug fixes be kept in mind. >>>>>>>> >>>>>>>> >>>>>>>> Hi Harold, >>>>>>>> >>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160605/45d0163d/attachment-0001.html From stuart.w.douglas at gmail.com Sun Jun 5 22:46:13 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Jun 2016 12:46:13 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> Message-ID: I think that would actually end up being more complex. Stuart On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene wrote: > Another option could be a post boot task. So it's still eager but don't > block completed start. We'd still need to block Tls ports though. So maybe > this does not help > > On Jun 5, 2016, at 9:31 PM, Stuart Douglas > wrote: > > 2048 bits adds close to a second to first boot on my machine (obviously > subsequent boots are unaffected). > > This is probably a bit much, I will work on getting a POC for the lazy > loading approach implemented. > > Stuart > > On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene > wrote: > >> We should really be generating 2048 bit keys. >> >> I don't like adding to our boot time, we have already seen it grow and >> this would be yet another case. >> >> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >> wrote: >> >> So I just did up a very quick prototype that generates self signed >> certificates on startup and it looks like the difference in startup time is >> negligible (at least when generating 1024 bit RSA keys). Even if the >> difference is measurable it only affects the very first startup. >> >> I think that in order to simplify the implementation of this it may be >> better to simply generate the key of first startup, instead of attempting >> to do it lazily. >> >> Stuart >> >> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene > > wrote: >> >>> >>> What will be default keysize? It has to be probably choosen to work also >>>> without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction >>>> Policy" >>>> >>> >>> Probably the largest that is supported without JCE. It does not matter >>> that much, self signed certs are inherently insecure, this is a developer >>> usability feature, not something that can be used in production. >>> >>> >>> IIRC there is actually no limit on RSA key size, it's only symmetric >>> algs that are limited, so we could use a standard 2048 bit key without >>> issue. >>> >>> >>> >>> Stuart >>> >>> >>>> >>>> >>>> >>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>> stuart.w.douglas at gmail.com> wrote: >>>> >>>>> So I guess we should talk about how this should actually work. >>>>> >>>>> In terms of auto generating the key I was thinking we would need to >>>>> add a new attribute to the 'keystore' element under the security realm, >>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>> other options we would need, or how configurable we should make it, but as >>>>> this is for testing/development purposes I don't think we need to expose >>>>> full control over the certificate generation process. >>>>> >>>>> In terms of the implementation we could just implement an SSLContext >>>>> wrapper, that can do the generation and then create a 'real' SSLContext the >>>>> first time it is asked to create and SSLEngine. >>>>> >>>>> Stuart >>>>> >>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >>>>> wrote: >>>>> >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>> wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the >>>>>> box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to >>>>>> WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent >>>>>> up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/9cee0fe1/attachment.html From stuart.w.douglas at gmail.com Mon Jun 6 00:53:42 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Jun 2016 14:53:42 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> Message-ID: I have some initial work on this at: https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed). Stuart On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas wrote: > I think that would actually end up being more complex. > > Stuart > > On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene > wrote: > >> Another option could be a post boot task. So it's still eager but don't >> block completed start. We'd still need to block Tls ports though. So maybe >> this does not help >> >> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >> wrote: >> >> 2048 bits adds close to a second to first boot on my machine (obviously >> subsequent boots are unaffected). >> >> This is probably a bit much, I will work on getting a POC for the lazy >> loading approach implemented. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene > > wrote: >> >>> We should really be generating 2048 bit keys. >>> >>> I don't like adding to our boot time, we have already seen it grow and >>> this would be yet another case. >>> >>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>> wrote: >>> >>> So I just did up a very quick prototype that generates self signed >>> certificates on startup and it looks like the difference in startup time is >>> negligible (at least when generating 1024 bit RSA keys). Even if the >>> difference is measurable it only affects the very first startup. >>> >>> I think that in order to simplify the implementation of this it may be >>> better to simply generate the key of first startup, instead of attempting >>> to do it lazily. >>> >>> Stuart >>> >>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >>> jason.greene at redhat.com> wrote: >>> >>>> >>>> What will be default keysize? It has to be probably choosen to work >>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>>> Jurisdiction Policy" >>>>> >>>> >>>> Probably the largest that is supported without JCE. It does not matter >>>> that much, self signed certs are inherently insecure, this is a developer >>>> usability feature, not something that can be used in production. >>>> >>>> >>>> IIRC there is actually no limit on RSA key size, it's only symmetric >>>> algs that are limited, so we could use a standard 2048 bit key without >>>> issue. >>>> >>>> >>>> >>>> Stuart >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>>> stuart.w.douglas at gmail.com> wrote: >>>>> >>>>>> So I guess we should talk about how this should actually work. >>>>>> >>>>>> In terms of auto generating the key I was thinking we would need to >>>>>> add a new attribute to the 'keystore' element under the security realm, >>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>>> other options we would need, or how configurable we should make it, but as >>>>>> this is for testing/development purposes I don't think we need to expose >>>>>> full control over the certificate generation process. >>>>>> >>>>>> In terms of the implementation we could just implement an SSLContext >>>>>> wrapper, that can do the generation and then create a 'real' SSLContext the >>>>>> first time it is asked to create and SSLEngine. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>> wrote: >>>>>>> > >>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>> >> Hi All, >>>>>>> >> >>>>>>> >> I would like to propose that we add support for HTTP/2 out of the >>>>>>> box >>>>>>> >> in Wildfly 10.1. >>>>>>> >> >>>>>>> > >>>>>>> > This lowly user desperately wants a release containing the fix to >>>>>>> WFLY- >>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>> > bugs awaiting release. >>>>>>> > >>>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>>> pent up >>>>>>> > bug fixes be kept in mind. >>>>>>> >>>>>>> >>>>>>> Hi Harold, >>>>>>> >>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>> >>>>>>> -- >>>>>>> Jason T. Greene >>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/6293cd00/attachment-0001.html From mchoma at redhat.com Mon Jun 6 00:59:35 2016 From: mchoma at redhat.com (Martin Choma) Date: Mon, 6 Jun 2016 06:59:35 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: I realized, that autogenerated JKS keystore probably won't work for Oracle/OpenJDK java in FIPS mode because of https://issues.jboss.org/browse/JBEAP-3789 . On Fri, Jun 3, 2016 at 9:28 AM, Stuart Douglas wrote: > > > On Fri, 3 Jun 2016, 17:18 Martin Choma wrote: > >> Hi Stuart, >> >> I have couple of questions regarding self-signed certificate >> autogeneration: >> >> What happens, when autogenerated certificate expires? >> > > I think we would go for ten year expiry so that would not be an issue. The > developer could just delete the store and generate a new one anyway. > > How it will be decided if certificate should be autogenerate or not? >> > > An attribute in the management model would be needed to explicitly enable > it. > > > What will be default keysize? It has to be probably choosen to work also >> without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction >> Policy" >> > > Probably the largest that is supported without JCE. It does not matter > that much, self signed certs are inherently insecure, this is a developer > usability feature, not something that can be used in production. > > Stuart > > >> >> >> >> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >> stuart.w.douglas at gmail.com> wrote: >> >>> So I guess we should talk about how this should actually work. >>> >>> In terms of auto generating the key I was thinking we would need to add >>> a new attribute to the 'keystore' element under the security realm, >>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>> other options we would need, or how configurable we should make it, but as >>> this is for testing/development purposes I don't think we need to expose >>> full control over the certificate generation process. >>> >>> In terms of the implementation we could just implement an SSLContext >>> wrapper, that can do the generation and then create a 'real' SSLContext the >>> first time it is asked to create and SSLEngine. >>> >>> Stuart >>> >>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene >>> wrote: >>> >>>> >>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>> wrote: >>>> > >>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>> >> Hi All, >>>> >> >>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>> >> in Wildfly 10.1. >>>> >> >>>> > >>>> > This lowly user desperately wants a release containing the fix to >>>> WFLY- >>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>> > bugs awaiting release. >>>> > >>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>> > bug fixes be kept in mind. >>>> >>>> >>>> Hi Harold, >>>> >>>> That fix is already in master, so it will be included in 10.1. >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/ba1e5dee/attachment.html From mchoma at redhat.com Mon Jun 6 01:49:08 2016 From: mchoma at redhat.com (Martin Choma) Date: Mon, 6 Jun 2016 07:49:08 +0200 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <098c8edd-3abb-0458-7cd4-c193ca789c7d@jboss.com> References: <1464884984.2997.3.camel@muerte.net> <098c8edd-3abb-0458-7cd4-c193ca789c7d@jboss.com> Message-ID: Hi Darran, talking about enhancing certificate obtaining process, i wonder if https://letsencrypt.org/ for automation could be utilized. On Fri, Jun 3, 2016 at 6:11 PM, Darran Lofthouse wrote: > Enhancing TLS set up with features such as CSR generation and the > importing of the resulting signed certificates is something we are > working on. > > Regards, > Darran Lofthouse. > > > On 03/06/16 15:28, Jorge Sol?rzano wrote: > > IMO this feature should be oriented to sysadmins not just developers. Is > > there really added value for developers to use HTTPS or HTTPS/2? > > > > It should be easy for sysadmins to setup TLS/SSL with "production" > > quality, from the gereration of the CSR that has to be send to the CA to > > the generation of the keystore. > > > > BTW... how is the performance of HTTPS using pure Java vs Apache for > > example? is this feature oriented for developers because for use in > > production is not recommended? > > > > * > > Ing. Jorge Sol?rzano* > > about.me/jorsol > > < > https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links > > > > > > On Fri, Jun 3, 2016 at 3:52 AM, Toma? Cerar > > wrote: > > > > This is completely off topic for this thread, there was one earlier > > about what should go into 10.x.... > > > > Anywho, issue you mention was already resolved and hibernate updated > > in master some time ago. > > which means it will be in next release, whatever that release will > be. > > > > -- > > tomaz > > > > On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell > > wrote: > > > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > > > Hi All, > > > > > > I would like to propose that we add support for HTTP/2 out of > the box > > > in Wildfly 10.1. > > > > > > > This lowly user desperately wants a release containing the fix > > to WFLY- > > 6283 sooner rather than later. I'm sure other people have other > pet > > bugs awaiting release. > > > > I have no opinion on HTTP/2 being added other than to ask that > > pent up > > bug fixes be kept in mind. > > > > -- > > Harold Campbell > > > > > Roses are red; > > Violets are blue. > > I'm schizophrenic, > > And so am I. > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/eb7c7af4/attachment.html From hrupp at redhat.com Mon Jun 6 07:27:09 2016 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 06 Jun 2016 07:27:09 -0400 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <9F7B7636-B5E1-40B7-B2D1-7125549A1752@redhat.com> On 6 Jun 2016, at 0:59, Martin Choma wrote: > I realized, that autogenerated JKS keystore probably won't work for > Oracle/OpenJDK java in FIPS mode because of I think this is actually a feature and helps not to abuse the self-generation in production. From darran.lofthouse at jboss.com Mon Jun 6 08:02:16 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Jun 2016 13:02:16 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <098c8edd-3abb-0458-7cd4-c193ca789c7d@jboss.com> Message-ID: Lets no hijack Stuart's thread too much ;-) But yes we will need to review what end users could be working with and which certificate authorities they would want to interact with - the tooling needs to be around how users will actually want to use it. On 06/06/16 06:49, Martin Choma wrote: > Hi Darran, > > talking about enhancing certificate obtaining process, i wonder if > https://letsencrypt.org/ for automation could be utilized. > > On Fri, Jun 3, 2016 at 6:11 PM, Darran Lofthouse > > wrote: > > Enhancing TLS set up with features such as CSR generation and the > importing of the resulting signed certificates is something we are > working on. > > Regards, > Darran Lofthouse. > > > On 03/06/16 15:28, Jorge Sol?rzano wrote: > > IMO this feature should be oriented to sysadmins not just developers. Is > > there really added value for developers to use HTTPS or HTTPS/2? > > > > It should be easy for sysadmins to setup TLS/SSL with "production" > > quality, from the gereration of the CSR that has to be send to the CA to > > the generation of the keystore. > > > > BTW... how is the performance of HTTPS using pure Java vs Apache for > > example? is this feature oriented for developers because for use in > > production is not recommended? > > > > * > > Ing. Jorge Sol?rzano* > > about.me/jorsol > > > > > > > On Fri, Jun 3, 2016 at 3:52 AM, Toma? Cerar > > >> wrote: > > > > This is completely off topic for this thread, there was one earlier > > about what should go into 10.x.... > > > > Anywho, issue you mention was already resolved and hibernate updated > > in master some time ago. > > which means it will be in next release, whatever that release will be. > > > > -- > > tomaz > > > > On Thu, Jun 2, 2016 at 6:29 PM, Harold Campbell > > >> wrote: > > > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > > > Hi All, > > > > > > I would like to propose that we add support for HTTP/2 out of the box > > > in Wildfly 10.1. > > > > > > > This lowly user desperately wants a release containing the fix > > to WFLY- > > 6283 sooner rather than later. I'm sure other people have other pet > > bugs awaiting release. > > > > I have no opinion on HTTP/2 being added other than to ask that > > pent up > > bug fixes be kept in mind. > > > > -- > > Harold Campbell >> > > > > Roses are red; > > Violets are blue. > > I'm schizophrenic, > > And so am I. > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From darran.lofthouse at jboss.com Mon Jun 6 08:04:17 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Jun 2016 13:04:17 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <9F7B7636-B5E1-40B7-B2D1-7125549A1752@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <9F7B7636-B5E1-40B7-B2D1-7125549A1752@redhat.com> Message-ID: <465f3152-e13d-7518-8ca7-c2ce8bafbf42@jboss.com> +1 An automatically generated self signed certificate should never be usable on a FIPS installation out of the box. On 06/06/16 12:27, Heiko W.Rupp wrote: > On 6 Jun 2016, at 0:59, Martin Choma wrote: > >> I realized, that autogenerated JKS keystore probably won't work for >> Oracle/OpenJDK java in FIPS mode because of > > I think this is actually a feature and helps not to abuse the > self-generation in production. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Mon Jun 6 08:13:14 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Jun 2016 13:13:14 +0100 Subject: [wildfly-dev] Elytron Subsystem Review Message-ID: At some point (unless Jason agrees core does not need the subsystem) we are going to be looking to move the Elytron subsystem over from it's isolated repository into the wildfly-core repository, to make that process less painful and also to start giving other teams more confidence in it's stability I was thinking if we should start reviewing the subsystem early. This isn't a call for everyone to check out the whole subsystem and comment on it all as we know there are some resources in there still to be re-worked. However on the Elytron team we know which pieces are stable / reaching stability so I was thinking if we were to start grouping related resource maybe by capability we could set up some smaller reviews. Ideally then when I submit the PR to merge into wildfly-core the actual content of the subsystem should be reviewed already and the review of that PR should be more about how it is fitting into the wildfly-core maven project structure. If others are interested in this I will see how we can start to chop it into review-able chunks. Regards, Darran Lofthouse. From jason.greene at redhat.com Mon Jun 6 08:24:00 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Mon, 6 Jun 2016 08:24:00 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> Message-ID: <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> Awesome! Another idea I had on how we could get away with it being in server boot, is to have a pre-boot first time setup task, either launched from the shell/batch scripts or as a special pre-step before the AS module loads. We could then report boot time as the time AFTER first time installation tasks have completed, which I think is fair because the server hasn't yet been started. > On Jun 5, 2016, at 11:53 PM, Stuart Douglas wrote: > > I have some initial work on this at: https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 > > If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed). > > Stuart > >> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas wrote: >> I think that would actually end up being more complex. >> >> Stuart >> >>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene wrote: >>> Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help >>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas wrote: >>>> >>>> 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). >>>> >>>> This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. >>>> >>>> Stuart >>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene wrote: >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we have already seen it grow and this would be yet another case. >>>>> >>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas wrote: >>>>>> >>>>>> So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: >>>>>>> >>>>>>>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>>>>>>> >>>>>>>> >>>>>>>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >>>>>>> >>>>>>> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >>>>>>>>> >>>>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>>>> >>>>>>>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>>>>>>> >>>>>>>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>>>>>>>>> >>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>>>>>>>>> > >>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>> >> Hi All, >>>>>>>>>>> >> >>>>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>> >> in Wildfly 10.1. >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>> > bugs awaiting release. >>>>>>>>>>> > >>>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>> > bug fixes be kept in mind. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Harold, >>>>>>>>>>> >>>>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jason T. Greene >>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160606/65013c86/attachment.html From jason.greene at redhat.com Mon Jun 6 08:51:50 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Mon, 6 Jun 2016 08:51:50 -0400 (EDT) Subject: [wildfly-dev] Elytron Subsystem Review In-Reply-To: References: Message-ID: <17E80490-0ACC-48C9-B0E8-2767D3A26CC7@redhat.com> > On Jun 6, 2016, at 7:13 AM, Darran Lofthouse wrote: > > At some point (unless Jason agrees core does not need the subsystem) Did someone make that argument? It seems to me it has to be in core because it replaces security realms? From darran.lofthouse at jboss.com Mon Jun 6 09:00:21 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Jun 2016 14:00:21 +0100 Subject: [wildfly-dev] Elytron Subsystem Review In-Reply-To: <17E80490-0ACC-48C9-B0E8-2767D3A26CC7@redhat.com> References: <17E80490-0ACC-48C9-B0E8-2767D3A26CC7@redhat.com> Message-ID: On 06/06/16 13:51, Jason T. Greene wrote: > > >> On Jun 6, 2016, at 7:13 AM, Darran Lofthouse wrote: >> >> At some point (unless Jason agrees core does not need the subsystem) > > Did someone make that argument? > > It seems to me it has to be in core because it replaces security realms? > As it stands today the Elytron subsystem is optional until the point where you release a distribution that you want to secure using it. So core contains the Elytron module and references items from the Elytron subsystem as capabilities. The legacy security realms are going to be staying around for a while allowing either new or old to be used. WildFly on the other hand could pull in the Elytron subsystem and contain default configuration for the feature packs entirely backed by Elytron. So really do we have a requirement at the moment to release a distribution based on core? From what I hear many other distributions still slim WildFly rather than add to core. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Mon Jun 6 15:26:54 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Jun 2016 14:26:54 -0500 Subject: [wildfly-dev] adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime In-Reply-To: <320939ba-369a-b80e-f7d5-532d78aaf38c@redhat.com> References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com> <0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com> <2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com> <673f9b90-e26f-bd2b-3567-8c07ba680d67@redhat.com> <320939ba-369a-b80e-f7d5-532d78aaf38c@redhat.com> Message-ID: On 5/31/16 6:04 PM, Scott Marlow wrote: > > On 05/31/2016 04:48 PM, Scott Marlow wrote: >> >> >> On 05/27/2016 10:19 AM, Scott Marlow wrote: >>> >>> >>> On 05/27/2016 09:33 AM, Brian Stansberry wrote: >>>> Can a new profile be added post-boot without requiring a reload to take >>>> effect? If yes, the add handler for the profile resource should do the >>>> service installation for that profile. It shouldn't count on the parent >>>> to do it, as the parent logic will only execute during boot. >>> >>> I like the idea of adding a new profile post-boot, without requiring a >>> reload of all of the profiles defined by the MongoDB/Cassandra >>> subsystem. >> >> I need to back up on my response. What does it mean for adding a new >> profile without requiring a reload? Does that require a hot change to >> the NoSQL profile service without undeploying the application? > > After refreshing on > https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates, > I think currently, we should specify that a reload (all-services) is > needed when adding/removing profiles. > Ok. I was on vacation, so sorry for no reply. I don't fully understand what these services are doing, so my only comment is that it's ok (and common) to require a reload for a remove but not for an add. A removal can disrupt other services while an add often doesn't. >> >>> >>> Currently, the standalone*.xml might contain: >>> >>> >>> >> jndi-name="java:jboss/mongodb/test" database="mongotestdb"> >>> >>> >>> >> jndi-name="java:jboss/mongodb/diary" database="diarydb"> >>> >>> >>> >>> >>> If the user wants to add an additional profile to the mongodb subsystem, >>> I think it would be worth us making the code changes to allow that. >>> Will be great to add a new "otherDB", without stopping the existing >>> database profiles. >>> >>> For supporting "remove" of an existing profile, I think that we will >>> need dependencies added on the underlying >>> MongoDriverService/CassandraDriverService, will be very worthwhile to >>> have that as well! Great feedback! :-) >>> >>>> >>>> BTW, if post-boot profile adds/removes don't require reload, then [1] >>>> should not be inside the "if >>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block? >>> >>> Makes sense, looks like we need a remove handler also for the profile >>> resource. >>> >>>> Same >>>> question applies for the cassandra add handler. >>> >>> We should change the cassandra add handler also. >>> >>> Thanks again, >>> Scott >>> >>>> >>>> [1] >>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124 >>>> >>>> >>>> On 5/26/16 3:02 PM, Scott Marlow wrote: >>>>> Hi, >>>>> >>>>> We will soon add several (nested) NoSQL configuration settings. >>>>> Before >>>>> we do that, I would like some feedback on the current NoSQL subsystem >>>>> code that reads connection settings. >>>>> >>>>> Any major corrections that you can suggest for the NoSQL subsystem >>>>> code >>>>> [1][2]? Especially, the >>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime >>>>> >>>>> methods. >>>>> >>>>> Should we continue to read all of the configuration settings from one >>>>> AddStepHandler or should we do that differently (perhaps with separate >>>>> AbstractAddStepHandler's)? >>>>> >>>>> Thanks, >>>>> Scott >>>>> >>>>> [1] >>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra >>>>> >>>>> >>>>> [2] >>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jun 6 17:28:12 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Jun 2016 16:28:12 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> Message-ID: <7e2144e3-780f-75c7-fa25-4ecd302628be@redhat.com> Darran, Do you have any concerns about supporting an equivalent-or-better variant of this in the Elytron subsystem for core 3.0 / WildFly 11? AIUI the change Stuart describes below will become a "legacy" feature once Elytron is in, so if people want to use Elytron (which we very much want and it's our planned default) they'll want an equivalent feature. I know you guys are planning to do stuff like this; I just want to confirm it will be done for 11, since otherwise not having it will be a barrier to people moving off the old stuff. On 6/2/16 3:01 PM, Stuart Douglas wrote: > So I guess we should talk about how this should actually work. > > In terms of auto generating the key I was thinking we would need to add > a new attribute to the 'keystore' element under the security realm, > something like 'auto-generate-cert-host="localhost"'. I am not sure what > other options we would need, or how configurable we should make it, but > as this is for testing/development purposes I don't think we need to > expose full control over the certificate generation process. > > In terms of the implementation we could just implement an SSLContext > wrapper, that can do the generation and then create a 'real' SSLContext > the first time it is asked to create and SSLEngine. > > Stuart > > On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene > wrote: > > > > On Jun 2, 2016, at 11:29 AM, Harold Campbell > wrote: > > > > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: > >> Hi All, > >> > >> I would like to propose that we add support for HTTP/2 out of the box > >> in Wildfly 10.1. > >> > > > > This lowly user desperately wants a release containing the fix to WFLY- > > 6283 sooner rather than later. I'm sure other people have other pet > > bugs awaiting release. > > > > I have no opinion on HTTP/2 being added other than to ask that pent up > > bug fixes be kept in mind. > > > Hi Harold, > > That fix is already in master, so it will be included in 10.1. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Mon Jun 6 23:48:33 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 7 Jun 2016 13:48:33 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> Message-ID: So while implementing this I have noticed a potential problem that it would be good to get some feedback on. If the management interface has SSL by default then the HTTP interface will always redirect to the HTTPS interface. This effectively breaks the management API, as clients such as the CLI, Arquillian etc will be redirected to HTTPS, and then reject the self signed certificate (as they should). I am not sure what to do about this, these are the options as I see them: 1) Don't enable SSL for the management interface (just for the Undertow subsystem). The management interface can still use this auto-generation capability, it just won't be enable by default (we could even leave the cert in the security domain, but just not enable the https interface). 2) Disable automatic redirects for HTTP upgrade requests (potentially controlled by an attribute). This will allow the CLI etc to work, but at the price of potentially reducing security, as some connections that would have previously been redirected to use HTTPS will no longer do this. 3) Enable it by default and leave it broken. We can setup some kind of automatic trust store thing so the local CLI works, and can get our test suite to work with Arquillian in a similar manner. Personally I think this is a terrible idea, but I am including it for completeness. Personally I think we should go for 1). Given that this is supposed to be about developer usability I don't think having management also use SSL as being that important. Stuart On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene wrote: > Awesome! Another idea I had on how we could get away with it being in > server boot, is to have a pre-boot first time setup task, either launched > from the shell/batch scripts or as a special pre-step before the AS module > loads. We could then report boot time as the time AFTER first time > installation tasks have completed, which I think is fair because the server > hasn't yet been started. > > On Jun 5, 2016, at 11:53 PM, Stuart Douglas > wrote: > > I have some initial work on this at: > https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 > > If you go to https://localhost:9993 it will generate the certificate > (although all that will be served is a 404 page as the console is not > installed). > > Stuart > > On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> I think that would actually end up being more complex. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene > > wrote: >> >>> Another option could be a post boot task. So it's still eager but don't >>> block completed start. We'd still need to block Tls ports though. So maybe >>> this does not help >>> >>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>> wrote: >>> >>> 2048 bits adds close to a second to first boot on my machine (obviously >>> subsequent boots are unaffected). >>> >>> This is probably a bit much, I will work on getting a POC for the lazy >>> loading approach implemented. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene < >>> jason.greene at redhat.com> wrote: >>> >>>> We should really be generating 2048 bit keys. >>>> >>>> I don't like adding to our boot time, we have already seen it grow and >>>> this would be yet another case. >>>> >>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>> wrote: >>>> >>>> So I just did up a very quick prototype that generates self signed >>>> certificates on startup and it looks like the difference in startup time is >>>> negligible (at least when generating 1024 bit RSA keys). Even if the >>>> difference is measurable it only affects the very first startup. >>>> >>>> I think that in order to simplify the implementation of this it may be >>>> better to simply generate the key of first startup, instead of attempting >>>> to do it lazily. >>>> >>>> Stuart >>>> >>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >>>> jason.greene at redhat.com> wrote: >>>> >>>>> >>>>> What will be default keysize? It has to be probably choosen to work >>>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>>>> Jurisdiction Policy" >>>>>> >>>>> >>>>> Probably the largest that is supported without JCE. It does not matter >>>>> that much, self signed certs are inherently insecure, this is a developer >>>>> usability feature, not something that can be used in production. >>>>> >>>>> >>>>> IIRC there is actually no limit on RSA key size, it's only symmetric >>>>> algs that are limited, so we could use a standard 2048 bit key without >>>>> issue. >>>>> >>>>> >>>>> >>>>> Stuart >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>> >>>>>>> So I guess we should talk about how this should actually work. >>>>>>> >>>>>>> In terms of auto generating the key I was thinking we would need to >>>>>>> add a new attribute to the 'keystore' element under the security realm, >>>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>>>> other options we would need, or how configurable we should make it, but as >>>>>>> this is for testing/development purposes I don't think we need to expose >>>>>>> full control over the certificate generation process. >>>>>>> >>>>>>> In terms of the implementation we could just implement an SSLContext >>>>>>> wrapper, that can do the generation and then create a 'real' SSLContext the >>>>>>> first time it is asked to create and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene < >>>>>>> jason.greene at redhat.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>> >> Hi All, >>>>>>>> >> >>>>>>>> >> I would like to propose that we add support for HTTP/2 out of >>>>>>>> the box >>>>>>>> >> in Wildfly 10.1. >>>>>>>> >> >>>>>>>> > >>>>>>>> > This lowly user desperately wants a release containing the fix to >>>>>>>> WFLY- >>>>>>>> > 6283 sooner rather than later. I'm sure other people have other >>>>>>>> pet >>>>>>>> > bugs awaiting release. >>>>>>>> > >>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>>>> pent up >>>>>>>> > bug fixes be kept in mind. >>>>>>>> >>>>>>>> >>>>>>>> Hi Harold, >>>>>>>> >>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>> JBoss, a division of Red Hat >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160607/df46e7fd/attachment-0001.html From darran.lofthouse at jboss.com Tue Jun 7 05:16:50 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 10:16:50 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> Message-ID: I think #1 sounds better. As a client the CLI in interactive mode works well when presented with an untrusted certificate, problems will arise however with remote CLI, Maven plug-in, jconsole / Remoting-JMX etc... We can revisit the management clients later once we have migrated them to a common security architecutre. On 07/06/16 04:48, Stuart Douglas wrote: > So while implementing this I have noticed a potential problem that it > would be good to get some feedback on. > > If the management interface has SSL by default then the HTTP interface > will always redirect to the HTTPS interface. This effectively breaks the > management API, as clients such as the CLI, Arquillian etc will be > redirected to HTTPS, and then reject the self signed certificate (as > they should). > > I am not sure what to do about this, these are the options as I see them: > > 1) Don't enable SSL for the management interface (just for the Undertow > subsystem). The management interface can still use this auto-generation > capability, it just won't be enable by default (we could even leave the > cert in the security domain, but just not enable the https interface). > > 2) Disable automatic redirects for HTTP upgrade requests (potentially > controlled by an attribute). This will allow the CLI etc to work, but at > the price of potentially reducing security, as some connections that > would have previously been redirected to use HTTPS will no longer do this. > > 3) Enable it by default and leave it broken. We can setup some kind of > automatic trust store thing so the local CLI works, and can get our test > suite to work with Arquillian in a similar manner. Personally I think > this is a terrible idea, but I am including it for completeness. > > Personally I think we should go for 1). Given that this is supposed to > be about developer usability I don't think having management also use > SSL as being that important. > > Stuart > > On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene > > wrote: > > Awesome! Another idea I had on how we could get away with it being > in server boot, is to have a pre-boot first time setup task, either > launched from the shell/batch scripts or as a special pre-step > before the AS module loads. We could then report boot time as the > time AFTER first time installation tasks have completed, which I > think is fair because the server hasn't yet been started. > > On Jun 5, 2016, at 11:53 PM, Stuart Douglas > > wrote: > >> I have some initial work on this at: >> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >> >> If you go to https://localhost:9993 it will generate the >> certificate (although all that will be served is a 404 page as the >> console is not installed). >> >> Stuart >> >> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >> > >> wrote: >> >> I think that would actually end up being more complex. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >> > wrote: >> >> Another option could be a post boot task. So it's still >> eager but don't block completed start. We'd still need to >> block Tls ports though. So maybe this does not help >> >> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >> > > wrote: >> >>> 2048 bits adds close to a second to first boot on my >>> machine (obviously subsequent boots are unaffected). >>> >>> This is probably a bit much, I will work on getting a POC >>> for the lazy loading approach implemented. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>> >> > wrote: >>> >>> We should really be generating 2048 bit keys. >>> >>> I don't like adding to our boot time, we have already >>> seen it grow and this would be yet another case. >>> >>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>> >> > wrote: >>> >>>> So I just did up a very quick prototype that >>>> generates self signed certificates on startup and it >>>> looks like the difference in startup time is >>>> negligible (at least when generating 1024 bit RSA >>>> keys). Even if the difference is measurable it only >>>> affects the very first startup. >>>> >>>> I think that in order to simplify the implementation >>>> of this it may be better to simply generate the key >>>> of first startup, instead of attempting to do it >>>> lazily. >>>> >>>> Stuart >>>> >>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>> >>> > wrote: >>>> >>>> >>>>> What will be default keysize? It has to be >>>>> probably choosen to work also without "Java >>>>> Cryptography Extension (JCE) Unlimited >>>>> Strength Jurisdiction Policy" >>>>> >>>>> >>>>> Probably the largest that is supported without >>>>> JCE. It does not matter that much, self signed >>>>> certs are inherently insecure, this is a >>>>> developer usability feature, not something that >>>>> can be used in production. >>>> >>>> IIRC there is actually no limit on RSA key size, >>>> it's only symmetric algs that are limited, so we >>>> could use a standard 2048 bit key without issue. >>>> >>>> >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>> Douglas >>>> > wrote: >>>>> >>>>> So I guess we should talk about how >>>>> this should actually work. >>>>> >>>>> In terms of auto generating the key I >>>>> was thinking we would need to add a new >>>>> attribute to the 'keystore' element >>>>> under the security realm, something >>>>> like >>>>> 'auto-generate-cert-host="localhost"'. >>>>> I am not sure what other options we >>>>> would need, or how configurable we >>>>> should make it, but as this is for >>>>> testing/development purposes I don't >>>>> think we need to expose full control >>>>> over the certificate generation process. >>>>> >>>>> In terms of the implementation we could >>>>> just implement an SSLContext wrapper, >>>>> that can do the generation and then >>>>> create a 'real' SSLContext the first >>>>> time it is asked to create and SSLEngine. >>>>> >>>>> Stuart >>>>> >>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>> Greene >>>> > wrote: >>>>> >>>>> >>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>> > wrote: >>>>> > >>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>> >> Hi All, >>>>> >> >>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>> >> in Wildfly 10.1. >>>>> >> >>>>> > >>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>> > bugs awaiting release. >>>>> > >>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>> > bug fixes be kept in mind. >>>>> >>>>> >>>>> Hi Harold, >>>>> >>>>> That fix is already in master, so >>>>> it will be included in 10.1. >>>>> >>>>> -- >>>>> Jason T. Greene >>>>> WildFly Lead / JBoss EAP Platform >>>>> Architect >>>>> JBoss, a division of Red Hat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>> >> >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Tue Jun 7 05:19:04 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 10:19:04 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <7e2144e3-780f-75c7-fa25-4ecd302628be@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <7e2144e3-780f-75c7-fa25-4ecd302628be@redhat.com> Message-ID: <6aace8a2-bf74-b774-afe1-5733b9ecdb6c@jboss.com> Will re-review that later - but the legacy code will still be usable in WildFly 11. On 06/06/16 22:28, Brian Stansberry wrote: > Darran, > > Do you have any concerns about supporting an equivalent-or-better > variant of this in the Elytron subsystem for core 3.0 / WildFly 11? > > AIUI the change Stuart describes below will become a "legacy" feature > once Elytron is in, so if people want to use Elytron (which we very much > want and it's our planned default) they'll want an equivalent feature. > > I know you guys are planning to do stuff like this; I just want to > confirm it will be done for 11, since otherwise not having it will be a > barrier to people moving off the old stuff. > > On 6/2/16 3:01 PM, Stuart Douglas wrote: >> So I guess we should talk about how this should actually work. >> >> In terms of auto generating the key I was thinking we would need to add >> a new attribute to the 'keystore' element under the security realm, >> something like 'auto-generate-cert-host="localhost"'. I am not sure what >> other options we would need, or how configurable we should make it, but >> as this is for testing/development purposes I don't think we need to >> expose full control over the certificate generation process. >> >> In terms of the implementation we could just implement an SSLContext >> wrapper, that can do the generation and then create a 'real' SSLContext >> the first time it is asked to create and SSLEngine. >> >> Stuart >> >> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene > > wrote: >> >> >> > On Jun 2, 2016, at 11:29 AM, Harold Campbell > wrote: >> > >> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >> >> Hi All, >> >> >> >> I would like to propose that we add support for HTTP/2 out of the box >> >> in Wildfly 10.1. >> >> >> > >> > This lowly user desperately wants a release containing the fix to WFLY- >> > 6283 sooner rather than later. I'm sure other people have other pet >> > bugs awaiting release. >> > >> > I have no opinion on HTTP/2 being added other than to ask that pent up >> > bug fixes be kept in mind. >> >> >> Hi Harold, >> >> That fix is already in master, so it will be included in 10.1. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From darran.lofthouse at jboss.com Tue Jun 7 05:46:58 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 10:46:58 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> Message-ID: Just thinking if this is for out of the box development only purposes, maybe this would be better with a short validity period supporting localhost only. That way they can get up and running quickly but still need to take action to do it properly. I think a long validity period with automatic host name detection leaves more chance of this making it into production. On 07/06/16 10:16, Darran Lofthouse wrote: > I think #1 sounds better. > > As a client the CLI in interactive mode works well when presented with > an untrusted certificate, problems will arise however with remote CLI, > Maven plug-in, jconsole / Remoting-JMX etc... > > We can revisit the management clients later once we have migrated them > to a common security architecutre. > > On 07/06/16 04:48, Stuart Douglas wrote: >> So while implementing this I have noticed a potential problem that it >> would be good to get some feedback on. >> >> If the management interface has SSL by default then the HTTP interface >> will always redirect to the HTTPS interface. This effectively breaks the >> management API, as clients such as the CLI, Arquillian etc will be >> redirected to HTTPS, and then reject the self signed certificate (as >> they should). >> >> I am not sure what to do about this, these are the options as I see them: >> >> 1) Don't enable SSL for the management interface (just for the Undertow >> subsystem). The management interface can still use this auto-generation >> capability, it just won't be enable by default (we could even leave the >> cert in the security domain, but just not enable the https interface). >> >> 2) Disable automatic redirects for HTTP upgrade requests (potentially >> controlled by an attribute). This will allow the CLI etc to work, but at >> the price of potentially reducing security, as some connections that >> would have previously been redirected to use HTTPS will no longer do this. >> >> 3) Enable it by default and leave it broken. We can setup some kind of >> automatic trust store thing so the local CLI works, and can get our test >> suite to work with Arquillian in a similar manner. Personally I think >> this is a terrible idea, but I am including it for completeness. >> >> Personally I think we should go for 1). Given that this is supposed to >> be about developer usability I don't think having management also use >> SSL as being that important. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >> > wrote: >> >> Awesome! Another idea I had on how we could get away with it being >> in server boot, is to have a pre-boot first time setup task, either >> launched from the shell/batch scripts or as a special pre-step >> before the AS module loads. We could then report boot time as the >> time AFTER first time installation tasks have completed, which I >> think is fair because the server hasn't yet been started. >> >> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >> > wrote: >> >>> I have some initial work on this at: >>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>> >>> If you go to https://localhost:9993 it will generate the >>> certificate (although all that will be served is a 404 page as the >>> console is not installed). >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>> > >>> wrote: >>> >>> I think that would actually end up being more complex. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>> > wrote: >>> >>> Another option could be a post boot task. So it's still >>> eager but don't block completed start. We'd still need to >>> block Tls ports though. So maybe this does not help >>> >>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>> >> > wrote: >>> >>>> 2048 bits adds close to a second to first boot on my >>>> machine (obviously subsequent boots are unaffected). >>>> >>>> This is probably a bit much, I will work on getting a POC >>>> for the lazy loading approach implemented. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>> >>> > wrote: >>>> >>>> We should really be generating 2048 bit keys. >>>> >>>> I don't like adding to our boot time, we have already >>>> seen it grow and this would be yet another case. >>>> >>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> So I just did up a very quick prototype that >>>>> generates self signed certificates on startup and it >>>>> looks like the difference in startup time is >>>>> negligible (at least when generating 1024 bit RSA >>>>> keys). Even if the difference is measurable it only >>>>> affects the very first startup. >>>>> >>>>> I think that in order to simplify the implementation >>>>> of this it may be better to simply generate the key >>>>> of first startup, instead of attempting to do it >>>>> lazily. >>>>> >>>>> Stuart >>>>> >>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> >>>>>> What will be default keysize? It has to be >>>>>> probably choosen to work also without "Java >>>>>> Cryptography Extension (JCE) Unlimited >>>>>> Strength Jurisdiction Policy" >>>>>> >>>>>> >>>>>> Probably the largest that is supported without >>>>>> JCE. It does not matter that much, self signed >>>>>> certs are inherently insecure, this is a >>>>>> developer usability feature, not something that >>>>>> can be used in production. >>>>> >>>>> IIRC there is actually no limit on RSA key size, >>>>> it's only symmetric algs that are limited, so we >>>>> could use a standard 2048 bit key without issue. >>>>> >>>>> >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>> Douglas >>>>> > wrote: >>>>>> >>>>>> So I guess we should talk about how >>>>>> this should actually work. >>>>>> >>>>>> In terms of auto generating the key I >>>>>> was thinking we would need to add a new >>>>>> attribute to the 'keystore' element >>>>>> under the security realm, something >>>>>> like >>>>>> 'auto-generate-cert-host="localhost"'. >>>>>> I am not sure what other options we >>>>>> would need, or how configurable we >>>>>> should make it, but as this is for >>>>>> testing/development purposes I don't >>>>>> think we need to expose full control >>>>>> over the certificate generation process. >>>>>> >>>>>> In terms of the implementation we could >>>>>> just implement an SSLContext wrapper, >>>>>> that can do the generation and then >>>>>> create a 'real' SSLContext the first >>>>>> time it is asked to create and SSLEngine. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>> Greene >>>>> > wrote: >>>>>> >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>> > wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so >>>>>> it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform >>>>>> Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>> >>> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Tue Jun 7 07:24:42 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 7 Jun 2016 07:24:42 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> Message-ID: <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> Long term I think we want management using TLS, but that can of course come in phases. Assuming 2) is one of those phases to come (either now or later), a following step is that the CLI, and really any remoting client, should prefer TLS with a defaulted trust store location that points to the keystore. With 2) if we have the default of the attribute that forces redirect be true, and our default config be false, then someone that carries over their old config would not have a potential security weakness. If they have a CLI script that adds the https port, it will fail, hopefully sending a signal to look. Although, the user might just assume that oh it's there, I don't have to do anything. Another interesting thing about 2 is that IIRC we have conflicting behavior between the app port which doesn't force upgrade and the management port which does. So my preference is 2, because at some point we have to do it anyway, and if we have TLS out of the box might as well use it. On Jun 6, 2016, at 10:48 PM, Stuart Douglas wrote: > So while implementing this I have noticed a potential problem that it would be good to get some feedback on. > > If the management interface has SSL by default then the HTTP interface will always redirect to the HTTPS interface. This effectively breaks the management API, as clients such as the CLI, Arquillian etc will be redirected to HTTPS, and then reject the self signed certificate (as they should). > > I am not sure what to do about this, these are the options as I see them: > > 1) Don't enable SSL for the management interface (just for the Undertow subsystem). The management interface can still use this auto-generation capability, it just won't be enable by default (we could even leave the cert in the security domain, but just not enable the https interface). > > 2) Disable automatic redirects for HTTP upgrade requests (potentially controlled by an attribute). This will allow the CLI etc to work, but at the price of potentially reducing security, as some connections that would have previously been redirected to use HTTPS will no longer do this. > > 3) Enable it by default and leave it broken. We can setup some kind of automatic trust store thing so the local CLI works, and can get our test suite to work with Arquillian in a similar manner. Personally I think this is a terrible idea, but I am including it for completeness. > > Personally I think we should go for 1). Given that this is supposed to be about developer usability I don't think having management also use SSL as being that important. > > Stuart > >> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene wrote: >> Awesome! Another idea I had on how we could get away with it being in server boot, is to have a pre-boot first time setup task, either launched from the shell/batch scripts or as a special pre-step before the AS module loads. We could then report boot time as the time AFTER first time installation tasks have completed, which I think is fair because the server hasn't yet been started. >> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas wrote: >>> >>> I have some initial work on this at: https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>> >>> If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed). >>> >>> Stuart >>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas wrote: >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene wrote: >>>>> Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help >>>>> >>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas wrote: >>>>>> >>>>>> 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). >>>>>> >>>>>> This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. >>>>>> >>>>>> Stuart >>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene wrote: >>>>>>> We should really be generating 2048 bit keys. >>>>>>> >>>>>>> I don't like adding to our boot time, we have already seen it grow and this would be yet another case. >>>>>>> >>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas wrote: >>>>>>>> >>>>>>>> So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. >>>>>>>> >>>>>>>> I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: >>>>>>>>> >>>>>>>>>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >>>>>>>>> >>>>>>>>> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >>>>>>>>>>> >>>>>>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>>>>>> >>>>>>>>>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>>>>>>>>> >>>>>>>>>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>>>>>>>>> >>>>>>>>>>>> Stuart >>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>>>> >> Hi All, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>>>> >> in Wildfly 10.1. >>>>>>>>>>>>> >> >>>>>>>>>>>>> > >>>>>>>>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>>>> > bugs awaiting release. >>>>>>>>>>>>> > >>>>>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>>>> > bug fixes be kept in mind. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Harold, >>>>>>>>>>>>> >>>>>>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Jason T. Greene >>>>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160607/f42ce136/attachment.html From darran.lofthouse at jboss.com Tue Jun 7 07:32:57 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 12:32:57 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> Message-ID: <135d0493-3955-2ecc-06f6-5c36caf6de9a@jboss.com> On 07/06/16 12:24, Jason T. Greene wrote: > Long term I think we want management using TLS, but that can of course > come in phases. Assuming 2) is one of those phases to come (either now > or later), a following step is that the CLI, and really any remoting > client, should prefer TLS with a defaulted trust store location that > points to the keystore. > > With 2) if we have the default of the attribute that forces redirect be > true, and our default config be false, then someone that carries over > their old config would not have a potential security weakness. If they > have a CLI script that adds the https port, it will fail, hopefully > sending a signal to look. Although, the user might just assume that oh > it's there, I don't have to do anything. > > Another interesting thing about 2 is that IIRC we have conflicting > behavior between the app port which doesn't force upgrade and the > management port which does. In applications you configure which paths require a confidential transport guarantee so you can be selective. For managements all requests come over a single path so if you switch on SSL why not use it for the one and only path containing your sensitive requests. > So my preference is 2, because at some point we have to do it anyway, > and if we have TLS out of the box might as well use it. > > On Jun 6, 2016, at 10:48 PM, Stuart Douglas > wrote: > >> So while implementing this I have noticed a potential problem that it >> would be good to get some feedback on. >> >> If the management interface has SSL by default then the HTTP interface >> will always redirect to the HTTPS interface. This effectively breaks >> the management API, as clients such as the CLI, Arquillian etc will be >> redirected to HTTPS, and then reject the self signed certificate (as >> they should). >> >> I am not sure what to do about this, these are the options as I see them: >> >> 1) Don't enable SSL for the management interface (just for the >> Undertow subsystem). The management interface can still use this >> auto-generation capability, it just won't be enable by default (we >> could even leave the cert in the security domain, but just not enable >> the https interface). >> >> 2) Disable automatic redirects for HTTP upgrade requests (potentially >> controlled by an attribute). This will allow the CLI etc to work, but >> at the price of potentially reducing security, as some connections >> that would have previously been redirected to use HTTPS will no longer >> do this. >> >> 3) Enable it by default and leave it broken. We can setup some kind of >> automatic trust store thing so the local CLI works, and can get our >> test suite to work with Arquillian in a similar manner. Personally I >> think this is a terrible idea, but I am including it for completeness. >> >> Personally I think we should go for 1). Given that this is supposed to >> be about developer usability I don't think having management also use >> SSL as being that important. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >> > wrote: >> >> Awesome! Another idea I had on how we could get away with it being >> in server boot, is to have a pre-boot first time setup task, >> either launched from the shell/batch scripts or as a special >> pre-step before the AS module loads. We could then report boot >> time as the time AFTER first time installation tasks have >> completed, which I think is fair because the server hasn't yet >> been started. >> >> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >> > >> wrote: >> >>> I have some initial work on this at: >>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>> >>> If you go to https://localhost:9993 it will generate the >>> certificate (although all that will be served is a 404 page as >>> the console is not installed). >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>> > >>> wrote: >>> >>> I think that would actually end up being more complex. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>> > wrote: >>> >>> Another option could be a post boot task. So it's still >>> eager but don't block completed start. We'd still need to >>> block Tls ports though. So maybe this does not help >>> >>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>> >> > wrote: >>> >>>> 2048 bits adds close to a second to first boot on my >>>> machine (obviously subsequent boots are unaffected). >>>> >>>> This is probably a bit much, I will work on getting a >>>> POC for the lazy loading approach implemented. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>> >>> > wrote: >>>> >>>> We should really be generating 2048 bit keys. >>>> >>>> I don't like adding to our boot time, we have >>>> already seen it grow and this would be yet another case. >>>> >>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> So I just did up a very quick prototype that >>>>> generates self signed certificates on startup and >>>>> it looks like the difference in startup time is >>>>> negligible (at least when generating 1024 bit RSA >>>>> keys). Even if the difference is measurable it only >>>>> affects the very first startup. >>>>> >>>>> I think that in order to simplify the >>>>> implementation of this it may be better to simply >>>>> generate the key of first startup, instead of >>>>> attempting to do it lazily. >>>>> >>>>> Stuart >>>>> >>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> >>>>>> What will be default keysize? It has to be >>>>>> probably choosen to work also without >>>>>> "Java Cryptography Extension (JCE) >>>>>> Unlimited Strength Jurisdiction Policy" >>>>>> >>>>>> >>>>>> Probably the largest that is supported without >>>>>> JCE. It does not matter that much, self signed >>>>>> certs are inherently insecure, this is a >>>>>> developer usability feature, not something >>>>>> that can be used in production. >>>>> >>>>> IIRC there is actually no limit on RSA key >>>>> size, it's only symmetric algs that are >>>>> limited, so we could use a standard 2048 bit >>>>> key without issue. >>>>> >>>>> >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>> Douglas >>>>> > wrote: >>>>>> >>>>>> So I guess we should talk about how >>>>>> this should actually work. >>>>>> >>>>>> In terms of auto generating the key I >>>>>> was thinking we would need to add a >>>>>> new attribute to the 'keystore' >>>>>> element under the security realm, >>>>>> something like >>>>>> 'auto-generate-cert-host="localhost"'. >>>>>> I am not sure what other options we >>>>>> would need, or how configurable we >>>>>> should make it, but as this is for >>>>>> testing/development purposes I don't >>>>>> think we need to expose full control >>>>>> over the certificate generation process. >>>>>> >>>>>> In terms of the implementation we >>>>>> could just implement an SSLContext >>>>>> wrapper, that can do the generation >>>>>> and then create a 'real' SSLContext >>>>>> the first time it is asked to create >>>>>> and SSLEngine. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>> Greene >>>>> > wrote: >>>>>> >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>> > wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so >>>>>> it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform >>>>>> Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>> >>> >>> >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Tue Jun 7 07:47:59 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 7 Jun 2016 07:47:59 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <135d0493-3955-2ecc-06f6-5c36caf6de9a@jboss.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <135d0493-3955-2ecc! -06f6-5c36caf6de9a@jboss.com> Message-ID: > On Jun 7, 2016, at 6:33 AM, Darran Lofthouse wrote: > > > >> On 07/06/16 12:24, Jason T. Greene wrote: >> Long term I think we want management using TLS, but that can of course >> come in phases. Assuming 2) is one of those phases to come (either now >> or later), a following step is that the CLI, and really any remoting >> client, should prefer TLS with a defaulted trust store location that >> points to the keystore. >> >> With 2) if we have the default of the attribute that forces redirect be >> true, and our default config be false, then someone that carries over >> their old config would not have a potential security weakness. If they >> have a CLI script that adds the https port, it will fail, hopefully >> sending a signal to look. Although, the user might just assume that oh >> it's there, I don't have to do anything. >> >> Another interesting thing about 2 is that IIRC we have conflicting >> behavior between the app port which doesn't force upgrade and the >> management port which does. > > In applications you configure which paths require a confidential > transport guarantee so you can be selective. > > For managements all requests come over a single path so if you switch on > SSL why not use it for the one and only path containing your sensitive > requests. Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. > >> So my preference is 2, because at some point we have to do it anyway, >> and if we have TLS out of the box might as well use it. >> >> On Jun 6, 2016, at 10:48 PM, Stuart Douglas > > wrote: >> >>> So while implementing this I have noticed a potential problem that it >>> would be good to get some feedback on. >>> >>> If the management interface has SSL by default then the HTTP interface >>> will always redirect to the HTTPS interface. This effectively breaks >>> the management API, as clients such as the CLI, Arquillian etc will be >>> redirected to HTTPS, and then reject the self signed certificate (as >>> they should). >>> >>> I am not sure what to do about this, these are the options as I see them: >>> >>> 1) Don't enable SSL for the management interface (just for the >>> Undertow subsystem). The management interface can still use this >>> auto-generation capability, it just won't be enable by default (we >>> could even leave the cert in the security domain, but just not enable >>> the https interface). >>> >>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>> controlled by an attribute). This will allow the CLI etc to work, but >>> at the price of potentially reducing security, as some connections >>> that would have previously been redirected to use HTTPS will no longer >>> do this. >>> >>> 3) Enable it by default and leave it broken. We can setup some kind of >>> automatic trust store thing so the local CLI works, and can get our >>> test suite to work with Arquillian in a similar manner. Personally I >>> think this is a terrible idea, but I am including it for completeness. >>> >>> Personally I think we should go for 1). Given that this is supposed to >>> be about developer usability I don't think having management also use >>> SSL as being that important. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>> > wrote: >>> >>> Awesome! Another idea I had on how we could get away with it being >>> in server boot, is to have a pre-boot first time setup task, >>> either launched from the shell/batch scripts or as a special >>> pre-step before the AS module loads. We could then report boot >>> time as the time AFTER first time installation tasks have >>> completed, which I think is fair because the server hasn't yet >>> been started. >>> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>> > >>> wrote: >>> >>>> I have some initial work on this at: >>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>> >>>> If you go to https://localhost:9993 it will generate the >>>> certificate (although all that will be served is a 404 page as >>>> the console is not installed). >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>> > >>>> wrote: >>>> >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>> > wrote: >>>> >>>> Another option could be a post boot task. So it's still >>>> eager but don't block completed start. We'd still need to >>>> block Tls ports though. So maybe this does not help >>>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> 2048 bits adds close to a second to first boot on my >>>>> machine (obviously subsequent boots are unaffected). >>>>> >>>>> This is probably a bit much, I will work on getting a >>>>> POC for the lazy loading approach implemented. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we have >>>>> already seen it grow and this would be yet another case. >>>>> >>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> So I just did up a very quick prototype that >>>>>> generates self signed certificates on startup and >>>>>> it looks like the difference in startup time is >>>>>> negligible (at least when generating 1024 bit RSA >>>>>> keys). Even if the difference is measurable it only >>>>>> affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the >>>>>> implementation of this it may be better to simply >>>>>> generate the key of first startup, instead of >>>>>> attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>>> What will be default keysize? It has to be >>>>>>> probably choosen to work also without >>>>>>> "Java Cryptography Extension (JCE) >>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>> >>>>>>> >>>>>>> Probably the largest that is supported without >>>>>>> JCE. It does not matter that much, self signed >>>>>>> certs are inherently insecure, this is a >>>>>>> developer usability feature, not something >>>>>>> that can be used in production. >>>>>> >>>>>> IIRC there is actually no limit on RSA key >>>>>> size, it's only symmetric algs that are >>>>>> limited, so we could use a standard 2048 bit >>>>>> key without issue. >>>>>> >>>>>> >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>> Douglas >>>>>> > wrote: >>>>>>> >>>>>>> So I guess we should talk about how >>>>>>> this should actually work. >>>>>>> >>>>>>> In terms of auto generating the key I >>>>>>> was thinking we would need to add a >>>>>>> new attribute to the 'keystore' >>>>>>> element under the security realm, >>>>>>> something like >>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>> I am not sure what other options we >>>>>>> would need, or how configurable we >>>>>>> should make it, but as this is for >>>>>>> testing/development purposes I don't >>>>>>> think we need to expose full control >>>>>>> over the certificate generation process. >>>>>>> >>>>>>> In terms of the implementation we >>>>>>> could just implement an SSLContext >>>>>>> wrapper, that can do the generation >>>>>>> and then create a 'real' SSLContext >>>>>>> the first time it is asked to create >>>>>>> and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>> Greene >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>> in Wildfly 10.1. >>>>>>>> >>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>> bugs awaiting release. >>>>>>>> >>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>> bug fixes be kept in mind. >>>>>>> >>>>>>> >>>>>>> Hi Harold, >>>>>>> >>>>>>> That fix is already in master, so >>>>>>> it will be included in 10.1. >>>>>>> >>>>>>> -- >>>>>>> Jason T. Greene >>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>> Architect >>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Tue Jun 7 07:55:35 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 12:55:35 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <135d0493-3955-2ecc! -06f6-5c36caf6de9a@jboss.com> Message-ID: <6d6d8c25-12c2-f33f-40a8-9c12b98a429f@jboss.com> On 07/06/16 12:47, Jason T. Greene wrote: > > >> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse wrote: >> >> >> >>> On 07/06/16 12:24, Jason T. Greene wrote: >>> Long term I think we want management using TLS, but that can of course >>> come in phases. Assuming 2) is one of those phases to come (either now >>> or later), a following step is that the CLI, and really any remoting >>> client, should prefer TLS with a defaulted trust store location that >>> points to the keystore. >>> >>> With 2) if we have the default of the attribute that forces redirect be >>> true, and our default config be false, then someone that carries over >>> their old config would not have a potential security weakness. If they >>> have a CLI script that adds the https port, it will fail, hopefully >>> sending a signal to look. Although, the user might just assume that oh >>> it's there, I don't have to do anything. >>> >>> Another interesting thing about 2 is that IIRC we have conflicting >>> behavior between the app port which doesn't force upgrade and the >>> management port which does. >> >> In applications you configure which paths require a confidential >> transport guarantee so you can be selective. >> >> For managements all requests come over a single path so if you switch on >> SSL why not use it for the one and only path containing your sensitive >> requests. > > Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. But on the management port we still only have a single "app" using HTTP upgrade. > >> >>> So my preference is 2, because at some point we have to do it anyway, >>> and if we have TLS out of the box might as well use it. >>> >>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >> > wrote: >>> >>>> So while implementing this I have noticed a potential problem that it >>>> would be good to get some feedback on. >>>> >>>> If the management interface has SSL by default then the HTTP interface >>>> will always redirect to the HTTPS interface. This effectively breaks >>>> the management API, as clients such as the CLI, Arquillian etc will be >>>> redirected to HTTPS, and then reject the self signed certificate (as >>>> they should). >>>> >>>> I am not sure what to do about this, these are the options as I see them: >>>> >>>> 1) Don't enable SSL for the management interface (just for the >>>> Undertow subsystem). The management interface can still use this >>>> auto-generation capability, it just won't be enable by default (we >>>> could even leave the cert in the security domain, but just not enable >>>> the https interface). >>>> >>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>> controlled by an attribute). This will allow the CLI etc to work, but >>>> at the price of potentially reducing security, as some connections >>>> that would have previously been redirected to use HTTPS will no longer >>>> do this. >>>> >>>> 3) Enable it by default and leave it broken. We can setup some kind of >>>> automatic trust store thing so the local CLI works, and can get our >>>> test suite to work with Arquillian in a similar manner. Personally I >>>> think this is a terrible idea, but I am including it for completeness. >>>> >>>> Personally I think we should go for 1). Given that this is supposed to >>>> be about developer usability I don't think having management also use >>>> SSL as being that important. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>> > wrote: >>>> >>>> Awesome! Another idea I had on how we could get away with it being >>>> in server boot, is to have a pre-boot first time setup task, >>>> either launched from the shell/batch scripts or as a special >>>> pre-step before the AS module loads. We could then report boot >>>> time as the time AFTER first time installation tasks have >>>> completed, which I think is fair because the server hasn't yet >>>> been started. >>>> >>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>> > >>>> wrote: >>>> >>>>> I have some initial work on this at: >>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>> >>>>> If you go to https://localhost:9993 it will generate the >>>>> certificate (although all that will be served is a 404 page as >>>>> the console is not installed). >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>> > >>>>> wrote: >>>>> >>>>> I think that would actually end up being more complex. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>> > wrote: >>>>> >>>>> Another option could be a post boot task. So it's still >>>>> eager but don't block completed start. We'd still need to >>>>> block Tls ports though. So maybe this does not help >>>>> >>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> 2048 bits adds close to a second to first boot on my >>>>>> machine (obviously subsequent boots are unaffected). >>>>>> >>>>>> This is probably a bit much, I will work on getting a >>>>>> POC for the lazy loading approach implemented. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>> >>>>> > wrote: >>>>>> >>>>>> We should really be generating 2048 bit keys. >>>>>> >>>>>> I don't like adding to our boot time, we have >>>>>> already seen it grow and this would be yet another case. >>>>>> >>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>> >>>>> > wrote: >>>>>> >>>>>>> So I just did up a very quick prototype that >>>>>>> generates self signed certificates on startup and >>>>>>> it looks like the difference in startup time is >>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>> keys). Even if the difference is measurable it only >>>>>>> affects the very first startup. >>>>>>> >>>>>>> I think that in order to simplify the >>>>>>> implementation of this it may be better to simply >>>>>>> generate the key of first startup, instead of >>>>>>> attempting to do it lazily. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>>> What will be default keysize? It has to be >>>>>>>> probably choosen to work also without >>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>> >>>>>>>> >>>>>>>> Probably the largest that is supported without >>>>>>>> JCE. It does not matter that much, self signed >>>>>>>> certs are inherently insecure, this is a >>>>>>>> developer usability feature, not something >>>>>>>> that can be used in production. >>>>>>> >>>>>>> IIRC there is actually no limit on RSA key >>>>>>> size, it's only symmetric algs that are >>>>>>> limited, so we could use a standard 2048 bit >>>>>>> key without issue. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>> Douglas >>>>>>> > wrote: >>>>>>>> >>>>>>>> So I guess we should talk about how >>>>>>>> this should actually work. >>>>>>>> >>>>>>>> In terms of auto generating the key I >>>>>>>> was thinking we would need to add a >>>>>>>> new attribute to the 'keystore' >>>>>>>> element under the security realm, >>>>>>>> something like >>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>> I am not sure what other options we >>>>>>>> would need, or how configurable we >>>>>>>> should make it, but as this is for >>>>>>>> testing/development purposes I don't >>>>>>>> think we need to expose full control >>>>>>>> over the certificate generation process. >>>>>>>> >>>>>>>> In terms of the implementation we >>>>>>>> could just implement an SSLContext >>>>>>>> wrapper, that can do the generation >>>>>>>> and then create a 'real' SSLContext >>>>>>>> the first time it is asked to create >>>>>>>> and SSLEngine. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>> Greene >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>> in Wildfly 10.1. >>>>>>>>> >>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>> bugs awaiting release. >>>>>>>>> >>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>> bug fixes be kept in mind. >>>>>>>> >>>>>>>> >>>>>>>> Hi Harold, >>>>>>>> >>>>>>>> That fix is already in master, so >>>>>>>> it will be included in 10.1. >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>> Architect >>>>>>>> JBoss, a division of Red Hat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Tue Jun 7 08:00:05 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 7 Jun 2016 08:00:05 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <6d6d8c25-12c2-f33f-40a8-9c12b98a429f@jboss.com> References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <135d0493-3955-2ecc! -06f6-5c36caf6de9a@jboss.com> <6d6d! 8c25-12c2-f33f-40a8-9c12b98a429f@jboss.com> Message-ID: > On Jun 7, 2016, at 6:55 AM, Darran Lofthouse wrote: > > > >> On 07/06/16 12:47, Jason T. Greene wrote: >> >> >>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse wrote: >>> >>> >>> >>>> On 07/06/16 12:24, Jason T. Greene wrote: >>>> Long term I think we want management using TLS, but that can of course >>>> come in phases. Assuming 2) is one of those phases to come (either now >>>> or later), a following step is that the CLI, and really any remoting >>>> client, should prefer TLS with a defaulted trust store location that >>>> points to the keystore. >>>> >>>> With 2) if we have the default of the attribute that forces redirect be >>>> true, and our default config be false, then someone that carries over >>>> their old config would not have a potential security weakness. If they >>>> have a CLI script that adds the https port, it will fail, hopefully >>>> sending a signal to look. Although, the user might just assume that oh >>>> it's there, I don't have to do anything. >>>> >>>> Another interesting thing about 2 is that IIRC we have conflicting >>>> behavior between the app port which doesn't force upgrade and the >>>> management port which does. >>> >>> In applications you configure which paths require a confidential >>> transport guarantee so you can be selective. >>> >>> For managements all requests come over a single path so if you switch on >>> SSL why not use it for the one and only path containing your sensitive >>> requests. >> >> Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. > > But on the management port we still only have a single "app" using HTTP upgrade. Well technically you have two right. You have /console, and /management but sure they are always constant. I guess My point is just think it's weird that remote EJB (and other proprietary protocols over http upgrade) doesn't redirect and management does. > >> >>> >>>> So my preference is 2, because at some point we have to do it anyway, >>>> and if we have TLS out of the box might as well use it. >>>> >>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>> > wrote: >>>> >>>>> So while implementing this I have noticed a potential problem that it >>>>> would be good to get some feedback on. >>>>> >>>>> If the management interface has SSL by default then the HTTP interface >>>>> will always redirect to the HTTPS interface. This effectively breaks >>>>> the management API, as clients such as the CLI, Arquillian etc will be >>>>> redirected to HTTPS, and then reject the self signed certificate (as >>>>> they should). >>>>> >>>>> I am not sure what to do about this, these are the options as I see them: >>>>> >>>>> 1) Don't enable SSL for the management interface (just for the >>>>> Undertow subsystem). The management interface can still use this >>>>> auto-generation capability, it just won't be enable by default (we >>>>> could even leave the cert in the security domain, but just not enable >>>>> the https interface). >>>>> >>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>>> controlled by an attribute). This will allow the CLI etc to work, but >>>>> at the price of potentially reducing security, as some connections >>>>> that would have previously been redirected to use HTTPS will no longer >>>>> do this. >>>>> >>>>> 3) Enable it by default and leave it broken. We can setup some kind of >>>>> automatic trust store thing so the local CLI works, and can get our >>>>> test suite to work with Arquillian in a similar manner. Personally I >>>>> think this is a terrible idea, but I am including it for completeness. >>>>> >>>>> Personally I think we should go for 1). Given that this is supposed to >>>>> be about developer usability I don't think having management also use >>>>> SSL as being that important. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>>> > wrote: >>>>> >>>>> Awesome! Another idea I had on how we could get away with it being >>>>> in server boot, is to have a pre-boot first time setup task, >>>>> either launched from the shell/batch scripts or as a special >>>>> pre-step before the AS module loads. We could then report boot >>>>> time as the time AFTER first time installation tasks have >>>>> completed, which I think is fair because the server hasn't yet >>>>> been started. >>>>> >>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>>> > >>>>> wrote: >>>>> >>>>>> I have some initial work on this at: >>>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>> >>>>>> If you go to https://localhost:9993 it will generate the >>>>>> certificate (although all that will be served is a 404 page as >>>>>> the console is not installed). >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>>> > >>>>>> wrote: >>>>>> >>>>>> I think that would actually end up being more complex. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>>> > wrote: >>>>>> >>>>>> Another option could be a post boot task. So it's still >>>>>> eager but don't block completed start. We'd still need to >>>>>> block Tls ports though. So maybe this does not help >>>>>> >>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>>> >>>>> > wrote: >>>>>> >>>>>>> 2048 bits adds close to a second to first boot on my >>>>>>> machine (obviously subsequent boots are unaffected). >>>>>>> >>>>>>> This is probably a bit much, I will work on getting a >>>>>>> POC for the lazy loading approach implemented. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> We should really be generating 2048 bit keys. >>>>>>> >>>>>>> I don't like adding to our boot time, we have >>>>>>> already seen it grow and this would be yet another case. >>>>>>> >>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> So I just did up a very quick prototype that >>>>>>>> generates self signed certificates on startup and >>>>>>>> it looks like the difference in startup time is >>>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>>> keys). Even if the difference is measurable it only >>>>>>>> affects the very first startup. >>>>>>>> >>>>>>>> I think that in order to simplify the >>>>>>>> implementation of this it may be better to simply >>>>>>>> generate the key of first startup, instead of >>>>>>>> attempting to do it lazily. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>>> What will be default keysize? It has to be >>>>>>>>> probably choosen to work also without >>>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>>> >>>>>>>>> >>>>>>>>> Probably the largest that is supported without >>>>>>>>> JCE. It does not matter that much, self signed >>>>>>>>> certs are inherently insecure, this is a >>>>>>>>> developer usability feature, not something >>>>>>>>> that can be used in production. >>>>>>>> >>>>>>>> IIRC there is actually no limit on RSA key >>>>>>>> size, it's only symmetric algs that are >>>>>>>> limited, so we could use a standard 2048 bit >>>>>>>> key without issue. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>>> Douglas >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> So I guess we should talk about how >>>>>>>>> this should actually work. >>>>>>>>> >>>>>>>>> In terms of auto generating the key I >>>>>>>>> was thinking we would need to add a >>>>>>>>> new attribute to the 'keystore' >>>>>>>>> element under the security realm, >>>>>>>>> something like >>>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>>> I am not sure what other options we >>>>>>>>> would need, or how configurable we >>>>>>>>> should make it, but as this is for >>>>>>>>> testing/development purposes I don't >>>>>>>>> think we need to expose full control >>>>>>>>> over the certificate generation process. >>>>>>>>> >>>>>>>>> In terms of the implementation we >>>>>>>>> could just implement an SSLContext >>>>>>>>> wrapper, that can do the generation >>>>>>>>> and then create a 'real' SSLContext >>>>>>>>> the first time it is asked to create >>>>>>>>> and SSLEngine. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>>> Greene >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>> in Wildfly 10.1. >>>>>>>>>> >>>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>> bugs awaiting release. >>>>>>>>>> >>>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>> bug fixes be kept in mind. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Harold, >>>>>>>>> >>>>>>>>> That fix is already in master, so >>>>>>>>> it will be included in 10.1. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jason T. Greene >>>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>>> Architect >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Tue Jun 7 08:03:17 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 7 Jun 2016 08:03:17 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <135d0493-3955-2ecc! -06f6-5c36caf6de9a@jboss.com> <6d6d! ! 8c25-12c2-f33f-40a8-9c12b98a429f@jboss.com> Message-ID: <2C56A72F-AB93-402E-A5A2-13952A3F9DB7@redhat.com> > On Jun 7, 2016, at 7:01 AM, Jason T. Greene wrote: > > > > >> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse wrote: >> >> >> >>> On 07/06/16 12:47, Jason T. Greene wrote: >>> >>> >>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse wrote: >>>> >>>> >>>> >>>>> On 07/06/16 12:24, Jason T. Greene wrote: >>>>> Long term I think we want management using TLS, but that can of course >>>>> come in phases. Assuming 2) is one of those phases to come (either now >>>>> or later), a following step is that the CLI, and really any remoting >>>>> client, should prefer TLS with a defaulted trust store location that >>>>> points to the keystore. >>>>> >>>>> With 2) if we have the default of the attribute that forces redirect be >>>>> true, and our default config be false, then someone that carries over >>>>> their old config would not have a potential security weakness. If they >>>>> have a CLI script that adds the https port, it will fail, hopefully >>>>> sending a signal to look. Although, the user might just assume that oh >>>>> it's there, I don't have to do anything. >>>>> >>>>> Another interesting thing about 2 is that IIRC we have conflicting >>>>> behavior between the app port which doesn't force upgrade and the >>>>> management port which does. >>>> >>>> In applications you configure which paths require a confidential >>>> transport guarantee so you can be selective. >>>> >>>> For managements all requests come over a single path so if you switch on >>>> SSL why not use it for the one and only path containing your sensitive >>>> requests. >>> >>> Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. >> >> But on the management port we still only have a single "app" using HTTP upgrade. > > Well technically you have two right. You have /console, and /management but sure they are always constant. (By pointing this out what I am getting at is that http json clients are distinct from the console, I could technically want different policies for the two, although i do agree that if TLs is available you tend to want it) > > I guess My point is just think it's weird that remote EJB (and other proprietary protocols over http upgrade) doesn't redirect and management does. > > >> >>> >>>> >>>>> So my preference is 2, because at some point we have to do it anyway, >>>>> and if we have TLS out of the box might as well use it. >>>>> >>>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>>> > wrote: >>>>> >>>>>> So while implementing this I have noticed a potential problem that it >>>>>> would be good to get some feedback on. >>>>>> >>>>>> If the management interface has SSL by default then the HTTP interface >>>>>> will always redirect to the HTTPS interface. This effectively breaks >>>>>> the management API, as clients such as the CLI, Arquillian etc will be >>>>>> redirected to HTTPS, and then reject the self signed certificate (as >>>>>> they should). >>>>>> >>>>>> I am not sure what to do about this, these are the options as I see them: >>>>>> >>>>>> 1) Don't enable SSL for the management interface (just for the >>>>>> Undertow subsystem). The management interface can still use this >>>>>> auto-generation capability, it just won't be enable by default (we >>>>>> could even leave the cert in the security domain, but just not enable >>>>>> the https interface). >>>>>> >>>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>>>> controlled by an attribute). This will allow the CLI etc to work, but >>>>>> at the price of potentially reducing security, as some connections >>>>>> that would have previously been redirected to use HTTPS will no longer >>>>>> do this. >>>>>> >>>>>> 3) Enable it by default and leave it broken. We can setup some kind of >>>>>> automatic trust store thing so the local CLI works, and can get our >>>>>> test suite to work with Arquillian in a similar manner. Personally I >>>>>> think this is a terrible idea, but I am including it for completeness. >>>>>> >>>>>> Personally I think we should go for 1). Given that this is supposed to >>>>>> be about developer usability I don't think having management also use >>>>>> SSL as being that important. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>>>> > wrote: >>>>>> >>>>>> Awesome! Another idea I had on how we could get away with it being >>>>>> in server boot, is to have a pre-boot first time setup task, >>>>>> either launched from the shell/batch scripts or as a special >>>>>> pre-step before the AS module loads. We could then report boot >>>>>> time as the time AFTER first time installation tasks have >>>>>> completed, which I think is fair because the server hasn't yet >>>>>> been started. >>>>>> >>>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>>>> > >>>>>> wrote: >>>>>> >>>>>>> I have some initial work on this at: >>>>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>>> >>>>>>> If you go to https://localhost:9993 it will generate the >>>>>>> certificate (although all that will be served is a 404 page as >>>>>>> the console is not installed). >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> I think that would actually end up being more complex. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>>>> > wrote: >>>>>>> >>>>>>> Another option could be a post boot task. So it's still >>>>>>> eager but don't block completed start. We'd still need to >>>>>>> block Tls ports though. So maybe this does not help >>>>>>> >>>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> 2048 bits adds close to a second to first boot on my >>>>>>>> machine (obviously subsequent boots are unaffected). >>>>>>>> >>>>>>>> This is probably a bit much, I will work on getting a >>>>>>>> POC for the lazy loading approach implemented. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> We should really be generating 2048 bit keys. >>>>>>>> >>>>>>>> I don't like adding to our boot time, we have >>>>>>>> already seen it grow and this would be yet another case. >>>>>>>> >>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> So I just did up a very quick prototype that >>>>>>>>> generates self signed certificates on startup and >>>>>>>>> it looks like the difference in startup time is >>>>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>>>> keys). Even if the difference is measurable it only >>>>>>>>> affects the very first startup. >>>>>>>>> >>>>>>>>> I think that in order to simplify the >>>>>>>>> implementation of this it may be better to simply >>>>>>>>> generate the key of first startup, instead of >>>>>>>>> attempting to do it lazily. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> What will be default keysize? It has to be >>>>>>>>>> probably choosen to work also without >>>>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Probably the largest that is supported without >>>>>>>>>> JCE. It does not matter that much, self signed >>>>>>>>>> certs are inherently insecure, this is a >>>>>>>>>> developer usability feature, not something >>>>>>>>>> that can be used in production. >>>>>>>>> >>>>>>>>> IIRC there is actually no limit on RSA key >>>>>>>>> size, it's only symmetric algs that are >>>>>>>>> limited, so we could use a standard 2048 bit >>>>>>>>> key without issue. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>>>> Douglas >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> So I guess we should talk about how >>>>>>>>>> this should actually work. >>>>>>>>>> >>>>>>>>>> In terms of auto generating the key I >>>>>>>>>> was thinking we would need to add a >>>>>>>>>> new attribute to the 'keystore' >>>>>>>>>> element under the security realm, >>>>>>>>>> something like >>>>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>>>> I am not sure what other options we >>>>>>>>>> would need, or how configurable we >>>>>>>>>> should make it, but as this is for >>>>>>>>>> testing/development purposes I don't >>>>>>>>>> think we need to expose full control >>>>>>>>>> over the certificate generation process. >>>>>>>>>> >>>>>>>>>> In terms of the implementation we >>>>>>>>>> could just implement an SSLContext >>>>>>>>>> wrapper, that can do the generation >>>>>>>>>> and then create a 'real' SSLContext >>>>>>>>>> the first time it is asked to create >>>>>>>>>> and SSLEngine. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>>>> Greene >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>>> in Wildfly 10.1. >>>>>>>>>>> >>>>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>> bugs awaiting release. >>>>>>>>>>> >>>>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>> bug fixes be kept in mind. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Harold, >>>>>>>>>> >>>>>>>>>> That fix is already in master, so >>>>>>>>>> it will be included in 10.1. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jason T. Greene >>>>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>>>> Architect >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Tue Jun 7 08:05:29 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Jun 2016 13:05:29 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <2C56A72F-AB93-402E-A5A2-13952A3F9DB7@redhat.com> References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <135d0493-3955-2ecc! -06f6-5c36caf6de9a@jboss.com> <6d6d! ! 8c25-12c2-f33f-40a8-9c12b98a429f@jboss.com> <2C56A72F-AB93-402E-A5A2-13952A3F9DB7@redhat.com> Message-ID: <989d527d-8b7c-b08a-8a34-0e14784e6770@jboss.com> On 07/06/16 13:03, Jason T. Greene wrote: > > > >> On Jun 7, 2016, at 7:01 AM, Jason T. Greene wrote: >> >> >> >> >>> On Jun 7, 2016, at 6:55 AM, Darran Lofthouse wrote: >>> >>> >>> >>>> On 07/06/16 12:47, Jason T. Greene wrote: >>>> >>>> >>>>> On Jun 7, 2016, at 6:33 AM, Darran Lofthouse wrote: >>>>> >>>>> >>>>> >>>>>> On 07/06/16 12:24, Jason T. Greene wrote: >>>>>> Long term I think we want management using TLS, but that can of course >>>>>> come in phases. Assuming 2) is one of those phases to come (either now >>>>>> or later), a following step is that the CLI, and really any remoting >>>>>> client, should prefer TLS with a defaulted trust store location that >>>>>> points to the keystore. >>>>>> >>>>>> With 2) if we have the default of the attribute that forces redirect be >>>>>> true, and our default config be false, then someone that carries over >>>>>> their old config would not have a potential security weakness. If they >>>>>> have a CLI script that adds the https port, it will fail, hopefully >>>>>> sending a signal to look. Although, the user might just assume that oh >>>>>> it's there, I don't have to do anything. >>>>>> >>>>>> Another interesting thing about 2 is that IIRC we have conflicting >>>>>> behavior between the app port which doesn't force upgrade and the >>>>>> management port which does. >>>>> >>>>> In applications you configure which paths require a confidential >>>>> transport guarantee so you can be selective. >>>>> >>>>> For managements all requests come over a single path so if you switch on >>>>> SSL why not use it for the one and only path containing your sensitive >>>>> requests. >>>> >>>> Sure for standard web applications, but for anything using http upgrade that hits the root resource for all apps. >>> >>> But on the management port we still only have a single "app" using HTTP upgrade. >> >> Well technically you have two right. You have /console, and /management but sure they are always constant. > > (By pointing this out what I am getting at is that http json clients are distinct from the console, I could technically want different policies for the two, although i do agree that if TLs is available you tend to want it) >> >> I guess My point is just think it's weird that remote EJB (and other proprietary protocols over http upgrade) doesn't redirect and management does. In the management case those going for option #2 feels like say TLS is good we should have TLS - but then we make it optional for all and down to the individual client to decide if it wants to use it. >> >> >>> >>>> >>>>> >>>>>> So my preference is 2, because at some point we have to do it anyway, >>>>>> and if we have TLS out of the box might as well use it. >>>>>> >>>>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>>>> > wrote: >>>>>> >>>>>>> So while implementing this I have noticed a potential problem that it >>>>>>> would be good to get some feedback on. >>>>>>> >>>>>>> If the management interface has SSL by default then the HTTP interface >>>>>>> will always redirect to the HTTPS interface. This effectively breaks >>>>>>> the management API, as clients such as the CLI, Arquillian etc will be >>>>>>> redirected to HTTPS, and then reject the self signed certificate (as >>>>>>> they should). >>>>>>> >>>>>>> I am not sure what to do about this, these are the options as I see them: >>>>>>> >>>>>>> 1) Don't enable SSL for the management interface (just for the >>>>>>> Undertow subsystem). The management interface can still use this >>>>>>> auto-generation capability, it just won't be enable by default (we >>>>>>> could even leave the cert in the security domain, but just not enable >>>>>>> the https interface). >>>>>>> >>>>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>>>>> controlled by an attribute). This will allow the CLI etc to work, but >>>>>>> at the price of potentially reducing security, as some connections >>>>>>> that would have previously been redirected to use HTTPS will no longer >>>>>>> do this. >>>>>>> >>>>>>> 3) Enable it by default and leave it broken. We can setup some kind of >>>>>>> automatic trust store thing so the local CLI works, and can get our >>>>>>> test suite to work with Arquillian in a similar manner. Personally I >>>>>>> think this is a terrible idea, but I am including it for completeness. >>>>>>> >>>>>>> Personally I think we should go for 1). Given that this is supposed to >>>>>>> be about developer usability I don't think having management also use >>>>>>> SSL as being that important. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>>>>> > wrote: >>>>>>> >>>>>>> Awesome! Another idea I had on how we could get away with it being >>>>>>> in server boot, is to have a pre-boot first time setup task, >>>>>>> either launched from the shell/batch scripts or as a special >>>>>>> pre-step before the AS module loads. We could then report boot >>>>>>> time as the time AFTER first time installation tasks have >>>>>>> completed, which I think is fair because the server hasn't yet >>>>>>> been started. >>>>>>> >>>>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>>> I have some initial work on this at: >>>>>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>>>> >>>>>>>> If you go to https://localhost:9993 it will generate the >>>>>>>> certificate (although all that will be served is a 404 page as >>>>>>>> the console is not installed). >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> I think that would actually end up being more complex. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Another option could be a post boot task. So it's still >>>>>>>> eager but don't block completed start. We'd still need to >>>>>>>> block Tls ports though. So maybe this does not help >>>>>>>> >>>>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> 2048 bits adds close to a second to first boot on my >>>>>>>>> machine (obviously subsequent boots are unaffected). >>>>>>>>> >>>>>>>>> This is probably a bit much, I will work on getting a >>>>>>>>> POC for the lazy loading approach implemented. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> We should really be generating 2048 bit keys. >>>>>>>>> >>>>>>>>> I don't like adding to our boot time, we have >>>>>>>>> already seen it grow and this would be yet another case. >>>>>>>>> >>>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>>>>> >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> So I just did up a very quick prototype that >>>>>>>>>> generates self signed certificates on startup and >>>>>>>>>> it looks like the difference in startup time is >>>>>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>>>>> keys). Even if the difference is measurable it only >>>>>>>>>> affects the very first startup. >>>>>>>>>> >>>>>>>>>> I think that in order to simplify the >>>>>>>>>> implementation of this it may be better to simply >>>>>>>>>> generate the key of first startup, instead of >>>>>>>>>> attempting to do it lazily. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>>>>> >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> What will be default keysize? It has to be >>>>>>>>>>> probably choosen to work also without >>>>>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Probably the largest that is supported without >>>>>>>>>>> JCE. It does not matter that much, self signed >>>>>>>>>>> certs are inherently insecure, this is a >>>>>>>>>>> developer usability feature, not something >>>>>>>>>>> that can be used in production. >>>>>>>>>> >>>>>>>>>> IIRC there is actually no limit on RSA key >>>>>>>>>> size, it's only symmetric algs that are >>>>>>>>>> limited, so we could use a standard 2048 bit >>>>>>>>>> key without issue. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Stuart >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>>>>> Douglas >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> So I guess we should talk about how >>>>>>>>>>> this should actually work. >>>>>>>>>>> >>>>>>>>>>> In terms of auto generating the key I >>>>>>>>>>> was thinking we would need to add a >>>>>>>>>>> new attribute to the 'keystore' >>>>>>>>>>> element under the security realm, >>>>>>>>>>> something like >>>>>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>>>>> I am not sure what other options we >>>>>>>>>>> would need, or how configurable we >>>>>>>>>>> should make it, but as this is for >>>>>>>>>>> testing/development purposes I don't >>>>>>>>>>> think we need to expose full control >>>>>>>>>>> over the certificate generation process. >>>>>>>>>>> >>>>>>>>>>> In terms of the implementation we >>>>>>>>>>> could just implement an SSLContext >>>>>>>>>>> wrapper, that can do the generation >>>>>>>>>>> and then create a 'real' SSLContext >>>>>>>>>>> the first time it is asked to create >>>>>>>>>>> and SSLEngine. >>>>>>>>>>> >>>>>>>>>>> Stuart >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>>>>> Greene >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>>>> in Wildfly 10.1. >>>>>>>>>>>> >>>>>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>>> bugs awaiting release. >>>>>>>>>>>> >>>>>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>>> bug fixes be kept in mind. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Harold, >>>>>>>>>>> >>>>>>>>>>> That fix is already in master, so >>>>>>>>>>> it will be included in 10.1. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jason T. Greene >>>>>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>>>>> Architect >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Tue Jun 7 10:15:00 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 7 Jun 2016 10:15:00 -0400 Subject: [wildfly-dev] adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime In-Reply-To: References: <59b14165-f461-337a-2782-a5cd565523b9@redhat.com> <0b66e7ef-ea37-5862-edff-5d3495221499@redhat.com> <2276deab-3196-fb4a-740e-79d85160a7fa@redhat.com> <673f9b90-e26f-bd2b-3567-8c07ba680d67@redhat.com> <320939ba-369a-b80e-f7d5-532d78aaf38c@redhat.com> Message-ID: <2992643b-7aca-07bd-b74c-f6514c8e2d6c@redhat.com> On 06/06/2016 03:26 PM, Brian Stansberry wrote: > On 5/31/16 6:04 PM, Scott Marlow wrote: >> >> On 05/31/2016 04:48 PM, Scott Marlow wrote: >>> >>> >>> On 05/27/2016 10:19 AM, Scott Marlow wrote: >>>> >>>> >>>> On 05/27/2016 09:33 AM, Brian Stansberry wrote: >>>>> Can a new profile be added post-boot without requiring a reload to >>>>> take >>>>> effect? If yes, the add handler for the profile resource should do the >>>>> service installation for that profile. It shouldn't count on the >>>>> parent >>>>> to do it, as the parent logic will only execute during boot. >>>> >>>> I like the idea of adding a new profile post-boot, without requiring a >>>> reload of all of the profiles defined by the MongoDB/Cassandra >>>> subsystem. >>> >>> I need to back up on my response. What does it mean for adding a new >>> profile without requiring a reload? Does that require a hot change to >>> the NoSQL profile service without undeploying the application? >> >> After refreshing on >> https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates, >> >> I think currently, we should specify that a reload (all-services) is >> needed when adding/removing profiles. >> > > Ok. > > I was on vacation, so sorry for no reply. Welcome back! :-) > > I don't fully understand what these services are doing, so my only > comment is that it's ok (and common) to require a reload for a remove > but not for an add. A removal can disrupt other services while an add > often doesn't. I think that should also be true for the NoSQL integration. So, we should probably handle both add/remove at the "profile" level, so that add does not require a reload. Some more details are below about what should be going on internally with these services... For the example below, "mongodbtestprofile" represents a connection profile that applications can @Inject/@Resource into an application MongoClient/MongoDatabase variable. The application may use the MongoClient/MongoDatabase to read/write the MongoDB database as represented by the "mongodbtestprofile" hostname/port/other settings. There could be zero to many, different application deployments that are using "mongodbtestprofile". A removal of the internal service representing "mongodbtestprofile", would *disrupt* the deployments that are using "mongodbtestprofile". The deployments do not yet have dependencies set on the "mongodbtestprofile" internal service but I think they will need to (currently on the TODO list). Adding a new NoSQL profile, would likely be done before some new application(s) are deployed that will use the added profile. There are differences between the different NoSQL profiles that we will support, which is why we will have a subsystem per NoSQL database type (MongoDB/Cassandra/Neo4J initially). For example, the Neo4J Driver class is thread safe and can be expected to be shared by multiple deployments, however the Neo4J Session is not expected to be shared. In contrast, MongoDB allows the MongoClient/MongoDatabase class instances to be shared by multiple threads. Hibernate OGM will also use the NoSQL profiles as well. > >>> >>>> >>>> Currently, the standalone*.xml might contain: >>>> >>>> >>>> >>> jndi-name="java:jboss/mongodb/test" database="mongotestdb"> >>>> >>>> >>>> >>> jndi-name="java:jboss/mongodb/diary" database="diarydb"> >>>> >>>> >>>> >>>> >>>> If the user wants to add an additional profile to the mongodb >>>> subsystem, >>>> I think it would be worth us making the code changes to allow that. >>>> Will be great to add a new "otherDB", without stopping the existing >>>> database profiles. >>>> >>>> For supporting "remove" of an existing profile, I think that we will >>>> need dependencies added on the underlying >>>> MongoDriverService/CassandraDriverService, will be very worthwhile to >>>> have that as well! Great feedback! :-) >>>> >>>>> >>>>> BTW, if post-boot profile adds/removes don't require reload, then [1] >>>>> should not be inside the "if >>>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block? >>>> >>>> Makes sense, looks like we need a remove handler also for the profile >>>> resource. >>>> >>>>> Same >>>>> question applies for the cassandra add handler. >>>> >>>> We should change the cassandra add handler also. >>>> >>>> Thanks again, >>>> Scott >>>> >>>>> >>>>> [1] >>>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124 >>>>> >>>>> >>>>> >>>>> On 5/26/16 3:02 PM, Scott Marlow wrote: >>>>>> Hi, >>>>>> >>>>>> We will soon add several (nested) NoSQL configuration settings. >>>>>> Before >>>>>> we do that, I would like some feedback on the current NoSQL subsystem >>>>>> code that reads connection settings. >>>>>> >>>>>> Any major corrections that you can suggest for the NoSQL subsystem >>>>>> code >>>>>> [1][2]? Especially, the >>>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime >>>>>> >>>>>> >>>>>> methods. >>>>>> >>>>>> Should we continue to read all of the configuration settings from one >>>>>> AddStepHandler or should we do that differently (perhaps with >>>>>> separate >>>>>> AbstractAddStepHandler's)? >>>>>> >>>>>> Thanks, >>>>>> Scott >>>>>> >>>>>> [1] >>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra >>>>>> >>>>>> >>>>>> >>>>>> [2] >>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > > From jperkins at redhat.com Tue Jun 7 11:35:40 2016 From: jperkins at redhat.com (James Perkins) Date: Tue, 7 Jun 2016 08:35:40 -0700 Subject: [wildfly-dev] WildFly Plugin Core Project In-Reply-To: References: Message-ID: Just as a follow up to anyone that wants to follow I created a JIRA for this https://issues.jboss.org/browse/WFMP-41. I've got a big chunk of the refactor done. I just need to document it and probably make it a little more user friendly. On Wed, Jun 1, 2016 at 5:29 PM, James Perkins wrote: > Hello All, > I've been asked a few times about creating a WildFly Plugin Core project > with some of the utilities from the wildfly-maven-plugin. Since it came up > twice today alone I'm wondering if we should have a separate > wildfly-plugin-core project. > > This would be useful if we wanted to have a Gradle or SBT plugin as well. > Maybe it's useful for JBoss Tools too. WildFly Arquillian could use it too. > > The idea would be to separate out the code that creates the deployment > operations as well as the code that creates and launches a container > process (maybe). Also expose of the helper stuff done to check the status > of a sever, get all the server groups of a managed domain, etc. It would > probably be fairly small overall. Essentially just some utilities that > create some common operations so consumers don't need to know how the > operation needs to be constructed. > > If it sounds reasonable the next step would be to determine if it should > be it's own project or just a maven module in the wildfly-maven-plugin. The > only reason I'd lean towards it's own project is to keep the release stream > separate from the wildfly-maven-plugin. > > Thoughts? > > -- > James R. Perkins > JBoss by Red Hat > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160607/88a166d5/attachment-0001.html From jason.greene at redhat.com Tue Jun 7 16:51:14 2016 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 7 Jun 2016 15:51:14 -0500 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> Message-ID: <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> So after reviewing this thread and discussing with a few folks, I?d like to propose, for 10.1: #1b - Same as the previous #1, we don?t enable TLS for management by default for now, but we additionally include an extra cli script to enable TLS. For 11 I think we should move to TLS by default, perhaps with a configurable URL policy on redirects, and address the incongruence with upgrade over app. I think its likely reasonable to redirect by default for 11, but we can hash that out further. One nice thing I had forgotten about is that the JDK will prompt for you to add unknown certs, and this all works with the CLI[1]. So it?s really only non-interactive clients we have to worry about, and that sounds like a reasonable burden for upgrade. [1] [disconnected /] connect Unable to connect due to unrecognised server certificate Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US Valid From - Tue Jun 07 15:22:06 CDT 2016 Valid To - Thu Jun 07 15:22:06 CDT 2018 MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t > On Jun 7, 2016, at 6:24 AM, Jason T. Greene wrote: > > Long term I think we want management using TLS, but that can of course come in phases. Assuming 2) is one of those phases to come (either now or later), a following step is that the CLI, and really any remoting client, should prefer TLS with a defaulted trust store location that points to the keystore. > > With 2) if we have the default of the attribute that forces redirect be true, and our default config be false, then someone that carries over their old config would not have a potential security weakness. If they have a CLI script that adds the https port, it will fail, hopefully sending a signal to look. Although, the user might just assume that oh it's there, I don't have to do anything. > > Another interesting thing about 2 is that IIRC we have conflicting behavior between the app port which doesn't force upgrade and the management port which does. > > So my preference is 2, because at some point we have to do it anyway, and if we have TLS out of the box might as well use it. > > On Jun 6, 2016, at 10:48 PM, Stuart Douglas > wrote: > >> So while implementing this I have noticed a potential problem that it would be good to get some feedback on. >> >> If the management interface has SSL by default then the HTTP interface will always redirect to the HTTPS interface. This effectively breaks the management API, as clients such as the CLI, Arquillian etc will be redirected to HTTPS, and then reject the self signed certificate (as they should). >> >> I am not sure what to do about this, these are the options as I see them: >> >> 1) Don't enable SSL for the management interface (just for the Undertow subsystem). The management interface can still use this auto-generation capability, it just won't be enable by default (we could even leave the cert in the security domain, but just not enable the https interface). >> >> 2) Disable automatic redirects for HTTP upgrade requests (potentially controlled by an attribute). This will allow the CLI etc to work, but at the price of potentially reducing security, as some connections that would have previously been redirected to use HTTPS will no longer do this. >> >> 3) Enable it by default and leave it broken. We can setup some kind of automatic trust store thing so the local CLI works, and can get our test suite to work with Arquillian in a similar manner. Personally I think this is a terrible idea, but I am including it for completeness. >> >> Personally I think we should go for 1). Given that this is supposed to be about developer usability I don't think having management also use SSL as being that important. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene > wrote: >> Awesome! Another idea I had on how we could get away with it being in server boot, is to have a pre-boot first time setup task, either launched from the shell/batch scripts or as a special pre-step before the AS module loads. We could then report boot time as the time AFTER first time installation tasks have completed, which I think is fair because the server hasn't yet been started. >> >> On Jun 5, 2016, at 11:53 PM, Stuart Douglas > wrote: >> >>> I have some initial work on this at: https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>> >>> If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed). >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas > wrote: >>> I think that would actually end up being more complex. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene > wrote: >>> Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help >>> >>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas > wrote: >>> >>>> 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). >>>> >>>> This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene > wrote: >>>> We should really be generating 2048 bit keys. >>>> >>>> I don't like adding to our boot time, we have already seen it grow and this would be yet another case. >>>> >>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas > wrote: >>>> >>>>> So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. >>>>> >>>>> I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. >>>>> >>>>> Stuart >>>>> >>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene > wrote: >>>>> >>>>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>>>>> >>>>>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >>>>> >>>>> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >>>>> >>>>> >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas > wrote: >>>>>> So I guess we should talk about how this should actually work. >>>>>> >>>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>>> >>>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene > wrote: >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell > wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160607/fef8fd4e/attachment-0001.html From stuart.w.douglas at gmail.com Tue Jun 7 16:55:00 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 8 Jun 2016 06:55:00 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene wrote: > So after reviewing this thread and discussing with a few folks, I?d like > to propose, for 10.1: > > #1b - Same as the previous #1, we don?t enable TLS for management by > default for now, but we additionally include an extra cli script to enable > TLS. > We would leave the cert generation bit in the security realm, but just don't enable the HTTPS interface. That way all that is required is for the user to add the https="managements-https" attribute. Stuart > > For 11 I think we should move to TLS by default, perhaps with a > configurable URL policy on redirects, and address the incongruence with > upgrade over app. > > I think its likely reasonable to redirect by default for 11, but we can > hash that out further. One nice thing I had forgotten about is that the JDK > will prompt for you to add unknown certs, and this all works with the > CLI[1]. So it?s really only non-interactive clients we have to worry about, > and that sounds like a reasonable burden for upgrade. > > [1] > > [disconnected /] connect > Unable to connect due to unrecognised server certificate > Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US > Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US > Valid From - Tue Jun 07 15:22:06 CDT 2016 > Valid To - Thu Jun 07 15:22:06 CDT 2018 > MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d > SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b > > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t > > > > On Jun 7, 2016, at 6:24 AM, Jason T. Greene > wrote: > > Long term I think we want management using TLS, but that can of course > come in phases. Assuming 2) is one of those phases to come (either now or > later), a following step is that the CLI, and really any remoting client, > should prefer TLS with a defaulted trust store location that points to the > keystore. > > With 2) if we have the default of the attribute that forces redirect be > true, and our default config be false, then someone that carries over their > old config would not have a potential security weakness. If they have a CLI > script that adds the https port, it will fail, hopefully sending a signal > to look. Although, the user might just assume that oh it's there, I don't > have to do anything. > > Another interesting thing about 2 is that IIRC we have conflicting > behavior between the app port which doesn't force upgrade and the > management port which does. > > So my preference is 2, because at some point we have to do it anyway, and > if we have TLS out of the box might as well use it. > > On Jun 6, 2016, at 10:48 PM, Stuart Douglas > wrote: > > So while implementing this I have noticed a potential problem that it > would be good to get some feedback on. > > If the management interface has SSL by default then the HTTP interface > will always redirect to the HTTPS interface. This effectively breaks the > management API, as clients such as the CLI, Arquillian etc will be > redirected to HTTPS, and then reject the self signed certificate (as they > should). > > I am not sure what to do about this, these are the options as I see them: > > 1) Don't enable SSL for the management interface (just for the Undertow > subsystem). The management interface can still use this auto-generation > capability, it just won't be enable by default (we could even leave the > cert in the security domain, but just not enable the https interface). > > 2) Disable automatic redirects for HTTP upgrade requests (potentially > controlled by an attribute). This will allow the CLI etc to work, but at > the price of potentially reducing security, as some connections that would > have previously been redirected to use HTTPS will no longer do this. > > 3) Enable it by default and leave it broken. We can setup some kind of > automatic trust store thing so the local CLI works, and can get our test > suite to work with Arquillian in a similar manner. Personally I think this > is a terrible idea, but I am including it for completeness. > > Personally I think we should go for 1). Given that this is supposed to be > about developer usability I don't think having management also use SSL as > being that important. > > Stuart > > On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene > wrote: > >> Awesome! Another idea I had on how we could get away with it being in >> server boot, is to have a pre-boot first time setup task, either launched >> from the shell/batch scripts or as a special pre-step before the AS module >> loads. We could then report boot time as the time AFTER first time >> installation tasks have completed, which I think is fair because the server >> hasn't yet been started. >> >> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >> wrote: >> >> I have some initial work on this at: >> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >> >> If you go to https://localhost:9993 it will generate the certificate >> (although all that will be served is a 404 page as the console is not >> installed). >> >> Stuart >> >> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas < >> stuart.w.douglas at gmail.com> wrote: >> >>> I think that would actually end up being more complex. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene < >>> jason.greene at redhat.com> wrote: >>> >>>> Another option could be a post boot task. So it's still eager but don't >>>> block completed start. We'd still need to block Tls ports though. So maybe >>>> this does not help >>>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>> wrote: >>>> >>>> 2048 bits adds close to a second to first boot on my machine (obviously >>>> subsequent boots are unaffected). >>>> >>>> This is probably a bit much, I will work on getting a POC for the lazy >>>> loading approach implemented. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene < >>>> jason.greene at redhat.com> wrote: >>>> >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we have already seen it grow and >>>>> this would be yet another case. >>>>> >>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>> wrote: >>>>> >>>>> So I just did up a very quick prototype that generates self signed >>>>> certificates on startup and it looks like the difference in startup time is >>>>> negligible (at least when generating 1024 bit RSA keys). Even if the >>>>> difference is measurable it only affects the very first startup. >>>>> >>>>> I think that in order to simplify the implementation of this it may be >>>>> better to simply generate the key of first startup, instead of attempting >>>>> to do it lazily. >>>>> >>>>> Stuart >>>>> >>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >>>>> jason.greene at redhat.com> wrote: >>>>> >>>>>> >>>>>> What will be default keysize? It has to be probably choosen to work >>>>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>>>>> Jurisdiction Policy" >>>>>>> >>>>>> >>>>>> Probably the largest that is supported without JCE. It does not >>>>>> matter that much, self signed certs are inherently insecure, this is a >>>>>> developer usability feature, not something that can be used in production. >>>>>> >>>>>> >>>>>> IIRC there is actually no limit on RSA key size, it's only symmetric >>>>>> algs that are limited, so we could use a standard 2048 bit key without >>>>>> issue. >>>>>> >>>>>> >>>>>> >>>>>> Stuart >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>>> >>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>> >>>>>>>> In terms of auto generating the key I was thinking we would need to >>>>>>>> add a new attribute to the 'keystore' element under the security realm, >>>>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>>>>> other options we would need, or how configurable we should make it, but as >>>>>>>> this is for testing/development purposes I don't think we need to expose >>>>>>>> full control over the certificate generation process. >>>>>>>> >>>>>>>> In terms of the implementation we could just implement an >>>>>>>> SSLContext wrapper, that can do the generation and then create a 'real' >>>>>>>> SSLContext the first time it is asked to create and SSLEngine. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene < >>>>>>>> jason.greene at redhat.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>> >> Hi All, >>>>>>>>> >> >>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of >>>>>>>>> the box >>>>>>>>> >> in Wildfly 10.1. >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> > This lowly user desperately wants a release containing the fix >>>>>>>>> to WFLY- >>>>>>>>> > 6283 sooner rather than later. I'm sure other people have other >>>>>>>>> pet >>>>>>>>> > bugs awaiting release. >>>>>>>>> > >>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>>>>> pent up >>>>>>>>> > bug fixes be kept in mind. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Harold, >>>>>>>>> >>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jason T. Greene >>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160608/2dfb1ba1/attachment-0001.html From stuart.w.douglas at gmail.com Tue Jun 7 21:51:51 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 8 Jun 2016 11:51:51 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: I have created a PR for this here: https://github.com/wildfly/wildfly-core/pull/1596 (it will also require some upstream changes). Basically this just creates a new schema version, and add the ' generate-self-signed-certificate-host' attribute to the keystore. I have not added a script to enable HTTPS over management as Jason suggested, I am not 100% sure if that really belongs in core or as part of the full distribution. Stuart On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas wrote: > > > On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene > wrote: > >> So after reviewing this thread and discussing with a few folks, I?d like >> to propose, for 10.1: >> >> #1b - Same as the previous #1, we don?t enable TLS for management by >> default for now, but we additionally include an extra cli script to enable >> TLS. >> > > We would leave the cert generation bit in the security realm, but just > don't enable the HTTPS interface. That way all that is required is for the > user to add the https="managements-https" attribute. > > Stuart > > >> >> For 11 I think we should move to TLS by default, perhaps with a >> configurable URL policy on redirects, and address the incongruence with >> upgrade over app. >> >> I think its likely reasonable to redirect by default for 11, but we can >> hash that out further. One nice thing I had forgotten about is that the JDK >> will prompt for you to add unknown certs, and this all works with the >> CLI[1]. So it?s really only non-interactive clients we have to worry about, >> and that sounds like a reasonable burden for upgrade. >> >> [1] >> >> [disconnected /] connect >> Unable to connect due to unrecognised server certificate >> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >> Valid From - Tue Jun 07 15:22:06 CDT 2016 >> Valid To - Thu Jun 07 15:22:06 CDT 2018 >> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >> >> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >> >> >> >> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >> wrote: >> >> Long term I think we want management using TLS, but that can of course >> come in phases. Assuming 2) is one of those phases to come (either now or >> later), a following step is that the CLI, and really any remoting client, >> should prefer TLS with a defaulted trust store location that points to the >> keystore. >> >> With 2) if we have the default of the attribute that forces redirect be >> true, and our default config be false, then someone that carries over their >> old config would not have a potential security weakness. If they have a CLI >> script that adds the https port, it will fail, hopefully sending a signal >> to look. Although, the user might just assume that oh it's there, I don't >> have to do anything. >> >> Another interesting thing about 2 is that IIRC we have conflicting >> behavior between the app port which doesn't force upgrade and the >> management port which does. >> >> So my preference is 2, because at some point we have to do it anyway, and >> if we have TLS out of the box might as well use it. >> >> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >> wrote: >> >> So while implementing this I have noticed a potential problem that it >> would be good to get some feedback on. >> >> If the management interface has SSL by default then the HTTP interface >> will always redirect to the HTTPS interface. This effectively breaks the >> management API, as clients such as the CLI, Arquillian etc will be >> redirected to HTTPS, and then reject the self signed certificate (as they >> should). >> >> I am not sure what to do about this, these are the options as I see them: >> >> 1) Don't enable SSL for the management interface (just for the Undertow >> subsystem). The management interface can still use this auto-generation >> capability, it just won't be enable by default (we could even leave the >> cert in the security domain, but just not enable the https interface). >> >> 2) Disable automatic redirects for HTTP upgrade requests (potentially >> controlled by an attribute). This will allow the CLI etc to work, but at >> the price of potentially reducing security, as some connections that would >> have previously been redirected to use HTTPS will no longer do this. >> >> 3) Enable it by default and leave it broken. We can setup some kind of >> automatic trust store thing so the local CLI works, and can get our test >> suite to work with Arquillian in a similar manner. Personally I think this >> is a terrible idea, but I am including it for completeness. >> >> Personally I think we should go for 1). Given that this is supposed to be >> about developer usability I don't think having management also use SSL as >> being that important. >> >> Stuart >> >> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene > > wrote: >> >>> Awesome! Another idea I had on how we could get away with it being in >>> server boot, is to have a pre-boot first time setup task, either launched >>> from the shell/batch scripts or as a special pre-step before the AS module >>> loads. We could then report boot time as the time AFTER first time >>> installation tasks have completed, which I think is fair because the server >>> hasn't yet been started. >>> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>> wrote: >>> >>> I have some initial work on this at: >>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>> >>> If you go to https://localhost:9993 it will generate the certificate >>> (although all that will be served is a 404 page as the console is not >>> installed). >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas < >>> stuart.w.douglas at gmail.com> wrote: >>> >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene < >>>> jason.greene at redhat.com> wrote: >>>> >>>>> Another option could be a post boot task. So it's still eager but >>>>> don't block completed start. We'd still need to block Tls ports though. So >>>>> maybe this does not help >>>>> >>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>> wrote: >>>>> >>>>> 2048 bits adds close to a second to first boot on my machine >>>>> (obviously subsequent boots are unaffected). >>>>> >>>>> This is probably a bit much, I will work on getting a POC for the lazy >>>>> loading approach implemented. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene < >>>>> jason.greene at redhat.com> wrote: >>>>> >>>>>> We should really be generating 2048 bit keys. >>>>>> >>>>>> I don't like adding to our boot time, we have already seen it grow >>>>>> and this would be yet another case. >>>>>> >>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas < >>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>> >>>>>> So I just did up a very quick prototype that generates self signed >>>>>> certificates on startup and it looks like the difference in startup time is >>>>>> negligible (at least when generating 1024 bit RSA keys). Even if the >>>>>> difference is measurable it only affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the implementation of this it may >>>>>> be better to simply generate the key of first startup, instead of >>>>>> attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >>>>>> jason.greene at redhat.com> wrote: >>>>>> >>>>>>> >>>>>>> What will be default keysize? It has to be probably choosen to work >>>>>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>>>>>> Jurisdiction Policy" >>>>>>>> >>>>>>> >>>>>>> Probably the largest that is supported without JCE. It does not >>>>>>> matter that much, self signed certs are inherently insecure, this is a >>>>>>> developer usability feature, not something that can be used in production. >>>>>>> >>>>>>> >>>>>>> IIRC there is actually no limit on RSA key size, it's only symmetric >>>>>>> algs that are limited, so we could use a standard 2048 bit key without >>>>>>> issue. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>>>> >>>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>>> >>>>>>>>> In terms of auto generating the key I was thinking we would need >>>>>>>>> to add a new attribute to the 'keystore' element under the security realm, >>>>>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>>>>>> other options we would need, or how configurable we should make it, but as >>>>>>>>> this is for testing/development purposes I don't think we need to expose >>>>>>>>> full control over the certificate generation process. >>>>>>>>> >>>>>>>>> In terms of the implementation we could just implement an >>>>>>>>> SSLContext wrapper, that can do the generation and then create a 'real' >>>>>>>>> SSLContext the first time it is asked to create and SSLEngine. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene < >>>>>>>>> jason.greene at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>>> wrote: >>>>>>>>>> > >>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>> >> Hi All, >>>>>>>>>> >> >>>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of >>>>>>>>>> the box >>>>>>>>>> >> in Wildfly 10.1. >>>>>>>>>> >> >>>>>>>>>> > >>>>>>>>>> > This lowly user desperately wants a release containing the fix >>>>>>>>>> to WFLY- >>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have other >>>>>>>>>> pet >>>>>>>>>> > bugs awaiting release. >>>>>>>>>> > >>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>>>>>> pent up >>>>>>>>>> > bug fixes be kept in mind. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Harold, >>>>>>>>>> >>>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jason T. Greene >>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160608/5352d6c2/attachment-0001.html From darran.lofthouse at jboss.com Wed Jun 8 06:23:02 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 8 Jun 2016 11:23:02 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: <5d162792-dea0-694f-cbf7-9c4367b793d8@jboss.com> On 07/06/16 21:51, Jason Greene wrote: > So after reviewing this thread and discussing with a few folks, I?d like > to propose, for 10.1: > > #1b - Same as the previous #1, we don?t enable TLS for management by > default for now, but we additionally include an extra cli script to > enable TLS. > > For 11 I think we should move to TLS by default, perhaps with a > configurable URL policy on redirects, and address the incongruence with > upgrade over app. > > I think its likely reasonable to redirect by default for 11, but we can > hash that out further. One nice thing I had forgotten about is that the > JDK will prompt for you to add unknown certs, and this all works with > the CLI[1]. So it?s really only non-interactive clients we have to worry > about, and that sounds like a reasonable burden for upgrade. > > [1] That is not the JDK, that is the code I worked on to create a more intuitive user experience when the CLI encounters an unexpected certificate ;-) > > [disconnected /] connect > Unable to connect due to unrecognised server certificate > Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US > Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US > Valid From - Tue Jun 07 15:22:06 CDT 2016 > Valid To - Thu Jun 07 15:22:06 CDT 2018 > MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d > SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b > > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t > > >> On Jun 7, 2016, at 6:24 AM, Jason T. Greene > > wrote: >> >> Long term I think we want management using TLS, but that can of course >> come in phases. Assuming 2) is one of those phases to come (either now >> or later), a following step is that the CLI, and really any remoting >> client, should prefer TLS with a defaulted trust store location that >> points to the keystore. >> >> With 2) if we have the default of the attribute that forces redirect >> be true, and our default config be false, then someone that carries >> over their old config would not have a potential security weakness. If >> they have a CLI script that adds the https port, it will fail, >> hopefully sending a signal to look. Although, the user might just >> assume that oh it's there, I don't have to do anything. >> >> Another interesting thing about 2 is that IIRC we have conflicting >> behavior between the app port which doesn't force upgrade and the >> management port which does. >> >> So my preference is 2, because at some point we have to do it anyway, >> and if we have TLS out of the box might as well use it. >> >> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >> > wrote: >> >>> So while implementing this I have noticed a potential problem that it >>> would be good to get some feedback on. >>> >>> If the management interface has SSL by default then the HTTP >>> interface will always redirect to the HTTPS interface. This >>> effectively breaks the management API, as clients such as the CLI, >>> Arquillian etc will be redirected to HTTPS, and then reject the self >>> signed certificate (as they should). >>> >>> I am not sure what to do about this, these are the options as I see them: >>> >>> 1) Don't enable SSL for the management interface (just for the >>> Undertow subsystem). The management interface can still use this >>> auto-generation capability, it just won't be enable by default (we >>> could even leave the cert in the security domain, but just not enable >>> the https interface). >>> >>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>> controlled by an attribute). This will allow the CLI etc to work, but >>> at the price of potentially reducing security, as some connections >>> that would have previously been redirected to use HTTPS will no >>> longer do this. >>> >>> 3) Enable it by default and leave it broken. We can setup some kind >>> of automatic trust store thing so the local CLI works, and can get >>> our test suite to work with Arquillian in a similar manner. >>> Personally I think this is a terrible idea, but I am including it for >>> completeness. >>> >>> Personally I think we should go for 1). Given that this is supposed >>> to be about developer usability I don't think having management also >>> use SSL as being that important. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>> > wrote: >>> >>> Awesome! Another idea I had on how we could get away with it >>> being in server boot, is to have a pre-boot first time setup >>> task, either launched from the shell/batch scripts or as a >>> special pre-step before the AS module loads. We could then report >>> boot time as the time AFTER first time installation tasks have >>> completed, which I think is fair because the server hasn't yet >>> been started. >>> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>> > >>> wrote: >>> >>>> I have some initial work on this at: >>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>> >>>> If you go to https://localhost:9993 it >>>> will generate the certificate (although all that will be served >>>> is a 404 page as the console is not installed). >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>> > >>>> wrote: >>>> >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>> > >>>> wrote: >>>> >>>> Another option could be a post boot task. So it's still >>>> eager but don't block completed start. We'd still need >>>> to block Tls ports though. So maybe this does not help >>>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> 2048 bits adds close to a second to first boot on my >>>>> machine (obviously subsequent boots are unaffected). >>>>> >>>>> This is probably a bit much, I will work on getting a >>>>> POC for the lazy loading approach implemented. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we have >>>>> already seen it grow and this would be yet another >>>>> case. >>>>> >>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> So I just did up a very quick prototype that >>>>>> generates self signed certificates on startup and >>>>>> it looks like the difference in startup time is >>>>>> negligible (at least when generating 1024 bit RSA >>>>>> keys). Even if the difference is measurable it >>>>>> only affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the >>>>>> implementation of this it may be better to simply >>>>>> generate the key of first startup, instead of >>>>>> attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>> >>>>> > wrote: >>>>>> >>>>>> >>>>>>> What will be default keysize? It has to >>>>>>> be probably choosen to work also without >>>>>>> "Java Cryptography Extension (JCE) >>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>> >>>>>>> >>>>>>> Probably the largest that is supported >>>>>>> without JCE. It does not matter that much, >>>>>>> self signed certs are inherently insecure, >>>>>>> this is a developer usability feature, not >>>>>>> something that can be used in production. >>>>>> >>>>>> IIRC there is actually no limit on RSA key >>>>>> size, it's only symmetric algs that are >>>>>> limited, so we could use a standard 2048 bit >>>>>> key without issue. >>>>>> >>>>>> >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>> Douglas >>>>>> > wrote: >>>>>>> >>>>>>> So I guess we should talk about how >>>>>>> this should actually work. >>>>>>> >>>>>>> In terms of auto generating the key I >>>>>>> was thinking we would need to add a >>>>>>> new attribute to the 'keystore' >>>>>>> element under the security realm, >>>>>>> something like >>>>>>> 'auto-generate-cert-host="localhost"'. I >>>>>>> am not sure what other options we >>>>>>> would need, or how configurable we >>>>>>> should make it, but as this is for >>>>>>> testing/development purposes I don't >>>>>>> think we need to expose full control >>>>>>> over the certificate generation process. >>>>>>> >>>>>>> In terms of the implementation we >>>>>>> could just implement an SSLContext >>>>>>> wrapper, that can do the generation >>>>>>> and then create a 'real' SSLContext >>>>>>> the first time it is asked to create >>>>>>> and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>> Greene >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>> > wrote: >>>>>>> > >>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>> >> Hi All, >>>>>>> >> >>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>> >> in Wildfly 10.1. >>>>>>> >> >>>>>>> > >>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>> > bugs awaiting release. >>>>>>> > >>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>> > bug fixes be kept in mind. >>>>>>> >>>>>>> >>>>>>> Hi Harold, >>>>>>> >>>>>>> That fix is already in master, so >>>>>>> it will be included in 10.1. >>>>>>> >>>>>>> -- >>>>>>> Jason T. Greene >>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>> Architect >>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Wed Jun 8 06:23:51 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 8 Jun 2016 11:23:51 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: On 07/06/16 21:55, Stuart Douglas wrote: > > > On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene > wrote: > > So after reviewing this thread and discussing with a few folks, I?d > like to propose, for 10.1: > > #1b - Same as the previous #1, we don?t enable TLS for management by > default for now, but we additionally include an extra cli script to > enable TLS. > > > We would leave the cert generation bit in the security realm, but just > don't enable the HTTPS interface. That way all that is required is for > the user to add the https="managements-https" attribute. +1 It is a minimal config change then to use it. > > Stuart > > > > For 11 I think we should move to TLS by default, perhaps with a > configurable URL policy on redirects, and address the incongruence > with upgrade over app. > > I think its likely reasonable to redirect by default for 11, but we > can hash that out further. One nice thing I had forgotten about is > that the JDK will prompt for you to add unknown certs, and this all > works with the CLI[1]. So it?s really only non-interactive clients > we have to worry about, and that sounds like a reasonable burden for > upgrade. > > [1] > > [disconnected /] connect > Unable to connect due to unrecognised server certificate > Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US > Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US > Valid From - Tue Jun 07 15:22:06 CDT 2016 > Valid To - Thu Jun 07 15:22:06 CDT 2018 > MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d > SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b > > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t > > > >> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >> > wrote: >> >> Long term I think we want management using TLS, but that can of >> course come in phases. Assuming 2) is one of those phases to come >> (either now or later), a following step is that the CLI, and >> really any remoting client, should prefer TLS with a defaulted >> trust store location that points to the keystore. >> >> With 2) if we have the default of the attribute that forces >> redirect be true, and our default config be false, then someone >> that carries over their old config would not have a potential >> security weakness. If they have a CLI script that adds the https >> port, it will fail, hopefully sending a signal to look. Although, >> the user might just assume that oh it's there, I don't have to do >> anything. >> >> Another interesting thing about 2 is that IIRC we have conflicting >> behavior between the app port which doesn't force upgrade and the >> management port which does. >> >> So my preference is 2, because at some point we have to do it >> anyway, and if we have TLS out of the box might as well use it. >> >> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >> > >> wrote: >> >>> So while implementing this I have noticed a potential problem >>> that it would be good to get some feedback on. >>> >>> If the management interface has SSL by default then the HTTP >>> interface will always redirect to the HTTPS interface. This >>> effectively breaks the management API, as clients such as the >>> CLI, Arquillian etc will be redirected to HTTPS, and then reject >>> the self signed certificate (as they should). >>> >>> I am not sure what to do about this, these are the options as I >>> see them: >>> >>> 1) Don't enable SSL for the management interface (just for the >>> Undertow subsystem). The management interface can still use this >>> auto-generation capability, it just won't be enable by default >>> (we could even leave the cert in the security domain, but just >>> not enable the https interface). >>> >>> 2) Disable automatic redirects for HTTP upgrade requests >>> (potentially controlled by an attribute). This will allow the CLI >>> etc to work, but at the price of potentially reducing security, >>> as some connections that would have previously been redirected to >>> use HTTPS will no longer do this. >>> >>> 3) Enable it by default and leave it broken. We can setup some >>> kind of automatic trust store thing so the local CLI works, and >>> can get our test suite to work with Arquillian in a similar >>> manner. Personally I think this is a terrible idea, but I am >>> including it for completeness. >>> >>> Personally I think we should go for 1). Given that this is >>> supposed to be about developer usability I don't think having >>> management also use SSL as being that important. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>> > wrote: >>> >>> Awesome! Another idea I had on how we could get away with it >>> being in server boot, is to have a pre-boot first time setup >>> task, either launched from the shell/batch scripts or as a >>> special pre-step before the AS module loads. We could then >>> report boot time as the time AFTER first time installation >>> tasks have completed, which I think is fair because the >>> server hasn't yet been started. >>> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>> >> > wrote: >>> >>>> I have some initial work on this at: >>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>> >>>> If you go to https://localhost:9993 >>>> it will generate the certificate >>>> (although all that will be served is a 404 page as the >>>> console is not installed). >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>> >>> > wrote: >>>> >>>> Another option could be a post boot task. So it's >>>> still eager but don't block completed start. We'd >>>> still need to block Tls ports though. So maybe this >>>> does not help >>>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> 2048 bits adds close to a second to first boot on >>>>> my machine (obviously subsequent boots are >>>>> unaffected). >>>>> >>>>> This is probably a bit much, I will work on getting >>>>> a POC for the lazy loading approach implemented. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we have >>>>> already seen it grow and this would be yet >>>>> another case. >>>>> >>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> So I just did up a very quick prototype that >>>>>> generates self signed certificates on startup >>>>>> and it looks like the difference in startup >>>>>> time is negligible (at least when generating >>>>>> 1024 bit RSA keys). Even if the difference is >>>>>> measurable it only affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the >>>>>> implementation of this it may be better to >>>>>> simply generate the key of first startup, >>>>>> instead of attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. >>>>>> Greene >>>>> > wrote: >>>>>> >>>>>> >>>>>>> What will be default keysize? It has >>>>>>> to be probably choosen to work also >>>>>>> without "Java Cryptography Extension >>>>>>> (JCE) Unlimited Strength Jurisdiction >>>>>>> Policy" >>>>>>> >>>>>>> >>>>>>> Probably the largest that is supported >>>>>>> without JCE. It does not matter that >>>>>>> much, self signed certs are inherently >>>>>>> insecure, this is a developer usability >>>>>>> feature, not something that can be used >>>>>>> in production. >>>>>> >>>>>> IIRC there is actually no limit on RSA key >>>>>> size, it's only symmetric algs that are >>>>>> limited, so we could use a standard 2048 >>>>>> bit key without issue. >>>>>> >>>>>> >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, >>>>>>> Stuart Douglas >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> So I guess we should talk about >>>>>>> how this should actually work. >>>>>>> >>>>>>> In terms of auto generating the >>>>>>> key I was thinking we would need >>>>>>> to add a new attribute to the >>>>>>> 'keystore' element under the >>>>>>> security realm, something like >>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>> I am not sure what other options >>>>>>> we would need, or how >>>>>>> configurable we should make it, >>>>>>> but as this is for >>>>>>> testing/development purposes I >>>>>>> don't think we need to expose >>>>>>> full control over the certificate >>>>>>> generation process. >>>>>>> >>>>>>> In terms of the implementation we >>>>>>> could just implement an >>>>>>> SSLContext wrapper, that can do >>>>>>> the generation and then create a >>>>>>> 'real' SSLContext the first time >>>>>>> it is asked to create and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, >>>>>>> Jason Greene >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>> > wrote: >>>>>>> > >>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>> >> Hi All, >>>>>>> >> >>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>> >> in Wildfly 10.1. >>>>>>> >> >>>>>>> > >>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>> > bugs awaiting release. >>>>>>> > >>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>> > bug fixes be kept in mind. >>>>>>> >>>>>>> >>>>>>> Hi Harold, >>>>>>> >>>>>>> That fix is already in >>>>>>> master, so it will be >>>>>>> included in 10.1. >>>>>>> >>>>>>> -- >>>>>>> Jason T. Greene >>>>>>> WildFly Lead / JBoss EAP >>>>>>> Platform Architect >>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Wed Jun 8 06:28:45 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 8 Jun 2016 11:28:45 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: For schema changes I find it better to split out the forking of the schema and then the configuration changes into separate commits - that way we can actually see what changed which is essential when porting upstream which will require changes to version 5 of the schema that already exists. Is there any chance we can split this into two? Darran. On 08/06/16 02:51, Stuart Douglas wrote: > I have created a PR for this here: > https://github.com/wildfly/wildfly-core/pull/1596 (it will also require > some upstream changes). > > Basically this just creates a new schema version, and add the > 'generate-self-signed-certificate-host' attribute to the keystore. > > I have not added a script to enable HTTPS over management as Jason > suggested, I am not 100% sure if that really belongs in core or as part > of the full distribution. > > Stuart > > On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas > > wrote: > > > > On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene > > wrote: > > So after reviewing this thread and discussing with a few folks, > I?d like to propose, for 10.1: > > #1b - Same as the previous #1, we don?t enable TLS for > management by default for now, but we additionally include an > extra cli script to enable TLS. > > > We would leave the cert generation bit in the security realm, but > just don't enable the HTTPS interface. That way all that is required > is for the user to add the https="managements-https" attribute. > > Stuart > > > > For 11 I think we should move to TLS by default, perhaps with a > configurable URL policy on redirects, and address the > incongruence with upgrade over app. > > I think its likely reasonable to redirect by default for 11, but > we can hash that out further. One nice thing I had forgotten > about is that the JDK will prompt for you to add unknown certs, > and this all works with the CLI[1]. So it?s really only > non-interactive clients we have to worry about, and that sounds > like a reasonable burden for upgrade. > > [1] > > [disconnected /] connect > Unable to connect due to unrecognised server certificate > Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US > Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US > Valid From - Tue Jun 07 15:22:06 CDT 2016 > Valid To - Thu Jun 07 15:22:06 CDT 2018 > MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d > SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b > > Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t > > > >> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >> > wrote: >> >> Long term I think we want management using TLS, but that can >> of course come in phases. Assuming 2) is one of those phases >> to come (either now or later), a following step is that the >> CLI, and really any remoting client, should prefer TLS with a >> defaulted trust store location that points to the keystore. >> >> With 2) if we have the default of the attribute that forces >> redirect be true, and our default config be false, then >> someone that carries over their old config would not have a >> potential security weakness. If they have a CLI script that >> adds the https port, it will fail, hopefully sending a signal >> to look. Although, the user might just assume that oh it's >> there, I don't have to do anything. >> >> Another interesting thing about 2 is that IIRC we have >> conflicting behavior between the app port which doesn't force >> upgrade and the management port which does. >> >> So my preference is 2, because at some point we have to do it >> anyway, and if we have TLS out of the box might as well use it. >> >> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >> > > wrote: >> >>> So while implementing this I have noticed a potential problem >>> that it would be good to get some feedback on. >>> >>> If the management interface has SSL by default then the HTTP >>> interface will always redirect to the HTTPS interface. This >>> effectively breaks the management API, as clients such as the >>> CLI, Arquillian etc will be redirected to HTTPS, and then >>> reject the self signed certificate (as they should). >>> >>> I am not sure what to do about this, these are the options as >>> I see them: >>> >>> 1) Don't enable SSL for the management interface (just for >>> the Undertow subsystem). The management interface can still >>> use this auto-generation capability, it just won't be enable >>> by default (we could even leave the cert in the security >>> domain, but just not enable the https interface). >>> >>> 2) Disable automatic redirects for HTTP upgrade requests >>> (potentially controlled by an attribute). This will allow the >>> CLI etc to work, but at the price of potentially reducing >>> security, as some connections that would have previously been >>> redirected to use HTTPS will no longer do this. >>> >>> 3) Enable it by default and leave it broken. We can setup >>> some kind of automatic trust store thing so the local CLI >>> works, and can get our test suite to work with Arquillian in >>> a similar manner. Personally I think this is a terrible idea, >>> but I am including it for completeness. >>> >>> Personally I think we should go for 1). Given that this is >>> supposed to be about developer usability I don't think having >>> management also use SSL as being that important. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>> > wrote: >>> >>> Awesome! Another idea I had on how we could get away with >>> it being in server boot, is to have a pre-boot first time >>> setup task, either launched from the shell/batch scripts >>> or as a special pre-step before the AS module loads. We >>> could then report boot time as the time AFTER first time >>> installation tasks have completed, which I think is fair >>> because the server hasn't yet been started. >>> >>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>> >> > wrote: >>> >>>> I have some initial work on this at: >>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>> >>>> If you go to https://localhost:9993 >>>> it will generate the >>>> certificate (although all that will be served is a 404 >>>> page as the console is not installed). >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>> I think that would actually end up being more complex. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>> >>> > wrote: >>>> >>>> Another option could be a post boot task. So >>>> it's still eager but don't block completed >>>> start. We'd still need to block Tls ports >>>> though. So maybe this does not help >>>> >>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> 2048 bits adds close to a second to first boot >>>>> on my machine (obviously subsequent boots are >>>>> unaffected). >>>>> >>>>> This is probably a bit much, I will work on >>>>> getting a POC for the lazy loading approach >>>>> implemented. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. >>>>> Greene >>>> > wrote: >>>>> >>>>> We should really be generating 2048 bit keys. >>>>> >>>>> I don't like adding to our boot time, we >>>>> have already seen it grow and this would be >>>>> yet another case. >>>>> >>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> So I just did up a very quick prototype >>>>>> that generates self signed certificates on >>>>>> startup and it looks like the difference >>>>>> in startup time is negligible (at least >>>>>> when generating 1024 bit RSA keys). Even >>>>>> if the difference is measurable it only >>>>>> affects the very first startup. >>>>>> >>>>>> I think that in order to simplify the >>>>>> implementation of this it may be better to >>>>>> simply generate the key of first startup, >>>>>> instead of attempting to do it lazily. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. >>>>>> Greene >>>>> > wrote: >>>>>> >>>>>> >>>>>>> What will be default keysize? It >>>>>>> has to be probably choosen to >>>>>>> work also without "Java >>>>>>> Cryptography Extension (JCE) >>>>>>> Unlimited Strength Jurisdiction >>>>>>> Policy" >>>>>>> >>>>>>> >>>>>>> Probably the largest that is >>>>>>> supported without JCE. It does not >>>>>>> matter that much, self signed certs >>>>>>> are inherently insecure, this is a >>>>>>> developer usability feature, not >>>>>>> something that can be used in production. >>>>>> >>>>>> IIRC there is actually no limit on RSA >>>>>> key size, it's only symmetric algs >>>>>> that are limited, so we could use a >>>>>> standard 2048 bit key without issue. >>>>>> >>>>>> >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, >>>>>>> Stuart Douglas >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> So I guess we should talk >>>>>>> about how this should >>>>>>> actually work. >>>>>>> >>>>>>> In terms of auto generating >>>>>>> the key I was thinking we >>>>>>> would need to add a new >>>>>>> attribute to the 'keystore' >>>>>>> element under the security >>>>>>> realm, something like >>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>> I am not sure what other >>>>>>> options we would need, or how >>>>>>> configurable we should make >>>>>>> it, but as this is for >>>>>>> testing/development purposes >>>>>>> I don't think we need to >>>>>>> expose full control over the >>>>>>> certificate generation process. >>>>>>> >>>>>>> In terms of the >>>>>>> implementation we could just >>>>>>> implement an SSLContext >>>>>>> wrapper, that can do the >>>>>>> generation and then create a >>>>>>> 'real' SSLContext the first >>>>>>> time it is asked to create >>>>>>> and SSLEngine. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 3:19 >>>>>>> AM, Jason Greene >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>> > wrote: >>>>>>> > >>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>> >> Hi All, >>>>>>> >> >>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>> >> in Wildfly 10.1. >>>>>>> >> >>>>>>> > >>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>> > bugs awaiting release. >>>>>>> > >>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>> > bug fixes be kept in mind. >>>>>>> >>>>>>> >>>>>>> Hi Harold, >>>>>>> >>>>>>> That fix is already in >>>>>>> master, so it will be >>>>>>> included in 10.1. >>>>>>> >>>>>>> -- >>>>>>> Jason T. Greene >>>>>>> WildFly Lead / JBoss EAP >>>>>>> Platform Architect >>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Wed Jun 8 08:24:44 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 8 Jun 2016 08:24:44 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <5d162792-dea0-694f-cbf7-9c4367b793d8@jboss.com> References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> <5d162! 792-dea0-694f-cbf7-9c4367b793d8@jboss.com> Message-ID: <6F2F61B9-62AF-484A-9606-DB415AF78FC1@redhat.com> > On Jun 8, 2016, at 5:23 AM, Darran Lofthouse wrote: > > > >> On 07/06/16 21:51, Jason Greene wrote: >> So after reviewing this thread and discussing with a few folks, I?d like >> to propose, for 10.1: >> >> #1b - Same as the previous #1, we don?t enable TLS for management by >> default for now, but we additionally include an extra cli script to >> enable TLS. >> >> For 11 I think we should move to TLS by default, perhaps with a >> configurable URL policy on redirects, and address the incongruence with >> upgrade over app. >> >> I think its likely reasonable to redirect by default for 11, but we can >> hash that out further. One nice thing I had forgotten about is that the >> JDK will prompt for you to add unknown certs, and this all works with >> the CLI[1]. So it?s really only non-interactive clients we have to worry >> about, and that sounds like a reasonable burden for upgrade. >> >> [1] > > That is not the JDK, that is the code I worked on to create a more > intuitive user experience when the CLI encounters an unexpected > certificate ;-) Ah duh. Well that explains it. I misread the stack trace. This is exactly what I thought we should do for 11 as part of enabling this by default. > >> >> [disconnected /] connect >> Unable to connect due to unrecognised server certificate >> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >> Valid From - Tue Jun 07 15:22:06 CDT 2016 >> Valid To - Thu Jun 07 15:22:06 CDT 2018 >> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >> >> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >> >> >>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >> > wrote: >>> >>> Long term I think we want management using TLS, but that can of course >>> come in phases. Assuming 2) is one of those phases to come (either now >>> or later), a following step is that the CLI, and really any remoting >>> client, should prefer TLS with a defaulted trust store location that >>> points to the keystore. >>> >>> With 2) if we have the default of the attribute that forces redirect >>> be true, and our default config be false, then someone that carries >>> over their old config would not have a potential security weakness. If >>> they have a CLI script that adds the https port, it will fail, >>> hopefully sending a signal to look. Although, the user might just >>> assume that oh it's there, I don't have to do anything. >>> >>> Another interesting thing about 2 is that IIRC we have conflicting >>> behavior between the app port which doesn't force upgrade and the >>> management port which does. >>> >>> So my preference is 2, because at some point we have to do it anyway, >>> and if we have TLS out of the box might as well use it. >>> >>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>> > wrote: >>> >>>> So while implementing this I have noticed a potential problem that it >>>> would be good to get some feedback on. >>>> >>>> If the management interface has SSL by default then the HTTP >>>> interface will always redirect to the HTTPS interface. This >>>> effectively breaks the management API, as clients such as the CLI, >>>> Arquillian etc will be redirected to HTTPS, and then reject the self >>>> signed certificate (as they should). >>>> >>>> I am not sure what to do about this, these are the options as I see them: >>>> >>>> 1) Don't enable SSL for the management interface (just for the >>>> Undertow subsystem). The management interface can still use this >>>> auto-generation capability, it just won't be enable by default (we >>>> could even leave the cert in the security domain, but just not enable >>>> the https interface). >>>> >>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>> controlled by an attribute). This will allow the CLI etc to work, but >>>> at the price of potentially reducing security, as some connections >>>> that would have previously been redirected to use HTTPS will no >>>> longer do this. >>>> >>>> 3) Enable it by default and leave it broken. We can setup some kind >>>> of automatic trust store thing so the local CLI works, and can get >>>> our test suite to work with Arquillian in a similar manner. >>>> Personally I think this is a terrible idea, but I am including it for >>>> completeness. >>>> >>>> Personally I think we should go for 1). Given that this is supposed >>>> to be about developer usability I don't think having management also >>>> use SSL as being that important. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>> > wrote: >>>> >>>> Awesome! Another idea I had on how we could get away with it >>>> being in server boot, is to have a pre-boot first time setup >>>> task, either launched from the shell/batch scripts or as a >>>> special pre-step before the AS module loads. We could then report >>>> boot time as the time AFTER first time installation tasks have >>>> completed, which I think is fair because the server hasn't yet >>>> been started. >>>> >>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>> > >>>> wrote: >>>> >>>>> I have some initial work on this at: >>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>> >>>>> If you go to https://localhost:9993 it >>>>> will generate the certificate (although all that will be served >>>>> is a 404 page as the console is not installed). >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>> > >>>>> wrote: >>>>> >>>>> I think that would actually end up being more complex. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>> > >>>>> wrote: >>>>> >>>>> Another option could be a post boot task. So it's still >>>>> eager but don't block completed start. We'd still need >>>>> to block Tls ports though. So maybe this does not help >>>>> >>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> 2048 bits adds close to a second to first boot on my >>>>>> machine (obviously subsequent boots are unaffected). >>>>>> >>>>>> This is probably a bit much, I will work on getting a >>>>>> POC for the lazy loading approach implemented. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>> >>>>> > wrote: >>>>>> >>>>>> We should really be generating 2048 bit keys. >>>>>> >>>>>> I don't like adding to our boot time, we have >>>>>> already seen it grow and this would be yet another >>>>>> case. >>>>>> >>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>> >>>>> > wrote: >>>>>> >>>>>>> So I just did up a very quick prototype that >>>>>>> generates self signed certificates on startup and >>>>>>> it looks like the difference in startup time is >>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>> keys). Even if the difference is measurable it >>>>>>> only affects the very first startup. >>>>>>> >>>>>>> I think that in order to simplify the >>>>>>> implementation of this it may be better to simply >>>>>>> generate the key of first startup, instead of >>>>>>> attempting to do it lazily. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>>> What will be default keysize? It has to >>>>>>>> be probably choosen to work also without >>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>> >>>>>>>> >>>>>>>> Probably the largest that is supported >>>>>>>> without JCE. It does not matter that much, >>>>>>>> self signed certs are inherently insecure, >>>>>>>> this is a developer usability feature, not >>>>>>>> something that can be used in production. >>>>>>> >>>>>>> IIRC there is actually no limit on RSA key >>>>>>> size, it's only symmetric algs that are >>>>>>> limited, so we could use a standard 2048 bit >>>>>>> key without issue. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>> Douglas >>>>>>> > wrote: >>>>>>>> >>>>>>>> So I guess we should talk about how >>>>>>>> this should actually work. >>>>>>>> >>>>>>>> In terms of auto generating the key I >>>>>>>> was thinking we would need to add a >>>>>>>> new attribute to the 'keystore' >>>>>>>> element under the security realm, >>>>>>>> something like >>>>>>>> 'auto-generate-cert-host="localhost"'. I >>>>>>>> am not sure what other options we >>>>>>>> would need, or how configurable we >>>>>>>> should make it, but as this is for >>>>>>>> testing/development purposes I don't >>>>>>>> think we need to expose full control >>>>>>>> over the certificate generation process. >>>>>>>> >>>>>>>> In terms of the implementation we >>>>>>>> could just implement an SSLContext >>>>>>>> wrapper, that can do the generation >>>>>>>> and then create a 'real' SSLContext >>>>>>>> the first time it is asked to create >>>>>>>> and SSLEngine. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>> Greene >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>> in Wildfly 10.1. >>>>>>>>> >>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>> bugs awaiting release. >>>>>>>>> >>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>> bug fixes be kept in mind. >>>>>>>> >>>>>>>> >>>>>>>> Hi Harold, >>>>>>>> >>>>>>>> That fix is already in master, so >>>>>>>> it will be included in 10.1. >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>> Architect >>>>>>>> JBoss, a division of Red Hat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Wed Jun 8 08:26:16 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 8 Jun 2016 08:26:16 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> Message-ID: <1D2009C3-D718-4FB2-9265-EC62844B6BB9@redhat.com> > On Jun 8, 2016, at 5:24 AM, Darran Lofthouse wrote: > >> On 07/06/16 21:55, Stuart Douglas wrote: >> >> >> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene > > wrote: >> >> So after reviewing this thread and discussing with a few folks, I?d >> like to propose, for 10.1: >> >> #1b - Same as the previous #1, we don?t enable TLS for management by >> default for now, but we additionally include an extra cli script to >> enable TLS. >> >> >> We would leave the cert generation bit in the security realm, but just >> don't enable the HTTPS interface. That way all that is required is for >> the user to add the https="managements-https" attribute. > > +1 It is a minimal config change then to use it. Indeed, but we still need to have a script so the user doesn't have to dig around for the magic setting. > > >> >> Stuart >> >> >> >> For 11 I think we should move to TLS by default, perhaps with a >> configurable URL policy on redirects, and address the incongruence >> with upgrade over app. >> >> I think its likely reasonable to redirect by default for 11, but we >> can hash that out further. One nice thing I had forgotten about is >> that the JDK will prompt for you to add unknown certs, and this all >> works with the CLI[1]. So it?s really only non-interactive clients >> we have to worry about, and that sounds like a reasonable burden for >> upgrade. >> >> [1] >> >> [disconnected /] connect >> Unable to connect due to unrecognised server certificate >> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >> Valid From - Tue Jun 07 15:22:06 CDT 2016 >> Valid To - Thu Jun 07 15:22:06 CDT 2018 >> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >> >> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >> >> >> >>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >>> > wrote: >>> >>> Long term I think we want management using TLS, but that can of >>> course come in phases. Assuming 2) is one of those phases to come >>> (either now or later), a following step is that the CLI, and >>> really any remoting client, should prefer TLS with a defaulted >>> trust store location that points to the keystore. >>> >>> With 2) if we have the default of the attribute that forces >>> redirect be true, and our default config be false, then someone >>> that carries over their old config would not have a potential >>> security weakness. If they have a CLI script that adds the https >>> port, it will fail, hopefully sending a signal to look. Although, >>> the user might just assume that oh it's there, I don't have to do >>> anything. >>> >>> Another interesting thing about 2 is that IIRC we have conflicting >>> behavior between the app port which doesn't force upgrade and the >>> management port which does. >>> >>> So my preference is 2, because at some point we have to do it >>> anyway, and if we have TLS out of the box might as well use it. >>> >>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>> > >>> wrote: >>> >>>> So while implementing this I have noticed a potential problem >>>> that it would be good to get some feedback on. >>>> >>>> If the management interface has SSL by default then the HTTP >>>> interface will always redirect to the HTTPS interface. This >>>> effectively breaks the management API, as clients such as the >>>> CLI, Arquillian etc will be redirected to HTTPS, and then reject >>>> the self signed certificate (as they should). >>>> >>>> I am not sure what to do about this, these are the options as I >>>> see them: >>>> >>>> 1) Don't enable SSL for the management interface (just for the >>>> Undertow subsystem). The management interface can still use this >>>> auto-generation capability, it just won't be enable by default >>>> (we could even leave the cert in the security domain, but just >>>> not enable the https interface). >>>> >>>> 2) Disable automatic redirects for HTTP upgrade requests >>>> (potentially controlled by an attribute). This will allow the CLI >>>> etc to work, but at the price of potentially reducing security, >>>> as some connections that would have previously been redirected to >>>> use HTTPS will no longer do this. >>>> >>>> 3) Enable it by default and leave it broken. We can setup some >>>> kind of automatic trust store thing so the local CLI works, and >>>> can get our test suite to work with Arquillian in a similar >>>> manner. Personally I think this is a terrible idea, but I am >>>> including it for completeness. >>>> >>>> Personally I think we should go for 1). Given that this is >>>> supposed to be about developer usability I don't think having >>>> management also use SSL as being that important. >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>> > wrote: >>>> >>>> Awesome! Another idea I had on how we could get away with it >>>> being in server boot, is to have a pre-boot first time setup >>>> task, either launched from the shell/batch scripts or as a >>>> special pre-step before the AS module loads. We could then >>>> report boot time as the time AFTER first time installation >>>> tasks have completed, which I think is fair because the >>>> server hasn't yet been started. >>>> >>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>> >>> > wrote: >>>> >>>>> I have some initial work on this at: >>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>> >>>>> If you go to https://localhost:9993 >>>>> it will generate the certificate >>>>> (although all that will be served is a 404 page as the >>>>> console is not installed). >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>> I think that would actually end up being more complex. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>> >>>> > wrote: >>>>> >>>>> Another option could be a post boot task. So it's >>>>> still eager but don't block completed start. We'd >>>>> still need to block Tls ports though. So maybe this >>>>> does not help >>>>> >>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>> >>>> > wrote: >>>>> >>>>>> 2048 bits adds close to a second to first boot on >>>>>> my machine (obviously subsequent boots are >>>>>> unaffected). >>>>>> >>>>>> This is probably a bit much, I will work on getting >>>>>> a POC for the lazy loading approach implemented. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>> >>>>> > wrote: >>>>>> >>>>>> We should really be generating 2048 bit keys. >>>>>> >>>>>> I don't like adding to our boot time, we have >>>>>> already seen it grow and this would be yet >>>>>> another case. >>>>>> >>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>> >>>>> > wrote: >>>>>> >>>>>>> So I just did up a very quick prototype that >>>>>>> generates self signed certificates on startup >>>>>>> and it looks like the difference in startup >>>>>>> time is negligible (at least when generating >>>>>>> 1024 bit RSA keys). Even if the difference is >>>>>>> measurable it only affects the very first startup. >>>>>>> >>>>>>> I think that in order to simplify the >>>>>>> implementation of this it may be better to >>>>>>> simply generate the key of first startup, >>>>>>> instead of attempting to do it lazily. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. >>>>>>> Greene >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>>> What will be default keysize? It has >>>>>>>> to be probably choosen to work also >>>>>>>> without "Java Cryptography Extension >>>>>>>> (JCE) Unlimited Strength Jurisdiction >>>>>>>> Policy" >>>>>>>> >>>>>>>> >>>>>>>> Probably the largest that is supported >>>>>>>> without JCE. It does not matter that >>>>>>>> much, self signed certs are inherently >>>>>>>> insecure, this is a developer usability >>>>>>>> feature, not something that can be used >>>>>>>> in production. >>>>>>> >>>>>>> IIRC there is actually no limit on RSA key >>>>>>> size, it's only symmetric algs that are >>>>>>> limited, so we could use a standard 2048 >>>>>>> bit key without issue. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, >>>>>>>> Stuart Douglas >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> So I guess we should talk about >>>>>>>> how this should actually work. >>>>>>>> >>>>>>>> In terms of auto generating the >>>>>>>> key I was thinking we would need >>>>>>>> to add a new attribute to the >>>>>>>> 'keystore' element under the >>>>>>>> security realm, something like >>>>>>>> 'auto-generate-cert-host="localhost"'. >>>>>>>> I am not sure what other options >>>>>>>> we would need, or how >>>>>>>> configurable we should make it, >>>>>>>> but as this is for >>>>>>>> testing/development purposes I >>>>>>>> don't think we need to expose >>>>>>>> full control over the certificate >>>>>>>> generation process. >>>>>>>> >>>>>>>> In terms of the implementation we >>>>>>>> could just implement an >>>>>>>> SSLContext wrapper, that can do >>>>>>>> the generation and then create a >>>>>>>> 'real' SSLContext the first time >>>>>>>> it is asked to create and SSLEngine. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, >>>>>>>> Jason Greene >>>>>>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>> in Wildfly 10.1. >>>>>>>>> >>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>> bugs awaiting release. >>>>>>>>> >>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>> bug fixes be kept in mind. >>>>>>>> >>>>>>>> >>>>>>>> Hi Harold, >>>>>>>> >>>>>>>> That fix is already in >>>>>>>> master, so it will be >>>>>>>> included in 10.1. >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> WildFly Lead / JBoss EAP >>>>>>>> Platform Architect >>>>>>>> JBoss, a division of Red Hat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Wed Jun 8 08:28:43 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 8 Jun 2016 08:28:43 -0400 (EDT) Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334! -BA68-FF441B3E0FC9@redhat.com> Message-ID: <4E1736CC-440A-44B4-B58E-C7125448427E@redhat.com> > On Jun 7, 2016, at 8:51 PM, Stuart Douglas wrote: > > I have created a PR for this here: https://github.com/wildfly/wildfly-core/pull/1596 (it will also require some upstream changes). > > Basically this just creates a new schema version, and add the 'generate-self-signed-certificate-host' attribute to the keystore. > > I have not added a script to enable HTTPS over management as Jason suggested, I am not 100% sure if that really belongs in core or as part of the full distribution. > It probably belongs in core so that other layered projects/products can get it as well. However for 10.1 I think it's fine if we stick it in full for now. > Stuart > >> On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas wrote: >> >> >>> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene wrote: >>> So after reviewing this thread and discussing with a few folks, I?d like to propose, for 10.1: >>> >>> #1b - Same as the previous #1, we don?t enable TLS for management by default for now, but we additionally include an extra cli script to enable TLS. >> >> We would leave the cert generation bit in the security realm, but just don't enable the HTTPS interface. That way all that is required is for the user to add the https="managements-https" attribute. >> >> Stuart >> >>> >>> For 11 I think we should move to TLS by default, perhaps with a configurable URL policy on redirects, and address the incongruence with upgrade over app. >>> >>> I think its likely reasonable to redirect by default for 11, but we can hash that out further. One nice thing I had forgotten about is that the JDK will prompt for you to add unknown certs, and this all works with the CLI[1]. So it?s really only non-interactive clients we have to worry about, and that sounds like a reasonable burden for upgrade. >>> >>> [1] >>> >>> [disconnected /] connect >>> Unable to connect due to unrecognised server certificate >>> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >>> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >>> Valid From - Tue Jun 07 15:22:06 CDT 2016 >>> Valid To - Thu Jun 07 15:22:06 CDT 2018 >>> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >>> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >>> >>> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >>> >>> >>> >>>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene wrote: >>>> >>>> Long term I think we want management using TLS, but that can of course come in phases. Assuming 2) is one of those phases to come (either now or later), a following step is that the CLI, and really any remoting client, should prefer TLS with a defaulted trust store location that points to the keystore. >>>> >>>> With 2) if we have the default of the attribute that forces redirect be true, and our default config be false, then someone that carries over their old config would not have a potential security weakness. If they have a CLI script that adds the https port, it will fail, hopefully sending a signal to look. Although, the user might just assume that oh it's there, I don't have to do anything. >>>> >>>> Another interesting thing about 2 is that IIRC we have conflicting behavior between the app port which doesn't force upgrade and the management port which does. >>>> >>>> So my preference is 2, because at some point we have to do it anyway, and if we have TLS out of the box might as well use it. >>>> >>>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas wrote: >>>>> >>>>> So while implementing this I have noticed a potential problem that it would be good to get some feedback on. >>>>> >>>>> If the management interface has SSL by default then the HTTP interface will always redirect to the HTTPS interface. This effectively breaks the management API, as clients such as the CLI, Arquillian etc will be redirected to HTTPS, and then reject the self signed certificate (as they should). >>>>> >>>>> I am not sure what to do about this, these are the options as I see them: >>>>> >>>>> 1) Don't enable SSL for the management interface (just for the Undertow subsystem). The management interface can still use this auto-generation capability, it just won't be enable by default (we could even leave the cert in the security domain, but just not enable the https interface). >>>>> >>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially controlled by an attribute). This will allow the CLI etc to work, but at the price of potentially reducing security, as some connections that would have previously been redirected to use HTTPS will no longer do this. >>>>> >>>>> 3) Enable it by default and leave it broken. We can setup some kind of automatic trust store thing so the local CLI works, and can get our test suite to work with Arquillian in a similar manner. Personally I think this is a terrible idea, but I am including it for completeness. >>>>> >>>>> Personally I think we should go for 1). Given that this is supposed to be about developer usability I don't think having management also use SSL as being that important. >>>>> >>>>> Stuart >>>>> >>>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene wrote: >>>>>> Awesome! Another idea I had on how we could get away with it being in server boot, is to have a pre-boot first time setup task, either launched from the shell/batch scripts or as a special pre-step before the AS module loads. We could then report boot time as the time AFTER first time installation tasks have completed, which I think is fair because the server hasn't yet been started. >>>>>> >>>>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas wrote: >>>>>>> >>>>>>> I have some initial work on this at: https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>>> >>>>>>> If you go to https://localhost:9993 it will generate the certificate (although all that will be served is a 404 page as the console is not installed). >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas wrote: >>>>>>>> I think that would actually end up being more complex. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene wrote: >>>>>>>>> Another option could be a post boot task. So it's still eager but don't block completed start. We'd still need to block Tls ports though. So maybe this does not help >>>>>>>>> >>>>>>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas wrote: >>>>>>>>>> >>>>>>>>>> 2048 bits adds close to a second to first boot on my machine (obviously subsequent boots are unaffected). >>>>>>>>>> >>>>>>>>>> This is probably a bit much, I will work on getting a POC for the lazy loading approach implemented. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene wrote: >>>>>>>>>>> We should really be generating 2048 bit keys. >>>>>>>>>>> >>>>>>>>>>> I don't like adding to our boot time, we have already seen it grow and this would be yet another case. >>>>>>>>>>> >>>>>>>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas wrote: >>>>>>>>>>>> >>>>>>>>>>>> So I just did up a very quick prototype that generates self signed certificates on startup and it looks like the difference in startup time is negligible (at least when generating 1024 bit RSA keys). Even if the difference is measurable it only affects the very first startup. >>>>>>>>>>>> >>>>>>>>>>>> I think that in order to simplify the implementation of this it may be better to simply generate the key of first startup, instead of attempting to do it lazily. >>>>>>>>>>>> >>>>>>>>>>>> Stuart >>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>> What will be default keysize? It has to be probably choosen to work also without "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy" >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Probably the largest that is supported without JCE. It does not matter that much, self signed certs are inherently insecure, this is a developer usability feature, not something that can be used in production. >>>>>>>>>>>>> >>>>>>>>>>>>> IIRC there is actually no limit on RSA key size, it's only symmetric algs that are limited, so we could use a standard 2048 bit key without issue. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Stuart >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In terms of auto generating the key I was thinking we would need to add a new attribute to the 'keystore' element under the security realm, something like 'auto-generate-cert-host="localhost"'. I am not sure what other options we would need, or how configurable we should make it, but as this is for testing/development purposes I don't think we need to expose full control over the certificate generation process. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In terms of the implementation we could just implement an SSLContext wrapper, that can do the generation and then create a 'real' SSLContext the first time it is asked to create and SSLEngine. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Stuart >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell wrote: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>>>>>>>> >> Hi All, >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>>>>>>>> >> in Wildfly 10.1. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>>>>>>>>> > bugs awaiting release. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>>>>>>>>> > bug fixes be kept in mind. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Harold, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Jason T. Greene >>>>>>>>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160608/702560d1/attachment-0001.html From darran.lofthouse at jboss.com Wed Jun 8 08:36:21 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 8 Jun 2016 13:36:21 +0100 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <6F2F61B9-62AF-484A-9606-DB415AF78FC1@redhat.com> References: <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <656F097F-EAA8-4334-BA68-FF441B3E0FC9@redhat.com> <5d162! 792-dea0-694f-cbf7-9c4367b793d8@jboss.com> <6F2F61B9-62AF-484A-9606-DB415AF78FC1@redhat.com> Message-ID: On 08/06/16 13:24, Jason T. Greene wrote: > > > >> On Jun 8, 2016, at 5:23 AM, Darran Lofthouse wrote: >> >> >> >>> On 07/06/16 21:51, Jason Greene wrote: >>> So after reviewing this thread and discussing with a few folks, I?d like >>> to propose, for 10.1: >>> >>> #1b - Same as the previous #1, we don?t enable TLS for management by >>> default for now, but we additionally include an extra cli script to >>> enable TLS. >>> >>> For 11 I think we should move to TLS by default, perhaps with a >>> configurable URL policy on redirects, and address the incongruence with >>> upgrade over app. >>> >>> I think its likely reasonable to redirect by default for 11, but we can >>> hash that out further. One nice thing I had forgotten about is that the >>> JDK will prompt for you to add unknown certs, and this all works with >>> the CLI[1]. So it?s really only non-interactive clients we have to worry >>> about, and that sounds like a reasonable burden for upgrade. >>> >>> [1] >> >> That is not the JDK, that is the code I worked on to create a more >> intuitive user experience when the CLI encounters an unexpected >> certificate ;-) > > > Ah duh. Well that explains it. I misread the stack trace. This is exactly what I thought we should do for 11 as part of enabling this by default. We could even ship the CLI with a configured server trust store and add the generated certificate to that store - it would not stop the prompt from working but local CLI to local server the prompt would not even be needed. We need to think about how the Maven plug-in will resolve Elytron client configuration as that is typically executed from within a build but with a common security configuration on the way it may even be possible for that to automatically use the local server generated trust store. > >> >>> >>> [disconnected /] connect >>> Unable to connect due to unrecognised server certificate >>> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >>> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >>> Valid From - Tue Jun 07 15:22:06 CDT 2016 >>> Valid To - Thu Jun 07 15:22:06 CDT 2018 >>> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >>> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >>> >>> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >>> >>> >>>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >>> > wrote: >>>> >>>> Long term I think we want management using TLS, but that can of course >>>> come in phases. Assuming 2) is one of those phases to come (either now >>>> or later), a following step is that the CLI, and really any remoting >>>> client, should prefer TLS with a defaulted trust store location that >>>> points to the keystore. >>>> >>>> With 2) if we have the default of the attribute that forces redirect >>>> be true, and our default config be false, then someone that carries >>>> over their old config would not have a potential security weakness. If >>>> they have a CLI script that adds the https port, it will fail, >>>> hopefully sending a signal to look. Although, the user might just >>>> assume that oh it's there, I don't have to do anything. >>>> >>>> Another interesting thing about 2 is that IIRC we have conflicting >>>> behavior between the app port which doesn't force upgrade and the >>>> management port which does. >>>> >>>> So my preference is 2, because at some point we have to do it anyway, >>>> and if we have TLS out of the box might as well use it. >>>> >>>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>>> > wrote: >>>> >>>>> So while implementing this I have noticed a potential problem that it >>>>> would be good to get some feedback on. >>>>> >>>>> If the management interface has SSL by default then the HTTP >>>>> interface will always redirect to the HTTPS interface. This >>>>> effectively breaks the management API, as clients such as the CLI, >>>>> Arquillian etc will be redirected to HTTPS, and then reject the self >>>>> signed certificate (as they should). >>>>> >>>>> I am not sure what to do about this, these are the options as I see them: >>>>> >>>>> 1) Don't enable SSL for the management interface (just for the >>>>> Undertow subsystem). The management interface can still use this >>>>> auto-generation capability, it just won't be enable by default (we >>>>> could even leave the cert in the security domain, but just not enable >>>>> the https interface). >>>>> >>>>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>>>> controlled by an attribute). This will allow the CLI etc to work, but >>>>> at the price of potentially reducing security, as some connections >>>>> that would have previously been redirected to use HTTPS will no >>>>> longer do this. >>>>> >>>>> 3) Enable it by default and leave it broken. We can setup some kind >>>>> of automatic trust store thing so the local CLI works, and can get >>>>> our test suite to work with Arquillian in a similar manner. >>>>> Personally I think this is a terrible idea, but I am including it for >>>>> completeness. >>>>> >>>>> Personally I think we should go for 1). Given that this is supposed >>>>> to be about developer usability I don't think having management also >>>>> use SSL as being that important. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene >>>>> > wrote: >>>>> >>>>> Awesome! Another idea I had on how we could get away with it >>>>> being in server boot, is to have a pre-boot first time setup >>>>> task, either launched from the shell/batch scripts or as a >>>>> special pre-step before the AS module loads. We could then report >>>>> boot time as the time AFTER first time installation tasks have >>>>> completed, which I think is fair because the server hasn't yet >>>>> been started. >>>>> >>>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>>> > >>>>> wrote: >>>>> >>>>>> I have some initial work on this at: >>>>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>>>> >>>>>> If you go to https://localhost:9993 it >>>>>> will generate the certificate (although all that will be served >>>>>> is a 404 page as the console is not installed). >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas >>>>>> > >>>>>> wrote: >>>>>> >>>>>> I think that would actually end up being more complex. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Another option could be a post boot task. So it's still >>>>>> eager but don't block completed start. We'd still need >>>>>> to block Tls ports though. So maybe this does not help >>>>>> >>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas >>>>>> >>>>> > wrote: >>>>>> >>>>>>> 2048 bits adds close to a second to first boot on my >>>>>>> machine (obviously subsequent boots are unaffected). >>>>>>> >>>>>>> This is probably a bit much, I will work on getting a >>>>>>> POC for the lazy loading approach implemented. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> We should really be generating 2048 bit keys. >>>>>>> >>>>>>> I don't like adding to our boot time, we have >>>>>>> already seen it grow and this would be yet another >>>>>>> case. >>>>>>> >>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>>> So I just did up a very quick prototype that >>>>>>>> generates self signed certificates on startup and >>>>>>>> it looks like the difference in startup time is >>>>>>>> negligible (at least when generating 1024 bit RSA >>>>>>>> keys). Even if the difference is measurable it >>>>>>>> only affects the very first startup. >>>>>>>> >>>>>>>> I think that in order to simplify the >>>>>>>> implementation of this it may be better to simply >>>>>>>> generate the key of first startup, instead of >>>>>>>> attempting to do it lazily. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>>> What will be default keysize? It has to >>>>>>>>> be probably choosen to work also without >>>>>>>>> "Java Cryptography Extension (JCE) >>>>>>>>> Unlimited Strength Jurisdiction Policy" >>>>>>>>> >>>>>>>>> >>>>>>>>> Probably the largest that is supported >>>>>>>>> without JCE. It does not matter that much, >>>>>>>>> self signed certs are inherently insecure, >>>>>>>>> this is a developer usability feature, not >>>>>>>>> something that can be used in production. >>>>>>>> >>>>>>>> IIRC there is actually no limit on RSA key >>>>>>>> size, it's only symmetric algs that are >>>>>>>> limited, so we could use a standard 2048 bit >>>>>>>> key without issue. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart >>>>>>>>> Douglas >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> So I guess we should talk about how >>>>>>>>> this should actually work. >>>>>>>>> >>>>>>>>> In terms of auto generating the key I >>>>>>>>> was thinking we would need to add a >>>>>>>>> new attribute to the 'keystore' >>>>>>>>> element under the security realm, >>>>>>>>> something like >>>>>>>>> 'auto-generate-cert-host="localhost"'. I >>>>>>>>> am not sure what other options we >>>>>>>>> would need, or how configurable we >>>>>>>>> should make it, but as this is for >>>>>>>>> testing/development purposes I don't >>>>>>>>> think we need to expose full control >>>>>>>>> over the certificate generation process. >>>>>>>>> >>>>>>>>> In terms of the implementation we >>>>>>>>> could just implement an SSLContext >>>>>>>>> wrapper, that can do the generation >>>>>>>>> and then create a 'real' SSLContext >>>>>>>>> the first time it is asked to create >>>>>>>>> and SSLEngine. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason >>>>>>>>> Greene >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I would like to propose that we add support for HTTP/2 out of the box >>>>>>>>>>> in Wildfly 10.1. >>>>>>>>>> >>>>>>>>>> This lowly user desperately wants a release containing the fix to WFLY- >>>>>>>>>> 6283 sooner rather than later. I'm sure other people have other pet >>>>>>>>>> bugs awaiting release. >>>>>>>>>> >>>>>>>>>> I have no opinion on HTTP/2 being added other than to ask that pent up >>>>>>>>>> bug fixes be kept in mind. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Harold, >>>>>>>>> >>>>>>>>> That fix is already in master, so >>>>>>>>> it will be included in 10.1. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jason T. Greene >>>>>>>>> WildFly Lead / JBoss EAP Platform >>>>>>>>> Architect >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Wed Jun 8 10:39:36 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 8 Jun 2016 10:39:36 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... Message-ID: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> [1] is an example of the MongoDB subsystem configuration (work in progress), that specifies three different connection profiles (mongodbtestprofile_ack, mongodbtestprofile_unack, mongodbtestprofile_custom). It should be easy for users to specify one of the MongoDB constants for the write-concern setting, for each of the MongoDB profiles. Specifying a custom write-concern is also possible (see mongodbtestprofile_custom and underlying MongoDB java driver api [2]). In [1], I prefer the first configuration example that names the custom write-concern element "custom-write-concern", as I thought it might be confusing if users used the same "write-concern" name in two different places, however, using "write-concern" for both, could be more consistent. Should we use "custom-write-concern" or "write-concern" for the custom configuration element? It comes down to a choice between: ... For those not reading [1], we also can support one of the predefined write-concern constants via: ... Also, is the 'name="default"' setting required for addressing specific elements with the CLI tool? I assume this is the case but don't remember for sure. Thanks for the input/discussion! :-) Scott [1] https://gist.github.com/scottmarlow/6895f15219ca16a5bc95fc19ef5b397e [2] https://api.mongodb.com/java/3.1/com/mongodb/WriteConcern.html#WriteConcern-int-int-boolean-boolean- From jesper.pedersen at redhat.com Wed Jun 8 10:44:29 2016 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Wed, 8 Jun 2016 10:44:29 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> Message-ID: <57582F4D.2090103@redhat.com> On 06/08/2016 10:39 AM, Scott Marlow wrote: > For those not reading [1], we also can support one of the predefined > write-concern constants via: > > > ... > > I would choose this approach, and support the predefined constants. Exposing MongoDB internal API details in the configuration seems to be overkill, and put extra effort on your part when they change the API. Best regards, Jesper From brian.stansberry at redhat.com Wed Jun 8 16:12:35 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 8 Jun 2016 15:12:35 -0500 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> Message-ID: On 6/8/16 9:39 AM, Scott Marlow wrote: > [1] is an example of the MongoDB subsystem configuration (work in > progress), that specifies three different connection profiles > (mongodbtestprofile_ack, mongodbtestprofile_unack, > mongodbtestprofile_custom). It should be easy for users to specify one > of the MongoDB constants for the write-concern setting, for each of the > MongoDB profiles. Specifying a custom write-concern is also possible > (see mongodbtestprofile_custom and underlying MongoDB java driver api [2]). > > In [1], I prefer the first configuration example that names the custom > write-concern element "custom-write-concern", as I thought it might be > confusing if users used the same "write-concern" name in two different > places, however, using "write-concern" for both, could be more consistent. > > Should we use "custom-write-concern" or "write-concern" for the custom > configuration element? > > It comes down to a choice between: > > > ... > > > > For those not reading [1], we also can support one of the predefined > write-concern constants via: > > > ... > > I think it's confusing to have both an attribute and an element named "write-concern". Also, in the management model you are going to need to have two attributes, one an enum for ACKNOWLEGED etc and then another for the custom write concern. (The attributes would be declared as alternatives to each other so the user can only configure one or the other. CUSTOM would not be a value for the enum.) Since you'll have two attributes in the model, probably "write-concern" and "custom-write-concern", it will be even more confusing to call them both "write-concern" in the xml. > Also, is the 'name="default"' setting required for addressing specific > elements with the CLI tool? I assume this is the case but don't > remember for sure. > Can there be more than 1 custom-write-concern per profile? If not I doubt that the config of the custom write concern should be done via a resource. It's a complex attribute of the profile resource, and any "name" is superfluous. Even if you model it via a resource, if there is only one the value part of the final type=value element of its address can be statically defined; it doesn't need to be user configurable or stored in xml. > Thanks for the input/discussion! :-) > > Scott > > [1] https://gist.github.com/scottmarlow/6895f15219ca16a5bc95fc19ef5b397e > > [2] > https://api.mongodb.com/java/3.1/com/mongodb/WriteConcern.html#WriteConcern-int-int-boolean-boolean- > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Jun 8 16:18:03 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 8 Jun 2016 15:18:03 -0500 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <57582F4D.2090103@redhat.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> Message-ID: On 6/8/16 9:44 AM, Jesper Pedersen wrote: > On 06/08/2016 10:39 AM, Scott Marlow wrote: >> For those not reading [1], we also can support one of the predefined >> write-concern constants via: >> >> >> ... >> >> > > I would choose this approach, and support the predefined constants. > > Exposing MongoDB internal API details in the configuration seems to be > overkill, and put extra effort on your part when they change the API. > This is good input. If this ends up in WildFly or EAP, we have stringent compatibility guarantees, so be cautious about exposing things in your API. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jorsol at gmail.com Wed Jun 8 19:25:05 2016 From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=) Date: Wed, 8 Jun 2016 17:25:05 -0600 Subject: [wildfly-dev] WildFly call to sp_reset_connection on SQL Server 2008 R2 Message-ID: Hi, I'm using Microsoft SQL Server JDBC Driver 4.2 with WildFly 10, and looking at https://msdn.microsoft.com/en-us/library/ms378484.aspx there is a note about connection pooling: The JDBC driver does not currently call the sp_reset_connection stored > procedure when it returns the connection to the pool. Instead, the driver > relies on third-party Java Application Servers to return the connections > back to their original states. > *?*I ? ? create a trace ? ? and ? ? that sp is not executed ? ? when the connection is returned to the pool, ? this should be called explicitly in my app or the Application Server should do it?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160608/646c7812/attachment.html From gunnar at hibernate.org Thu Jun 9 06:27:30 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 9 Jun 2016 12:27:30 +0200 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> Message-ID: Hi, My concern with the current proposal and its usage of dedicated elements/attributes for specific options such as write concern is that it easily leads into a catch-up game with datastore vendors as they keep adding new options. That might create a constant effort for maintaining this subsystem. How about having a more generic approach which only has typed elements for common properties/settings such as user, password, database name and then allows to set custom things as part of the connection URL: nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... bob secret Here, the connection-url would be analyzed to load the right driver and pass any configured settings to it. While compact, that URL syntax might be confused with existing URI schemes of specific stores, so an alternative might be this (a bit more verbose, though): mongodb localhost:27017,otherhost:27017 somedatabase bob secret ACKNOWLEDGED MAJORITY Both alternatives don't address custom write concerns, but I think you foresee CDI producer methods for more advanced customizations, so that might be fine. That'd also be needed for some other non-primitive options (dbDecoderFactory, codecRegistry etc.), unless you provide a way to configure classes here and have them instantiated. These more generic approaches will make it more robust towards new options being added, but of course you also loose type-safety and I suppose usability in the console which might provide dedicated editors for real types such as boolean etc. --Gunnar 2016-06-08 22:18 GMT+02:00 Brian Stansberry : > On 6/8/16 9:44 AM, Jesper Pedersen wrote: > > On 06/08/2016 10:39 AM, Scott Marlow wrote: > >> For those not reading [1], we also can support one of the predefined > >> write-concern constants via: > >> > >> > >> ... > >> > >> > > > > I would choose this approach, and support the predefined constants. > > > > Exposing MongoDB internal API details in the configuration seems to be > > overkill, and put extra effort on your part when they change the API. > > > > This is good input. If this ends up in WildFly or EAP, we have stringent > compatibility guarantees, so be cautious about exposing things in your API. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160609/f26a0494/attachment.html From jesper.pedersen at redhat.com Thu Jun 9 11:34:44 2016 From: jesper.pedersen at redhat.com (Jesper Pedersen) Date: Thu, 9 Jun 2016 11:34:44 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> Message-ID: <57598C94.8010601@redhat.com> Hi, On 06/09/2016 06:27 AM, Gunnar Morling wrote: > My concern with the current proposal and its usage of dedicated > elements/attributes for specific options such as write concern is that it > easily leads into a catch-up game with datastore vendors as they keep > adding new options. That might create a constant effort for maintaining > this subsystem. > Yes, that is def something to take into account, as there is no common functionality across all the stores. > How about having a more generic approach which only has typed elements for > common properties/settings such as user, password, database name and then > allows to set custom things as part of the connection URL: > > > > > nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... > > bob > secret > > > > > Here, the connection-url would be analyzed to load the right driver and > pass any configured settings to it. > The problem I see with that approach is that some stores doesn't have a URL concept, so that part will be foreign to those users. Also the parameters may need to be applied to various "levels" in the setup. It would be better to scope those as close to component in question, like we have the pooling configuration under in :datasources:. Parsing the URL w/ configuration could also lead to more configuration errors in general. > While compact, that URL syntax might be confused with existing URI schemes > of specific stores, so an alternative might be this (a bit more verbose, > though): > > > > mongodb > localhost:27017,otherhost:27017 > somedatabase > > bob > secret > > > ACKNOWLEDGED > MAJORITY > > > > Yes, I agree that this would be easier to support over time. And the element could be scoped under the NoSQL components that needs it. That is how works for :datasources:, as we can't change the subsystem configuration for each patch release of a JDBC driver. > Both alternatives don't address custom write concerns, but I think you > foresee CDI producer methods for more advanced customizations, so that > might be fine. That'd also be needed for some other non-primitive options > (dbDecoderFactory, codecRegistry etc.), unless you provide a way to > configure classes here and have them instantiated. > > These more generic approaches will make it more robust towards new options > being added, but of course you also loose type-safety and I suppose > usability in the console which might provide dedicated editors for real > types such as boolean etc. True, but I think that properties that needs a set- are likely important enough to expose directly in the configuration as an element/attribute. And that comes down to what each store supports - for JCA we just got a 'supportsDynamic' concept in JCA 1.6, but that doesn't necessarily translate to JDBC drivers and their DataSource deployments... Best regards, Jesper From smarlow at redhat.com Thu Jun 9 16:23:09 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 9 Jun 2016 16:23:09 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> Message-ID: <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> On 06/09/2016 06:27 AM, Gunnar Morling wrote: > Hi, > > My concern with the current proposal and its usage of dedicated > elements/attributes for specific options such as write concern is that > it easily leads into a catch-up game with datastore vendors as they keep > adding new options. That might create a constant effort for maintaining > this subsystem. > > How about having a more generic approach which only has typed elements > for common properties/settings such as user, password, database name and > then allows to set custom things as part of the connection URL: > > > > > nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... > > bob > secret > > > > > Here, the connection-url would be analyzed to load the right driver and > pass any configured settings to it. > > While compact, that URL syntax might be confused with existing URI > schemes of specific stores, so an alternative might be this (a bit more > verbose, though): > > > > mongodb > localhost:27017,otherhost:27017 We cannot include hostname + port numbers directly, instead we reference host names/port pairs defined in the outbound-socket-binding section of standalone.xml. > somedatabase > > bob > secret > > > ACKNOWLEDGED > MAJORITY > > > > +1 for the separate properties idea! > Both alternatives don't address custom write concerns, but I think you > foresee CDI producer methods for more advanced customizations, so that > might be fine. That'd also be needed for some other non-primitive > options (dbDecoderFactory, codecRegistry etc.), unless you provide a way > to configure classes here and have them instantiated. I'm still learning more about how to use advance customizations in the CDI producer but yes, we definitely want to do this, to simplify application program use of NoSQL. > > These more generic approaches will make it more robust towards new > options being added, but of course you also loose type-safety and I > suppose usability in the console which might provide dedicated editors > for real types such as boolean etc. I think that about summarizes the difference. Eventually, when the configuration options stabilize, it might be better to switch to dedicated editors, which would be a big one-off upgrade, I think. If we used dedicated editors now, we will have several big (NoSQL subsystem configuration) upgrades, as the NoSQL database options may change over time. Thanks, Scott > > --Gunnar > > > > > 2016-06-08 22:18 GMT+02:00 Brian Stansberry >: > > On 6/8/16 9:44 AM, Jesper Pedersen wrote: > > On 06/08/2016 10:39 AM, Scott Marlow wrote: > >> For those not reading [1], we also can support one of the predefined > >> write-concern constants via: > >> > >> > >> ... > >> > >> > > > > I would choose this approach, and support the predefined constants. > > > > Exposing MongoDB internal API details in the configuration seems to be > > overkill, and put extra effort on your part when they change the API. > > > > This is good input. If this ends up in WildFly or EAP, we have stringent > compatibility guarantees, so be cautious about exposing things in > your API. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From smarlow at redhat.com Thu Jun 9 16:29:34 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 9 Jun 2016 16:29:34 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <57598C94.8010601@redhat.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <57598C94.8010601@redhat.com> Message-ID: On 06/09/2016 11:34 AM, Jesper Pedersen wrote: > Hi, > > On 06/09/2016 06:27 AM, Gunnar Morling wrote: >> My concern with the current proposal and its usage of dedicated >> elements/attributes for specific options such as write concern is that it >> easily leads into a catch-up game with datastore vendors as they keep >> adding new options. That might create a constant effort for maintaining >> this subsystem. >> > > Yes, that is def something to take into account, as there is no common > functionality across all the stores. > >> How about having a more generic approach which only has typed elements >> for >> common properties/settings such as user, password, database name and then >> allows to set custom things as part of the connection URL: >> >> >> >> >> nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... >> >> >> bob >> secret >> >> >> >> >> Here, the connection-url would be analyzed to load the right driver and >> pass any configured settings to it. >> > > The problem I see with that approach is that some stores doesn't have a > URL concept, so that part will be foreign to those users. > > Also the parameters may need to be applied to various "levels" in the > setup. It would be better to scope those as close to component in > question, like we have the pooling configuration under in > :datasources:. > > Parsing the URL w/ configuration could also lead to more configuration > errors in general. > >> While compact, that URL syntax might be confused with existing URI >> schemes >> of specific stores, so an alternative might be this (a bit more verbose, >> though): >> >> >> >> mongodb >> localhost:27017,otherhost:27017 >> somedatabase >> >> bob >> secret >> >> >> ACKNOWLEDGED >> MAJORITY >> >> >> >> > > Yes, I agree that this would be easier to support over time. And the > element could be scoped under the NoSQL components that > needs it. +1, easier to support over time, helps us. > > That is how works for :datasources:, as we can't > change the subsystem configuration for each patch release of a JDBC driver. > >> Both alternatives don't address custom write concerns, but I think you >> foresee CDI producer methods for more advanced customizations, so that >> might be fine. That'd also be needed for some other non-primitive options >> (dbDecoderFactory, codecRegistry etc.), unless you provide a way to >> configure classes here and have them instantiated. >> >> These more generic approaches will make it more robust towards new >> options >> being added, but of course you also loose type-safety and I suppose >> usability in the console which might provide dedicated editors for real >> types such as boolean etc. > > True, but I think that properties that needs a set- are likely important > enough to expose directly in the configuration as an element/attribute. > > And that comes down to what each store supports - for JCA we just got a > 'supportsDynamic' concept in JCA 1.6, but that doesn't necessarily > translate to JDBC drivers and their DataSource deployments... > > Best regards, > Jesper > From gunnar at hibernate.org Fri Jun 10 01:46:20 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 10 Jun 2016 07:46:20 +0200 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> Message-ID: > We cannot include hostname + port numbers directly, instead we reference host names/port pairs defined in the outbound-socket-binding section of standalone.xml. Why is that? Some general principle in WF config? In OGM, we recently had the feature request to support a custom socket factory (see MongoClientOptions#setSocketFactory()); The user wanted to set a SSLSocketFactory configured with a custom trust store. Would that still be possible? 2016-06-09 22:23 GMT+02:00 Scott Marlow : > > > On 06/09/2016 06:27 AM, Gunnar Morling wrote: > >> Hi, >> >> My concern with the current proposal and its usage of dedicated >> elements/attributes for specific options such as write concern is that >> it easily leads into a catch-up game with datastore vendors as they keep >> adding new options. That might create a constant effort for maintaining >> this subsystem. >> >> How about having a more generic approach which only has typed elements >> for common properties/settings such as user, password, database name and >> then allows to set custom things as part of the connection URL: >> >> >> >> >> >> nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... >> >> bob >> secret >> >> >> >> >> Here, the connection-url would be analyzed to load the right driver and >> pass any configured settings to it. >> >> While compact, that URL syntax might be confused with existing URI >> schemes of specific stores, so an alternative might be this (a bit more >> verbose, though): >> >> >> >> mongodb >> localhost:27017,otherhost:27017 >> > > We cannot include hostname + port numbers directly, instead we reference > host names/port pairs defined in the outbound-socket-binding section of > standalone.xml. > > somedatabase >> >> bob >> secret >> >> >> ACKNOWLEDGED >> MAJORITY >> >> >> >> >> > +1 for the separate properties idea! > > Both alternatives don't address custom write concerns, but I think you >> foresee CDI producer methods for more advanced customizations, so that >> might be fine. That'd also be needed for some other non-primitive >> options (dbDecoderFactory, codecRegistry etc.), unless you provide a way >> to configure classes here and have them instantiated. >> > > I'm still learning more about how to use advance customizations in the CDI > producer but yes, we definitely want to do this, to simplify application > program use of NoSQL. > > >> These more generic approaches will make it more robust towards new >> options being added, but of course you also loose type-safety and I >> suppose usability in the console which might provide dedicated editors >> for real types such as boolean etc. >> > > I think that about summarizes the difference. Eventually, when the > configuration options stabilize, it might be better to switch to dedicated > editors, which would be a big one-off upgrade, I think. If we used > dedicated editors now, we will have several big (NoSQL subsystem > configuration) upgrades, as the NoSQL database options may change over time. > > Thanks, > Scott > > >> --Gunnar >> >> >> >> >> 2016-06-08 22:18 GMT+02:00 Brian Stansberry > >: >> >> On 6/8/16 9:44 AM, Jesper Pedersen wrote: >> > On 06/08/2016 10:39 AM, Scott Marlow wrote: >> >> For those not reading [1], we also can support one of the >> predefined >> >> write-concern constants via: >> >> >> >> >> >> ... >> >> >> >> >> > >> > I would choose this approach, and support the predefined constants. >> > >> > Exposing MongoDB internal API details in the configuration seems to >> be >> > overkill, and put extra effort on your part when they change the >> API. >> > >> >> This is good input. If this ends up in WildFly or EAP, we have >> stringent >> compatibility guarantees, so be cautious about exposing things in >> your API. >> >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/17a318d0/attachment.html From darran.lofthouse at jboss.com Fri Jun 10 05:46:01 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 10 Jun 2016 10:46:01 +0100 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> Message-ID: <15a4baff-2ec1-0fff-01ac-067d69d07bc1@jboss.com> Shortly we are going to be starting to transition subsystems to make use of Elytron defined capabilities so things like custom trust manager configuration should not need to live in individual subsystems any more: - https://developer.jboss.org/docs/DOC-53383 Regards, Darran Lofthouse. On 10/06/16 06:46, Gunnar Morling wrote: >> We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the outbound-socket-binding > section of standalone.xml. > > Why is that? Some general principle in WF config? > > In OGM, we recently had the feature request to support a custom socket > factory (see MongoClientOptions#setSocketFactory()); The user wanted to > set a SSLSocketFactory configured with a custom trust store. Would that > still be possible? > > > 2016-06-09 22:23 GMT+02:00 Scott Marlow >: > > > > On 06/09/2016 06:27 AM, Gunnar Morling wrote: > > Hi, > > My concern with the current proposal and its usage of dedicated > elements/attributes for specific options such as write concern > is that > it easily leads into a catch-up game with datastore vendors as > they keep > adding new options. That might create a constant effort for > maintaining > this subsystem. > > How about having a more generic approach which only has typed > elements > for common properties/settings such as user, password, database > name and > then allows to set custom things as part of the connection URL: > > > > > nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... > > bob > secret > > > > > Here, the connection-url would be analyzed to load the right > driver and > pass any configured settings to it. > > While compact, that URL syntax might be confused with existing URI > schemes of specific stores, so an alternative might be this (a > bit more > verbose, though): > > > > mongodb > localhost:27017,otherhost:27017 > > > We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the > outbound-socket-binding section of standalone.xml. > > somedatabase > > bob > secret > > > name="writeConcern">ACKNOWLEDGED > MAJORITY > > > > > > +1 for the separate properties idea! > > Both alternatives don't address custom write concerns, but I > think you > foresee CDI producer methods for more advanced customizations, > so that > might be fine. That'd also be needed for some other non-primitive > options (dbDecoderFactory, codecRegistry etc.), unless you > provide a way > to configure classes here and have them instantiated. > > > I'm still learning more about how to use advance customizations in > the CDI producer but yes, we definitely want to do this, to simplify > application program use of NoSQL. > > > These more generic approaches will make it more robust towards new > options being added, but of course you also loose type-safety and I > suppose usability in the console which might provide dedicated > editors > for real types such as boolean etc. > > > I think that about summarizes the difference. Eventually, when the > configuration options stabilize, it might be better to switch to > dedicated editors, which would be a big one-off upgrade, I think. > If we used dedicated editors now, we will have several big (NoSQL > subsystem configuration) upgrades, as the NoSQL database options may > change over time. > > Thanks, > Scott > > > --Gunnar > > > > > 2016-06-08 22:18 GMT+02:00 Brian Stansberry > > >>: > > On 6/8/16 9:44 AM, Jesper Pedersen wrote: > > On 06/08/2016 10:39 AM, Scott Marlow wrote: > >> For those not reading [1], we also can support one of the > predefined > >> write-concern constants via: > >> > >> > >> ... > >> > >> > > > > I would choose this approach, and support the predefined > constants. > > > > Exposing MongoDB internal API details in the configuration > seems to be > > overkill, and put extra effort on your part when they > change the API. > > > > This is good input. If this ends up in WildFly or EAP, we > have stringent > compatibility guarantees, so be cautious about exposing > things in > your API. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Fri Jun 10 09:38:26 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 08:38:26 -0500 Subject: [wildfly-dev] Managed exploded deployments Message-ID: Emmanuel Hugonnet has been working on a long requested feature to have WildFly support "managed exploded deployments." We have a requirements analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and I just wanted to point that out to the list so anyone interested can have a look, and comment on this thread or on the document. A managed deployment is one where the user provided content is copied by the server/host controller into its internal content repo and then thereafter that copy is what is used. I estimate that 99%+ of all zipped deployments in WildFly are managed. With an unmanaged deployment the user provides the server with the local FS path to the content and then the server directly uses that content. All exploded deployments are unmanaged, as we don't support managed yet. We propose to add 5 new operations to the deployment resource: explode (to convert and archive deployment to exploded) add-content update-content remove-content read-content There is one "nice-to-have" requirement listed on the doc where I'm increasingly thinking it needs to be a hard requirement, so thought on this are appreciated: "The explode operation can take an optional path parameter, the value of which is a path within the deployment that should be exploded. * The use case for this is scenarios like an exploded ear that contains an unexploded war, and then the user later wishes the war to be exploded. * This is much closer to a hard requirement if the nice-to-have requirement for recursively exploding is not supported. * This operation will fail if the content referred to by the path parameter is already exploded or is not a zip file. * This operation will fail if any content between the root of the deployment and the content referred to by the path parameter is an unexploded archive. * So, /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would fail if thewar.war hadn't previously been exploded." -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Fri Jun 10 10:22:49 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 10 Jun 2016 09:22:49 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: Message-ID: <575ACD39.5010204@redhat.com> On 06/10/2016 08:38 AM, Brian Stansberry wrote: > Emmanuel Hugonnet has been working on a long requested feature to have > WildFly support "managed exploded deployments." We have a requirements > analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and > I just wanted to point that out to the list so anyone interested can > have a look, and comment on this thread or on the document. > > A managed deployment is one where the user provided content is copied by > the server/host controller into its internal content repo and then > thereafter that copy is what is used. I estimate that 99%+ of all zipped > deployments in WildFly are managed. With an unmanaged deployment the > user provides the server with the local FS path to the content and then > the server directly uses that content. All exploded deployments are > unmanaged, as we don't support managed yet. > > We propose to add 5 new operations to the deployment resource: > > explode (to convert and archive deployment to exploded) Hmmm. Is deployment explosion really an deployer concern, or is it a deployment provider concern? Consider: * The deployment provider is the one who will know whether or not his/her deployment will function correctly with or without exploding. * The deployment will have been tested in the desired configuration (exploded or unexploded). * Making this a deployer/administrator concern means that he/she must ensure that the extra step(s) taken in development and testing are also replicated in production. Wouldn't it make more sense to have some deployment control metadata (maybe even just a MANIFEST header) that says whether the particular archive should be exploded? Also, I don't think it's clear that you always want to explode the outer archive if an inner archive is to be exploded (I'm not sure that's necessarily implied by the proposed design, but it certainly would be in the recursive case). In particular it's definitely useful to explode WARs inside of EARs that need not be exploded. Explode!! (eom) > add-content > update-content > remove-content > read-content > > There is one "nice-to-have" requirement listed on the doc where I'm > increasingly thinking it needs to be a hard requirement, so thought on > this are appreciated: > > > "The explode operation can take an optional path parameter, the value of > which is a path within the deployment that should be exploded. > * The use case for this is scenarios like an exploded ear that > contains an unexploded war, and then the user later wishes the war to be > exploded. > * This is much closer to a hard requirement if the nice-to-have > requirement for recursively exploding is not supported. > * This operation will fail if the content referred to by the path > parameter is already exploded or is not a zip file. > * This operation will fail if any content between the root of the > deployment and the content referred to by the path parameter is an > unexploded archive. > * So, > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) > would fail if thewar.war hadn't previously been exploded." > -- - DML From ehugonne at redhat.com Fri Jun 10 10:24:17 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 10 Jun 2016 16:24:17 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: Message-ID: <575ACD91.5020302@redhat.com> Some details on the current implementation : * the add-content will overwrite existing content so there is no update-content updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those in sync for no real value from my point of view. * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete each change. * you can start from an 'empty' deployment and add contents to it step by step Emmanuel On 10/06/2016 15:38, Brian Stansberry wrote: > Emmanuel Hugonnet has been working on a long requested feature to have > WildFly support "managed exploded deployments." We have a requirements > analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and > I just wanted to point that out to the list so anyone interested can > have a look, and comment on this thread or on the document. > > A managed deployment is one where the user provided content is copied by > the server/host controller into its internal content repo and then > thereafter that copy is what is used. I estimate that 99%+ of all zipped > deployments in WildFly are managed. With an unmanaged deployment the > user provides the server with the local FS path to the content and then > the server directly uses that content. All exploded deployments are > unmanaged, as we don't support managed yet. > > We propose to add 5 new operations to the deployment resource: > > explode (to convert and archive deployment to exploded) > add-content > update-content > remove-content > read-content > > There is one "nice-to-have" requirement listed on the doc where I'm > increasingly thinking it needs to be a hard requirement, so thought on > this are appreciated: > > > "The explode operation can take an optional path parameter, the value of > which is a path within the deployment that should be exploded. > * The use case for this is scenarios like an exploded ear that > contains an unexploded war, and then the user later wishes the war to be > exploded. > * This is much closer to a hard requirement if the nice-to-have > requirement for recursively exploding is not supported. > * This operation will fail if the content referred to by the path > parameter is already exploded or is not a zip file. > * This operation will fail if any content between the root of the > deployment and the content referred to by the path parameter is an > unexploded archive. > * So, > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) > would fail if thewar.war hadn't previously been exploded." > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/b1eef45c/attachment.bin From ehugonne at redhat.com Fri Jun 10 10:39:38 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 10 Jun 2016 16:39:38 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ACD39.5010204@redhat.com> References: <575ACD39.5010204@redhat.com> Message-ID: <575AD12A.80706@redhat.com> On 10/06/2016 16:22, David M. Lloyd wrote: > On 06/10/2016 08:38 AM, Brian Stansberry wrote: >> Emmanuel Hugonnet has been working on a long requested feature to have >> WildFly support "managed exploded deployments." We have a requirements >> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >> I just wanted to point that out to the list so anyone interested can >> have a look, and comment on this thread or on the document. >> >> A managed deployment is one where the user provided content is copied by >> the server/host controller into its internal content repo and then >> thereafter that copy is what is used. I estimate that 99%+ of all zipped >> deployments in WildFly are managed. With an unmanaged deployment the >> user provides the server with the local FS path to the content and then >> the server directly uses that content. All exploded deployments are >> unmanaged, as we don't support managed yet. >> >> We propose to add 5 new operations to the deployment resource: >> >> explode (to convert and archive deployment to exploded) > > Hmmm. > > Is deployment explosion really an deployer concern, or is it a > deployment provider concern? Consider: > > * The deployment provider is the one who will know whether or not > his/her deployment will function correctly with or without exploding. > * The deployment will have been tested in the desired configuration > (exploded or unexploded). > * Making this a deployer/administrator concern means that he/she must > ensure that the extra step(s) taken in development and testing are also > replicated in production. > > Wouldn't it make more sense to have some deployment control metadata > (maybe even just a MANIFEST header) that says whether the particular > archive should be exploded? > > Also, I don't think it's clear that you always want to explode the outer > archive if an inner archive is to be exploded (I'm not sure that's > necessarily implied by the proposed design, but it certainly would be in > the recursive case). In particular it's definitely useful to explode > WARs inside of EARs that need not be exploded. > > Explode!! > > (eom) I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a development environment. so this mecanism is transparent from the developer point of vuiew. You have the same functionalities as with the scanner with hopefully a better control over the deployment management. Also this means you can develop on a remote server or even on a domain without having to rebuild the whole archive everytime. Emmanuel > >> add-content >> update-content >> remove-content >> read-content >> >> There is one "nice-to-have" requirement listed on the doc where I'm >> increasingly thinking it needs to be a hard requirement, so thought on >> this are appreciated: >> >> >> "The explode operation can take an optional path parameter, the value of >> which is a path within the deployment that should be exploded. >> * The use case for this is scenarios like an exploded ear that >> contains an unexploded war, and then the user later wishes the war to be >> exploded. >> * This is much closer to a hard requirement if the nice-to-have >> requirement for recursively exploding is not supported. >> * This operation will fail if the content referred to by the path >> parameter is already exploded or is not a zip file. >> * This operation will fail if any content between the root of the >> deployment and the content referred to by the path parameter is an >> unexploded archive. >> * So, >> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >> would fail if thewar.war hadn't previously been exploded." >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e9d59a8a/attachment.bin From smarlow at redhat.com Fri Jun 10 10:56:41 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 10 Jun 2016 10:56:41 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> Message-ID: <5d08806a-86c6-fdb9-1ffd-6f1a7027540b@redhat.com> On 06/10/2016 01:46 AM, Gunnar Morling wrote: >> We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the outbound-socket-binding > section of standalone.xml. > > Why is that? Some general principle in WF config? Yes, users define the host/port pairs as a group. An example Ne04J subsystem config using "neo4jtesthost" to separately define the host/port, might be: ... We are using this everywhere but datasources, which still include host/port (I assume for backward compatibility reasons). > > In OGM, we recently had the feature request to support a custom socket > factory (see MongoClientOptions#setSocketFactory()); The user wanted to > set a SSLSocketFactory configured with a custom trust store. Would that > still be possible? > > > 2016-06-09 22:23 GMT+02:00 Scott Marlow >: > > > > On 06/09/2016 06:27 AM, Gunnar Morling wrote: > > Hi, > > My concern with the current proposal and its usage of dedicated > elements/attributes for specific options such as write concern > is that > it easily leads into a catch-up game with datastore vendors as > they keep > adding new options. That might create a constant effort for > maintaining > this subsystem. > > How about having a more generic approach which only has typed > elements > for common properties/settings such as user, password, database > name and > then allows to set custom things as part of the connection URL: > > > > > nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... > > bob > secret > > > > > Here, the connection-url would be analyzed to load the right > driver and > pass any configured settings to it. > > While compact, that URL syntax might be confused with existing URI > schemes of specific stores, so an alternative might be this (a > bit more > verbose, though): > > > > mongodb > localhost:27017,otherhost:27017 > > > We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the > outbound-socket-binding section of standalone.xml. > > somedatabase > > bob > secret > > > name="writeConcern">ACKNOWLEDGED > MAJORITY > > > > > > +1 for the separate properties idea! > > Both alternatives don't address custom write concerns, but I > think you > foresee CDI producer methods for more advanced customizations, > so that > might be fine. That'd also be needed for some other non-primitive > options (dbDecoderFactory, codecRegistry etc.), unless you > provide a way > to configure classes here and have them instantiated. > > > I'm still learning more about how to use advance customizations in > the CDI producer but yes, we definitely want to do this, to simplify > application program use of NoSQL. > > > These more generic approaches will make it more robust towards new > options being added, but of course you also loose type-safety and I > suppose usability in the console which might provide dedicated > editors > for real types such as boolean etc. > > > I think that about summarizes the difference. Eventually, when the > configuration options stabilize, it might be better to switch to > dedicated editors, which would be a big one-off upgrade, I think. > If we used dedicated editors now, we will have several big (NoSQL > subsystem configuration) upgrades, as the NoSQL database options may > change over time. > > Thanks, > Scott > > > --Gunnar > > > > > 2016-06-08 22:18 GMT+02:00 Brian Stansberry > > >>: > > On 6/8/16 9:44 AM, Jesper Pedersen wrote: > > On 06/08/2016 10:39 AM, Scott Marlow wrote: > >> For those not reading [1], we also can support one of the > predefined > >> write-concern constants via: > >> > >> > >> ... > >> > >> > > > > I would choose this approach, and support the predefined > constants. > > > > Exposing MongoDB internal API details in the configuration > seems to be > > overkill, and put extra effort on your part when they > change the API. > > > > This is good input. If this ends up in WildFly or EAP, we > have stringent > compatibility guarantees, so be cautious about exposing > things in > your API. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From brian.stansberry at redhat.com Fri Jun 10 11:00:18 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 10:00:18 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ACD91.5020302@redhat.com> References: <575ACD91.5020302@redhat.com> Message-ID: So in terms of the requirements analysis: On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote: > Some details on the current implementation : > * the add-content will overwrite existing content so there is no update-content > updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those > in sync for no real value from my point of view. If there is no objection to this, then the requirement should be altered. > * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete > each change. This I think is a nice-to-have requirement. (And yes, I know it already exists, but if we by some strange chance find horrible problems then it can be dropped.) > * you can start from an 'empty' deployment and add contents to it step by step Yep. This one is in the hard requirements. > > Emmanuel > > > On 10/06/2016 15:38, Brian Stansberry wrote: >> Emmanuel Hugonnet has been working on a long requested feature to have >> WildFly support "managed exploded deployments." We have a requirements >> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >> I just wanted to point that out to the list so anyone interested can >> have a look, and comment on this thread or on the document. >> >> A managed deployment is one where the user provided content is copied by >> the server/host controller into its internal content repo and then >> thereafter that copy is what is used. I estimate that 99%+ of all zipped >> deployments in WildFly are managed. With an unmanaged deployment the >> user provides the server with the local FS path to the content and then >> the server directly uses that content. All exploded deployments are >> unmanaged, as we don't support managed yet. >> >> We propose to add 5 new operations to the deployment resource: >> >> explode (to convert and archive deployment to exploded) >> add-content >> update-content >> remove-content >> read-content >> >> There is one "nice-to-have" requirement listed on the doc where I'm >> increasingly thinking it needs to be a hard requirement, so thought on >> this are appreciated: >> >> >> "The explode operation can take an optional path parameter, the value of >> which is a path within the deployment that should be exploded. >> * The use case for this is scenarios like an exploded ear that >> contains an unexploded war, and then the user later wishes the war to be >> exploded. >> * This is much closer to a hard requirement if the nice-to-have >> requirement for recursively exploding is not supported. >> * This operation will fail if the content referred to by the path >> parameter is already exploded or is not a zip file. >> * This operation will fail if any content between the root of the >> deployment and the content referred to by the path parameter is an >> unexploded archive. >> * So, >> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >> would fail if thewar.war hadn't previously been exploded." >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Fri Jun 10 11:06:21 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 10:06:21 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575AD12A.80706@redhat.com> References: <575ACD39.5010204@redhat.com> <575AD12A.80706@redhat.com> Message-ID: On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote: > > > On 10/06/2016 16:22, David M. Lloyd wrote: >> On 06/10/2016 08:38 AM, Brian Stansberry wrote: >>> Emmanuel Hugonnet has been working on a long requested feature to have >>> WildFly support "managed exploded deployments." We have a requirements >>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>> I just wanted to point that out to the list so anyone interested can >>> have a look, and comment on this thread or on the document. >>> >>> A managed deployment is one where the user provided content is copied by >>> the server/host controller into its internal content repo and then >>> thereafter that copy is what is used. I estimate that 99%+ of all zipped >>> deployments in WildFly are managed. With an unmanaged deployment the >>> user provides the server with the local FS path to the content and then >>> the server directly uses that content. All exploded deployments are >>> unmanaged, as we don't support managed yet. >>> >>> We propose to add 5 new operations to the deployment resource: >>> >>> explode (to convert and archive deployment to exploded) >> >> Hmmm. >> >> Is deployment explosion really an deployer concern, or is it a >> deployment provider concern? Consider: >> >> * The deployment provider is the one who will know whether or not >> his/her deployment will function correctly with or without exploding. >> * The deployment will have been tested in the desired configuration >> (exploded or unexploded). >> * Making this a deployer/administrator concern means that he/she must >> ensure that the extra step(s) taken in development and testing are also >> replicated in production. >> >> Wouldn't it make more sense to have some deployment control metadata >> (maybe even just a MANIFEST header) that says whether the particular >> archive should be exploded? >> >> Also, I don't think it's clear that you always want to explode the outer >> archive if an inner archive is to be exploded (I'm not sure that's >> necessarily implied by the proposed design, but it certainly would be in >> the recursive case). In particular it's definitely useful to explode >> WARs inside of EARs that need not be exploded. >> >> Explode!! >> >> (eom) > > I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a development environment. so this mecanism is > transparent from the developer point of vuiew. > You have the same functionalities as with the scanner with hopefully a better control over the deployment management. > Also this means you can develop on a remote server or even on a domain without having to rebuild the whole archive everytime. > So would you use the 'explode' operation in your netbeans plugin, i.e. start archived and explode? I'm curious if the JBDS guys will. I suspect it would be used as a convenience; i.e. instead of the tool initially uploading 100 files, it uploads a zip and explodes it. And then either way it begins to manipulate the few files that the tool regards as eligible for update without redeploy (.html, .css, etc.) > Emmanuel > >> >>> add-content >>> update-content >>> remove-content >>> read-content >>> >>> There is one "nice-to-have" requirement listed on the doc where I'm >>> increasingly thinking it needs to be a hard requirement, so thought on >>> this are appreciated: >>> >>> >>> "The explode operation can take an optional path parameter, the value of >>> which is a path within the deployment that should be exploded. >>> * The use case for this is scenarios like an exploded ear that >>> contains an unexploded war, and then the user later wishes the war to be >>> exploded. >>> * This is much closer to a hard requirement if the nice-to-have >>> requirement for recursively exploding is not supported. >>> * This operation will fail if the content referred to by the path >>> parameter is already exploded or is not a zip file. >>> * This operation will fail if any content between the root of the >>> deployment and the content referred to by the path parameter is an >>> unexploded archive. >>> * So, >>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >>> would fail if thewar.war hadn't previously been exploded." >>> >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From smarlow at redhat.com Fri Jun 10 11:06:28 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 10 Jun 2016 11:06:28 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> Message-ID: <7af2e9c0-9743-c7af-ef0e-ef9a682f764c@redhat.com> On 06/10/2016 01:46 AM, Gunnar Morling wrote: >> We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the outbound-socket-binding > section of standalone.xml. > > Why is that? Some general principle in WF config? > > In OGM, we recently had the feature request to support a custom socket > factory (see MongoClientOptions#setSocketFactory()); The user wanted to > set a SSLSocketFactory configured with a custom trust store. Would that > still be possible? I'm not sure yet, that should be independent of the hostname/port#, being in a separate part of the WildFly configuration file. > > > 2016-06-09 22:23 GMT+02:00 Scott Marlow >: > > > > On 06/09/2016 06:27 AM, Gunnar Morling wrote: > > Hi, > > My concern with the current proposal and its usage of dedicated > elements/attributes for specific options such as write concern > is that > it easily leads into a catch-up game with datastore vendors as > they keep > adding new options. That might create a constant effort for > maintaining > this subsystem. > > How about having a more generic approach which only has typed > elements > for common properties/settings such as user, password, database > name and > then allows to set custom things as part of the connection URL: > > > > > nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... > > bob > secret > > > > > Here, the connection-url would be analyzed to load the right > driver and > pass any configured settings to it. > > While compact, that URL syntax might be confused with existing URI > schemes of specific stores, so an alternative might be this (a > bit more > verbose, though): > > > > mongodb > localhost:27017,otherhost:27017 > > > We cannot include hostname + port numbers directly, instead we > reference host names/port pairs defined in the > outbound-socket-binding section of standalone.xml. > > somedatabase > > bob > secret > > > name="writeConcern">ACKNOWLEDGED > MAJORITY > > > > > > +1 for the separate properties idea! > > Both alternatives don't address custom write concerns, but I > think you > foresee CDI producer methods for more advanced customizations, > so that > might be fine. That'd also be needed for some other non-primitive > options (dbDecoderFactory, codecRegistry etc.), unless you > provide a way > to configure classes here and have them instantiated. > > > I'm still learning more about how to use advance customizations in > the CDI producer but yes, we definitely want to do this, to simplify > application program use of NoSQL. > > > These more generic approaches will make it more robust towards new > options being added, but of course you also loose type-safety and I > suppose usability in the console which might provide dedicated > editors > for real types such as boolean etc. > > > I think that about summarizes the difference. Eventually, when the > configuration options stabilize, it might be better to switch to > dedicated editors, which would be a big one-off upgrade, I think. > If we used dedicated editors now, we will have several big (NoSQL > subsystem configuration) upgrades, as the NoSQL database options may > change over time. > > Thanks, > Scott > > > --Gunnar > > > > > 2016-06-08 22:18 GMT+02:00 Brian Stansberry > > >>: > > On 6/8/16 9:44 AM, Jesper Pedersen wrote: > > On 06/08/2016 10:39 AM, Scott Marlow wrote: > >> For those not reading [1], we also can support one of the > predefined > >> write-concern constants via: > >> > >> > >> ... > >> > >> > > > > I would choose this approach, and support the predefined > constants. > > > > Exposing MongoDB internal API details in the configuration > seems to be > > overkill, and put extra effort on your part when they > change the API. > > > > This is good input. If this ends up in WildFly or EAP, we > have stringent > compatibility guarantees, so be cautious about exposing > things in > your API. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From smarlow at redhat.com Fri Jun 10 11:07:17 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 10 Jun 2016 11:07:17 -0400 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: <15a4baff-2ec1-0fff-01ac-067d69d07bc1@jboss.com> References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> <15a4baff-2ec1-0fff-01ac-067d69d07bc1@jboss.com> Message-ID: Darran, We didn't yet try to configure NoSQL authentication, should we try that after switching WildFly to Elytron, or before? We definitely want to support authentication. Perhaps we should consider requiring authentication by default and let developers disable it, as there are many unsecured NoSQL databases out there. Thanks, Scott On 06/10/2016 05:46 AM, Darran Lofthouse wrote: > Shortly we are going to be starting to transition subsystems to make use > of Elytron defined capabilities so things like custom trust manager > configuration should not need to live in individual subsystems any more: - > > https://developer.jboss.org/docs/DOC-53383 > > Regards, > Darran Lofthouse. > > > On 10/06/16 06:46, Gunnar Morling wrote: >>> We cannot include hostname + port numbers directly, instead we >> reference host names/port pairs defined in the outbound-socket-binding >> section of standalone.xml. >> >> Why is that? Some general principle in WF config? >> >> In OGM, we recently had the feature request to support a custom socket >> factory (see MongoClientOptions#setSocketFactory()); The user wanted to >> set a SSLSocketFactory configured with a custom trust store. Would that >> still be possible? >> >> >> 2016-06-09 22:23 GMT+02:00 Scott Marlow > >: >> >> >> >> On 06/09/2016 06:27 AM, Gunnar Morling wrote: >> >> Hi, >> >> My concern with the current proposal and its usage of dedicated >> elements/attributes for specific options such as write concern >> is that >> it easily leads into a catch-up game with datastore vendors as >> they keep >> adding new options. That might create a constant effort for >> maintaining >> this subsystem. >> >> How about having a more generic approach which only has typed >> elements >> for common properties/settings such as user, password, database >> name and >> then allows to set custom things as part of the connection URL: >> >> >> >> >> nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... >> >> bob >> secret >> >> >> >> >> Here, the connection-url would be analyzed to load the right >> driver and >> pass any configured settings to it. >> >> While compact, that URL syntax might be confused with existing URI >> schemes of specific stores, so an alternative might be this (a >> bit more >> verbose, though): >> >> >> >> mongodb >> localhost:27017,otherhost:27017 >> >> >> We cannot include hostname + port numbers directly, instead we >> reference host names/port pairs defined in the >> outbound-socket-binding section of standalone.xml. >> >> somedatabase >> >> bob >> secret >> >> >> > name="writeConcern">ACKNOWLEDGED >> MAJORITY >> >> >> >> >> >> +1 for the separate properties idea! >> >> Both alternatives don't address custom write concerns, but I >> think you >> foresee CDI producer methods for more advanced customizations, >> so that >> might be fine. That'd also be needed for some other non-primitive >> options (dbDecoderFactory, codecRegistry etc.), unless you >> provide a way >> to configure classes here and have them instantiated. >> >> >> I'm still learning more about how to use advance customizations in >> the CDI producer but yes, we definitely want to do this, to simplify >> application program use of NoSQL. >> >> >> These more generic approaches will make it more robust towards new >> options being added, but of course you also loose type-safety and I >> suppose usability in the console which might provide dedicated >> editors >> for real types such as boolean etc. >> >> >> I think that about summarizes the difference. Eventually, when the >> configuration options stabilize, it might be better to switch to >> dedicated editors, which would be a big one-off upgrade, I think. >> If we used dedicated editors now, we will have several big (NoSQL >> subsystem configuration) upgrades, as the NoSQL database options may >> change over time. >> >> Thanks, >> Scott >> >> >> --Gunnar >> >> >> >> >> 2016-06-08 22:18 GMT+02:00 Brian Stansberry >> >> > >>: >> >> On 6/8/16 9:44 AM, Jesper Pedersen wrote: >> > On 06/08/2016 10:39 AM, Scott Marlow wrote: >> >> For those not reading [1], we also can support one of the >> predefined >> >> write-concern constants via: >> >> >> >> >> >> ... >> >> >> >> >> > >> > I would choose this approach, and support the predefined >> constants. >> > >> > Exposing MongoDB internal API details in the configuration >> seems to be >> > overkill, and put extra effort on your part when they >> change the API. >> > >> >> This is good input. If this ends up in WildFly or EAP, we >> have stringent >> compatibility guarantees, so be cautious about exposing >> things in >> your API. >> >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> >> > > >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> >> > > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Fri Jun 10 11:16:27 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 10:16:27 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ACD39.5010204@redhat.com> References: <575ACD39.5010204@redhat.com> Message-ID: <392e197f-7b9d-4604-7198-c5f718282926@redhat.com> On 6/10/16 9:22 AM, David M. Lloyd wrote: > On 06/10/2016 08:38 AM, Brian Stansberry wrote: >> Emmanuel Hugonnet has been working on a long requested feature to have >> WildFly support "managed exploded deployments." We have a requirements >> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >> I just wanted to point that out to the list so anyone interested can >> have a look, and comment on this thread or on the document. >> >> A managed deployment is one where the user provided content is copied by >> the server/host controller into its internal content repo and then >> thereafter that copy is what is used. I estimate that 99%+ of all zipped >> deployments in WildFly are managed. With an unmanaged deployment the >> user provides the server with the local FS path to the content and then >> the server directly uses that content. All exploded deployments are >> unmanaged, as we don't support managed yet. >> >> We propose to add 5 new operations to the deployment resource: >> >> explode (to convert and archive deployment to exploded) > > Hmmm. > > Is deployment explosion really an deployer concern, or is it a > deployment provider concern? Consider: > > * The deployment provider is the one who will know whether or not > his/her deployment will function correctly with or without exploding. > * The deployment will have been tested in the desired configuration > (exploded or unexploded). > * Making this a deployer/administrator concern means that he/she must > ensure that the extra step(s) taken in development and testing are also > replicated in production. > The admin already has this capability; they can just convert a zip to unmanaged exploded and redeploy. Granted, this op makes it easier to do and bypasses limitations that currently exist like the need for said admin to write to the local FS. > Wouldn't it make more sense to have some deployment control metadata > (maybe even just a MANIFEST header) that says whether the particular > archive should be exploded? > This one gives me a not so nice feeling, as now we are taking things typically done by DUPs (analyzing deployment structure, extracting files, parsing) and doing it in a different area. > Also, I don't think it's clear that you always want to explode the outer > archive if an inner archive is to be exploded (I'm not sure that's > necessarily implied by the proposed design, but it certainly would be in > the recursive case). In particular it's definitely useful to explode > WARs inside of EARs that need not be exploded. > There's a lot of complexity that comes from allowing the parent to be an archive and the child exploded. And I don't see a huge benefit. How much unzipped child content do ears have? Mostly a few deployments descriptors and a manifest. I certainly see a benefit though in having the parent and 1 child exploded while all other children remain as zips. > Explode!! > > (eom) > >> add-content >> update-content >> remove-content >> read-content >> >> There is one "nice-to-have" requirement listed on the doc where I'm >> increasingly thinking it needs to be a hard requirement, so thought on >> this are appreciated: >> >> >> "The explode operation can take an optional path parameter, the value of >> which is a path within the deployment that should be exploded. >> * The use case for this is scenarios like an exploded ear that >> contains an unexploded war, and then the user later wishes the war to be >> exploded. >> * This is much closer to a hard requirement if the nice-to-have >> requirement for recursively exploding is not supported. >> * This operation will fail if the content referred to by the path >> parameter is already exploded or is not a zip file. >> * This operation will fail if any content between the root of the >> deployment and the content referred to by the path parameter is an >> unexploded archive. >> * So, >> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >> would fail if thewar.war hadn't previously been exploded." >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Fri Jun 10 11:18:22 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 10 Jun 2016 17:18:22 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: <575ACD39.5010204@redhat.com> <575AD12A.80706@redhat.com> Message-ID: <575ADA3E.1010808@redhat.com> On 10/06/2016 17:06, Brian Stansberry wrote: > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote: >> >> >> On 10/06/2016 16:22, David M. Lloyd wrote: >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote: >>>> Emmanuel Hugonnet has been working on a long requested feature to have >>>> WildFly support "managed exploded deployments." We have a requirements >>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>>> I just wanted to point that out to the list so anyone interested can >>>> have a look, and comment on this thread or on the document. >>>> >>>> A managed deployment is one where the user provided content is copied by >>>> the server/host controller into its internal content repo and then >>>> thereafter that copy is what is used. I estimate that 99%+ of all zipped >>>> deployments in WildFly are managed. With an unmanaged deployment the >>>> user provides the server with the local FS path to the content and then >>>> the server directly uses that content. All exploded deployments are >>>> unmanaged, as we don't support managed yet. >>>> >>>> We propose to add 5 new operations to the deployment resource: >>>> >>>> explode (to convert and archive deployment to exploded) >>> >>> Hmmm. >>> >>> Is deployment explosion really an deployer concern, or is it a >>> deployment provider concern? Consider: >>> >>> * The deployment provider is the one who will know whether or not >>> his/her deployment will function correctly with or without exploding. >>> * The deployment will have been tested in the desired configuration >>> (exploded or unexploded). >>> * Making this a deployer/administrator concern means that he/she must >>> ensure that the extra step(s) taken in development and testing are also >>> replicated in production. >>> >>> Wouldn't it make more sense to have some deployment control metadata >>> (maybe even just a MANIFEST header) that says whether the particular >>> archive should be exploded? >>> >>> Also, I don't think it's clear that you always want to explode the outer >>> archive if an inner archive is to be exploded (I'm not sure that's >>> necessarily implied by the proposed design, but it certainly would be in >>> the recursive case). In particular it's definitely useful to explode >>> WARs inside of EARs that need not be exploded. >>> >>> Explode!! >>> >>> (eom) >> >> I think the main target for explosion scenarios are tools (IDE, build tools, etc.) in a development environment. so this mecanism is >> transparent from the developer point of vuiew. >> You have the same functionalities as with the scanner with hopefully a better control over the deployment management. >> Also this means you can develop on a remote server or even on a domain without having to rebuild the whole archive everytime. >> > > So would you use the 'explode' operation in your netbeans plugin, i.e. > start archived and explode? I'm curious if the JBDS guys will. Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that the 'build' (since the build process it externalized in Netbeans) will no longer produce an archive but a list of changes. So I might need to explode the deployment somewhere in time. > > I suspect it would be used as a convenience; i.e. instead of the tool > initially uploading 100 files, it uploads a zip and explodes it. And > then either way it begins to manipulate the few files that the tool > regards as eligible for update without redeploy (.html, .css, etc.) That's also a use case (depending on producing an archive in the first place). Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/71e86e50/attachment.bin From jperkins at redhat.com Fri Jun 10 17:20:37 2016 From: jperkins at redhat.com (James Perkins) Date: Fri, 10 Jun 2016 14:20:37 -0700 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ACD91.5020302@redhat.com> References: <575ACD91.5020302@redhat.com> Message-ID: On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet wrote: > Some details on the current implementation : > * the add-content will overwrite existing content so there is no > update-content > updating instead of just adding means having the state on the client as > well as on the server which would require more checks to keep those > in sync for no real value from my point of view. > I think there should be a force attribute, or something along those lines, that can be changed to indicate an add shouldn't override. It can default to false, but there are probably scenarios where you would want an add to fail of the content already exists. > * the add-content/remove-content work with a list of contents thus for an > IDE we don't have to create a bunch of ops to upload or delete > each change. > * you can start from an 'empty' deployment and add contents to it step by > step > > Emmanuel > > > On 10/06/2016 15:38, Brian Stansberry wrote: > > Emmanuel Hugonnet has been working on a long requested feature to have > > WildFly support "managed exploded deployments." We have a requirements > > analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and > > I just wanted to point that out to the list so anyone interested can > > have a look, and comment on this thread or on the document. > > > > A managed deployment is one where the user provided content is copied by > > the server/host controller into its internal content repo and then > > thereafter that copy is what is used. I estimate that 99%+ of all zipped > > deployments in WildFly are managed. With an unmanaged deployment the > > user provides the server with the local FS path to the content and then > > the server directly uses that content. All exploded deployments are > > unmanaged, as we don't support managed yet. > > > > We propose to add 5 new operations to the deployment resource: > > > > explode (to convert and archive deployment to exploded) > > add-content > > update-content > > remove-content > > read-content > > > > There is one "nice-to-have" requirement listed on the doc where I'm > > increasingly thinking it needs to be a hard requirement, so thought on > > this are appreciated: > > > > > > "The explode operation can take an optional path parameter, the value of > > which is a path within the deployment that should be exploded. > > * The use case for this is scenarios like an exploded ear that > > contains an unexploded war, and then the user later wishes the war to be > > exploded. > > * This is much closer to a hard requirement if the nice-to-have > > requirement for recursively exploding is not supported. > > * This operation will fail if the content referred to by the path > > parameter is already exploded or is not a zip file. > > * This operation will fail if any content between the root of the > > deployment and the content referred to by the path parameter is an > > unexploded archive. > > * So, > > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) > > would fail if thewar.war hadn't previously been exploded." > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/ddc20c51/attachment.html From jperkins at redhat.com Fri Jun 10 17:27:25 2016 From: jperkins at redhat.com (James Perkins) Date: Fri, 10 Jun 2016 14:27:25 -0700 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ADA3E.1010808@redhat.com> References: <575ACD39.5010204@redhat.com> <575AD12A.80706@redhat.com> <575ADA3E.1010808@redhat.com> Message-ID: On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet wrote: > > > On 10/06/2016 17:06, Brian Stansberry wrote: > > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote: > >> > >> > >> On 10/06/2016 16:22, David M. Lloyd wrote: > >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote: > >>>> Emmanuel Hugonnet has been working on a long requested feature to have > >>>> WildFly support "managed exploded deployments." We have a requirements > >>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 > and > >>>> I just wanted to point that out to the list so anyone interested can > >>>> have a look, and comment on this thread or on the document. > >>>> > >>>> A managed deployment is one where the user provided content is copied > by > >>>> the server/host controller into its internal content repo and then > >>>> thereafter that copy is what is used. I estimate that 99%+ of all > zipped > >>>> deployments in WildFly are managed. With an unmanaged deployment the > >>>> user provides the server with the local FS path to the content and > then > >>>> the server directly uses that content. All exploded deployments are > >>>> unmanaged, as we don't support managed yet. > >>>> > >>>> We propose to add 5 new operations to the deployment resource: > >>>> > >>>> explode (to convert and archive deployment to exploded) > >>> > >>> Hmmm. > >>> > >>> Is deployment explosion really an deployer concern, or is it a > >>> deployment provider concern? Consider: > >>> > >>> * The deployment provider is the one who will know whether or not > >>> his/her deployment will function correctly with or without exploding. > >>> * The deployment will have been tested in the desired configuration > >>> (exploded or unexploded). > >>> * Making this a deployer/administrator concern means that he/she must > >>> ensure that the extra step(s) taken in development and testing are also > >>> replicated in production. > >>> > >>> Wouldn't it make more sense to have some deployment control metadata > >>> (maybe even just a MANIFEST header) that says whether the particular > >>> archive should be exploded? > >>> > >>> Also, I don't think it's clear that you always want to explode the > outer > >>> archive if an inner archive is to be exploded (I'm not sure that's > >>> necessarily implied by the proposed design, but it certainly would be > in > >>> the recursive case). In particular it's definitely useful to explode > >>> WARs inside of EARs that need not be exploded. > >>> > >>> Explode!! > >>> > >>> (eom) > >> > >> I think the main target for explosion scenarios are tools (IDE, build > tools, etc.) in a development environment. so this mecanism is > >> transparent from the developer point of vuiew. > >> You have the same functionalities as with the scanner with hopefully a > better control over the deployment management. > >> Also this means you can develop on a remote server or even on a domain > without having to rebuild the whole archive everytime. > >> > > > > So would you use the 'explode' operation in your netbeans plugin, i.e. > > start archived and explode? I'm curious if the JBDS guys will. > > Well it depends. On NetBeans you have a "Deploy on Save" checkbox so that > the 'build' (since the build process it externalized in Netbeans) > will no longer produce an archive but a list of changes. > So I might need to explode the deployment somewhere in time. > I could see this being useful in a scenario where a user launches WildFly in something like Docker but they want to see changes on static content without a full redeploy. If it's all local then it's already possible to do this using an unmanaged deployment. > > > > > > I suspect it would be used as a convenience; i.e. instead of the tool > > initially uploading 100 files, it uploads a zip and explodes it. And > > then either way it begins to manipulate the few files that the tool > > regards as eligible for update without redeploy (.html, .css, etc.) > > That's also a use case (depending on producing an archive in the first > place). > > Emmanuel > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e0fa0aa5/attachment-0001.html From brian.stansberry at redhat.com Fri Jun 10 17:32:21 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 16:32:21 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: <575ACD91.5020302@redhat.com> Message-ID: <72080d67-83b2-6565-2396-25537b102a80@redhat.com> On 6/10/16 4:20 PM, James Perkins wrote: > > > On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet > wrote: > > Some details on the current implementation : > * the add-content will overwrite existing content so there is no > update-content > updating instead of just adding means having the state on the client > as well as on the server which would require more checks to keep those > in sync for no real value from my point of view. > > > I think there should be a force attribute, or something along those > lines, that can be changed to indicate an add shouldn't override. It can > default to false, but there are probably scenarios where you would want > an add to fail of the content already exists. In that case, we should have an op called "update-content". :) Oh, I think you meant the default should be 'force=true', so by default add can update but the user can turn that off. > > > * the add-content/remove-content work with a list of contents thus > for an IDE we don't have to create a bunch of ops to upload or delete > each change. > * you can start from an 'empty' deployment and add contents to it > step by step > > Emmanuel > > > On 10/06/2016 15:38, Brian Stansberry wrote: > > Emmanuel Hugonnet has been working on a long requested feature to have > > WildFly support "managed exploded deployments." We have a requirements > > analysis doc for this at > https://developer.jboss.org/docs/DOC-55497 and > > I just wanted to point that out to the list so anyone interested can > > have a look, and comment on this thread or on the document. > > > > A managed deployment is one where the user provided content is > copied by > > the server/host controller into its internal content repo and then > > thereafter that copy is what is used. I estimate that 99%+ of all > zipped > > deployments in WildFly are managed. With an unmanaged deployment the > > user provides the server with the local FS path to the content and > then > > the server directly uses that content. All exploded deployments are > > unmanaged, as we don't support managed yet. > > > > We propose to add 5 new operations to the deployment resource: > > > > explode (to convert and archive deployment to exploded) > > add-content > > update-content > > remove-content > > read-content > > > > There is one "nice-to-have" requirement listed on the doc where I'm > > increasingly thinking it needs to be a hard requirement, so thought on > > this are appreciated: > > > > > > "The explode operation can take an optional path parameter, the > value of > > which is a path within the deployment that should be exploded. > > * The use case for this is scenarios like an exploded ear that > > contains an unexploded war, and then the user later wishes the war > to be > > exploded. > > * This is much closer to a hard requirement if the nice-to-have > > requirement for recursively exploding is not supported. > > * This operation will fail if the content referred to by the path > > parameter is already exploded or is not a zip file. > > * This operation will fail if any content between the root of the > > deployment and the content referred to by the path parameter is an > > unexploded archive. > > * So, > > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) > > would fail if thewar.war hadn't previously been exploded." > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Fri Jun 10 17:41:40 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 16:41:40 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: <575ACD39.5010204@redhat.com> <575AD12A.80706@redhat.com> <575ADA3E.1010808@redhat.com> Message-ID: <92f5472b-0666-b082-cf2b-0bcb863f29ed@redhat.com> On 6/10/16 4:27 PM, James Perkins wrote: > > > On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet > wrote: > > > > On 10/06/2016 17:06, Brian Stansberry wrote: > > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote: > >> > >> > >> On 10/06/2016 16:22, David M. Lloyd wrote: > >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote: > >>>> Emmanuel Hugonnet has been working on a long requested feature > to have > >>>> WildFly support "managed exploded deployments." We have a > requirements > >>>> analysis doc for this at > https://developer.jboss.org/docs/DOC-55497 and > >>>> I just wanted to point that out to the list so anyone > interested can > >>>> have a look, and comment on this thread or on the document. > >>>> > >>>> A managed deployment is one where the user provided content is > copied by > >>>> the server/host controller into its internal content repo and then > >>>> thereafter that copy is what is used. I estimate that 99%+ of > all zipped > >>>> deployments in WildFly are managed. With an unmanaged > deployment the > >>>> user provides the server with the local FS path to the content > and then > >>>> the server directly uses that content. All exploded deployments are > >>>> unmanaged, as we don't support managed yet. > >>>> > >>>> We propose to add 5 new operations to the deployment resource: > >>>> > >>>> explode (to convert and archive deployment to exploded) > >>> > >>> Hmmm. > >>> > >>> Is deployment explosion really an deployer concern, or is it a > >>> deployment provider concern? Consider: > >>> > >>> * The deployment provider is the one who will know whether or not > >>> his/her deployment will function correctly with or without > exploding. > >>> * The deployment will have been tested in the desired configuration > >>> (exploded or unexploded). > >>> * Making this a deployer/administrator concern means that he/she > must > >>> ensure that the extra step(s) taken in development and testing > are also > >>> replicated in production. > >>> > >>> Wouldn't it make more sense to have some deployment control metadata > >>> (maybe even just a MANIFEST header) that says whether the particular > >>> archive should be exploded? > >>> > >>> Also, I don't think it's clear that you always want to explode > the outer > >>> archive if an inner archive is to be exploded (I'm not sure that's > >>> necessarily implied by the proposed design, but it certainly > would be in > >>> the recursive case). In particular it's definitely useful to > explode > >>> WARs inside of EARs that need not be exploded. > >>> > >>> Explode!! > >>> > >>> (eom) > >> > >> I think the main target for explosion scenarios are tools (IDE, > build tools, etc.) in a development environment. so this mecanism is > >> transparent from the developer point of vuiew. > >> You have the same functionalities as with the scanner with > hopefully a better control over the deployment management. > >> Also this means you can develop on a remote server or even on a > domain without having to rebuild the whole archive everytime. > >> > > > > So would you use the 'explode' operation in your netbeans plugin, i.e. > > start archived and explode? I'm curious if the JBDS guys will. > > Well it depends. On NetBeans you have a "Deploy on Save" checkbox so > that the 'build' (since the build process it externalized in Netbeans) > will no longer produce an archive but a list of changes. > So I might need to explode the deployment somewhere in time. > > > I could see this being useful in a scenario where a user launches > WildFly in something like Docker but they want to see changes on static > content without a full redeploy. > > If it's all local then it's already possible to do this using an > unmanaged deployment. I think David's original point was objecting to the "explode" op which takes an existing managed archive deployment and turns it into a managed exploded deployment. He questions whether that's a valid use case to support. It wasn't about whether managed exploded deployments are a good idea at all, just whether an internal conversion operation should be supported. Managed exploded deployments have a number of benefits over unmanaged: 1) Remote content administration, no local FS access required 2) Automatic content replication in a managed domain. 3) The content is stored in the internal repo, less likely to get messed up somehow by other user activity on the filesystem. > > > > > > > > I suspect it would be used as a convenience; i.e. instead of the tool > > initially uploading 100 files, it uploads a zip and explodes it. And > > then either way it begins to manipulate the few files that the tool > > regards as eligible for update without redeploy (.html, .css, etc.) > > That's also a use case (depending on producing an archive in the > first place). > > Emmanuel > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Fri Jun 10 17:46:59 2016 From: jperkins at redhat.com (James Perkins) Date: Fri, 10 Jun 2016 14:46:59 -0700 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <92f5472b-0666-b082-cf2b-0bcb863f29ed@redhat.com> References: <575ACD39.5010204@redhat.com> <575AD12A.80706@redhat.com> <575ADA3E.1010808@redhat.com> <92f5472b-0666-b082-cf2b-0bcb863f29ed@redhat.com> Message-ID: On Fri, Jun 10, 2016 at 2:41 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 6/10/16 4:27 PM, James Perkins wrote: > > > > > > On Fri, Jun 10, 2016 at 8:18 AM, Emmanuel Hugonnet > > wrote: > > > > > > > > On 10/06/2016 17:06, Brian Stansberry wrote: > > > On 6/10/16 9:39 AM, Emmanuel Hugonnet wrote: > > >> > > >> > > >> On 10/06/2016 16:22, David M. Lloyd wrote: > > >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote: > > >>>> Emmanuel Hugonnet has been working on a long requested feature > > to have > > >>>> WildFly support "managed exploded deployments." We have a > > requirements > > >>>> analysis doc for this at > > https://developer.jboss.org/docs/DOC-55497 and > > >>>> I just wanted to point that out to the list so anyone > > interested can > > >>>> have a look, and comment on this thread or on the document. > > >>>> > > >>>> A managed deployment is one where the user provided content is > > copied by > > >>>> the server/host controller into its internal content repo and > then > > >>>> thereafter that copy is what is used. I estimate that 99%+ of > > all zipped > > >>>> deployments in WildFly are managed. With an unmanaged > > deployment the > > >>>> user provides the server with the local FS path to the content > > and then > > >>>> the server directly uses that content. All exploded deployments > are > > >>>> unmanaged, as we don't support managed yet. > > >>>> > > >>>> We propose to add 5 new operations to the deployment resource: > > >>>> > > >>>> explode (to convert and archive deployment to exploded) > > >>> > > >>> Hmmm. > > >>> > > >>> Is deployment explosion really an deployer concern, or is it a > > >>> deployment provider concern? Consider: > > >>> > > >>> * The deployment provider is the one who will know whether or not > > >>> his/her deployment will function correctly with or without > > exploding. > > >>> * The deployment will have been tested in the desired > configuration > > >>> (exploded or unexploded). > > >>> * Making this a deployer/administrator concern means that he/she > > must > > >>> ensure that the extra step(s) taken in development and testing > > are also > > >>> replicated in production. > > >>> > > >>> Wouldn't it make more sense to have some deployment control > metadata > > >>> (maybe even just a MANIFEST header) that says whether the > particular > > >>> archive should be exploded? > > >>> > > >>> Also, I don't think it's clear that you always want to explode > > the outer > > >>> archive if an inner archive is to be exploded (I'm not sure > that's > > >>> necessarily implied by the proposed design, but it certainly > > would be in > > >>> the recursive case). In particular it's definitely useful to > > explode > > >>> WARs inside of EARs that need not be exploded. > > >>> > > >>> Explode!! > > >>> > > >>> (eom) > > >> > > >> I think the main target for explosion scenarios are tools (IDE, > > build tools, etc.) in a development environment. so this mecanism is > > >> transparent from the developer point of vuiew. > > >> You have the same functionalities as with the scanner with > > hopefully a better control over the deployment management. > > >> Also this means you can develop on a remote server or even on a > > domain without having to rebuild the whole archive everytime. > > >> > > > > > > So would you use the 'explode' operation in your netbeans plugin, > i.e. > > > start archived and explode? I'm curious if the JBDS guys will. > > > > Well it depends. On NetBeans you have a "Deploy on Save" checkbox so > > that the 'build' (since the build process it externalized in > Netbeans) > > will no longer produce an archive but a list of changes. > > So I might need to explode the deployment somewhere in time. > > > > > > I could see this being useful in a scenario where a user launches > > WildFly in something like Docker but they want to see changes on static > > content without a full redeploy. > > > > If it's all local then it's already possible to do this using an > > unmanaged deployment. > > I think David's original point was objecting to the "explode" op which > takes an existing managed archive deployment and turns it into a managed > exploded deployment. He questions whether that's a valid use case to > support. It wasn't about whether managed exploded deployments are a good > idea at all, just whether an internal conversion operation should be > supported. > > Managed exploded deployments have a number of benefits over unmanaged: > > 1) Remote content administration, no local FS access required > 2) Automatic content replication in a managed domain. > 3) The content is stored in the internal repo, less likely to get messed > up somehow by other user activity on the filesystem. > > Got it. I think I misread something in there :) > > > > > > > > > > > > > > I suspect it would be used as a convenience; i.e. instead of the > tool > > > initially uploading 100 files, it uploads a zip and explodes it. > And > > > then either way it begins to manipulate the few files that the tool > > > regards as eligible for update without redeploy (.html, .css, etc.) > > > > That's also a use case (depending on producing an archive in the > > first place). > > > > Emmanuel > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > James R. Perkins > > JBoss by Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/3eb91b05/attachment-0001.html From jperkins at redhat.com Fri Jun 10 17:48:12 2016 From: jperkins at redhat.com (James Perkins) Date: Fri, 10 Jun 2016 14:48:12 -0700 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <72080d67-83b2-6565-2396-25537b102a80@redhat.com> References: <575ACD91.5020302@redhat.com> <72080d67-83b2-6565-2396-25537b102a80@redhat.com> Message-ID: On Fri, Jun 10, 2016 at 2:32 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 6/10/16 4:20 PM, James Perkins wrote: > > > > > > On Fri, Jun 10, 2016 at 7:24 AM, Emmanuel Hugonnet > > wrote: > > > > Some details on the current implementation : > > * the add-content will overwrite existing content so there is no > > update-content > > updating instead of just adding means having the state on the client > > as well as on the server which would require more checks to keep > those > > in sync for no real value from my point of view. > > > > > > I think there should be a force attribute, or something along those > > lines, that can be changed to indicate an add shouldn't override. It can > > default to false, but there are probably scenarios where you would want > > an add to fail of the content already exists. > > In that case, we should have an op called "update-content". :) > > Oh, I think you meant the default should be 'force=true', so by default > add can update but the user can turn that off. Yes correct. If we want add-content to also act like update-content I think there should be a way to indicate the operation should fail if content is being updated instead of added. > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160610/e55d4758/attachment.html From brian.stansberry at redhat.com Fri Jun 10 17:48:14 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 10 Jun 2016 16:48:14 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575ACD91.5020302@redhat.com> References: <575ACD91.5020302@redhat.com> Message-ID: Emmanuel, Can you work with Alexey and Jeff to add some CLI requirements to this? I went on PTO and forget about our discussions in Neuchatel about being able to associate streams wit the add-content op. If we can't make it easy to do that with low level operations, we'd need a high level command. The doc already mentions there needs to be some CLI "deploy" command support for starting an empty exploded deployment. Perhaps that's not strictly required though; a low level op could suffice. The deployment doesn't need to be mapped to server groups or enabled until it isn't empty any more. On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote: > Some details on the current implementation : > * the add-content will overwrite existing content so there is no update-content > updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those > in sync for no real value from my point of view. > * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete > each change. > * you can start from an 'empty' deployment and add contents to it step by step > > Emmanuel > > > On 10/06/2016 15:38, Brian Stansberry wrote: >> Emmanuel Hugonnet has been working on a long requested feature to have >> WildFly support "managed exploded deployments." We have a requirements >> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >> I just wanted to point that out to the list so anyone interested can >> have a look, and comment on this thread or on the document. >> >> A managed deployment is one where the user provided content is copied by >> the server/host controller into its internal content repo and then >> thereafter that copy is what is used. I estimate that 99%+ of all zipped >> deployments in WildFly are managed. With an unmanaged deployment the >> user provides the server with the local FS path to the content and then >> the server directly uses that content. All exploded deployments are >> unmanaged, as we don't support managed yet. >> >> We propose to add 5 new operations to the deployment resource: >> >> explode (to convert and archive deployment to exploded) >> add-content >> update-content >> remove-content >> read-content >> >> There is one "nice-to-have" requirement listed on the doc where I'm >> increasingly thinking it needs to be a hard requirement, so thought on >> this are appreciated: >> >> >> "The explode operation can take an optional path parameter, the value of >> which is a path within the deployment that should be exploded. >> * The use case for this is scenarios like an exploded ear that >> contains an unexploded war, and then the user later wishes the war to be >> exploded. >> * This is much closer to a hard requirement if the nice-to-have >> requirement for recursively exploding is not supported. >> * This operation will fail if the content referred to by the path >> parameter is already exploded or is not a zip file. >> * This operation will fail if any content between the root of the >> deployment and the content referred to by the path parameter is an >> unexploded archive. >> * So, >> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >> would fail if thewar.war hadn't previously been exploded." >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Sun Jun 12 09:59:35 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Sun, 12 Jun 2016 14:59:35 +0100 Subject: [wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration... In-Reply-To: References: <7cf0bf54-7214-6896-224e-71a99d67a63d@redhat.com> <57582F4D.2090103@redhat.com> <4cb6f124-cbbd-83f0-82bb-aad9335b29b8@redhat.com> <15a4baff-2ec1-0fff-01ac-067d69d07bc1@jboss.com> Message-ID: Elytron is targeted for WildFly 11 so assuming this is coming at the same time probably makes sense to review how the default our of the box security settings can be combined with Elytron. On 10/06/16 16:07, Scott Marlow wrote: > Darran, > > We didn't yet try to configure NoSQL authentication, should we try that > after switching WildFly to Elytron, or before? We definitely want to > support authentication. Perhaps we should consider requiring > authentication by default and let developers disable it, as there are > many unsecured NoSQL databases out there. > > Thanks, > Scott > > On 06/10/2016 05:46 AM, Darran Lofthouse wrote: >> Shortly we are going to be starting to transition subsystems to make use >> of Elytron defined capabilities so things like custom trust manager >> configuration should not need to live in individual subsystems any >> more: - >> >> https://developer.jboss.org/docs/DOC-53383 >> >> Regards, >> Darran Lofthouse. >> >> >> On 10/06/16 06:46, Gunnar Morling wrote: >>>> We cannot include hostname + port numbers directly, instead we >>> reference host names/port pairs defined in the outbound-socket-binding >>> section of standalone.xml. >>> >>> Why is that? Some general principle in WF config? >>> >>> In OGM, we recently had the feature request to support a custom socket >>> factory (see MongoClientOptions#setSocketFactory()); The user wanted to >>> set a SSLSocketFactory configured with a custom trust store. Would that >>> still be possible? >>> >>> >>> 2016-06-09 22:23 GMT+02:00 Scott Marlow >> >: >>> >>> >>> >>> On 06/09/2016 06:27 AM, Gunnar Morling wrote: >>> >>> Hi, >>> >>> My concern with the current proposal and its usage of dedicated >>> elements/attributes for specific options such as write concern >>> is that >>> it easily leads into a catch-up game with datastore vendors as >>> they keep >>> adding new options. That might create a constant effort for >>> maintaining >>> this subsystem. >>> >>> How about having a more generic approach which only has typed >>> elements >>> for common properties/settings such as user, password, database >>> name and >>> then allows to set custom things as part of the connection URL: >>> >>> >>> >> jndi-name="java:jboss/nosql/mongodb_test"> >>> >>> >>> nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&... >>> >>> >>> bob >>> secret >>> >>> >>> >>> >>> Here, the connection-url would be analyzed to load the right >>> driver and >>> pass any configured settings to it. >>> >>> While compact, that URL syntax might be confused with >>> existing URI >>> schemes of specific stores, so an alternative might be this (a >>> bit more >>> verbose, though): >>> >>> >>> >> jndi-name="java:jboss/nosql/mongodb_test"> >>> mongodb >>> >>> localhost:27017,otherhost:27017 >>> >>> >>> We cannot include hostname + port numbers directly, instead we >>> reference host names/port pairs defined in the >>> outbound-socket-binding section of standalone.xml. >>> >>> somedatabase >>> >>> bob >>> secret >>> >>> >>> >> name="writeConcern">ACKNOWLEDGED >>> >> name="readPreference">MAJORITY >>> >>> >>> >>> >>> >>> +1 for the separate properties idea! >>> >>> Both alternatives don't address custom write concerns, but I >>> think you >>> foresee CDI producer methods for more advanced customizations, >>> so that >>> might be fine. That'd also be needed for some other >>> non-primitive >>> options (dbDecoderFactory, codecRegistry etc.), unless you >>> provide a way >>> to configure classes here and have them instantiated. >>> >>> >>> I'm still learning more about how to use advance customizations in >>> the CDI producer but yes, we definitely want to do this, to simplify >>> application program use of NoSQL. >>> >>> >>> These more generic approaches will make it more robust >>> towards new >>> options being added, but of course you also loose type-safety >>> and I >>> suppose usability in the console which might provide dedicated >>> editors >>> for real types such as boolean etc. >>> >>> >>> I think that about summarizes the difference. Eventually, when the >>> configuration options stabilize, it might be better to switch to >>> dedicated editors, which would be a big one-off upgrade, I think. >>> If we used dedicated editors now, we will have several big (NoSQL >>> subsystem configuration) upgrades, as the NoSQL database options may >>> change over time. >>> >>> Thanks, >>> Scott >>> >>> >>> --Gunnar >>> >>> >>> >>> >>> 2016-06-08 22:18 GMT+02:00 Brian Stansberry >>> >> >>> >> >>: >>> >>> On 6/8/16 9:44 AM, Jesper Pedersen wrote: >>> > On 06/08/2016 10:39 AM, Scott Marlow wrote: >>> >> For those not reading [1], we also can support one of the >>> predefined >>> >> write-concern constants via: >>> >> >>> >> >>> >> ... >>> >> >>> >> >>> > >>> > I would choose this approach, and support the predefined >>> constants. >>> > >>> > Exposing MongoDB internal API details in the configuration >>> seems to be >>> > overkill, and put extra effort on your part when they >>> change the API. >>> > >>> >>> This is good input. If this ends up in WildFly or EAP, we >>> have stringent >>> compatibility guarantees, so be cautious about exposing >>> things in >>> your API. >>> >>> > >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev at lists.jboss.org >>> >>> >> > >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> >>> >> > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From david.lloyd at redhat.com Mon Jun 13 09:16:02 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Jun 2016 08:16:02 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <392e197f-7b9d-4604-7198-c5f718282926@redhat.com> References: <575ACD39.5010204@redhat.com> <392e197f-7b9d-4604-7198-c5f718282926@redhat.com> Message-ID: <575EB212.4050300@redhat.com> On 06/10/2016 10:16 AM, Brian Stansberry wrote: > On 6/10/16 9:22 AM, David M. Lloyd wrote: >> On 06/10/2016 08:38 AM, Brian Stansberry wrote: >>> Emmanuel Hugonnet has been working on a long requested feature to have >>> WildFly support "managed exploded deployments." We have a requirements >>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>> I just wanted to point that out to the list so anyone interested can >>> have a look, and comment on this thread or on the document. >>> >>> A managed deployment is one where the user provided content is copied by >>> the server/host controller into its internal content repo and then >>> thereafter that copy is what is used. I estimate that 99%+ of all zipped >>> deployments in WildFly are managed. With an unmanaged deployment the >>> user provides the server with the local FS path to the content and then >>> the server directly uses that content. All exploded deployments are >>> unmanaged, as we don't support managed yet. >>> >>> We propose to add 5 new operations to the deployment resource: >>> >>> explode (to convert and archive deployment to exploded) >> >> Hmmm. >> >> Is deployment explosion really an deployer concern, or is it a >> deployment provider concern? Consider: >> >> * The deployment provider is the one who will know whether or not >> his/her deployment will function correctly with or without exploding. >> * The deployment will have been tested in the desired configuration >> (exploded or unexploded). >> * Making this a deployer/administrator concern means that he/she must >> ensure that the extra step(s) taken in development and testing are also >> replicated in production. >> > > The admin already has this capability; they can just convert a zip to > unmanaged exploded and redeploy. Granted, this op makes it easier to do > and bypasses limitations that currently exist like the need for said > admin to write to the local FS. Sure, but I think that creates a false equivalency between unmanaged deployments and exploded deployments. Managed deployments have many advantages. Exploded deployments on the other hand have key functional differences at run time (consider the case we used to discuss all the time: servlets which call ServletContext.getRealPath() and expect to get a non-null answer). If the answer to a given problem is "use an unmanaged deployment" then I think we have a deficiency with managed deployments, which were IMO always meant to be the primary deployment function for most apps; unmanaged deployments were meant to be a combination of convenience feature and continuation of capabilities from previous JBoss AS generations. That said, I think the IDE case (of dynamic content updates) is completely legitimate, and honestly one I did not think of. So maybe the right thing is to support both an operation set as Emmanuel proposes, *and* a deployment flag that can be set an a per-archive basis, which would meet all the use cases. >> Wouldn't it make more sense to have some deployment control metadata >> (maybe even just a MANIFEST header) that says whether the particular >> archive should be exploded? > > This one gives me a not so nice feeling, as now we are taking things > typically done by DUPs (analyzing deployment structure, extracting > files, parsing) and doing it in a different area. Not necessarily - it could be a simple as adding a DUP step which examines the descriptor and pokes the VFS mount so that at run time, the deployment is exploded. That would satisfy the run-time requirements without impacting the implementation of the proposed management operation(s). >> Also, I don't think it's clear that you always want to explode the outer >> archive if an inner archive is to be exploded (I'm not sure that's >> necessarily implied by the proposed design, but it certainly would be in >> the recursive case). In particular it's definitely useful to explode >> WARs inside of EARs that need not be exploded. > > There's a lot of complexity that comes from allowing the parent to be an > archive and the child exploded. And I don't see a huge benefit. How much > unzipped child content do ears have? Mostly a few deployments > descriptors and a manifest. I don't think you need to actively prevent a recursive explode situation, but I think it's just not always necessary and using the DUP approach it's easier to just explode individual pieces. But using the management operation approach, the opposite is true, as addressing interior components is more complex than just recursively exploding the whole thing. > I certainly see a benefit though in having the parent and 1 child > exploded while all other children remain as zips. Sure. -- - DML From jdenise at redhat.com Mon Jun 13 11:14:04 2016 From: jdenise at redhat.com (Jean-Francois Denise) Date: Mon, 13 Jun 2016 17:14:04 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: <575ACD91.5020302@redhat.com> Message-ID: Hi, we have discussed the CLI requirements. The main item is the addition of a support for streams (in batch and non batch) in low level Operation. Doing so we will support the update/add-content operation. A field that it a File stream, will be annotated with attached_stream and filesystem_path. In the particular case of the update/add-content operation, the index_stream attribute should be renamed to a more appropriate name since we won't use any aliasing in the cli (something like source_file). This does answer the path/stream duality that CLI user could observe (a file system path converted internally onto an array index). Introducing some special aliasing in the metadata would make ergonomics constraint to slip into lower level API. For a simpler command, with better options, we should implement a dedicated Command. Discussing the explode operation, we could have a need for an extra operation (list-content) that would allow to offer completion when selecting sub archives to explode. JF On 10/06/16 23:48, Brian Stansberry wrote: > Emmanuel, > > Can you work with Alexey and Jeff to add some CLI requirements to this? > I went on PTO and forget about our discussions in Neuchatel about being > able to associate streams wit the add-content op. If we can't make it > easy to do that with low level operations, we'd need a high level command. > > The doc already mentions there needs to be some CLI "deploy" command > support for starting an empty exploded deployment. Perhaps that's not > strictly required though; a low level op could suffice. The deployment > doesn't need to be mapped to server groups or enabled until it isn't > empty any more. > > On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote: >> Some details on the current implementation : >> * the add-content will overwrite existing content so there is no update-content >> updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those >> in sync for no real value from my point of view. >> * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete >> each change. >> * you can start from an 'empty' deployment and add contents to it step by step >> >> Emmanuel >> >> >> On 10/06/2016 15:38, Brian Stansberry wrote: >>> Emmanuel Hugonnet has been working on a long requested feature to have >>> WildFly support "managed exploded deployments." We have a requirements >>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>> I just wanted to point that out to the list so anyone interested can >>> have a look, and comment on this thread or on the document. >>> >>> A managed deployment is one where the user provided content is copied by >>> the server/host controller into its internal content repo and then >>> thereafter that copy is what is used. I estimate that 99%+ of all zipped >>> deployments in WildFly are managed. With an unmanaged deployment the >>> user provides the server with the local FS path to the content and then >>> the server directly uses that content. All exploded deployments are >>> unmanaged, as we don't support managed yet. >>> >>> We propose to add 5 new operations to the deployment resource: >>> >>> explode (to convert and archive deployment to exploded) >>> add-content >>> update-content >>> remove-content >>> read-content >>> >>> There is one "nice-to-have" requirement listed on the doc where I'm >>> increasingly thinking it needs to be a hard requirement, so thought on >>> this are appreciated: >>> >>> >>> "The explode operation can take an optional path parameter, the value of >>> which is a path within the deployment that should be exploded. >>> * The use case for this is scenarios like an exploded ear that >>> contains an unexploded war, and then the user later wishes the war to be >>> exploded. >>> * This is much closer to a hard requirement if the nice-to-have >>> requirement for recursively exploding is not supported. >>> * This operation will fail if the content referred to by the path >>> parameter is already exploded or is not a zip file. >>> * This operation will fail if any content between the root of the >>> deployment and the content referred to by the path parameter is an >>> unexploded archive. >>> * So, >>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >>> would fail if thewar.war hadn't previously been exploded." >>> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > From david.lloyd at redhat.com Mon Jun 13 11:19:24 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Jun 2016 10:19:24 -0500 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575EB212.4050300@redhat.com> References: <575ACD39.5010204@redhat.com> <392e197f-7b9d-4604-7198-c5f718282926@redhat.com> <575EB212.4050300@redhat.com> Message-ID: <575ECEFC.5040107@redhat.com> Just had an offline discussion with Emmanuel and he cleared up some things for me. Turns out my recollection of how managed deployments work was faulty (surprise!)... IOW carry on, nothing to see here :-) On 06/13/2016 08:16 AM, David M. Lloyd wrote: > On 06/10/2016 10:16 AM, Brian Stansberry wrote: >> On 6/10/16 9:22 AM, David M. Lloyd wrote: >>> On 06/10/2016 08:38 AM, Brian Stansberry wrote: >>>> Emmanuel Hugonnet has been working on a long requested feature to have >>>> WildFly support "managed exploded deployments." We have a requirements >>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>>> I just wanted to point that out to the list so anyone interested can >>>> have a look, and comment on this thread or on the document. >>>> >>>> A managed deployment is one where the user provided content is >>>> copied by >>>> the server/host controller into its internal content repo and then >>>> thereafter that copy is what is used. I estimate that 99%+ of all >>>> zipped >>>> deployments in WildFly are managed. With an unmanaged deployment the >>>> user provides the server with the local FS path to the content and then >>>> the server directly uses that content. All exploded deployments are >>>> unmanaged, as we don't support managed yet. >>>> >>>> We propose to add 5 new operations to the deployment resource: >>>> >>>> explode (to convert and archive deployment to exploded) >>> >>> Hmmm. >>> >>> Is deployment explosion really an deployer concern, or is it a >>> deployment provider concern? Consider: >>> >>> * The deployment provider is the one who will know whether or not >>> his/her deployment will function correctly with or without exploding. >>> * The deployment will have been tested in the desired configuration >>> (exploded or unexploded). >>> * Making this a deployer/administrator concern means that he/she must >>> ensure that the extra step(s) taken in development and testing are also >>> replicated in production. >>> >> >> The admin already has this capability; they can just convert a zip to >> unmanaged exploded and redeploy. Granted, this op makes it easier to do >> and bypasses limitations that currently exist like the need for said >> admin to write to the local FS. > > Sure, but I think that creates a false equivalency between unmanaged > deployments and exploded deployments. Managed deployments have many > advantages. Exploded deployments on the other hand have key functional > differences at run time (consider the case we used to discuss all the > time: servlets which call ServletContext.getRealPath() and expect to get > a non-null answer). If the answer to a given problem is "use an > unmanaged deployment" then I think we have a deficiency with managed > deployments, which were IMO always meant to be the primary deployment > function for most apps; unmanaged deployments were meant to be a > combination of convenience feature and continuation of capabilities from > previous JBoss AS generations. > > That said, I think the IDE case (of dynamic content updates) is > completely legitimate, and honestly one I did not think of. So maybe > the right thing is to support both an operation set as Emmanuel > proposes, *and* a deployment flag that can be set an a per-archive > basis, which would meet all the use cases. > >>> Wouldn't it make more sense to have some deployment control metadata >>> (maybe even just a MANIFEST header) that says whether the particular >>> archive should be exploded? >> >> This one gives me a not so nice feeling, as now we are taking things >> typically done by DUPs (analyzing deployment structure, extracting >> files, parsing) and doing it in a different area. > > Not necessarily - it could be a simple as adding a DUP step which > examines the descriptor and pokes the VFS mount so that at run time, the > deployment is exploded. That would satisfy the run-time requirements > without impacting the implementation of the proposed management > operation(s). > >>> Also, I don't think it's clear that you always want to explode the outer >>> archive if an inner archive is to be exploded (I'm not sure that's >>> necessarily implied by the proposed design, but it certainly would be in >>> the recursive case). In particular it's definitely useful to explode >>> WARs inside of EARs that need not be exploded. >> >> There's a lot of complexity that comes from allowing the parent to be an >> archive and the child exploded. And I don't see a huge benefit. How much >> unzipped child content do ears have? Mostly a few deployments >> descriptors and a manifest. > > I don't think you need to actively prevent a recursive explode > situation, but I think it's just not always necessary and using the DUP > approach it's easier to just explode individual pieces. But using the > management operation approach, the opposite is true, as addressing > interior components is more complex than just recursively exploding the > whole thing. > >> I certainly see a benefit though in having the parent and 1 child >> exploded while all other children remain as zips. > > Sure. > -- - DML From rstryker at redhat.com Mon Jun 13 13:07:36 2016 From: rstryker at redhat.com (Robert Stryker) Date: Mon, 13 Jun 2016 13:07:36 -0400 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: Message-ID: Quick question here: Will the various add / update / remove methods have syntax for working on multiple files at once? Or will one management call be required for each request? Requiring a separate management call for each changed file might be pretty slow if the server being acted against is remote. On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Emmanuel Hugonnet has been working on a long requested feature to have > WildFly support "managed exploded deployments." We have a requirements > analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and I > just wanted to point that out to the list so anyone interested can have a > look, and comment on this thread or on the document. > > A managed deployment is one where the user provided content is copied by > the server/host controller into its internal content repo and then > thereafter that copy is what is used. I estimate that 99%+ of all zipped > deployments in WildFly are managed. With an unmanaged deployment the user > provides the server with the local FS path to the content and then the > server directly uses that content. All exploded deployments are unmanaged, > as we don't support managed yet. > > We propose to add 5 new operations to the deployment resource: > > explode (to convert and archive deployment to exploded) > add-content > update-content > remove-content > read-content > > There is one "nice-to-have" requirement listed on the doc where I'm > increasingly thinking it needs to be a hard requirement, so thought on this > are appreciated: > > > "The explode operation can take an optional path parameter, the value of > which is a path within the deployment that should be exploded. > * The use case for this is scenarios like an exploded ear that > contains an unexploded war, and then the user later wishes the war to be > exploded. > * This is much closer to a hard requirement if the nice-to-have > requirement for recursively exploding is not supported. > * This operation will fail if the content referred to by the path > parameter is already exploded or is not a zip file. > * This operation will fail if any content between the root of the > deployment and the content referred to by the path parameter is an > unexploded archive. > * So, > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would > fail if thewar.war hadn't previously been exploded." > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/aa8bb571/attachment.html From ehugonne at redhat.com Mon Jun 13 13:16:30 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 13 Jun 2016 19:16:30 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: Message-ID: <575EEA6E.7050903@redhat.com> Well I only made the add-content (which does the update to) and remove-content support list of content. Exploding has only one file support as the order might have an impact. Maybe adding recusrive is sufficient ? read-content is also one file only has I didn't have a proper use-case for multiple targets. What do you have in mind for read-content or explode ? Cheers Emmanuel On 13/06/2016 19:07, Robert Stryker wrote: > Quick question here: > > Will the various add / update / remove methods have syntax for working on multiple files at once? Or will one management call be required > for each request? Requiring a separate management call for each changed file might be pretty slow if the server being acted against is remote. > > On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry > wrote: > > Emmanuel Hugonnet has been working on a long requested feature to have WildFly support "managed exploded deployments." We have a > requirements analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and I just wanted to point that out to the list so > anyone interested can have a look, and comment on this thread or on the document. > > A managed deployment is one where the user provided content is copied by the server/host controller into its internal content repo and > then thereafter that copy is what is used. I estimate that 99%+ of all zipped deployments in WildFly are managed. With an unmanaged > deployment the user provides the server with the local FS path to the content and then the server directly uses that content. All > exploded deployments are unmanaged, as we don't support managed yet. > > We propose to add 5 new operations to the deployment resource: > > explode (to convert and archive deployment to exploded) > add-content > update-content > remove-content > read-content > > There is one "nice-to-have" requirement listed on the doc where I'm increasingly thinking it needs to be a hard requirement, so thought > on this are appreciated: > > > "The explode operation can take an optional path parameter, the value of which is a path within the deployment that should be exploded. > * The use case for this is scenarios like an exploded ear that contains an unexploded war, and then the user later wishes the war to > be exploded. > * This is much closer to a hard requirement if the nice-to-have requirement for recursively exploding is not supported. > * This operation will fail if the content referred to by the path parameter is already exploded or is not a zip file. > * This operation will fail if any content between the root of the deployment and the content referred to by the path parameter is an > unexploded archive. > * So, /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would fail if thewar.war hadn't previously been > exploded." > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/36c092dd/attachment.bin From rstryker at redhat.com Mon Jun 13 13:35:49 2016 From: rstryker at redhat.com (Robert Stryker) Date: Mon, 13 Jun 2016 13:35:49 -0400 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: <575EEA6E.7050903@redhat.com> References: <575EEA6E.7050903@redhat.com> Message-ID: I was primarily concerned with update / remove, so I'm glad to hear those two are targeted to be supported. At this time, I don't think I have a need for read-content of multiple items, so I think we're ok there if no one else requires it. In terms of explode, I'm hard-pressed to design the API, but I'd imagine if order is critical, that it would take an array or list of paths, and explode them in the order provided, collecting the errors in some fashion to be returned at the end. Alternatively, if the server is prepared to discover all sub-deployments in an efficient manner, perhaps an integer representing max-depth, with a depth_infinite flag, would work? Again, these are just ideas, so I defer to your judgement. On Mon, Jun 13, 2016 at 1:16 PM, Emmanuel Hugonnet wrote: > Well I only made the add-content (which does the update to) and > remove-content support list of content. > Exploding has only one file support as the order might have an impact. > Maybe adding recusrive is sufficient ? > read-content is also one file only has I didn't have a proper use-case for > multiple targets. > What do you have in mind for read-content or explode ? > Cheers > Emmanuel > > > On 13/06/2016 19:07, Robert Stryker wrote: > > Quick question here: > > > > Will the various add / update / remove methods have syntax for working > on multiple files at once? Or will one management call be required > > for each request? Requiring a separate management call for each changed > file might be pretty slow if the server being acted against is remote. > > > > On Fri, Jun 10, 2016 at 9:38 AM, Brian Stansberry < > brian.stansberry at redhat.com > wrote: > > > > Emmanuel Hugonnet has been working on a long requested feature to > have WildFly support "managed exploded deployments." We have a > > requirements analysis doc for this at > https://developer.jboss.org/docs/DOC-55497 and I just wanted to point > that out to the list so > > anyone interested can have a look, and comment on this thread or on > the document. > > > > A managed deployment is one where the user provided content is > copied by the server/host controller into its internal content repo and > > then thereafter that copy is what is used. I estimate that 99%+ of > all zipped deployments in WildFly are managed. With an unmanaged > > deployment the user provides the server with the local FS path to > the content and then the server directly uses that content. All > > exploded deployments are unmanaged, as we don't support managed yet. > > > > We propose to add 5 new operations to the deployment resource: > > > > explode (to convert and archive deployment to exploded) > > add-content > > update-content > > remove-content > > read-content > > > > There is one "nice-to-have" requirement listed on the doc where I'm > increasingly thinking it needs to be a hard requirement, so thought > > on this are appreciated: > > > > > > "The explode operation can take an optional path parameter, the > value of which is a path within the deployment that should be exploded. > > * The use case for this is scenarios like an exploded ear that > contains an unexploded war, and then the user later wishes the war to > > be exploded. > > * This is much closer to a hard requirement if the nice-to-have > requirement for recursively exploding is not supported. > > * This operation will fail if the content referred to by the > path parameter is already exploded or is not a zip file. > > * This operation will fail if any content between the root of > the deployment and the content referred to by the path parameter is an > > unexploded archive. > > * So, > /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) would > fail if thewar.war hadn't previously been > > exploded." > > > > -- > > Brian Stansberry > > Senior Principal Software Engineer > > JBoss by Red Hat > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/e2fd1861/attachment-0001.html From ropalka at redhat.com Mon Jun 13 17:48:39 2016 From: ropalka at redhat.com (Richard Opalka) Date: Mon, 13 Jun 2016 23:48:39 +0200 Subject: [wildfly-dev] Support for DMR Streams Message-ID: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> Hi All, The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - see attachment. The idea of this new feature grew up while I was working on DMR-9 issue [2]. In short the news in upcoming JBoss DMR 1.4.0 are: * it will be compilable on JDK8 and above * it will be 100% backward compatible on binary level with previous version * it replaces old cookcc based parser with new one based on DMR Streaming API * DMR parsing will be times faster with old model based API * new DMR streaming API is highly memory efficient and really very fast One example on how to use new DMR streaming API can be seen here [3]. I believe this new DMR Streaming API will become very handy for many of us because it opens new opportunities to decrease memory and CPU usage in our core. At the moment in current prototype [4] I didn't touch DMR object model writing yet because new DMR Streaming API does not (and most probably will not) support pretty print feature (because of its focus on speed and efficiency). But I'm considering I might fix the object model writing flow when pretty print is off. Fixing it would speed it up significantly. Any objections? As a final note today I run few benchmarks (see attachments). Here are some outcomes from benchmark results in short: * Writing small DMR structures in DMR format is 2,4 times faster with new DMR streaming API * Writing small DMR structures in JSON format is 2,6 times faster with new DMR streaming API * Reading small DMR structures in DMR format is 3,9 times faster with old DMR object model API * Reading small DMR structures in JSON format is 3,7 times faster with old DMR object model API * Reading small DMR structures in DMR format is 5 times faster with new DMR streaming API * Reading small DMR structures in JSON format is 4,4 times faster with new DMR streaming API * Reading big DMR structures in DMR format is 5,2 times faster with old DMR object model API * Reading big DMR structures in JSON format is 6 times faster with old DMR object model API * Reading big DMR structures in DMR format is 7,6 times faster with new DMR streaming API * Reading big DMR structures in JSON format is 8,8 times faster with new DMR streaming API PS: Hopefully new DMR streaming API will seamlessly integrate with GWT (used in our console). [1] https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream [2] https://issues.jboss.org/browse/DMR-9 [3] https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 Regards, -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 -------------- next part -------------- A non-text attachment was scrubbed... Name: apidocs.zip Type: application/zip Size: 61709 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/2576ccc8/attachment-0001.zip -------------- next part -------------- A non-text attachment was scrubbed... Name: JBoss-DMR-Big-Structure-Benchmarks.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 26651 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/2576ccc8/attachment-0002.ods -------------- next part -------------- A non-text attachment was scrubbed... Name: JBoss-DMR-Small-Structure-Benchmarks.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 40191 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160613/2576ccc8/attachment-0003.ods From kabir.khan at jboss.com Mon Jun 13 17:51:41 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 13 Jun 2016 23:51:41 +0200 Subject: [wildfly-dev] Managed exploded deployments In-Reply-To: References: <575ACD91.5020302@redhat.com> Message-ID: Please open a separate EAP7 issue linked to the WFCORE one, and let Bilge know so he can rank it > On 13 Jun 2016, at 17:14, Jean-Francois Denise wrote: > > Hi, > > we have discussed the CLI requirements. The main item is the addition of > a support for streams (in batch and non batch) in low level Operation. > Doing so we will support the update/add-content operation. > > A field that it a File stream, will be annotated with attached_stream > and filesystem_path. > > In the particular case of the update/add-content operation, the > index_stream attribute should be renamed to a more appropriate name > since we won't use any aliasing in the cli (something like source_file). > This does answer the path/stream duality that CLI user could observe (a > file system path converted internally onto an array index). Introducing > some special aliasing in the metadata would make ergonomics constraint > to slip into lower level API. For a simpler command, with better > options, we should implement a dedicated Command. > > Discussing the explode operation, we could have a need for an extra > operation (list-content) that would allow to offer completion when > selecting sub archives to explode. > > JF > > > On 10/06/16 23:48, Brian Stansberry wrote: >> Emmanuel, >> >> Can you work with Alexey and Jeff to add some CLI requirements to this? >> I went on PTO and forget about our discussions in Neuchatel about being >> able to associate streams wit the add-content op. If we can't make it >> easy to do that with low level operations, we'd need a high level command. >> >> The doc already mentions there needs to be some CLI "deploy" command >> support for starting an empty exploded deployment. Perhaps that's not >> strictly required though; a low level op could suffice. The deployment >> doesn't need to be mapped to server groups or enabled until it isn't >> empty any more. >> >> On 6/10/16 9:24 AM, Emmanuel Hugonnet wrote: >>> Some details on the current implementation : >>> * the add-content will overwrite existing content so there is no update-content >>> updating instead of just adding means having the state on the client as well as on the server which would require more checks to keep those >>> in sync for no real value from my point of view. >>> * the add-content/remove-content work with a list of contents thus for an IDE we don't have to create a bunch of ops to upload or delete >>> each change. >>> * you can start from an 'empty' deployment and add contents to it step by step >>> >>> Emmanuel >>> >>> >>> On 10/06/2016 15:38, Brian Stansberry wrote: >>>> Emmanuel Hugonnet has been working on a long requested feature to have >>>> WildFly support "managed exploded deployments." We have a requirements >>>> analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and >>>> I just wanted to point that out to the list so anyone interested can >>>> have a look, and comment on this thread or on the document. >>>> >>>> A managed deployment is one where the user provided content is copied by >>>> the server/host controller into its internal content repo and then >>>> thereafter that copy is what is used. I estimate that 99%+ of all zipped >>>> deployments in WildFly are managed. With an unmanaged deployment the >>>> user provides the server with the local FS path to the content and then >>>> the server directly uses that content. All exploded deployments are >>>> unmanaged, as we don't support managed yet. >>>> >>>> We propose to add 5 new operations to the deployment resource: >>>> >>>> explode (to convert and archive deployment to exploded) >>>> add-content >>>> update-content >>>> remove-content >>>> read-content >>>> >>>> There is one "nice-to-have" requirement listed on the doc where I'm >>>> increasingly thinking it needs to be a hard requirement, so thought on >>>> this are appreciated: >>>> >>>> >>>> "The explode operation can take an optional path parameter, the value of >>>> which is a path within the deployment that should be exploded. >>>> * The use case for this is scenarios like an exploded ear that >>>> contains an unexploded war, and then the user later wishes the war to be >>>> exploded. >>>> * This is much closer to a hard requirement if the nice-to-have >>>> requirement for recursively exploding is not supported. >>>> * This operation will fail if the content referred to by the path >>>> parameter is already exploded or is not a zip file. >>>> * This operation will fail if any content between the root of the >>>> deployment and the content referred to by the path parameter is an >>>> unexploded archive. >>>> * So, >>>> /deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar) >>>> would fail if thewar.war hadn't previously been exploded." >>>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stuart.w.douglas at gmail.com Tue Jun 14 04:53:32 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 14 Jun 2016 16:53:32 +0800 Subject: [wildfly-dev] Wildfly Provisioning Message-ID: Hi Everyone, Recently a few of us had a meeting to discuss a new provisioning/patching system for Wildfly. I have written up the notes for this meeting which are at [1]. The document contains the full details, but the basic idea is to design a provisioning/patching/package management system for Wildfly and downstream products. This will not be based on our existing patching or feature pack code, but should take over the responsibilities of both. Obviously this is still in the early stages, and any feedback is welcome. Stuart [1] https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160614/6cc1f6e6/attachment.html From rsvoboda at redhat.com Tue Jun 14 07:01:20 2016 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 14 Jun 2016 07:01:20 -0400 (EDT) Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> Message-ID: <681608415.6061264.1465902080061.JavaMail.zimbra@redhat.com> > Hi All, > > The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - > see attachment. Will be DMR 1.4.z included in WF 11 or also in next EAP 7 release? > The idea of this new feature grew up while I was working on DMR-9 issue [2]. > > In short the news in upcoming JBoss DMR 1.4.0 are: > * it will be compilable on JDK8 and above > * it will be 100% backward compatible on binary level with previous > version > * it replaces old cookcc based parser with new one based on DMR > Streaming API > * DMR parsing will be times faster with old model based API > * new DMR streaming API is highly memory efficient and really very fast Nice results in attached spreadsheets. > One example on how to use new DMR streaming API can be seen here [3]. > > I believe this new DMR Streaming API will become very handy for many of us > because it opens new opportunities to decrease memory and CPU usage in > our core. > > At the moment in current prototype [4] I didn't touch DMR object model > writing yet > because new DMR Streaming API does not (and most probably will not) > support pretty print feature > (because of its focus on speed and efficiency). > But I'm considering I might fix the object model writing flow when > pretty print is off. > Fixing it would speed it up significantly. Any objections? I think pretty print feature is need, at least in CLI for stuff like ':read-resource(recursive=true)' Rostislav > As a final note today I run few benchmarks (see attachments). > Here are some outcomes from benchmark results in short: > * Writing small DMR structures in DMR format is 2,4 times faster with > new DMR streaming API > * Writing small DMR structures in JSON format is 2,6 times faster with > new DMR streaming API > * Reading small DMR structures in DMR format is 3,9 times faster with > old DMR object model API > * Reading small DMR structures in JSON format is 3,7 times faster with > old DMR object model API > * Reading small DMR structures in DMR format is 5 times faster with > new DMR streaming API > * Reading small DMR structures in JSON format is 4,4 times faster with > new DMR streaming API > * Reading big DMR structures in DMR format is 5,2 times faster with > old DMR object model API > * Reading big DMR structures in JSON format is 6 times faster with old > DMR object model API > * Reading big DMR structures in DMR format is 7,6 times faster with > new DMR streaming API > * Reading big DMR structures in JSON format is 8,8 times faster with > new DMR streaming API > > PS: Hopefully new DMR streaming API will seamlessly integrate with GWT > (used in our console). > > [1] > https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream > [2] https://issues.jboss.org/browse/DMR-9 > [3] > https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java > [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 > > Regards, > > -- > Richard Opalka > Principal Software Engineer > JBoss by Red Hat > Mobile: +420 731 186 942 > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Tue Jun 14 07:26:10 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 14 Jun 2016 06:26:10 -0500 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <681608415.6061264.1465902080061.JavaMail.zimbra@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> <681608415.6061264.1465902080061.JavaMail.zimbra@redhat.com> Message-ID: <575FE9D2.7050803@redhat.com> On 06/14/2016 06:01 AM, Rostislav Svoboda wrote: >> Hi All, >> >> The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - >> see attachment. > > Will be DMR 1.4.z included in WF 11 or also in next EAP 7 release? Most likely both. >> The idea of this new feature grew up while I was working on DMR-9 issue [2]. >> >> In short the news in upcoming JBoss DMR 1.4.0 are: >> * it will be compilable on JDK8 and above >> * it will be 100% backward compatible on binary level with previous >> version >> * it replaces old cookcc based parser with new one based on DMR >> Streaming API >> * DMR parsing will be times faster with old model based API >> * new DMR streaming API is highly memory efficient and really very fast > > Nice results in attached spreadsheets. > >> One example on how to use new DMR streaming API can be seen here [3]. >> >> I believe this new DMR Streaming API will become very handy for many of us >> because it opens new opportunities to decrease memory and CPU usage in >> our core. >> >> At the moment in current prototype [4] I didn't touch DMR object model >> writing yet >> because new DMR Streaming API does not (and most probably will not) >> support pretty print feature >> (because of its focus on speed and efficiency). >> But I'm considering I might fix the object model writing flow when >> pretty print is off. >> Fixing it would speed it up significantly. Any objections? > > I think pretty print feature is need, at least in CLI for stuff like ':read-resource(recursive=true)' This is still done by the DOM-style API, correct Richard? (eom) > Rostislav > >> As a final note today I run few benchmarks (see attachments). >> Here are some outcomes from benchmark results in short: >> * Writing small DMR structures in DMR format is 2,4 times faster with >> new DMR streaming API >> * Writing small DMR structures in JSON format is 2,6 times faster with >> new DMR streaming API >> * Reading small DMR structures in DMR format is 3,9 times faster with >> old DMR object model API >> * Reading small DMR structures in JSON format is 3,7 times faster with >> old DMR object model API >> * Reading small DMR structures in DMR format is 5 times faster with >> new DMR streaming API >> * Reading small DMR structures in JSON format is 4,4 times faster with >> new DMR streaming API >> * Reading big DMR structures in DMR format is 5,2 times faster with >> old DMR object model API >> * Reading big DMR structures in JSON format is 6 times faster with old >> DMR object model API >> * Reading big DMR structures in DMR format is 7,6 times faster with >> new DMR streaming API >> * Reading big DMR structures in JSON format is 8,8 times faster with >> new DMR streaming API >> >> PS: Hopefully new DMR streaming API will seamlessly integrate with GWT >> (used in our console). >> >> [1] >> https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream >> [2] https://issues.jboss.org/browse/DMR-9 >> [3] >> https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java >> [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 >> >> Regards, >> >> -- >> Richard Opalka >> Principal Software Engineer >> JBoss by Red Hat >> Mobile: +420 731 186 942 >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From ropalka at redhat.com Tue Jun 14 08:27:24 2016 From: ropalka at redhat.com (Richard Opalka) Date: Tue, 14 Jun 2016 14:27:24 +0200 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <575FE9D2.7050803@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> <681608415.6061264.1465902080061.JavaMail.zimbra@redhat.com> <575FE9D2.7050803@redhat.com> Message-ID: <593dc4a5-1eec-f4bf-f2f6-2f6f5c726dac@redhat.com> On 06/14/2016 01:26 PM, David M. Lloyd wrote: > On 06/14/2016 06:01 AM, Rostislav Svoboda wrote: >>> Hi All, >>> >>> The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - >>> see attachment. >> Will be DMR 1.4.z included in WF 11 or also in next EAP 7 release? > Most likely both. > >>> The idea of this new feature grew up while I was working on DMR-9 issue [2]. >>> >>> In short the news in upcoming JBoss DMR 1.4.0 are: >>> * it will be compilable on JDK8 and above >>> * it will be 100% backward compatible on binary level with previous >>> version >>> * it replaces old cookcc based parser with new one based on DMR >>> Streaming API >>> * DMR parsing will be times faster with old model based API >>> * new DMR streaming API is highly memory efficient and really very fast >> Nice results in attached spreadsheets. >> >>> One example on how to use new DMR streaming API can be seen here [3]. >>> >>> I believe this new DMR Streaming API will become very handy for many of us >>> because it opens new opportunities to decrease memory and CPU usage in >>> our core. >>> >>> At the moment in current prototype [4] I didn't touch DMR object model >>> writing yet >>> because new DMR Streaming API does not (and most probably will not) >>> support pretty print feature >>> (because of its focus on speed and efficiency). >>> But I'm considering I might fix the object model writing flow when >>> pretty print is off. >>> Fixing it would speed it up significantly. Any objections? >> I think pretty print feature is need, at least in CLI for stuff like ':read-resource(recursive=true)' > This is still done by the DOM-style API, correct Richard? Right. > > (eom) > >> Rostislav >> >>> As a final note today I run few benchmarks (see attachments). >>> Here are some outcomes from benchmark results in short: >>> * Writing small DMR structures in DMR format is 2,4 times faster with >>> new DMR streaming API >>> * Writing small DMR structures in JSON format is 2,6 times faster with >>> new DMR streaming API >>> * Reading small DMR structures in DMR format is 3,9 times faster with >>> old DMR object model API >>> * Reading small DMR structures in JSON format is 3,7 times faster with >>> old DMR object model API >>> * Reading small DMR structures in DMR format is 5 times faster with >>> new DMR streaming API >>> * Reading small DMR structures in JSON format is 4,4 times faster with >>> new DMR streaming API >>> * Reading big DMR structures in DMR format is 5,2 times faster with >>> old DMR object model API >>> * Reading big DMR structures in JSON format is 6 times faster with old >>> DMR object model API >>> * Reading big DMR structures in DMR format is 7,6 times faster with >>> new DMR streaming API >>> * Reading big DMR structures in JSON format is 8,8 times faster with >>> new DMR streaming API >>> >>> PS: Hopefully new DMR streaming API will seamlessly integrate with GWT >>> (used in our console). >>> >>> [1] >>> https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream >>> [2] https://issues.jboss.org/browse/DMR-9 >>> [3] >>> https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java >>> [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 >>> >>> Regards, >>> >>> -- >>> Richard Opalka >>> Principal Software Engineer >>> JBoss by Red Hat >>> Mobile: +420 731 186 942 >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> Rio From ken at zaptillion.net Tue Jun 14 10:31:49 2016 From: ken at zaptillion.net (Ken Wills) Date: Tue, 14 Jun 2016 09:31:49 -0500 Subject: [wildfly-dev] Wildfly Provisioning In-Reply-To: References: Message-ID: On Tue, Jun 14, 2016 at 3:53 AM, Stuart Douglas wrote: > Hi Everyone, > > Recently a few of us had a meeting to discuss a new provisioning/patching > system for Wildfly. I have written up the notes for this meeting which are > at [1]. > > The document contains the full details, but the basic idea is to design a > provisioning/patching/package management system for Wildfly and downstream > products. This will not be based on our existing patching or feature pack > code, but should take over the responsibilities of both. > > Obviously this is still in the early stages, and any feedback is welcome. > > Stuart > > [1] > https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc > > Hi Stuart, Thanks for the doc! It wasn't quite clear to me from the 'Multiple FS Locations', section, but would the provisioning tool take a list of installed servers and attempt the same operation on them all (for example applying a the relevant patch to each individual server), or is it expected to operate on one server at a time? Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160614/752e2271/attachment-0001.html From stuart.w.douglas at gmail.com Tue Jun 14 10:40:12 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 14 Jun 2016 14:40:12 +0000 Subject: [wildfly-dev] Wildfly Provisioning In-Reply-To: References: Message-ID: One server at a time. The multiple locations thing basically means that unlike yum etc it is possible to install two instances in different locations. Actions taken by the till only apply to the current location. On Tue, 14 Jun 2016, 22:31 Ken Wills wrote: > On Tue, Jun 14, 2016 at 3:53 AM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> Hi Everyone, >> >> Recently a few of us had a meeting to discuss a new provisioning/patching >> system for Wildfly. I have written up the notes for this meeting which are >> at [1]. >> > > >> The document contains the full details, but the basic idea is to design a >> provisioning/patching/package management system for Wildfly and downstream >> products. This will not be based on our existing patching or feature pack >> code, but should take over the responsibilities of both. >> >> Obviously this is still in the early stages, and any feedback is welcome. >> >> Stuart >> >> [1] >> https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc >> >> Hi Stuart, > > Thanks for the doc! > > It wasn't quite clear to me from the 'Multiple FS Locations', section, but > would the provisioning tool take a list of installed servers and attempt > the same operation on them all (for example applying a the relevant patch > to each individual server), or is it expected to operate on one server at a > time? > > Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160614/b83d7c2d/attachment.html From psotirop at redhat.com Tue Jun 14 10:58:44 2016 From: psotirop at redhat.com (Panagiotis Sotiropoulos) Date: Tue, 14 Jun 2016 10:58:44 -0400 (EDT) Subject: [wildfly-dev] Could a wildlfy jira be reviewed, if possible? In-Reply-To: <57600374.9000500@redhat.com> References: <1207395659.101928451.1465825319720.JavaMail.zimbra@redhat.com> <3b24395c-1473-0022-b2d8-c56a1f78dc84@redhat.com> <57600374.9000500@redhat.com> Message-ID: <1925152538.102326313.1465916324831.JavaMail.zimbra@redhat.com> Hello, How about removing the "ear exclusion" line (https://github.com/wildfly/wildfly-core/pull/1317/files#diff-9ed4135f0f37784ca6a099e1f035ceddR72) and keeping the rule of not adding the Service Activator files in the parent modules of the ones where the Service Activator classes are included? That means closing https://issues.jboss.org/browse/WFCORE-1234 and keeping https://issues.jboss.org/browse/WFCORE-1235. Regards, Panagiotis ----- Original Message ----- From: "David M. Lloyd" To: "Stuart Douglas" , "Brian Stansberry" Cc: "Jason T. Greene" , "Panagiotis Sotiropoulos" Sent: Tuesday, June 14, 2016 3:15:32 PM Subject: Re: Could a wildlfy jira be reviewed, if possible? True but this is not ideal because instantiating the activator might have side-effects. I think looking in VFS is the right way to do this. On 06/13/2016 07:11 PM, Stuart Douglas wrote: > I guess there is a slightly more hacky way to approach this where you > just ensure that the resulting ServiceActivator's ClassLoader is the > same as the module class loader, although this will result in > ServiceActivators being instantiated multiple times but then not > actually used. > > Stuart > > On Tue, Jun 14, 2016 at 10:09 AM, Stuart Douglas wrote: >> Firstly the PR itself is crap, just checking if the deployment name >> ends with ".ear" is not the correct way to do things, and it does not >> even fix the underlying problem (which is caused by ServiceActivator >> files being visible from multiple deployments). >> >> I think your interpretation of what the semantics should be is >> correct. I think the only real way to implement this however is to >> change from using Module.loadServices() to using VFS based discovery >> to get more control over the loading process. >> >> Stuart >> >> On Tue, Jun 14, 2016 at 1:08 AM, Brian Stansberry >> wrote: >>> Hi David, Jason, Stuart: >>> >>> We need to decide how to deal with these PRs. AIUI that means deciding what >>> are the supported semantics and then what changes are needed to meet those. >>> >>> IMO it seems like the semantics should be simple. For each >>> META-INF/services/org.jboss.msc.service.ServiceActivator file in the overall >>> deployment, the service gets activated once and only once. If there are 2 >>> such files that install the same service, we execute both, there's a >>> DuplicateServiceException, and the user fixes their deployment. >>> >>> On 6/13/16 8:41 AM, Panagiotis Sotiropoulos wrote: >>>> >>>> Hello Mr Brian, >>>> >>>> Could you please review https://issues.jboss.org/browse/WFCORE-1235, >>>> https://issues.jboss.org/browse/WFCORE-1234 (they have the same PR). It is >>>> related to https://bugzilla.redhat.com/show_bug.cgi?id=1286272 (which is >>>> related to https://bugzilla.redhat.com/show_bug.cgi?id=1292044 (VERIFIED)). >>>> >>>> Thank you in advance. >>>> >>>> Best Regards, >>>> Panagiotis Sotiropoulos >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat -- - DML From kabir.khan at jboss.com Tue Jun 14 11:42:04 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 14 Jun 2016 17:42:04 +0200 Subject: [wildfly-dev] Wildfly Provisioning In-Reply-To: References: Message-ID: "It should be possible for a layered product to modify and override the base installation." Can there be more than one layered product? If they are, are they "siblings", or on top of each other? If they are "siblings" and two override the same thing, who wins? I think if they are on top of each other, then there isn't really a problem. > On 14 Jun 2016, at 16:40, Stuart Douglas wrote: > > One server at a time. The multiple locations thing basically means that unlike yum etc it is possible to install two instances in different locations. Actions taken by the till only apply to the current location. > > > On Tue, 14 Jun 2016, 22:31 Ken Wills wrote: > On Tue, Jun 14, 2016 at 3:53 AM, Stuart Douglas wrote: > Hi Everyone, > > Recently a few of us had a meeting to discuss a new provisioning/patching system for Wildfly. I have written up the notes for this meeting which are at [1]. > > The document contains the full details, but the basic idea is to design a provisioning/patching/package management system for Wildfly and downstream products. This will not be based on our existing patching or feature pack code, but should take over the responsibilities of both. > > Obviously this is still in the early stages, and any feedback is welcome. > > Stuart > > [1] https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc > > Hi Stuart, > > Thanks for the doc! > > It wasn't quite clear to me from the 'Multiple FS Locations', section, but would the provisioning tool take a list of installed servers and attempt the same operation on them all (for example applying a the relevant patch to each individual server), or is it expected to operate on one server at a time? > > Ken > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Tue Jun 14 18:27:51 2016 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 14 Jun 2016 17:27:51 -0500 Subject: [wildfly-dev] Wildfly Provisioning In-Reply-To: References: Message-ID: <2C8AF232-474E-4D64-B454-019DE3ADFC32@redhat.com> That?s a good question. We never specified what happens in sibling relationships with conflicts. Not everything can form a perfect inheritance hierarchy, so we need a strategy to deal with the problem. My thinking is to follow install order. So we would say hierarchy is the first preference, followed by install order of the feature pack. > On Jun 14, 2016, at 10:42 AM, Kabir Khan wrote: > > "It should be possible for a layered product to modify and override the base installation." > > Can there be more than one layered product? If they are, are they "siblings", or on top of each other? If they are "siblings" and two override the same thing, who wins? I think if they are on top of each other, then there isn't really a problem. >> On 14 Jun 2016, at 16:40, Stuart Douglas wrote: >> >> One server at a time. The multiple locations thing basically means that unlike yum etc it is possible to install two instances in different locations. Actions taken by the till only apply to the current location. >> >> >> On Tue, 14 Jun 2016, 22:31 Ken Wills wrote: >> On Tue, Jun 14, 2016 at 3:53 AM, Stuart Douglas wrote: >> Hi Everyone, >> >> Recently a few of us had a meeting to discuss a new provisioning/patching system for Wildfly. I have written up the notes for this meeting which are at [1]. >> >> The document contains the full details, but the basic idea is to design a provisioning/patching/package management system for Wildfly and downstream products. This will not be based on our existing patching or feature pack code, but should take over the responsibilities of both. >> >> Obviously this is still in the early stages, and any feedback is welcome. >> >> Stuart >> >> [1] https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc >> >> Hi Stuart, >> >> Thanks for the doc! >> >> It wasn't quite clear to me from the 'Multiple FS Locations', section, but would the provisioning tool take a list of installed servers and attempt the same operation on them all (for example applying a the relevant patch to each individual server), or is it expected to operate on one server at a time? >> >> Ken >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From stuart.w.douglas at gmail.com Tue Jun 14 19:01:53 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 15 Jun 2016 09:01:53 +1000 Subject: [wildfly-dev] Wildfly Provisioning In-Reply-To: <2C8AF232-474E-4D64-B454-019DE3ADFC32@redhat.com> References: <2C8AF232-474E-4D64-B454-019DE3ADFC32@redhat.com> Message-ID: This makes sense to me, although install order in this case should actually mean 'the order they are listed in the provisioning file'. Stuart On Wed, Jun 15, 2016 at 8:27 AM, Jason Greene wrote: > That?s a good question. We never specified what happens in sibling > relationships with conflicts. Not everything can form a perfect inheritance > hierarchy, so we need a strategy to deal with the problem. My thinking is > to follow install order. So we would say hierarchy is the first preference, > followed by install order of the feature pack. > > > On Jun 14, 2016, at 10:42 AM, Kabir Khan wrote: > > > > "It should be possible for a layered product to modify and override the > base installation." > > > > Can there be more than one layered product? If they are, are they > "siblings", or on top of each other? If they are "siblings" and two > override the same thing, who wins? I think if they are on top of each > other, then there isn't really a problem. > >> On 14 Jun 2016, at 16:40, Stuart Douglas > wrote: > >> > >> One server at a time. The multiple locations thing basically means that > unlike yum etc it is possible to install two instances in different > locations. Actions taken by the till only apply to the current location. > >> > >> > >> On Tue, 14 Jun 2016, 22:31 Ken Wills wrote: > >> On Tue, Jun 14, 2016 at 3:53 AM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> Hi Everyone, > >> > >> Recently a few of us had a meeting to discuss a new > provisioning/patching system for Wildfly. I have written up the notes for > this meeting which are at [1]. > >> > >> The document contains the full details, but the basic idea is to design > a provisioning/patching/package management system for Wildfly and > downstream products. This will not be based on our existing patching or > feature pack code, but should take over the responsibilities of both. > >> > >> Obviously this is still in the early stages, and any feedback is > welcome. > >> > >> Stuart > >> > >> [1] > https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc > >> > >> Hi Stuart, > >> > >> Thanks for the doc! > >> > >> It wasn't quite clear to me from the 'Multiple FS Locations', section, > but would the provisioning tool take a list of installed servers and > attempt the same operation on them all (for example applying a the relevant > patch to each individual server), or is it expected to operate on one > server at a time? > >> > >> Ken > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160615/5f647727/attachment-0001.html From kabir.khan at jboss.com Wed Jun 15 17:19:56 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 15 Jun 2016 23:19:56 +0200 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars Message-ID: I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method. The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously, but on the other hand having notification handlers mess around with the model seems a bit strange as well. From kabir.khan at jboss.com Thu Jun 16 04:29:01 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 16 Jun 2016 10:29:01 +0200 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: References: Message-ID: <77D9F6A4-F759-41F7-A1F1-D3092FA5F889@jboss.com> > On 15 Jun 2016, at 23:19, Kabir Khan wrote: > > I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars > > My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method. The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously, Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the above isn't 100% true > but on the other hand having notification handlers mess around with the model seems a bit strange as well. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Thu Jun 16 04:29:53 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 16 Jun 2016 10:29:53 +0200 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: <77D9F6A4-F759-41F7-A1F1-D3092FA5F889@jboss.com> References: <77D9F6A4-F759-41F7-A1F1-D3092FA5F889@jboss.com> Message-ID: > On 16 Jun 2016, at 10:29, Kabir Khan wrote: > > >> On 15 Jun 2016, at 23:19, Kabir Khan wrote: >> >> I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars >> >> My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method. The only reason this is there is it was there in Brian's original draft. I think I'd like to remove it for now >> The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously, > Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the above isn't 100% true >> but on the other hand having notification handlers mess around with the model seems a bit strange as well. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From kabir.khan at jboss.com Thu Jun 16 09:42:48 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 16 Jun 2016 15:42:48 +0200 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: References: <77D9F6A4-F759-41F7-A1F1-D3092FA5F889@jboss.com> Message-ID: <1248CA3F-A776-4325-91C2-CF784BAACC5E@jboss.com> > On 16 Jun 2016, at 10:29, Kabir Khan wrote: > > >> On 16 Jun 2016, at 10:29, Kabir Khan wrote: >> >> >>> On 15 Jun 2016, at 23:19, Kabir Khan wrote: >>> >>> I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars >>> >>> My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method. > The only reason this is there is it was there in Brian's original draft. I think I'd like to remove it for now Unless the intent is to do something along the lines of when something happens in subsystem A to modify some resources elsewhere? >>> The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously, >> Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the above isn't 100% true >>> but on the other hand having notification handlers mess around with the model seems a bit strange as well. >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mazz at redhat.com Thu Jun 16 09:46:24 2016 From: mazz at redhat.com (John Mazzitelli) Date: Thu, 16 Jun 2016 09:46:24 -0400 (EDT) Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: References: Message-ID: <1330721449.7057663.1466084784264.JavaMail.zimbra@redhat.com> > I have written up analysis/design notes for the new notification registrar mechanism at > https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars I posted this question on that wiki page as a comment, but I'll ask here: It says, "We do not support remote management notifications yet, so all registered notification handlers need to be in-vm." I just want to be clear - this proposal does not address this issue of remote notifications, correct? This is still strictly for in-vm notifications from what I understand. From kabir.khan at jboss.com Thu Jun 16 10:03:30 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 16 Jun 2016 16:03:30 +0200 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: <1330721449.7057663.1466084784264.JavaMail.zimbra@redhat.com> References: <1330721449.7057663.1466084784264.JavaMail.zimbra@redhat.com> Message-ID: <67193A18-5D4D-494E-82E9-F22C56C5A53B@jboss.com> > On 16 Jun 2016, at 15:46, John Mazzitelli wrote: > >> I have written up analysis/design notes for the new notification registrar mechanism at >> https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars > > I posted this question on that wiki page as a comment, but I'll ask here: > > It says, "We do not support remote management notifications yet, so all registered notification handlers need to be in-vm." > > I just want to be clear - this proposal does not address this issue of remote notifications, correct? This is still strictly for in-vm notifications from what I understand. Correct, just an easier/nicer way to register in-vm notifications > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ropalka at redhat.com Thu Jun 16 18:28:28 2016 From: ropalka at redhat.com (Richard Opalka) Date: Fri, 17 Jun 2016 00:28:28 +0200 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> Message-ID: Hi All, Important note I forgot to mention, replacing old cookcc based parser introduces API incompatibility, because JSONParser, Parser and JSONParserImpl were public classes in DMR 1.3.0.Final. I optimized DOM API write process in 'compact' mode as mentioned in previous mail. Finally attached are up2date benchmarks against PR [1]. DMR 1.4.0.Beta is faster on all benchmarks comparing to DMR 1.3.0.Final. Concretely: * Writing small DMR structures in DMR format is 1,3 times faster with DOM API * Writing small DMR structures in JSON format is 1,4 times faster with DOM API * Writing small DMR structures in DMR format is 2,5 times faster with streaming API * Writing small DMR structures in JSON format is 2,6 times faster with streaming API * Reading small DMR structures in DMR format is 4 times faster with DOM API * Reading small DMR structures in JSON format is 3,7 times faster with DOM API * Reading small DMR structures in DMR format is 4,9 times faster with Streaming API * Reading small DMR structures in JSON format is 4,4 times faster with Streaming API * Reading big DMR documents in DMR format is 5,7 times faster with DOM API * Reading big DMR documents in JSON format is 6,4 times faster with DOM API * Reading big DMR documents in DMR format is 7,4 times faster with Streaming API * Reading big DMR documents in JSON format is 8,8 times faster with Streaming API [1] https://github.com/jbossas/jboss-dmr/pull/20 On 06/13/2016 11:48 PM, Richard Opalka wrote: > Hi All, > > The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - > see attachment. > > The idea of this new feature grew up while I was working on DMR-9 > issue [2]. > > In short the news in upcoming JBoss DMR 1.4.0 are: > * it will be compilable on JDK8 and above > * it will be 100% backward compatible on binary level with previous > version > * it replaces old cookcc based parser with new one based on DMR > Streaming API > * DMR parsing will be times faster with old model based API > * new DMR streaming API is highly memory efficient and really very fast > > One example on how to use new DMR streaming API can be seen here [3]. > > I believe this new DMR Streaming API will become very handy for many > of us > because it opens new opportunities to decrease memory and CPU usage in > our core. > > At the moment in current prototype [4] I didn't touch DMR object model > writing yet > because new DMR Streaming API does not (and most probably will not) > support pretty print feature > (because of its focus on speed and efficiency). > But I'm considering I might fix the object model writing flow when > pretty print is off. > Fixing it would speed it up significantly. Any objections? > > As a final note today I run few benchmarks (see attachments). > Here are some outcomes from benchmark results in short: > * Writing small DMR structures in DMR format is 2,4 times faster with > new DMR streaming API > * Writing small DMR structures in JSON format is 2,6 times faster > with new DMR streaming API > * Reading small DMR structures in DMR format is 3,9 times faster with > old DMR object model API > * Reading small DMR structures in JSON format is 3,7 times faster > with old DMR object model API > * Reading small DMR structures in DMR format is 5 times faster with > new DMR streaming API > * Reading small DMR structures in JSON format is 4,4 times faster > with new DMR streaming API > * Reading big DMR structures in DMR format is 5,2 times faster with > old DMR object model API > * Reading big DMR structures in JSON format is 6 times faster with > old DMR object model API > * Reading big DMR structures in DMR format is 7,6 times faster with > new DMR streaming API > * Reading big DMR structures in JSON format is 8,8 times faster with > new DMR streaming API > > PS: Hopefully new DMR streaming API will seamlessly integrate with GWT > (used in our console). > > [1] > https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream > [2] https://issues.jboss.org/browse/DMR-9 > [3] > https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java > [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 > > Regards, > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160617/9409fdc8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: JBoss-DMR-Big-Structure-Benchmarks.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 28245 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160617/9409fdc8/attachment-0002.ods -------------- next part -------------- A non-text attachment was scrubbed... Name: JBoss-DMR-Small-Structure-Benchmarks.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 40996 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160617/9409fdc8/attachment-0003.ods From brian.stansberry at redhat.com Fri Jun 17 10:55:02 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 17 Jun 2016 07:55:02 -0700 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> Message-ID: <7ddff164-4dd7-d7e1-b9cc-168df13ed155@redhat.com> On 6/16/16 3:28 PM, Richard Opalka wrote: > Hi All, > > Important note I forgot to mention, replacing old cookcc based parser > > introduces API incompatibility, because JSONParser, Parser and > JSONParserImpl > > were public classes in DMR 1.3.0.Final. > Can we keep these around and @Deprecate them? For Parser and JSONParser I mean the actual current generated classes. If generating them is an issue I see no need to keep doing it. Deleting them isn't the end of the world but if it is simple to keep them it's nice to do a deprecate and then remove later. > I optimized DOM API write process in 'compact' mode as mentioned in > previous mail. > > Finally attached are up2date benchmarks against PR [1]. > > DMR 1.4.0.Beta is faster on all benchmarks comparing to DMR 1.3.0.Final. > > Concretely: > > * Writing small DMR structures in DMR format is 1,3 times faster with > DOM API > * Writing small DMR structures in JSON format is 1,4 times faster with > DOM API > * Writing small DMR structures in DMR format is 2,5 times faster with > streaming API > * Writing small DMR structures in JSON format is 2,6 times faster with > streaming API > * Reading small DMR structures in DMR format is 4 times faster with DOM > API > * Reading small DMR structures in JSON format is 3,7 times faster with > DOM API > * Reading small DMR structures in DMR format is 4,9 times faster with > Streaming API > * Reading small DMR structures in JSON format is 4,4 times faster with > Streaming API > > * Reading big DMR documents in DMR format is 5,7 times faster with DOM API > * Reading big DMR documents in JSON format is 6,4 times faster with DOM > API > * Reading big DMR documents in DMR format is 7,4 times faster with > Streaming API > * Reading big DMR documents in JSON format is 8,8 times faster with > Streaming API > > [1] https://github.com/jbossas/jboss-dmr/pull/20 > > On 06/13/2016 11:48 PM, Richard Opalka wrote: >> Hi All, >> >> The upcoming DMR 1.4.0 version will introduce DMR Streaming API [1] - >> see attachment. >> >> The idea of this new feature grew up while I was working on DMR-9 >> issue [2]. >> >> In short the news in upcoming JBoss DMR 1.4.0 are: >> * it will be compilable on JDK8 and above >> * it will be 100% backward compatible on binary level with previous >> version >> * it replaces old cookcc based parser with new one based on DMR >> Streaming API >> * DMR parsing will be times faster with old model based API >> * new DMR streaming API is highly memory efficient and really very fast >> >> One example on how to use new DMR streaming API can be seen here [3]. >> >> I believe this new DMR Streaming API will become very handy for many >> of us >> because it opens new opportunities to decrease memory and CPU usage in >> our core. >> >> At the moment in current prototype [4] I didn't touch DMR object model >> writing yet >> because new DMR Streaming API does not (and most probably will not) >> support pretty print feature >> (because of its focus on speed and efficiency). >> But I'm considering I might fix the object model writing flow when >> pretty print is off. >> Fixing it would speed it up significantly. Any objections? >> >> As a final note today I run few benchmarks (see attachments). >> Here are some outcomes from benchmark results in short: >> * Writing small DMR structures in DMR format is 2,4 times faster with >> new DMR streaming API >> * Writing small DMR structures in JSON format is 2,6 times faster >> with new DMR streaming API >> * Reading small DMR structures in DMR format is 3,9 times faster with >> old DMR object model API >> * Reading small DMR structures in JSON format is 3,7 times faster >> with old DMR object model API >> * Reading small DMR structures in DMR format is 5 times faster with >> new DMR streaming API >> * Reading small DMR structures in JSON format is 4,4 times faster >> with new DMR streaming API >> * Reading big DMR structures in DMR format is 5,2 times faster with >> old DMR object model API >> * Reading big DMR structures in JSON format is 6 times faster with >> old DMR object model API >> * Reading big DMR structures in DMR format is 7,6 times faster with >> new DMR streaming API >> * Reading big DMR structures in JSON format is 8,8 times faster with >> new DMR streaming API >> >> PS: Hopefully new DMR streaming API will seamlessly integrate with GWT >> (used in our console). >> >> [1] >> https://github.com/ropalka/jboss-dmr/tree/DMR-9/src/main/java/org/jboss/dmr/stream >> [2] https://issues.jboss.org/browse/DMR-9 >> [3] >> https://github.com/ropalka/jboss-dmr/blob/DMR-9/src/main/java/org/jboss/dmr/ModelNodeFactory.java >> [4] https://github.com/ropalka/jboss-dmr/commits/DMR-9 >> >> Regards, >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Richard Opalka > Principal Software Engineer > JBoss by Red Hat > Mobile: +420 731 186 942 > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Fri Jun 17 11:23:18 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 17 Jun 2016 10:23:18 -0500 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <7ddff164-4dd7-d7e1-b9cc-168df13ed155@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> <7ddff164-4dd7-d7e1-b9cc-168df13ed155@redhat.com> Message-ID: <576415E6.7070109@redhat.com> On 06/17/2016 09:55 AM, Brian Stansberry wrote: > On 6/16/16 3:28 PM, Richard Opalka wrote: >> Hi All, >> >> Important note I forgot to mention, replacing old cookcc based parser >> >> introduces API incompatibility, because JSONParser, Parser and >> JSONParserImpl >> >> were public classes in DMR 1.3.0.Final. >> > > Can we keep these around and @Deprecate them? > > For Parser and JSONParser I mean the actual current generated classes. > If generating them is an issue I see no need to keep doing it. > > Deleting them isn't the end of the world but if it is simple to keep > them it's nice to do a deprecate and then remove later. It may be possible to create compatible stubs. -- - DML From brian.stansberry at redhat.com Fri Jun 17 17:38:14 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 17 Jun 2016 16:38:14 -0500 Subject: [wildfly-dev] WFCORE-1405 - Notification Registrars In-Reply-To: <1248CA3F-A776-4325-91C2-CF784BAACC5E@jboss.com> References: <77D9F6A4-F759-41F7-A1F1-D3092FA5F889@jboss.com> <1248CA3F-A776-4325-91C2-CF784BAACC5E@jboss.com> Message-ID: <6e829b29-9e57-ea58-dc24-f84bd2752473@redhat.com> On 6/16/16 8:42 AM, Kabir Khan wrote: > >> On 16 Jun 2016, at 10:29, Kabir Khan wrote: >> >> >>> On 16 Jun 2016, at 10:29, Kabir Khan wrote: >>> >>> >>>> On 15 Jun 2016, at 23:19, Kabir Khan wrote: >>>> >>>> I have written up analysis/design notes for the new notification registrar mechanism at https://developer.jboss.org/wiki/DesignNotesForAbilityToRegisterAListenerintegratedWithTheManagementLayerThatWillBeNotifiedOfTheLifecycleServerEventsNotificationRegistrars >>>> >>>> My main doubt is about the usefulness of the NotificationRegistrarContext.getModelControllerClient() method. >> The only reason this is there is it was there in Brian's original draft. I think I'd like to remove it for now > Unless the intent is to do something along the lines of when something happens in subsystem A to modify some resources elsewhere? The reason for this is just that the only reason to receive a notification is to in turn take some action. So unless whatever they want to do has nothing to do with the rest of the system, they must: 1) Update the state of the MBeanServer, affecting JMX domains other than jboss.as[.expr]. This kind of thing is what was specifically mentioned by users in some of the discussions that led to this. 2) Take some action affecting the management resources, either via the ModelController or via the jboss.as[.expr] mbeans. Perhaps deploy something or... 3) Hack at MSC services via something like CurrentServiceContainer. 4) Update some state stored in static fields, which can then be read by other code of theirs that has access to the field. I think it's ok to not support 2) for now; we can see if people ask for it with a concrete use case. That said I think it's not good if we can't support it by making these notifications truly asynchronous to the operation that spawns them. Not providing a ModelControllerClient isn't going to block people using the jboss.as[.expr] mbeans, so the problem still exists, it's just more hidden. We don't want people doing 3) as its not a supported API. People who want to do that should write a subsystem. Same with 4) although at least there they aren't hacking our code, just their own. >>>> The NotificationRegistrarContext is used by NotificationRegistrar.registerNotificationListeners(), which in turn is called by a service's start() method. The service is installed by an add handler. Is my memory of calling the ModelControllerClient execute methods at this stage a bad thing correct? I mention that the MCC can be cached for later use by the handlers, which on one hand I think should be ok since the handlers are executed on asynchronously, >>> Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the above isn't 100% true >>>> but on the other hand having notification handlers mess around with the model seems a bit strange as well. >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ropalka at redhat.com Mon Jun 20 05:54:32 2016 From: ropalka at redhat.com (Richard Opalka) Date: Mon, 20 Jun 2016 11:54:32 +0200 Subject: [wildfly-dev] Support for DMR Streams In-Reply-To: <576415E6.7070109@redhat.com> References: <22be16c2-a5af-2737-43dd-b58059af1228@redhat.com> <7ddff164-4dd7-d7e1-b9cc-168df13ed155@redhat.com> <576415E6.7070109@redhat.com> Message-ID: On 06/17/2016 05:23 PM, David M. Lloyd wrote: > On 06/17/2016 09:55 AM, Brian Stansberry wrote: >> On 6/16/16 3:28 PM, Richard Opalka wrote: >>> Hi All, >>> >>> Important note I forgot to mention, replacing old cookcc based parser >>> >>> introduces API incompatibility, because JSONParser, Parser and >>> JSONParserImpl >>> >>> were public classes in DMR 1.3.0.Final. >>> >> Can we keep these around and @Deprecate them? >> >> For Parser and JSONParser I mean the actual current generated classes. >> If generating them is an issue I see no need to keep doing it. >> >> Deleting them isn't the end of the world but if it is simple to keep >> them it's nice to do a deprecate and then remove later. > It may be possible to create compatible stubs. Definitely we should maintain API compatibility: https://github.com/jbossas/jboss-dmr/pull/20/commits/dbf13f4e2f5d484643c7af22856119e8d209540a > -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 From kabir.khan at jboss.com Mon Jun 20 06:04:04 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 20 Jun 2016 11:04:04 +0100 Subject: [wildfly-dev] WFCORE-1157 Message-ID: Jeff and I were chatting about https://issues.jboss.org/browse/WFCORE-1157 last week. There is currently a PR (https://issues.jboss.org/browse/WFCORE-1157?devStatusDetailDialog=pullrequest) to allow listening on the ControlledProcessState state changes. This is done via users registering NotificationHandlers on the runtime-configuration-state. Since the notification handlers are executed asynchronously, there is no guarantee that e.g. on a stop that the notification handler is triggered for the 'stopping' and 'stopped' (the PR introduces this latter state) state changes since the server may be down before this happens. The PR works around this by making the controller execute the runtime-configuration-state handlers synchronously. However, this then means that the standard notifications and the runtime-configuration-state notifications end up being in separate streams, so that the 'stopping' handler may be invoked upon before the standard/async notification handlers reflecting earlier changes. In fact looking at this a bit closer, the NonBlockingNotificationSupport class uses a thread pool with several threads. This means that for the standard async notifications, it is very likely that the handler for notification1 gets invoked before notification2's handler, but is is _not_ guaranteed. If the thread processing notification1 is paused for whatever reason, notification2 may end up being handled first. Should we change the executor in NonBlockingNotificationSupport to be a single thread executor? Jeff also suggested, perhaps keeping the runtime-configuration-state notifications as asynchronous, but to add some constructs to make sure that these always get executed before server shutdown. This would keep the functionality from this PR where the notifications are always invoked, and also make sure that the order is preserved. From kabir.khan at jboss.com Mon Jun 20 06:08:41 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 20 Jun 2016 11:08:41 +0100 Subject: [wildfly-dev] WFCORE-1157 In-Reply-To: References: Message-ID: > On 20 Jun 2016, at 11:04, Kabir Khan wrote: > > Jeff and I were chatting about https://issues.jboss.org/browse/WFCORE-1157 last week. There is currently a PR (https://issues.jboss.org/browse/WFCORE-1157?devStatusDetailDialog=pullrequest) to allow listening on the ControlledProcessState state changes. This is done via users registering NotificationHandlers on the runtime-configuration-state. > > Since the notification handlers are executed asynchronously, there is no guarantee that e.g. on a stop that the notification handler is triggered for the 'stopping' and 'stopped' (the PR introduces this latter state) state changes since the server may be down before this happens. The PR works around this by making the controller execute the runtime-configuration-state handlers synchronously. However, this then means that the standard notifications and the runtime-configuration-state notifications end up being in separate streams, so that the 'stopping' handler may be invoked upon before the standard/async notification handlers reflecting earlier changes. > > In fact looking at this a bit closer, the NonBlockingNotificationSupport class uses a thread pool with several threads. This means that for the standard async notifications, it is very likely that the handler for notification1 gets invoked before notification2's handler, but is is _not_ guaranteed. If the thread processing notification1 is paused for whatever reason, notification2 may end up being handled first. Should we change the executor in NonBlockingNotificationSupport to be a single thread executor? > > Jeff also suggested, perhaps keeping the runtime-configuration-state notifications as asynchronous, but to add some constructs to make sure that these always get executed before server shutdown. This would keep the functionality from this PR where the notifications are always invoked, and also make sure that the order is preserved. There may be problems with this though. If e.g. one of the lifecycle handlers needs access to services etc. they may have been stopped before the stopped/stopping notifications are invoked. But that could perhaps already happen with the current sync approach (I need to look and refamiliariase myself) > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From sanne at hibernate.org Mon Jun 20 12:37:33 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 20 Jun 2016 17:37:33 +0100 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly Message-ID: Hi all, today trying to help some Hibernate users on SO I stumbled on a question regarding an application being developed with Spring - and apparently Spring Boot (?) - and deployed on WildFly. Clearly the poster is having duplicate Hibernate classes, or possibly mismatches with the version he's expecting vs the app server's expectations, or more likely a mismatch between the Hibernate ORM and Hibernate Search versions being loaded. I'm familiar with JipiJapa, but while this automates some things - like adding a module dependency to Hibernate ORM and/or Hibernate Search automatically - this logic is usually controlled by application settings in the `persistence.xml` and is aimed at standard JEE deployments - so I guess it might actually be interfering in this case. Beyond helping the specific question, do we have a general set of tests or recommendations - maybe some example template - for Spring Boot users on WildFly? Anyone maybe interested in contributing some Spring related examples? I've never used Spring myself but I guess I'd like to have a look to better understand what kind of issues such users might bump into, and what we could do to make it easier. Thanks, Sanne From ken at kenfinnigan.me Mon Jun 20 12:44:14 2016 From: ken at kenfinnigan.me (Ken Finnigan) Date: Mon, 20 Jun 2016 12:44:14 -0400 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: Sanne, Is he creating a Spring Boot war? I know that Spring Boot is used here -> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1.x-develop/spring-petclinic Ken On Mon, Jun 20, 2016 at 12:37 PM, Sanne Grinovero wrote: > Hi all, > > today trying to help some Hibernate users on SO I stumbled on a > question regarding an application being developed with Spring - and > apparently Spring Boot (?) - and deployed on WildFly. > > Clearly the poster is having duplicate Hibernate classes, or possibly > mismatches with the version he's expecting vs the app server's > expectations, or more likely a mismatch between the Hibernate ORM and > Hibernate Search versions being loaded. > > I'm familiar with JipiJapa, but while this automates some things - > like adding a module dependency to Hibernate ORM and/or Hibernate > Search automatically - this logic is usually controlled by application > settings in the `persistence.xml` and is aimed at standard JEE > deployments - so I guess it might actually be interfering in this > case. > > Beyond helping the specific question, do we have a general set of > tests or recommendations - maybe some example template - for Spring > Boot users on WildFly? > > Anyone maybe interested in contributing some Spring related examples? > > I've never used Spring myself but I guess I'd like to have a look to > better understand what kind of issues such users might bump into, and > what we could do to make it easier. > > Thanks, > Sanne > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160620/d73b42d6/attachment.html From tomaz.cerar at gmail.com Mon Jun 20 12:44:32 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 20 Jun 2016 18:44:32 +0200 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On Mon, Jun 20, 2016 at 6:37 PM, Sanne Grinovero wrote: > Beyond helping the specific question, do we have a general set of > tests or recommendations - maybe some example template - for Spring > Boot users on WildFly? > I would say that if users want to go spring full way, aka make spring mange hibernate/jpa stuff they should disable jpa subsystem all together as it will make it easier for them. Problem only occurs when they want to use "hybrid" aproach and use some spring & some EE in combination that can cause issues and is harder to get right wrt deps & configuration. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160620/28aa1bf9/attachment.html From brian.stansberry at redhat.com Mon Jun 20 15:48:00 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 20 Jun 2016 14:48:00 -0500 Subject: [wildfly-dev] WFCORE-1157 In-Reply-To: References: Message-ID: <87ff6804-9ec1-7402-2281-a5cffcb48cae@redhat.com> On 6/20/16 5:04 AM, Kabir Khan wrote: > Jeff and I were chatting about https://issues.jboss.org/browse/WFCORE-1157 last week. There is currently a PR (https://issues.jboss.org/browse/WFCORE-1157?devStatusDetailDialog=pullrequest) to allow listening on the ControlledProcessState state changes. This is done via users registering NotificationHandlers on the runtime-configuration-state. > > Since the notification handlers are executed asynchronously, there is no guarantee that e.g. on a stop that the notification handler is triggered for the 'stopping' and 'stopped' (the PR introduces this latter state) state changes since the server may be down before this happens. The PR works around this by making the controller execute the runtime-configuration-state handlers synchronously. However, this then means that the standard notifications and the runtime-configuration-state notifications end up being in separate streams, so that the 'stopping' handler may be invoked upon before the standard/async notification handlers reflecting earlier changes. > > In fact looking at this a bit closer, the NonBlockingNotificationSupport class uses a thread pool with several threads. This means that for the standard async notifications, it is very likely that the handler for notification1 gets invoked before notification2's handler, but is is _not_ guaranteed. If the thread processing notification1 is paused for whatever reason, notification2 may end up being handled first. Should we change the executor in NonBlockingNotificationSupport to be a single thread executor? > I think it's guaranteed. All notifications go into a single queue and then there is a lock that ensures only 1 thread at a time is processing that queue. You could skip the locking bit by using a single thread executor, but that means creating a new executor, cleaning it up properly on shutdown, and always having a thread in this pool, mostly doing nothing. > Jeff also suggested, perhaps keeping the runtime-configuration-state notifications as asynchronous, but to add some constructs to make sure that these always get executed before server shutdown. This would keep the functionality from this PR where the notifications are always invoked, and also make sure that the order is preserved. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jun 20 16:27:45 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 20 Jun 2016 15:27:45 -0500 Subject: [wildfly-dev] WFCORE-1157 In-Reply-To: References: Message-ID: On 6/20/16 5:08 AM, Kabir Khan wrote: > >> On 20 Jun 2016, at 11:04, Kabir Khan wrote: >> >> Jeff and I were chatting about https://issues.jboss.org/browse/WFCORE-1157 last week. There is currently a PR (https://issues.jboss.org/browse/WFCORE-1157?devStatusDetailDialog=pullrequest) to allow listening on the ControlledProcessState state changes. This is done via users registering NotificationHandlers on the runtime-configuration-state. >> >> Since the notification handlers are executed asynchronously, there is no guarantee that e.g. on a stop that the notification handler is triggered for the 'stopping' and 'stopped' (the PR introduces this latter state) state changes since the server may be down before this happens. The PR works around this by making the controller execute the runtime-configuration-state handlers synchronously. However, this then means that the standard notifications and the runtime-configuration-state notifications end up being in separate streams, so that the 'stopping' handler may be invoked upon before the standard/async notification handlers reflecting earlier changes. >> >> In fact looking at this a bit closer, the NonBlockingNotificationSupport class uses a thread pool with several threads. This means that for the standard async notifications, it is very likely that the handler for notification1 gets invoked before notification2's handler, but is is _not_ guaranteed. If the thread processing notification1 is paused for whatever reason, notification2 may end up being handled first. Should we change the executor in NonBlockingNotificationSupport to be a single thread executor? >> >> Jeff also suggested, perhaps keeping the runtime-configuration-state notifications as asynchronous, but to add some constructs to make sure that these always get executed before server shutdown. This would keep the functionality from this PR where the notifications are always invoked, and also make sure that the order is preserved. That sounds better than having some notifications mysteriously be sync and others async. But, as you say... > There may be problems with this though. If e.g. one of the lifecycle handlers needs access to services etc. they may have been stopped before the stopped/stopping notifications are invoked. But that could perhaps already happen with the current sync approach (I need to look and refamiliariase myself) I've copied Ramesh Reddy, as I think he may be one of the users of the existing sync notifications via ControlledProcessStateService. At least I believe I pointed him to that in the past. IIRC he would have wanted to get the notification before the services started shutting down, in order to use that knowledge in detecting whether services were stopping due to shutdown vs mgmt op initiated removal (e.g. undeploy.) Ramesh, is my memory correct? The existing ControlledProcessStateService stuff will result in a stopping notification being received before services shut down. The process state is changed and notifications emitted before the thread moves on to doing things that affect MSC. I think we need a bit of a rethink of this whole thing. We have some seemingly conflicting use cases, e.g. wanting sync notifications of lifecycle (or even startup completion if the user wants to racelessly change something before requests start being handled), and also wanting to make changes (e.g. with a ModelControllerClient) when those events happen, which sometimes must be done async to avoid deadlock. One thought I've had around this is whether a cmd line flag to start up suspended would help with some use cases. (I think that's a useful thing anyway for other uses.) With that a user can get a notification of "running" but the server is still suspended. So they can tweak whatever and then tip the server out of suspended state. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From sanne at hibernate.org Mon Jun 20 18:36:14 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 20 Jun 2016 23:36:14 +0100 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On 20 June 2016 at 17:44, Ken Finnigan wrote: > Sanne, > > Is he creating a Spring Boot war? > > I know that Spring Boot is used here -> > https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1.x-develop/spring-petclinic Thanks Ken, I'll experiment with that! I don't know if he's creating a WAR; I'd assume so as otherwise I don't understand how this would run on WildFly :) -- Sanne > > Ken > > > On Mon, Jun 20, 2016 at 12:37 PM, Sanne Grinovero > wrote: >> >> Hi all, >> >> today trying to help some Hibernate users on SO I stumbled on a >> question regarding an application being developed with Spring - and >> apparently Spring Boot (?) - and deployed on WildFly. >> >> Clearly the poster is having duplicate Hibernate classes, or possibly >> mismatches with the version he's expecting vs the app server's >> expectations, or more likely a mismatch between the Hibernate ORM and >> Hibernate Search versions being loaded. >> >> I'm familiar with JipiJapa, but while this automates some things - >> like adding a module dependency to Hibernate ORM and/or Hibernate >> Search automatically - this logic is usually controlled by application >> settings in the `persistence.xml` and is aimed at standard JEE >> deployments - so I guess it might actually be interfering in this >> case. >> >> Beyond helping the specific question, do we have a general set of >> tests or recommendations - maybe some example template - for Spring >> Boot users on WildFly? >> >> Anyone maybe interested in contributing some Spring related examples? >> >> I've never used Spring myself but I guess I'd like to have a look to >> better understand what kind of issues such users might bump into, and >> what we could do to make it easier. >> >> Thanks, >> Sanne >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From sanne at hibernate.org Mon Jun 20 18:45:32 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 20 Jun 2016 23:45:32 +0100 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On 20 June 2016 at 17:44, Toma? Cerar wrote: > > On Mon, Jun 20, 2016 at 6:37 PM, Sanne Grinovero > wrote: >> >> Beyond helping the specific question, do we have a general set of >> tests or recommendations - maybe some example template - for Spring >> Boot users on WildFly? > > > > I would say that if users want to go spring full way, aka make spring mange > hibernate/jpa stuff > they should disable jpa subsystem all together as it will make it easier for > them. Right I would suggest the same, but how can one disable it? The only options I know of to control Jipijapa are read from the `persistence.xml` resource file, which is missing in these cases as the Persistence Unit will typically be configured via some alternative strategy. The irony ;) > Problem only occurs when they want to use "hybrid" approach and use some > spring & some EE > in combination that can cause issues and is harder to get right wrt deps & > configuration. Spot on. This is why I'm interested, I think we could improve some things.. For example, as previously suggested on this list: one step would be for us to inspect the deployment and avoid injecting dependencies for things which are already included in the archives.. people will never master all the exclusion rules on Maven correctly, especially if the app server does some undocumented magic with dependencies. A very simple thing I'd like to do, is to not automatically add the module dependency for Hibernate when clearly an Hibernate implementation is included in the user's deployment. [This is just a wish though, as I doubt I'll have time soon to actually work on this]. BTW exploring more on SO today, I found there's actually quite a population of people trying to get Spring Boot working on Wildfly. Thanks, Sanne From tomaz.cerar at gmail.com Mon Jun 20 19:01:04 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 21 Jun 2016 01:01:04 +0200 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On Tue, Jun 21, 2016 at 12:45 AM, Sanne Grinovero wrote: > Right I would suggest the same, but how can one disable it? > The only options I know of to control Jipijapa are read from the > `persistence.xml` resource file, which is missing in these cases as > the Persistence Unit will typically be configured via some alternative > strategy. The irony ;) > Nah, completely disable it, reading persistence.xml is already part of jpa subsystem :) you can do that by either removing it from standalone.xml (/subsystem=jpa:remove;reload) or by adding jboss-deployment-structure.xml to deployment with content which disabled jpa subsystem completely for deployment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160621/60379d07/attachment.html From smarlow at redhat.com Mon Jun 20 21:49:56 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 20 Jun 2016 21:49:56 -0400 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On 06/20/2016 06:45 PM, Sanne Grinovero wrote: > On 20 June 2016 at 17:44, Toma? Cerar wrote: >> >> On Mon, Jun 20, 2016 at 6:37 PM, Sanne Grinovero >> wrote: >>> >>> Beyond helping the specific question, do we have a general set of >>> tests or recommendations - maybe some example template - for Spring >>> Boot users on WildFly? >> >> >> >> I would say that if users want to go spring full way, aka make spring mange >> hibernate/jpa stuff >> they should disable jpa subsystem all together as it will make it easier for >> them. > > Right I would suggest the same, but how can one disable it? > The only options I know of to control Jipijapa are read from the > `persistence.xml` resource file, which is missing in these cases as > the Persistence Unit will typically be configured via some alternative > strategy. The irony ;) You can also set jboss.as.jpa.managed=false in the persistence unit, which avoids the EE bootstrapping of the persistence unit. I'm not sure if https://docs.jboss.org/author/display/WFLY10/Spring+applications+development+and+migration+guide is up to date but that mentions using jpa-persistence.xml instead of persistence.xml (via Spring LocalContainerEntityManagerFactoryBean settings). > >> Problem only occurs when they want to use "hybrid" approach and use some >> spring & some EE >> in combination that can cause issues and is harder to get right wrt deps & >> configuration. > > Spot on. This is why I'm interested, I think we could improve some things.. > For example, as previously suggested on this list: one step would be > for us to inspect the deployment and avoid injecting dependencies for > things which are already included in the archives.. people will never > master all the exclusion rules on Maven correctly, especially if the > app server does some undocumented magic with dependencies. > > A very simple thing I'd like to do, is to not automatically add the > module dependency for Hibernate when clearly an Hibernate > implementation is included in the user's deployment. [This is just a > wish though, as I doubt I'll have time soon to actually work on this]. > > BTW exploring more on SO today, I found there's actually quite a > population of people trying to get Spring Boot working on Wildfly. > > Thanks, > Sanne > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From kabir.khan at jboss.com Tue Jun 21 04:55:45 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 21 Jun 2016 09:55:45 +0100 Subject: [wildfly-dev] WFCORE-1157 In-Reply-To: <87ff6804-9ec1-7402-2281-a5cffcb48cae@redhat.com> References: <87ff6804-9ec1-7402-2281-a5cffcb48cae@redhat.com> Message-ID: <5884345B-1E75-420D-AA31-26DC34301FD7@jboss.com> > On 20 Jun 2016, at 20:48, Brian Stansberry wrote: > > On 6/20/16 5:04 AM, Kabir Khan wrote: >> Jeff and I were chatting about https://issues.jboss.org/browse/WFCORE-1157 last week. There is currently a PR (https://issues.jboss.org/browse/WFCORE-1157?devStatusDetailDialog=pullrequest) to allow listening on the ControlledProcessState state changes. This is done via users registering NotificationHandlers on the runtime-configuration-state. >> >> Since the notification handlers are executed asynchronously, there is no guarantee that e.g. on a stop that the notification handler is triggered for the 'stopping' and 'stopped' (the PR introduces this latter state) state changes since the server may be down before this happens. The PR works around this by making the controller execute the runtime-configuration-state handlers synchronously. However, this then means that the standard notifications and the runtime-configuration-state notifications end up being in separate streams, so that the 'stopping' handler may be invoked upon before the standard/async notification handlers reflecting earlier changes. >> >> In fact looking at this a bit closer, the NonBlockingNotificationSupport class uses a thread pool with several threads. This means that for the standard async notifications, it is very likely that the handler for notification1 gets invoked before notification2's handler, but is is _not_ guaranteed. If the thread processing notification1 is paused for whatever reason, notification2 may end up being handled first. Should we change the executor in NonBlockingNotificationSupport to be a single thread executor? >> > > I think it's guaranteed. All notifications go into a single queue and > then there is a lock that ensures only 1 thread at a time is processing > that queue. Ah yes, I missed that. I was speculating on the code according to my memory from a few weeks ago! > > You could skip the locking bit by using a single thread executor, but > that means creating a new executor, cleaning it up properly on shutdown, > and always having a thread in this pool, mostly doing nothing. > >> Jeff also suggested, perhaps keeping the runtime-configuration-state notifications as asynchronous, but to add some constructs to make sure that these always get executed before server shutdown. This would keep the functionality from this PR where the notifications are always invoked, and also make sure that the order is preserved. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From emmanuel at hibernate.org Tue Jun 21 05:03:16 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 21 Jun 2016 11:03:16 +0200 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: <20160621090316.GH18153@hibernate.org> I'd recommend a quick blog post with Tomas and Scott options and the caveat on why it's better to let us run the show instead of taking over dependency puzzle management. On Mon 2016-06-20 21:49, Scott Marlow wrote: > > > On 06/20/2016 06:45 PM, Sanne Grinovero wrote: > > On 20 June 2016 at 17:44, Toma? Cerar wrote: > >> > >> On Mon, Jun 20, 2016 at 6:37 PM, Sanne Grinovero > >> wrote: > >>> > >>> Beyond helping the specific question, do we have a general set of > >>> tests or recommendations - maybe some example template - for Spring > >>> Boot users on WildFly? > >> > >> > >> > >> I would say that if users want to go spring full way, aka make spring mange > >> hibernate/jpa stuff > >> they should disable jpa subsystem all together as it will make it easier for > >> them. > > > > Right I would suggest the same, but how can one disable it? > > The only options I know of to control Jipijapa are read from the > > `persistence.xml` resource file, which is missing in these cases as > > the Persistence Unit will typically be configured via some alternative > > strategy. The irony ;) > > You can also set jboss.as.jpa.managed=false in the persistence unit, > which avoids the EE bootstrapping of the persistence unit. > > I'm not sure if > https://docs.jboss.org/author/display/WFLY10/Spring+applications+development+and+migration+guide > is up to date but that mentions using jpa-persistence.xml instead of > persistence.xml (via Spring LocalContainerEntityManagerFactoryBean > settings). > > > > >> Problem only occurs when they want to use "hybrid" approach and use some > >> spring & some EE > >> in combination that can cause issues and is harder to get right wrt deps & > >> configuration. > > > > Spot on. This is why I'm interested, I think we could improve some things.. > > For example, as previously suggested on this list: one step would be > > for us to inspect the deployment and avoid injecting dependencies for > > things which are already included in the archives.. people will never > > master all the exclusion rules on Maven correctly, especially if the > > app server does some undocumented magic with dependencies. > > > > A very simple thing I'd like to do, is to not automatically add the > > module dependency for Hibernate when clearly an Hibernate > > implementation is included in the user's deployment. [This is just a > > wish though, as I doubt I'll have time soon to actually work on this]. > > > > BTW exploring more on SO today, I found there's actually quite a > > population of people trying to get Spring Boot working on Wildfly. > > > > Thanks, > > Sanne > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Tue Jun 21 09:23:58 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 21 Jun 2016 09:23:58 -0400 Subject: [wildfly-dev] Hibernate & Spring Boot on WildFly In-Reply-To: References: Message-ID: On 06/20/2016 12:44 PM, Toma? Cerar wrote: > > On Mon, Jun 20, 2016 at 6:37 PM, Sanne Grinovero > wrote: > > Beyond helping the specific question, do we have a general set of > tests or recommendations - maybe some example template - for Spring > Boot users on WildFly? > > > > I would say that if users want to go spring full way, aka make spring > mange hibernate/jpa stuff > they should disable jpa subsystem all together as it will make it easier > for them. +1. They have more than one way to deal with this but yeah, disabling the EE JPA container could be right for them. > > Problem only occurs when they want to use "hybrid" aproach and use some > spring & some EE > in combination that can cause issues and is harder to get right wrt deps > & configuration. > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Tue Jun 21 16:39:37 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 21 Jun 2016 15:39:37 -0500 Subject: [wildfly-dev] Module slots may be deprecated Message-ID: <5769A609.2010406@redhat.com> Java 9 modules do not have a concept of a slot, and are identified only by name. On the other hand, the module slot in JBoss Modules is essentially an extension of the name, and is used mainly as a helper to name parsing for things like the filesystem module loader to allow easy multi-version or parallel installation support. A few projects use slots for other purposes. In many module loaders, slots are not used at all and are allowed to default to "main". Among the changes coming to JBoss Modules for Java 9, my current plan for this is to migrate towards the Java 9 way of doing things and support only a general name field. For compatibility purposes, the ModuleIdentifier API will continue to function, until/unless it is clear that all major users have migrated off of it. It will work as a frontend to plain String names - a ModuleIdentifier with name "name" and slot "slot" will be translated behind the scenes as a module named "name:slot". A module with a slot of "main" will be translated as just "name". A simple character escaping scheme will be employed to ensure that there is a lossless two-way mapping from plain names to ModuleIdentifier-style names, in the event that there is a ':' in the name part of the ModuleIdentifier, though in practice this may not come up much. The existing module loaders can continue to function more or less as they are. For filesystem modules using module.xml, the slot could still be used by way of the compatibility syntax scheme above. The filesystem module loader will continue to use the same file name mapping scheme for now, using the aforementioned compatibility scheme to achieve the same effect that slots do now; we can look at ways to transition off of that later if it proves necessary to do so. The deployment module loader in WildFly can be transitioned to using plain names easily, and this can probably be done at any time. We can keep WildFly management APIs which reference modules as they are for now - if a slot is present, it could simply be appended to the given module name after a dividing ":", otherwise the module name is used as-is. The slot attributes could be deprecated at any time. Overall though I think the best way of approaching the change is that we start thinking of "name:slot" as merely a ModuleLoader-specific name syntax policy that some loaders use, and some do not. I suspect that some module loaders will actively benefit from not having to deal with the annoying possibility that a slot will be present and will not be the expected "main" value; having a simple unrestricted String name allows each ModuleLoader to have complete control over their syntax policy, which is something that JBoss Modules has been moving towards for some time now. Ultimately slots are a pretty limited tool and are already essentially a facade over a plain name, with a very thin convenience class over the top of it to implement a parsing policy. While many people have taken advantage of slots in many ways, it is my view that moving this logic/policy into each module loader will afford more flexibility than does simply dividing names into two fields. The ModuleIdentifier class could be preserved as a convenience, though I would not recommend its use (hence deprecation), especially as it may map awkwardly into things like Java 9 module-aware stack traces. However this is something that can be discussed before any decision is reached. The estimated time frame for these changes relates to the time frame and progress of Java 9, so it is not clear at the moment exactly when this must happen, but it is certain that the changes will definitely not occur before WildFly 12. Hopefully this will give everyone enough time to recover from the shock. :-) Discussion! -- - DML From bmcwhirt at redhat.com Tue Jun 21 16:43:39 2016 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Tue, 21 Jun 2016 16:43:39 -0400 Subject: [wildfly-dev] Module slots may be deprecated In-Reply-To: <5769A609.2010406@redhat.com> References: <5769A609.2010406@redhat.com> Message-ID: This is horrible! Horrible I say. Actually, no, we?re cool. Thanks for the heads-up. -Bob On Tue, Jun 21, 2016 at 4:39 PM, David M. Lloyd wrote: > Java 9 modules do not have a concept of a slot, and are identified only > by name. On the other hand, the module slot in JBoss Modules is > essentially an extension of the name, and is used mainly as a helper to > name parsing for things like the filesystem module loader to allow easy > multi-version or parallel installation support. A few projects use > slots for other purposes. In many module loaders, slots are not used at > all and are allowed to default to "main". > > Among the changes coming to JBoss Modules for Java 9, my current plan > for this is to migrate towards the Java 9 way of doing things and > support only a general name field. For compatibility purposes, the > ModuleIdentifier API will continue to function, until/unless it is clear > that all major users have migrated off of it. It will work as a > frontend to plain String names - a ModuleIdentifier with name "name" and > slot "slot" will be translated behind the scenes as a module named > "name:slot". A module with a slot of "main" will be translated as just > "name". A simple character escaping scheme will be employed to ensure > that there is a lossless two-way mapping from plain names to > ModuleIdentifier-style names, in the event that there is a ':' in the > name part of the ModuleIdentifier, though in practice this may not come > up much. > > The existing module loaders can continue to function more or less as > they are. For filesystem modules using module.xml, the slot could still > be used by way of the compatibility syntax scheme above. The filesystem > module loader will continue to use the same file name mapping scheme for > now, using the aforementioned compatibility scheme to achieve the same > effect that slots do now; we can look at ways to transition off of that > later if it proves necessary to do so. > > The deployment module loader in WildFly can be transitioned to using > plain names easily, and this can probably be done at any time. We can > keep WildFly management APIs which reference modules as they are for now > - if a slot is present, it could simply be appended to the given module > name after a dividing ":", otherwise the module name is used as-is. The > slot attributes could be deprecated at any time. > > Overall though I think the best way of approaching the change is that we > start thinking of "name:slot" as merely a ModuleLoader-specific name > syntax policy that some loaders use, and some do not. I suspect that > some module loaders will actively benefit from not having to deal with > the annoying possibility that a slot will be present and will not be the > expected "main" value; having a simple unrestricted String name allows > each ModuleLoader to have complete control over their syntax policy, > which is something that JBoss Modules has been moving towards for some > time now. > > Ultimately slots are a pretty limited tool and are already essentially a > facade over a plain name, with a very thin convenience class over the > top of it to implement a parsing policy. While many people have taken > advantage of slots in many ways, it is my view that moving this > logic/policy into each module loader will afford more flexibility than > does simply dividing names into two fields. The ModuleIdentifier class > could be preserved as a convenience, though I would not recommend its > use (hence deprecation), especially as it may map awkwardly into things > like Java 9 module-aware stack traces. However this is something that > can be discussed before any decision is reached. > > The estimated time frame for these changes relates to the time frame and > progress of Java 9, so it is not clear at the moment exactly when this > must happen, but it is certain that the changes will definitely not > occur before WildFly 12. Hopefully this will give everyone enough time > to recover from the shock. :-) > > Discussion! > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160621/f439575d/attachment.html From smarlow at redhat.com Tue Jun 21 19:13:48 2016 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 21 Jun 2016 19:13:48 -0400 Subject: [wildfly-dev] Module slots may be deprecated In-Reply-To: <5769A609.2010406@redhat.com> References: <5769A609.2010406@redhat.com> Message-ID: <61fac4a9-55d1-7a87-c558-a9f3e27da284@redhat.com> This might impact the second Infinispan module name that OGM will likely use for remote Infinispan access, since the base module name was going to be identical to the WildFly infinispan module, with the slot name used to distinguish between the different Infinispan modules. The WildFly JPA container currently supports a persistence unit hint (jboss.as.jpa.providerModule=name) to specify a non-default persistence provider. This is probably used by some applications. Recently, Sanne also mentioned some use cases for Hibernate Search applications to depend on jboss.as.jpa.providerModule as well. Applications that currently include the slot with "jboss.as.jpa.providerModule", could need changes when the slot support is removed. Have you created a WFLY tracking issue yet for deprecating module slots? I'm thinking that the JPA container should check if "jboss.as.jpa.providerModule" specifies a slot and if yes, log a deployment warning about the application referencing a slot that needs change to not require the slot. We should also create a dependent jira for the JPA container change to log the warning. The JPA container also supports a similar "jboss.as.jpa.adapterModule" persistence unit property but I don't think that is used much, if at all. Applications that specify a slot in "jboss.as.jpa.adapterModule=name", should also get a deployment warning logged about deprecated slot usage. The other related change, will be the convention that we use for legacy Hibernate module names, which use the module slot as well. From a compatibility point of view, of future WildFly versions, with WildFly 10, when we pull the switch for removing module slot support completely, I'm not really sure if that breaks application compatibility or more that the user needs to move the system/user modules that use slot, to a non-slot module. For example, if the application persistence unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the user will need to move their Hibernate 4.x jars into a different folder. Another thing, I'm not sure if in that future WildFly version that removes slots completely, if the JPA container, should translate the "jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot, with the colon separator removed, so "jboss.as.jpa.providerModule=org.hibernate:4.1" becomes ""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a deployment error until the user moves the Hibernate jars from "org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1" (in the user or system module folder). Scott From slaskawi at redhat.com Wed Jun 22 02:18:31 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 22 Jun 2016 08:18:31 +0200 Subject: [wildfly-dev] Module slots may be deprecated In-Reply-To: <61fac4a9-55d1-7a87-c558-a9f3e27da284@redhat.com> References: <5769A609.2010406@redhat.com> <61fac4a9-55d1-7a87-c558-a9f3e27da284@redhat.com> Message-ID: In Infinispan we actually use both approaches (with and without slots). We use slots when creating modules for WF/EAP [1][2]. The idea is to copy them directly into the modules directory and use in your deployment. Note that we want to be able to put multiple versions there (like *ispn-8.2* and *ispn-9.0* for example). The default slot is used for WF Clustering and when we create our own HotRod server [3]. I think those changes look fine and everything should still work as it did before. Thanks Sebastian [1] https://github.com/infinispan/infinispan/tree/master/as-modules/embedded [2] https://github.com/infinispan/infinispan/tree/master/as-modules/client [3] https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow wrote: > This might impact the second Infinispan module name that OGM will likely > use for remote Infinispan access, since the base module name was going > to be identical to the WildFly infinispan module, with the slot name > used to distinguish between the different Infinispan modules. > > The WildFly JPA container currently supports a persistence unit hint > (jboss.as.jpa.providerModule=name) to specify a non-default persistence > provider. This is probably used by some applications. Recently, Sanne > also mentioned some use cases for Hibernate Search applications to > depend on jboss.as.jpa.providerModule as well. Applications that > currently include the slot with "jboss.as.jpa.providerModule", could > need changes when the slot support is removed. > > Have you created a WFLY tracking issue yet for deprecating module slots? > I'm thinking that the JPA container should check if > "jboss.as.jpa.providerModule" specifies a slot and if yes, log a > deployment warning about the application referencing a slot that needs > change to not require the slot. We should also create a dependent jira > for the JPA container change to log the warning. > > The JPA container also supports a similar "jboss.as.jpa.adapterModule" > persistence unit property but I don't think that is used much, if at > all. Applications that specify a slot in > "jboss.as.jpa.adapterModule=name", should also get a deployment warning > logged about deprecated slot usage. > > The other related change, will be the convention that we use for legacy > Hibernate module names, which use the module slot as well. > > From a compatibility point of view, of future WildFly versions, with > WildFly 10, when we pull the switch for removing module slot support > completely, I'm not really sure if that breaks application compatibility > or more that the user needs to move the system/user modules that use > slot, to a non-slot module. For example, if the application persistence > unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the > user will need to move their Hibernate 4.x jars into a different folder. > > Another thing, I'm not sure if in that future WildFly version that > removes slots completely, if the JPA container, should translate the > "jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot, > with the colon separator removed, so > "jboss.as.jpa.providerModule=org.hibernate:4.1" becomes > ""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a > deployment error until the user moves the Hibernate jars from > "org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1" > (in the user or system module folder). > > Scott > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160622/1e5aac7a/attachment.html From gtrikler at redhat.com Wed Jun 22 07:30:06 2016 From: gtrikler at redhat.com (Gytis Trikleris) Date: Wed, 22 Jun 2016 13:30:06 +0200 Subject: [wildfly-dev] Correct way to use PropertiesAttributeDefinition Message-ID: <207DEF37-8440-43CA-B511-70A2C97FE887@redhat.com> Hello, I?m trying to add property attribute to the mongo subsystem in order to add custom parameters for the driver. I have looked through other subsystems and it seems that PropertiesAttributeDefinition is normally used for that. But I keep getting failures similar to this one http://pastebin.com/raw/6rHMdXRi . I might be missing something trivial, but so far couldn?t figure out what exactly. Maybe somebody has any tips on how to use PropertiesAttributeDefinition correctly? The commit with current changes is here: https://github.com/gytis/jboss-as/commit/c89d569554b103536dd2bf255abae957799bcbd1 . And the branch is here: https://github.com/gytis/jboss-as/tree/nosql-dev9-connection-properties-for-mongodb-no-resource . Thanks, Gytis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160622/a0db78f8/attachment-0001.html From tomaz.cerar at gmail.com Wed Jun 22 07:56:51 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 22 Jun 2016 13:56:51 +0200 Subject: [wildfly-dev] Correct way to use PropertiesAttributeDefinition In-Reply-To: <207DEF37-8440-43CA-B511-70A2C97FE887@redhat.com> References: <207DEF37-8440-43CA-B511-70A2C97FE887@redhat.com> Message-ID: I think changing definition of your attribute to: protected static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder( ModelDescriptionConstants.PROPERTIES, true) .setAllowExpression(true) .setAttributeMarshaller(AttributeMarshaller.PROPERTIES_MARSHALLER_UNWRAPPED) .setAttributeParser(AttributeParser.PROPERTIES_PARSER_UNWRAPPED) .build(); should do what you want. This is only proper way to have unwrapped properties in xml representation. What you ware using is old way of doing it and only works with "hand written" parsers. Default behavior for this was not changed as it would break existing hand written parsers. -- tomaz On Wed, Jun 22, 2016 at 1:30 PM, Gytis Trikleris wrote: > Hello, > > I?m trying to add property attribute to the mongo subsystem in order to > add custom parameters for the driver. I have looked through other > subsystems and it seems that PropertiesAttributeDefinition is normally used > for that. But I keep getting failures similar to this one > http://pastebin.com/raw/6rHMdXRi. I might be missing something trivial, > but so far couldn?t figure out what exactly. Maybe somebody has any tips on > how to use PropertiesAttributeDefinition correctly? > The commit with current changes is here: > https://github.com/gytis/jboss-as/commit/c89d569554b103536dd2bf255abae957799bcbd1. > And the branch is here: > https://github.com/gytis/jboss-as/tree/nosql-dev9-connection-properties-for-mongodb-no-resource > . > > Thanks, > Gytis > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160622/dc183748/attachment.html From sanne at hibernate.org Wed Jun 22 11:11:43 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 22 Jun 2016 16:11:43 +0100 Subject: [wildfly-dev] Module slots may be deprecated In-Reply-To: References: <5769A609.2010406@redhat.com> <61fac4a9-55d1-7a87-c558-a9f3e27da284@redhat.com> Message-ID: I'm a bit sad from this, as the notion of "slot" was very useful, but I understand that the alternatives will work the same. So +1 for your proposal, if that helps with Jigsaw.. however beyond how things are represented, I'd hope we will be able to still evolve the notion of "slots" as a concept, for example to one day be able to validate that it's illegal for a user to depend on both "org.hibernate:4.1" and "org.hibernate:5.0", just to name one. About the transition period and the idea of "escaping" the ":" character in the name: maybe it would be better to avoid such escaping so that we could already make the transition on some projects, without enforcing the new naming scheme on all of them? It might be useful to start publishing some modules with e.g. name="org.hibernate.search-engine:6.0.0.Final" and yet be able to depend on this via the couple { name="org.hibernate.search-engine", slot="6.0.0.Final" } from another project: we're having at this point several projects which depend on each other in a complex matrix, with different release times and possibly targeting different WildFly versions and different product builds. Support for aliases will stay I hope? Those have been extremely useful too. Thanks! Sanne On 22 June 2016 at 07:18, Sebastian Laskawiec wrote: > In Infinispan we actually use both approaches (with and without slots). > > We use slots when creating modules for WF/EAP [1][2]. The idea is to copy > them directly into the modules directory and use in your deployment. Note > that we want to be able to put multiple versions there (like ispn-8.2 and > ispn-9.0 for example). > > The default slot is used for WF Clustering and when we create our own HotRod > server [3]. > > I think those changes look fine and everything should still work as it did > before. > > Thanks > Sebastian > > [1] https://github.com/infinispan/infinispan/tree/master/as-modules/embedded > [2] https://github.com/infinispan/infinispan/tree/master/as-modules/client > [3] > https://github.com/infinispan/infinispan/tree/master/server/integration/feature-pack > > On Wed, Jun 22, 2016 at 1:13 AM, Scott Marlow wrote: >> >> This might impact the second Infinispan module name that OGM will likely >> use for remote Infinispan access, since the base module name was going >> to be identical to the WildFly infinispan module, with the slot name >> used to distinguish between the different Infinispan modules. >> >> The WildFly JPA container currently supports a persistence unit hint >> (jboss.as.jpa.providerModule=name) to specify a non-default persistence >> provider. This is probably used by some applications. Recently, Sanne >> also mentioned some use cases for Hibernate Search applications to >> depend on jboss.as.jpa.providerModule as well. Applications that >> currently include the slot with "jboss.as.jpa.providerModule", could >> need changes when the slot support is removed. >> >> Have you created a WFLY tracking issue yet for deprecating module slots? >> I'm thinking that the JPA container should check if >> "jboss.as.jpa.providerModule" specifies a slot and if yes, log a >> deployment warning about the application referencing a slot that needs >> change to not require the slot. We should also create a dependent jira >> for the JPA container change to log the warning. >> >> The JPA container also supports a similar "jboss.as.jpa.adapterModule" >> persistence unit property but I don't think that is used much, if at >> all. Applications that specify a slot in >> "jboss.as.jpa.adapterModule=name", should also get a deployment warning >> logged about deprecated slot usage. >> >> The other related change, will be the convention that we use for legacy >> Hibernate module names, which use the module slot as well. >> >> From a compatibility point of view, of future WildFly versions, with >> WildFly 10, when we pull the switch for removing module slot support >> completely, I'm not really sure if that breaks application compatibility >> or more that the user needs to move the system/user modules that use >> slot, to a non-slot module. For example, if the application persistence >> unit specifies "jboss.as.jpa.providerModule=org.hibernate:4.1", then the >> user will need to move their Hibernate 4.x jars into a different folder. >> >> Another thing, I'm not sure if in that future WildFly version that >> removes slots completely, if the JPA container, should translate the >> "jboss.as.jpa.providerModule=org.hibernate:4.1" into ModuleName + slot, >> with the colon separator removed, so >> "jboss.as.jpa.providerModule=org.hibernate:4.1" becomes >> ""jboss.as.jpa.providerModule=org.hibernate4.1", which could cause a >> deployment error until the user moves the Hibernate jars from >> "org.hibernate:4.1" to "jboss.as.jpa.providerModule=org.hibernate4.1" >> (in the user or system module folder). >> >> Scott >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Wed Jun 22 11:45:18 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 22 Jun 2016 10:45:18 -0500 Subject: [wildfly-dev] Module slots may be deprecated In-Reply-To: References: <5769A609.2010406@redhat.com> <61fac4a9-55d1-7a87-c558-a9f3e27da284@redhat.com> Message-ID: <576AB28E.5020501@redhat.com> I'll answer your questions inline. On 06/22/2016 10:11 AM, Sanne Grinovero wrote: > I'm a bit sad from this, as the notion of "slot" was very useful, but > I understand that the alternatives will work the same. So +1 for your > proposal, if that helps with Jigsaw.. however beyond how things are > represented, I'd hope we will be able to still evolve the notion of > "slots" as a concept, for example to one day be able to validate that > it's illegal for a user to depend on both "org.hibernate:4.1" and > "org.hibernate:5.0", just to name one. Sounds like a potentially useful feature. This could be implemented as a ModuleLoader policy. > About the transition period and the idea of "escaping" the ":" > character in the name: maybe it would be better to avoid such escaping > so that we could already make the transition on some projects, without > enforcing the new naming scheme on all of them? Sure, code can transition to using String names and avoid any kind of special handling. Also, I believe that at present the filesystem module loader does not support : in names, so it won't have any issue with escaping. Or are you proposing something else? > It might be useful to start publishing some modules with e.g. > name="org.hibernate.search-engine:6.0.0.Final" and yet be able to > depend on this via the couple { name="org.hibernate.search-engine", > slot="6.0.0.Final" } from another project: > we're having at this point several projects which depend on each other > in a complex matrix, with different release times and possibly > targeting different WildFly versions and different product builds. Something of note is that I will also be adding version support. The version string will not have any core function (other than to display the correct version in the module stack trace, a new feature of Java 9) - in particular it won't be used as part of the module's identification for loading modules - but ModuleLoaders can use it for whatever purpose they wish (for example the ModuleLoader could generate the version based on the module name) including policy enforcement decisions. > Support for aliases will stay I hope? Those have been extremely useful too. Yes, though there will be some implementation changes (independently of this change) because alias unloading does not presently work properly. -- - DML From jmesnil at redhat.com Fri Jun 24 10:02:19 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 24 Jun 2016 16:02:19 +0200 Subject: [wildfly-dev] Proposal to improve resource description and registration In-Reply-To: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> References: <386B359A-0D7D-443D-BF8B-FB965CC5CDDD@redhat.com> Message-ID: <498CB9C5-BC46-4322-AECA-00B8A57963E0@redhat.com> The work to simplify registration of metrics described in this mail was merged[1] in wildfly-core a few weeks ago. The idea is that the MRR will check the process type to determine whether the metric definition must actually be registered or discarded. There were cases where the metrics would have to be registered regardless of the process type (e.g. mainly for the jmx subsystem and few other resources) and I added a FORCE_REGISTRATION flag to force the registration of the metric. I?m now continuing on that direction for runtime attributes[2] and operations[3]. A so-called runtime attribute is flagged with the STORAGE_RUNTIME flag documented as "An attribute whose value is only stored in runtime services, and isn't stored in the persistent configuration.? I assume that in the definition ?runtime services? means ?runtime MSC services?. Please correct me if that?s not the case (and don?t bother reading the rest of the mail :) Looking at wildly-core and wildfly codebase, We have 2 distinct subsets of runtime attributes: (a) attributes which require runtime MSC services to be handled (b) attributes which don?t require runtime MSC services but compute/store their value from some other runtime. Type (a) corresponds to the STORAGE_RUNTIME definition but type (b) differs (its value is stored neither in runtime service, not in the persistent configuration) The type (a) is the majority of runtime attributes and all subsystem (except JMX) uses this type. The type (b) is often located in our core-service resources or on HC/server root resources. I have a branch where I flagged all the type (b) with the same FORCE_REGISTRATION flag than the metrics and it does the job. But I find this flag poorly named. It tells the MRR what to do with the attribute/metric but it does not describe the attribute/metric in a meaningful way. How is a subsystem writer supposed to know when to use this flag or not? I?d like to change it and rename it to something like RUNTIME_SERVICE_NOT_REQUIRED. A subsystem writer could use this flag to specify that a runtime attribute does not require runtime service to handle the attribute. Runtime attribute of type (a) would be flagged with STORAGE_RUNTIME Runtime attribute of type (b) would be flagged with STORAGE_RUNTIME and RUNTIME_SERVICE_NOT_REQUIRED The MRR could then decide whether to register the attributes depending on the process type and the presence of these flags. Another possibility would be to add a 3rd STORAGE flag such as STORAGE_RUNTIME_BUT_NOT_MSC_RUNTIME (I suck at naming things!) for the type (b). I don?t like this as attributes of type (b) will most likely always be implemented by core developers (i.e. people who knows what they do) and I don?t want to add to our API a type of STORAGE that subsystem developers will never have to use. What do you think about changing the name of the FORCE_REGISTRATION and is RUNTIME_SERVICE_NOT_REQUIRED a good renaming? (I don?t like having ?negative? flag though?) The FORCE_REGISTRATION flag was introduced in a 3.0.0.Alpha1. Would it be possible to rename it before 3.0.0 is released or should I add another flag + @Deprecated, etc.? jeff [1] https://github.com/wildfly/wildfly-core/pull/1541 [2] https://issues.jboss.org/browse/WFCORE-1588 [3] https://issues.jboss.org/browse/WFCORE-1586 > On 25 Apr 2016, at 17:15, Jeff Mesnil wrote: > > TL;DR - I propose to simplify subsystem development by moving some of the validation logic from the resource definitions to the management resource registration. The goal is to provide a static representation of the resources and let the MMR dynamically pick the ?meaningful? parts. > > Last week an user complains that the messaging-activemq subsystem?s statistics were not updated in domain mode. > It turned out that he was reading the metrics on the DC (/profile=full/subsytem=messaging-activemq/?) instead of reading on the server (/host=master/server=server-one/subsystem=messaging-activemq/?) > > It is a bug[1] in the messaging-activemq because its resources register their metrics without checking whether that makes sense. The correct check is to look at context.isRuntimeOnlyRegistrationValid() to check whether a resource can register its metrics (the same check applies also for runtime attributes/operations). > I looked at other subsystems and undertow has the same issue. > > This check does not work well with the PersistentResourceDefinition that is used throughout the messaging-activemq and undertow subsystems. This API works best when the definition of the resources uses a bunch of static instances for the resource itself, its attributes, metrics, etc. These static instances are also used by the companion PersistentResourceXMLDescription to provide a static XML representation of the subsystem. > If I have to pass this context.isRuntimeOnlyRegistrationValid() boolean to every resources in the subsystem, I get rid of the static representations used by the PersistentResourceDefinition and PersistentResourceXMLDescription and I have to add a lot of simple but boilerplate code in all my resource definitions. > > The datasources subsystem does not exhibit this issue. It works around it by installing a Service at RUNTIME step to register (resp. unregister) statistics resource definitions when the service is started (res. stopped). Since services are only installed when runtime is supported, it ensures that the datasources metrics are available only on server and not on the DC. > It looks correct but I?m not a big fan of this solution. It makes the subsystem definition more complex to understand and it also involves boilerplate code that every subsystem providing runtime should write. > > I was wondering if we could simplify the development of the subsystems by moving some of the logic dealing with that use case in the ManagementResourceRegistration instead. > > My proposal would be to have the resource definitions be ?complete?. The resource always defines its attributes/metrics/operations. > When the MMR takes this definition and registers the different parts, it would only register the ?meaningful? one depending on the ProcessType and RunningMode. E.g. the MRR of the DC or a admin-only server would not register metrics & runtime attributes/operations while the MMR on a normal server would register everything. > This increase the complexity of the MMR which has to figure out whether to actually register something or discard it but it makes writing subsystem simpler and more robust. > > Brian told me there might some exceptions (e.g. a runtime op that could be invoked on the DC) but these case could be handled by adding metadata to the resource definitions. > > This approach segues quite well with the idea to generate subsystem using annotations. All the subsystem developers has to do is describe extensively the subsystem resources (using static objects now, annotations in a future version) and let the MMR decides which parts of the resources are actually registered. > > To sum up, the definition of a resource is static, while its registration is dynamic. > > Do you see any issue with that proposal? > As a first step, I?ll start by creating the corresponding WFCORE issue to fix WFLY-6546 issue by ensuring the MMR does not register metric if the runtime registration is not valid. This should not have any API impact (but the behaviour will certainly change). > > jeff > > [1] https://issues.jboss.org/browse/WFLY-6546 > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From stuart.w.douglas at gmail.com Sun Jun 26 21:32:23 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 27 Jun 2016 11:32:23 +1000 Subject: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1 In-Reply-To: <4E1736CC-440A-44B4-B58E-C7125448427E@redhat.com> References: <1464884984.2997.3.camel@muerte.net> <4E2FB975-DB32-412E-A83E-0445A1161E06@redhat.com> <9AA45211-04CB-4BC0-AE1E-163C340D5463@redhat.com> <393B48F5-7B34-4E98-A895-4EFBD5703B86@redhat.com> <10BAAD80-1A3B-47DD-909F-82546CD9DA4E@redhat.com> <6AF36A74-FA21-4E7E-B2FD-19F20AA1EA0E@redhat.com> <4E1736CC-440A-44B4-B58E-C7125448427E@redhat.com> Message-ID: This is now in Wildfly upstream. The server will automatically generate a self signed certificate and HTTP/2 is enabled by default. Stuart On Wed, Jun 8, 2016 at 10:28 PM, Jason T. Greene wrote: > > > On Jun 7, 2016, at 8:51 PM, Stuart Douglas > wrote: > > I have created a PR for this here: > https://github.com/wildfly/wildfly-core/pull/1596 (it will also require > some upstream changes). > > Basically this just creates a new schema version, and add the ' > generate-self-signed-certificate-host' attribute to the keystore. > > I have not added a script to enable HTTPS over management as Jason > suggested, I am not 100% sure if that really belongs in core or as part of > the full distribution. > > > It probably belongs in core so that other layered projects/products can > get it as well. However for 10.1 I think it's fine if we stick it in full > for now. > > > > > Stuart > > On Wed, Jun 8, 2016 at 6:55 AM, Stuart Douglas > wrote: > >> >> >> On Wed, Jun 8, 2016 at 6:51 AM, Jason Greene >> wrote: >> >>> So after reviewing this thread and discussing with a few folks, I?d like >>> to propose, for 10.1: >>> >>> #1b - Same as the previous #1, we don?t enable TLS for management by >>> default for now, but we additionally include an extra cli script to enable >>> TLS. >>> >> >> We would leave the cert generation bit in the security realm, but just >> don't enable the HTTPS interface. That way all that is required is for the >> user to add the https="managements-https" attribute. >> >> Stuart >> >> >>> >>> For 11 I think we should move to TLS by default, perhaps with a >>> configurable URL policy on redirects, and address the incongruence with >>> upgrade over app. >>> >>> I think its likely reasonable to redirect by default for 11, but we can >>> hash that out further. One nice thing I had forgotten about is that the JDK >>> will prompt for you to add unknown certs, and this all works with the >>> CLI[1]. So it?s really only non-interactive clients we have to worry about, >>> and that sounds like a reasonable burden for upgrade. >>> >>> [1] >>> >>> [disconnected /] connect >>> Unable to connect due to unrecognised server certificate >>> Subject - CN=foo,OU=foo,L=Madison,ST=WI,C=US >>> Issuer - CN=myServer, OU=test, L=Madison, ST=WI, C=US >>> Valid From - Tue Jun 07 15:22:06 CDT 2016 >>> Valid To - Thu Jun 07 15:22:06 CDT 2018 >>> MD5 : cd:68:be:0b:e0:c0:1c:63:d5:2a:85:c8:d1:9d:e7:7d >>> SHA1 : ae:f8:35:fd:09:c9:b3:08:05:59:a6:40:5e:ac:6e:e8:ce:85:72:4b >>> >>> Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t >>> >>> >>> >>> On Jun 7, 2016, at 6:24 AM, Jason T. Greene >>> wrote: >>> >>> Long term I think we want management using TLS, but that can of course >>> come in phases. Assuming 2) is one of those phases to come (either now or >>> later), a following step is that the CLI, and really any remoting client, >>> should prefer TLS with a defaulted trust store location that points to the >>> keystore. >>> >>> With 2) if we have the default of the attribute that forces redirect be >>> true, and our default config be false, then someone that carries over their >>> old config would not have a potential security weakness. If they have a CLI >>> script that adds the https port, it will fail, hopefully sending a signal >>> to look. Although, the user might just assume that oh it's there, I don't >>> have to do anything. >>> >>> Another interesting thing about 2 is that IIRC we have conflicting >>> behavior between the app port which doesn't force upgrade and the >>> management port which does. >>> >>> So my preference is 2, because at some point we have to do it anyway, >>> and if we have TLS out of the box might as well use it. >>> >>> On Jun 6, 2016, at 10:48 PM, Stuart Douglas >>> wrote: >>> >>> So while implementing this I have noticed a potential problem that it >>> would be good to get some feedback on. >>> >>> If the management interface has SSL by default then the HTTP interface >>> will always redirect to the HTTPS interface. This effectively breaks the >>> management API, as clients such as the CLI, Arquillian etc will be >>> redirected to HTTPS, and then reject the self signed certificate (as they >>> should). >>> >>> I am not sure what to do about this, these are the options as I see them: >>> >>> 1) Don't enable SSL for the management interface (just for the Undertow >>> subsystem). The management interface can still use this auto-generation >>> capability, it just won't be enable by default (we could even leave the >>> cert in the security domain, but just not enable the https interface). >>> >>> 2) Disable automatic redirects for HTTP upgrade requests (potentially >>> controlled by an attribute). This will allow the CLI etc to work, but at >>> the price of potentially reducing security, as some connections that would >>> have previously been redirected to use HTTPS will no longer do this. >>> >>> 3) Enable it by default and leave it broken. We can setup some kind of >>> automatic trust store thing so the local CLI works, and can get our test >>> suite to work with Arquillian in a similar manner. Personally I think this >>> is a terrible idea, but I am including it for completeness. >>> >>> Personally I think we should go for 1). Given that this is supposed to >>> be about developer usability I don't think having management also use SSL >>> as being that important. >>> >>> Stuart >>> >>> On Mon, Jun 6, 2016 at 10:24 PM, Jason T. Greene < >>> jason.greene at redhat.com> wrote: >>> >>>> Awesome! Another idea I had on how we could get away with it being in >>>> server boot, is to have a pre-boot first time setup task, either launched >>>> from the shell/batch scripts or as a special pre-step before the AS module >>>> loads. We could then report boot time as the time AFTER first time >>>> installation tasks have completed, which I think is fair because the server >>>> hasn't yet been started. >>>> >>>> On Jun 5, 2016, at 11:53 PM, Stuart Douglas >>>> wrote: >>>> >>>> I have some initial work on this at: >>>> https://github.com/stuartwdouglas/wildfly-core/tree/WFCORE-1576 >>>> >>>> If you go to https://localhost:9993 it will generate the certificate >>>> (although all that will be served is a 404 page as the console is not >>>> installed). >>>> >>>> Stuart >>>> >>>> On Mon, Jun 6, 2016 at 12:46 PM, Stuart Douglas < >>>> stuart.w.douglas at gmail.com> wrote: >>>> >>>>> I think that would actually end up being more complex. >>>>> >>>>> Stuart >>>>> >>>>> On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene < >>>>> jason.greene at redhat.com> wrote: >>>>> >>>>>> Another option could be a post boot task. So it's still eager but >>>>>> don't block completed start. We'd still need to block Tls ports though. So >>>>>> maybe this does not help >>>>>> >>>>>> On Jun 5, 2016, at 9:31 PM, Stuart Douglas < >>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>> >>>>>> 2048 bits adds close to a second to first boot on my machine >>>>>> (obviously subsequent boots are unaffected). >>>>>> >>>>>> This is probably a bit much, I will work on getting a POC for the >>>>>> lazy loading approach implemented. >>>>>> >>>>>> Stuart >>>>>> >>>>>> On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene < >>>>>> jason.greene at redhat.com> wrote: >>>>>> >>>>>>> We should really be generating 2048 bit keys. >>>>>>> >>>>>>> I don't like adding to our boot time, we have already seen it grow >>>>>>> and this would be yet another case. >>>>>>> >>>>>>> On Jun 5, 2016, at 8:57 PM, Stuart Douglas < >>>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>>> >>>>>>> So I just did up a very quick prototype that generates self signed >>>>>>> certificates on startup and it looks like the difference in startup time is >>>>>>> negligible (at least when generating 1024 bit RSA keys). Even if the >>>>>>> difference is measurable it only affects the very first startup. >>>>>>> >>>>>>> I think that in order to simplify the implementation of this it may >>>>>>> be better to simply generate the key of first startup, instead of >>>>>>> attempting to do it lazily. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >>>>>>> jason.greene at redhat.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> What will be default keysize? It has to be probably choosen to work >>>>>>>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>>>>>>> Jurisdiction Policy" >>>>>>>>> >>>>>>>> >>>>>>>> Probably the largest that is supported without JCE. It does not >>>>>>>> matter that much, self signed certs are inherently insecure, this is a >>>>>>>> developer usability feature, not something that can be used in production. >>>>>>>> >>>>>>>> >>>>>>>> IIRC there is actually no limit on RSA key size, it's only >>>>>>>> symmetric algs that are limited, so we could use a standard 2048 bit key >>>>>>>> without issue. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>>>>>>> stuart.w.douglas at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> So I guess we should talk about how this should actually work. >>>>>>>>>> >>>>>>>>>> In terms of auto generating the key I was thinking we would need >>>>>>>>>> to add a new attribute to the 'keystore' element under the security realm, >>>>>>>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>>>>>>> other options we would need, or how configurable we should make it, but as >>>>>>>>>> this is for testing/development purposes I don't think we need to expose >>>>>>>>>> full control over the certificate generation process. >>>>>>>>>> >>>>>>>>>> In terms of the implementation we could just implement an >>>>>>>>>> SSLContext wrapper, that can do the generation and then create a 'real' >>>>>>>>>> SSLContext the first time it is asked to create and SSLEngine. >>>>>>>>>> >>>>>>>>>> Stuart >>>>>>>>>> >>>>>>>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene < >>>>>>>>>> jason.greene at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell >>>>>>>>>>> wrote: >>>>>>>>>>> > >>>>>>>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>>>>>>> >> Hi All, >>>>>>>>>>> >> >>>>>>>>>>> >> I would like to propose that we add support for HTTP/2 out of >>>>>>>>>>> the box >>>>>>>>>>> >> in Wildfly 10.1. >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> > This lowly user desperately wants a release containing the fix >>>>>>>>>>> to WFLY- >>>>>>>>>>> > 6283 sooner rather than later. I'm sure other people have >>>>>>>>>>> other pet >>>>>>>>>>> > bugs awaiting release. >>>>>>>>>>> > >>>>>>>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>>>>>>> pent up >>>>>>>>>>> > bug fixes be kept in mind. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Harold, >>>>>>>>>>> >>>>>>>>>>> That fix is already in master, so it will be included in 10.1. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jason T. Greene >>>>>>>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> wildfly-dev mailing list >>>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-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/wildfly-dev/attachments/20160627/55480ee9/attachment-0001.html From rory.odonnell at oracle.com Mon Jun 27 05:15:14 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 27 Jun 2016 10:15:14 +0100 Subject: [wildfly-dev] Early Access builds of JDK 8u112 b01, JDK 9 b124 are available on java.net Message-ID: <3a339a8c-b25a-30b8-0cb5-2fceda5d14fa@oracle.com> Hi Jason/Tomaz, Early Access b124 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b123 (#5178) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here Early Access b01 for JDK 8u112 is available on java.net. Update to JEP 261 : Module System - email from Mark Reinhold [1] - The special ALL-DEFAULT module name, which represents the default set of root modules for use with the -addmods option [2]; - A more thorough explanation of how the built-in class loaders have changed, how built-in modules are assigned to each loader, and how these loaders work together to load classes [3]; and - The reason why Java EE-related modules are no longer resolved by default [4]. - There are various other minor corrections and clarifications, as can be seen in the detailed diff [5]. Rgds,Rory [1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html [2]http://openjdk.java.net/jeps/261#ALL-DEFAULT [3]http://openjdk.java.net/jeps/261#Class-loaders [4]http://openjdk.java.net/jeps/261#EE-modules [5]http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/5bd825d8/attachment.html From tomaz.cerar at gmail.com Mon Jun 27 07:50:58 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 27 Jun 2016 13:50:58 +0200 Subject: [wildfly-dev] Early Access builds of JDK 8u112 b01, JDK 9 b124 are available on java.net In-Reply-To: <3a339a8c-b25a-30b8-0cb5-2fceda5d14fa@oracle.com> References: <3a339a8c-b25a-30b8-0cb5-2fceda5d14fa@oracle.com> Message-ID: Hey Rory, We are already testing on b124, we are back to testing every build that is out as soon as it is available. WildFly core status can be seen at https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 and WildFly full (again compiles on JDK9), current state can be seen at: https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea -- tomaz On Mon, Jun 27, 2016 at 11:15 AM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > Early Access b124 for JDK 9 is > available on java.net, summary of changes are listed here > . > > Early Access b123 ( #5178) for JDK 9 with > Project Jigsaw is available on java.net, summary of changes are listed > here > > > Early Access b01 for JDK 8u112 is > available on java.net. > > Update to JEP 261 : Module System - email from Mark Reinhold [1] > > - The special ALL-DEFAULT module name, which represents the default set of > root modules for use with the -addmods option [2]; > - A more thorough explanation of how the built-in class loaders have > changed, how built-in modules are assigned to each loader, > and how these loaders work together to load classes [3]; and > - The reason why Java EE-related modules are no longer resolved by default > [4]. > - There are various other minor corrections and clarifications, as can be > seen in the detailed diff [5]. > > > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html > [2] http://openjdk.java.net/jeps/261#ALL-DEFAULT > [3] http://openjdk.java.net/jeps/261#Class-loaders > [4] http://openjdk.java.net/jeps/261#EE-modules > [5] http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/6c0d5269/attachment.html From mmusgrov at redhat.com Mon Jun 27 09:58:03 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 27 Jun 2016 14:58:03 +0100 Subject: [wildfly-dev] Java SE 9 testing Message-ID: Does anyone have an arquillian + wildfly config yet for testing wildfly with Java 9? This is in the context of running our narayana test suite, parts of which require arquillian + wildfly Mike -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/f7efd2f7/attachment.html From tomaz.cerar at gmail.com Mon Jun 27 10:07:31 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 27 Jun 2016 16:07:31 +0200 Subject: [wildfly-dev] Java SE 9 testing In-Reply-To: References: Message-ID: You will need to be more specific. wildfly-arquillian 2.x containers work just fine on JDK9 (1.x should probably too, but I've not tested) What do you mean by wildfly config? To run WildFly on JDK9 b112+, you will need to grab latest build from master. As support to run it on latest builds just landed to wildfly master on friday. -- tomaz On Mon, Jun 27, 2016 at 3:58 PM, Michael Musgrove wrote: > Does anyone have an arquillian + wildfly config yet for testing wildfly > with Java 9? This is in the context of running our narayana test suite, > parts of which require arquillian + wildfly > > Mike > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/b79ec9fc/attachment.html From mmusgrov at redhat.com Mon Jun 27 10:10:09 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 27 Jun 2016 15:10:09 +0100 Subject: [wildfly-dev] Java SE 9 testing In-Reply-To: References: Message-ID: Thanks Tomaz, That is good enough for me to make progress (wildfly-arquillian 2.x + wildfly master + jdk build number) Mike On Mon, Jun 27, 2016 at 3:07 PM, Toma? Cerar wrote: > You will need to be more specific. > > wildfly-arquillian 2.x containers work just fine on JDK9 (1.x should > probably too, but I've not tested) > What do you mean by wildfly config? > To run WildFly on JDK9 b112+, you will need to grab latest build from > master. > As support to run it on latest builds just landed to wildfly master on > friday. > > -- > tomaz > > > On Mon, Jun 27, 2016 at 3:58 PM, Michael Musgrove > wrote: > >> Does anyone have an arquillian + wildfly config yet for testing wildfly >> with Java 9? This is in the context of running our narayana test suite, >> parts of which require arquillian + wildfly >> >> Mike >> >> -- >> Michael Musgrove >> Transactions Team >> e: mmusgrov at redhat.com >> t: +44 191 243 0870 >> >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson >> (US), Charles Peters (US) >> >> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael >> O'Neill(Ireland) >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/24a8956e/attachment-0001.html From tomaz.cerar at gmail.com Mon Jun 27 10:14:51 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 27 Jun 2016 16:14:51 +0200 Subject: [wildfly-dev] Java SE 9 testing In-Reply-To: References: Message-ID: just grab latest release of JDK9 from https://jdk9.java.net/download/ and use latest build of WildFly from master and you should be fine. If you hit any problems you can ping me on hipchat. -- tomaz On Mon, Jun 27, 2016 at 4:10 PM, Michael Musgrove wrote: > Thanks Tomaz, > > That is good enough for me to make progress (wildfly-arquillian 2.x + > wildfly master + jdk build number) > > Mike > > On Mon, Jun 27, 2016 at 3:07 PM, Toma? Cerar > wrote: > >> You will need to be more specific. >> >> wildfly-arquillian 2.x containers work just fine on JDK9 (1.x should >> probably too, but I've not tested) >> What do you mean by wildfly config? >> To run WildFly on JDK9 b112+, you will need to grab latest build from >> master. >> As support to run it on latest builds just landed to wildfly master on >> friday. >> >> -- >> tomaz >> >> >> On Mon, Jun 27, 2016 at 3:58 PM, Michael Musgrove >> wrote: >> >>> Does anyone have an arquillian + wildfly config yet for testing wildfly >>> with Java 9? This is in the context of running our narayana test suite, >>> parts of which require arquillian + wildfly >>> >>> Mike >>> >>> -- >>> Michael Musgrove >>> Transactions Team >>> e: mmusgrov at redhat.com >>> t: +44 191 243 0870 >>> >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson >>> (US), Charles Peters (US) >>> >>> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael >>> O'Neill(Ireland) >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/98d85a8e/attachment.html From rory.odonnell at oracle.com Mon Jun 27 11:55:38 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 27 Jun 2016 16:55:38 +0100 Subject: [wildfly-dev] Early Access builds of JDK 8u112 b01, JDK 9 b124 are available on java.net In-Reply-To: References: <3a339a8c-b25a-30b8-0cb5-2fceda5d14fa@oracle.com> Message-ID: <308bf6e4-a201-34ee-a4cb-67af9d72f9c4@oracle.com> Hi Tomaz, That is good news! Rgds,Rory On 27/06/2016 12:50, Toma? Cerar wrote: > Hey Rory, > > We are already testing on b124, > we are back to testing every build that is out as soon as it is > available. > > WildFly core status can be seen at > https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 > and WildFly full (again compiles on JDK9), current state can be seen at: > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea > > -- > tomaz > > On Mon, Jun 27, 2016 at 11:15 AM, Rory O'Donnell > > wrote: > > > Hi Jason/Tomaz, > > Early Access b124 for JDK 9 is > available on java.net , summary of changes are > listed here > . > > Early Access b123 (#5178) for JDK > 9 with Project Jigsaw is available on java.net , > summary of changes are listed here > > > Early Access b01 for JDK > 8u112 is available on java.net . > > Update to JEP 261 : Module System - email from Mark Reinhold [1] > > - The special ALL-DEFAULT module name, which represents the > default set of root modules for use with the -addmods option [2]; > - A more thorough explanation of how the built-in class loaders > have changed, how built-in modules are assigned to each loader, > and how these loaders work together to load classes [3]; and > - The reason why Java EE-related modules are no longer resolved by > default [4]. > - There are various other minor corrections and clarifications, as > can be seen in the detailed diff [5]. > > > Rgds,Rory > > [1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html > [2]http://openjdk.java.net/jeps/261#ALL-DEFAULT > [3]http://openjdk.java.net/jeps/261#Class-loaders > [4]http://openjdk.java.net/jeps/261#EE-modules > [5]http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160627/de622696/attachment.html From mazz at redhat.com Tue Jun 28 17:30:19 2016 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 28 Jun 2016 17:30:19 -0400 (EDT) Subject: [wildfly-dev] is supposed to be the same as -Djboss.node.name? In-Reply-To: <572674881.557328.1467149005869.JavaMail.zimbra@redhat.com> Message-ID: <935083574.560975.1467149419173.JavaMail.zimbra@redhat.com> There is some confusion about setting the WildFly node name (at least in the standalone server case). QUESTION: How does one change the server's cluster node name (say, for the JGroups configuration). I thought both would be equivalent (either setting or setting -Djboss.node.name=a) but that does not seem to be the case. Suppose I start WildFly via standalone.sh (with its stock out of box standalone.xml) but with the command line option: -Djboss.node.name=wotgorilla When I do this, I see the node-name (in the server-environment subsystem) set to "wotgorilla" but the server's name is my normal hostname (in this case "mazztower"): /core-service=server-environment/:read-attribute(name=node-name) { "outcome" => "success", "result" => "wotgorilla" } /:read-attribute(name=name) { "outcome" => "success", "result" => "mazztower" } OK, but now suppose I edit standalone.xml - in the top-level root element I add the name attribute: and I start the server WITHOUT any commmand line options (just "standalone.sh"). I see that BOTH "name" and "node-name" match my new server name: /core-service=server-environment/:read-attribute(name=node-name) { "outcome" => "success", "result" => "foobar" } /:read-attribute(name=name) { "outcome" => "success", "result" => "foobar" } QUESTION: Why the discrepency? Is this a bug or expected behavior? How does one change the server's cluster node name (say, for the JGroups configuration). I thought both would be equivalent (either setting or setting jboss.node.name) but that does not seem to be the case. Thanks, John Mazz From dennis.brouwer at kizitos.com Tue Jun 28 17:43:23 2016 From: dennis.brouwer at kizitos.com (Dennis Brouwer) Date: Tue, 28 Jun 2016 23:43:23 +0200 Subject: [wildfly-dev] is supposed to be the same as -Djboss.node.name? In-Reply-To: <935083574.560975.1467149419173.JavaMail.zimbra@redhat.com> References: <572674881.557328.1467149005869.JavaMail.zimbra@redhat.com> <935083574.560975.1467149419173.JavaMail.zimbra@redhat.com> Message-ID: Dear John, Suppose you have two JBoss instances running on one (the same) host (using e.g. port offset) identifying both would be done by explicitly setting the jboss.node.name so this is expected behavior. Otherwise there would be a conflict. (In our development stage we have over 30 JBoss servers running on the same host, all being tied up to JGroups). Regards Dennis On Tue, Jun 28, 2016 at 11:30 PM, John Mazzitelli wrote: > There is some confusion about setting the WildFly node name (at least in > the standalone server case). > > > QUESTION: How does one change the server's cluster node name (say, for > the JGroups configuration). I thought both would be equivalent (either > setting or setting -Djboss.node.name=a) but that does > not seem to be the case. > > > Suppose I start WildFly via standalone.sh (with its stock out of box > standalone.xml) but with the command line option: > > -Djboss.node.name=wotgorilla > > When I do this, I see the node-name (in the server-environment subsystem) > set to "wotgorilla" but the server's name is my normal hostname (in this > case "mazztower"): > > /core-service=server-environment/:read-attribute(name=node-name) > { > "outcome" => "success", > "result" => "wotgorilla" > } > > /:read-attribute(name=name) > { > "outcome" => "success", > "result" => "mazztower" > } > > OK, but now suppose I edit standalone.xml - in the top-level root element > I add the name attribute: > > > > and I start the server WITHOUT any commmand line options (just > "standalone.sh"). I see that BOTH "name" and "node-name" match my new > server name: > > /core-service=server-environment/:read-attribute(name=node-name) > { > "outcome" => "success", > "result" => "foobar" > } > > /:read-attribute(name=name) > { > "outcome" => "success", > "result" => "foobar" > } > > QUESTION: Why the discrepency? Is this a bug or expected behavior? How > does one change the server's cluster node name (say, for the JGroups > configuration). I thought both would be equivalent (either setting name="a"> or setting jboss.node.name) but that does not seem to be the > case. > > Thanks, > John Mazz > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Best regards, *Dennis Brouwer* Extraordinary Goalkeeper ZEEF - Kizitos B.V. Amstelboulevard 184 1096 HM Amsterdam www.ZEEF.com US: +1 (415) 992-9409 NL: +31 (085) 888-3186 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160628/981d0ed4/attachment-0001.html From mazz at redhat.com Tue Jun 28 17:56:03 2016 From: mazz at redhat.com (John Mazzitelli) Date: Tue, 28 Jun 2016 17:56:03 -0400 (EDT) Subject: [wildfly-dev] is supposed to be the same as -Djboss.node.name? In-Reply-To: References: <572674881.557328.1467149005869.JavaMail.zimbra@redhat.com> <935083574.560975.1467149419173.JavaMail.zimbra@redhat.com> Message-ID: <1747258689.564661.1467150963701.JavaMail.zimbra@redhat.com> > Dear John, > > Suppose you have two JBoss instances running on one (the same) host (using > e.g. port offset) identifying both would be done by explicitly setting the > jboss.node.name so this is expected behavior. Otherwise there would be a > conflict. (In our development stage we have over 30 JBoss servers running > on the same host, all being tied up to JGroups). In that case, both of your servers would have identical "name" values (your hostname). That seems "odd" in that the name for multiple servers are the same - so their "name"s are not unique - but perhaps that is why WF 10 introduced the UUID attribute? Still, not sure why the discrepancy between jboss.node.name and - you would think they both would behave the same, but do not. > > Regards Dennis > > On Tue, Jun 28, 2016 at 11:30 PM, John Mazzitelli wrote: > > > There is some confusion about setting the WildFly node name (at least in > > the standalone server case). > > > > > > QUESTION: How does one change the server's cluster node name (say, for > > the JGroups configuration). I thought both would be equivalent (either > > setting or setting -Djboss.node.name=a) but that does > > not seem to be the case. > > > > > > Suppose I start WildFly via standalone.sh (with its stock out of box > > standalone.xml) but with the command line option: > > > > -Djboss.node.name=wotgorilla > > > > When I do this, I see the node-name (in the server-environment subsystem) > > set to "wotgorilla" but the server's name is my normal hostname (in this > > case "mazztower"): > > > > /core-service=server-environment/:read-attribute(name=node-name) > > { > > "outcome" => "success", > > "result" => "wotgorilla" > > } > > > > /:read-attribute(name=name) > > { > > "outcome" => "success", > > "result" => "mazztower" > > } > > > > OK, but now suppose I edit standalone.xml - in the top-level root element > > I add the name attribute: > > > > > > > > and I start the server WITHOUT any commmand line options (just > > "standalone.sh"). I see that BOTH "name" and "node-name" match my new > > server name: > > > > /core-service=server-environment/:read-attribute(name=node-name) > > { > > "outcome" => "success", > > "result" => "foobar" > > } > > > > /:read-attribute(name=name) > > { > > "outcome" => "success", > > "result" => "foobar" > > } > > > > QUESTION: Why the discrepency? Is this a bug or expected behavior? How > > does one change the server's cluster node name (say, for the JGroups > > configuration). I thought both would be equivalent (either setting > name="a"> or setting jboss.node.name) but that does not seem to be the > > case. > > > > Thanks, > > John Mazz > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > Best regards, > > *Dennis Brouwer* > Extraordinary Goalkeeper > > > > > ZEEF - Kizitos B.V. > Amstelboulevard 184 > 1096 HM Amsterdam > www.ZEEF.com > US: +1 (415) 992-9409 > NL: +31 (085) 888-3186 > From smarlow at redhat.com Wed Jun 29 09:50:07 2016 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 29 Jun 2016 09:50:07 -0400 Subject: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration... In-Reply-To: <5731F8E5.7030609@redhat.com> References: <572B875C.20903@redhat.com> <5731F8E5.7030609@redhat.com> Message-ID: I think that we will move forward now and prototype the transaction enlistment for ACID NoSQL databases. This is important to nail down now, as we would like forward application compatibility. We need to choose now, whether MySLSB.myMethod() performs the Neo4j database update immediately when (#4) tx.close() is called or when the JTA transaction completes. By now, I mean that we need to decide before a release of WildFly that contains the NoSQL integration is released, so that we know that future releases will be compatible. I don't think that transaction enlistment should be allowed for BASE NoSQL databases, which is why I mentioned ACID above. With BASE databases, the application code is responsible for dealing with dirty data. As such, I think it would be misleading to enlist BASE operations into a JTA transaction. This means that BASE NoSQL database profiles will not allow 1-phase/2-phase transaction attribute to be specified. We started to write some design notes [1] for NoSQL integration. We will update the design notes after hearing more feedback on the above. Scott [1] https://developer.jboss.org/wiki/DesignNotesForNoSQLIntegrationOnWildFly On 05/10/2016 11:06 AM, Jesper Pedersen wrote: >> Any links to existing IronJacamar code to share here? I think that we >> could prototype new transaction enlistment handling code, based on what >> we currently have. >> > > The IronJacamar code is here for Narayana: > > https://github.com/ironjacamar/ironjacamar/tree/master/core/src/main/java/org/ironjacamar/core/tx/narayana > > > However, that is based on the Java EE Connector Architecture > specification, so we have a *much* easier job. > > Lets take an example from the NoSQL world using Neo4J: > > http://neo4j.com/docs/api/java-driver/current/org/neo4j/driver/v1/Driver.html > > > ...neo4j.LocalXAResource implements XAResource, org.jboss.tm.LastResource > > public void start(Xid xid, int flags) throws XAException { > tx = session.beginTransaction(); > } > > public void commit(Xid xid, boolean onePhase) throws XAException { > tx.success(); > } > > public void rollback(Xid xid) throws XAException { > tx.failure(); > } > > And the app, f.ex. in a SLSB method > > public class MySLSB ... > > @Resource(mappedName="java:jboss/nosql/neo4j") > private Driver neo4j; > > public void myMethod() { > #1 Session s = neo4j.createSession(); > s.run( "CREATE (n {name:'Bob'})" ); > > #2 Transaction tx = s.beginTransaction(); > tx.run( "CREATE (n {name:'Alice'})" ); > tx.run( "CREATE (n {name:'Tina'})" ); > > #3 tx.success(); > > #4 tx.close(); > #5 s.close(); > #6 neo4j.close(); > } > > However, as you can see there are a number of hidden things going on > here if ".../neo4j" is deployed as "transaction=1phase". > > #1: Here you have to intercept the call, create the LocalXAResource > instance and enlist it in the active transaction > > #2: Here you have to a delegator instance that only executes the run() > calls > > #3: No-op call, happens upon EE transaction completion > > #4: No-op call. happens upon EE transaction completion > > #5: No-op call, happens in an enlisted Synchronization instance > (afterCompletion) (done in #1 too) > > #6: No-op call, handled by subsystem > > The value-add is that #3 is tied into the overall EE transaction. > > If ".../neo4j" is deployed as "transaction=none", then all calls are on > the "real" Neo4J objects. > > As you can see it isn't as simple as it may appear, and application flow > could be different from what the developer expects, as #3 could be a > real tx.failure() call in case of MARKED_FOR_ROLLBACK. > > There are def pros/cons of doing tx enlistment for this area... From brian.stansberry at redhat.com Wed Jun 29 10:22:12 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 29 Jun 2016 09:22:12 -0500 Subject: [wildfly-dev] is supposed to be the same as -Djboss.node.name? In-Reply-To: <1747258689.564661.1467150963701.JavaMail.zimbra@redhat.com> References: <572674881.557328.1467149005869.JavaMail.zimbra@redhat.com> <935083574.560975.1467149419173.JavaMail.zimbra@redhat.com> <1747258689.564661.1467150963701.JavaMail.zimbra@redhat.com> Message-ID: <726CF4D9-8E4C-439A-BB84-502D259C6F86@redhat.com> The node name concept configured via -Djboss.node.name is a clustering concept not a general managment one. You can set the node name by setting the server name, so that?s the way to do it. Don?t try the other way around. The server name can also be set via system property for standalone servers: -Djboss.server.name So there is no need to edit xml. In a managed domain if a server process doesn?t have jboss.node.name set, the node name will be :. It needs to be a tuple like that as only that tuple is required to be unique in a domain. Node name needs to be unique across a cluster. The discrepancy is because the jboss.node.name property is only used for some clustering stuff and has never been part of AS 7+?s algorithm for establishing the server?s name for management purposes. IIRC it was added to AS7 account for some use case previously not handled in domain mode ? but now handled better ? or perhaps it was added in to be more like AS < 7 where that property was long used in clustering. Probably both. I don?t think the jboss.node.name property is even needed any more. But, we?re not going to drop support of jboss.node.name as that may break some people. And I don?t think we?ll add jboss.node.name to the algorithm for setting the server name, as that may break people as well. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat > On Jun 28, 2016, at 4:56 PM, John Mazzitelli wrote: > >> Dear John, >> >> Suppose you have two JBoss instances running on one (the same) host (using >> e.g. port offset) identifying both would be done by explicitly setting the >> jboss.node.name so this is expected behavior. Otherwise there would be a >> conflict. (In our development stage we have over 30 JBoss servers running >> on the same host, all being tied up to JGroups). > > > In that case, both of your servers would have identical "name" values (your hostname). That seems "odd" in that the name for multiple servers are the same - so their "name"s are not unique - but perhaps that is why WF 10 introduced the UUID attribute? > > Still, not sure why the discrepancy between jboss.node.name and - you would think they both would behave the same, but do not. > > >> >> Regards Dennis >> >> On Tue, Jun 28, 2016 at 11:30 PM, John Mazzitelli wrote: >> >>> There is some confusion about setting the WildFly node name (at least in >>> the standalone server case). >>> >>> >>> QUESTION: How does one change the server's cluster node name (say, for >>> the JGroups configuration). I thought both would be equivalent (either >>> setting or setting -Djboss.node.name=a) but that does >>> not seem to be the case. >>> >>> >>> Suppose I start WildFly via standalone.sh (with its stock out of box >>> standalone.xml) but with the command line option: >>> >>> -Djboss.node.name=wotgorilla >>> >>> When I do this, I see the node-name (in the server-environment subsystem) >>> set to "wotgorilla" but the server's name is my normal hostname (in this >>> case "mazztower"): >>> >>> /core-service=server-environment/:read-attribute(name=node-name) >>> { >>> "outcome" => "success", >>> "result" => "wotgorilla" >>> } >>> >>> /:read-attribute(name=name) >>> { >>> "outcome" => "success", >>> "result" => "mazztower" >>> } >>> >>> OK, but now suppose I edit standalone.xml - in the top-level root element >>> I add the name attribute: >>> >>> >>> >>> and I start the server WITHOUT any commmand line options (just >>> "standalone.sh"). I see that BOTH "name" and "node-name" match my new >>> server name: >>> >>> /core-service=server-environment/:read-attribute(name=node-name) >>> { >>> "outcome" => "success", >>> "result" => "foobar" >>> } >>> >>> /:read-attribute(name=name) >>> { >>> "outcome" => "success", >>> "result" => "foobar" >>> } >>> >>> QUESTION: Why the discrepency? Is this a bug or expected behavior? How >>> does one change the server's cluster node name (say, for the JGroups >>> configuration). I thought both would be equivalent (either setting >> name="a"> or setting jboss.node.name) but that does not seem to be the >>> case. >>> >>> Thanks, >>> John Mazz >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> -- >> Best regards, >> >> *Dennis Brouwer* >> Extraordinary Goalkeeper >> >> >> >> >> ZEEF - Kizitos B.V. >> Amstelboulevard 184 >> 1096 HM Amsterdam >> www.ZEEF.com > >> US: +1 (415) 992-9409 >> NL: +31 (085) 888-3186 >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/ea223811/attachment-0001.html From Andrew.Marlow at fisglobal.com Wed Jun 29 11:08:03 2016 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Wed, 29 Jun 2016 15:08:03 +0000 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 Message-ID: Hello everyone, This is an appeal for help to resolve the error JBREM000200 that I get when a process connects to wildfly to do some JMS work. Details follow:- I am trying to switch from JBoss-as-7.1.1.Final to Wildfly 9.0.1.Final. My project runs on Microsoft Windows and Red Hat Linux (RHEL 5.11). I am using java jdk 1.8.0_60. The switch to wildfly worked fine on Windows, once I found out what the config file changes were, especially the switch from remote port 4777 to undertow http port 8080. However, on linux the wildfly server get an error as soon as one of my processes connects to it. The wildfly log is not very busy. Wildfly starts with not much logged then I get a one line error report for every connection attempt: 2016-06-29 15:09:09,555 ERROR [org.jboss.remoting.remote.connection] (default I/O-6) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856 The log of the process that connects contains a bit more detail: Error: NamingException detected during EndPointFactory JMS Server queue initialisation: Failed to connect to any server. Servers tried: [http-remoting://:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] : Failed to connect to any server. Servers tried: [http-remoting://:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] Cause unknown. : Stack trace: javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://:8180 (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244) at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149) at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130) at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) at org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) at javax.naming.InitialContext.lookup(InitialContext.java:417) I am using port 8180 because port 8080 is already taken (jenkins). I have googled for this causes of this error. I found several hits that suggested various "solutions". I tried them all. None of them worked. Here's what I have tried: * I ensured that no other process was using 8180. Some wildfly users have been in environments where a rogue process was writing to the undertow port. I used netstat in a loop to monitor any process using 8180. It just showed wildfly listening on it until my app made the connection attempt. Then it showed my app as well. No other apps. * I tried using the port number offset feature. This used different port numbers but the problem remained. * xml config, disable section security-realm-name="ApplicationRealm". This made no difference. * In the interfaces section, interface name="public" replace inet-address value=${jboss.bind.address:0.0.0.0} with value = "". This did make a difference - I lost connectivity completely. This was fixed by me changing localhost in my remoting URL to the ip address as a dotted quad. Then I got the invalid message length error back. This seems like a very deep mystery to me. It might force me to abandon using wildfly on linux and say that it is only supported on windows. Any help will be much appreciated. Regards, Andrew Marlow. http://www.andrewpetermarlow.co.uk _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/1142a357/attachment.html From david.lloyd at redhat.com Wed Jun 29 11:15:19 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 29 Jun 2016 10:15:19 -0500 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: Message-ID: <5773E607.8020304@redhat.com> JBoss Remoting uses a feature called "HTTP Upgrade", which basically allows a client to connect to an HTTP port and then send a special HTTP request which allows an "upgrade" to another arbitrary protocol. Later versions of WildFly use this feature by default to reduce the count of bound ports. What is probably happening is that you are connecting to a port that has a plain Remoting listener on it, but the client is using "http-remoting" which means "JBoss Remoting over HTTP Upgrade". So the client sends an HTTP request, but the server interprets it as garbage because it is expecting a Remoting framed packet instead. The fix is to either change the client from "http-remoting" to just "remoting", or to change your server to use HTTP upgrade instead. Information on this should be in the user docs. On 06/29/2016 10:08 AM, Marlow, Andrew wrote: > Hello everyone, > > This is an appeal for help to resolve the error JBREM000200 that I get > when a process connects to wildfly to do some JMS work. Details follow:- > > I am trying to switch from JBoss-as-7.1.1.Final to Wildfly 9.0.1.Final. > My project runs on Microsoft Windows and Red Hat Linux (RHEL 5.11). I am > using java jdk 1.8.0_60. The switch to wildfly worked fine on Windows, > once I found out what the config file changes were, especially the > switch from remote port 4777 to undertow http port 8080. However, on > linux the wildfly server get an error as soon as one of my processes > connects to it. The wildfly log is not very busy. Wildfly starts with > not much logged then I get a one line error report for every connection > attempt: > > 2016-06-29 15:09:09,555 ERROR [org.jboss.remoting.remote.connection] > (default I/O-6) JBREM000200: Remote connection failed: > java.io.IOException: XNIO000804: Received an invalid message length of > 1195725856 > > The log of the process that connects contains a bit more detail: > > Error: NamingException detected during EndPointFactory JMS Server queue > initialisation: Failed to connect to any server. Servers tried: > [http-remoting://:8180 (java.io.EOFException: XNIO000812: > Connection closed unexpectedly)] : Failed to connect to any server. > Servers tried: [http-remoting://:8180 > (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] > Cause unknown. : Stack trace: javax.naming.CommunicationException: > Failed to connect to any server. Servers tried: > [http-remoting://:8180 (java.io.EOFException: XNIO000812: > Connection closed unexpectedly)] > > at > org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244) > > at > org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149) > > at > org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130) > > at > org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) > > at > org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) > > at > org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) > > at > org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) > > at javax.naming.InitialContext.lookup(InitialContext.java:417) > > I am using port 8180 because port 8080 is already taken (jenkins). > > I have googled for this causes of this error. I found several hits that > suggested various ?solutions?. I tried them all. None of them worked. > Here?s what I have tried: > > ?I ensured that no other process was using 8180. Some wildfly users have > been in environments where a rogue process was writing to the undertow > port. I used netstat in a loop to monitor any process using 8180. It > just showed wildfly listening on it until my app made the connection > attempt. Then it showed my app as well. No other apps. > > ?I tried using the port number offset feature. This used different port > numbers but the problem remained. > > ?xml config, disable section security-realm-name=?ApplicationRealm?. > This made no difference. > > ?In the interfaces section, interface name=?public? replace inet-address > value=${jboss.bind.address:0.0.0.0} with value = > ??. This did make a difference ? I lost > connectivity completely. This was fixed by me changing localhost in my > remoting URL to the ip address as a dotted quad. Then I got the invalid > message length error back. > > This seems like a very deep mystery to me. It might force me to abandon > using wildfly on linux and say that it is only supported on windows. Any > help will be much appreciated. > > Regards, > > Andrew Marlow. > > http://www.andrewpetermarlow.co.uk > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete > the message and all copies; (ii) do not disclose, distribute or use the > message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is > subject to archiving and review by persons other than the intended > recipient. Thank you. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From tomaz.cerar at gmail.com Wed Jun 29 11:17:48 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 29 Jun 2016 17:17:48 +0200 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: <5773E607.8020304@redhat.com> References: <5773E607.8020304@redhat.com> Message-ID: Other option would be that you are just using old version of client libs, they should be updated to match ones used in WildFly On Wed, Jun 29, 2016 at 5:15 PM, David M. Lloyd wrote: > JBoss Remoting uses a feature called "HTTP Upgrade", which basically > allows a client to connect to an HTTP port and then send a special HTTP > request which allows an "upgrade" to another arbitrary protocol. Later > versions of WildFly use this feature by default to reduce the count of > bound ports. > > What is probably happening is that you are connecting to a port that has > a plain Remoting listener on it, but the client is using "http-remoting" > which means "JBoss Remoting over HTTP Upgrade". So the client sends an > HTTP request, but the server interprets it as garbage because it is > expecting a Remoting framed packet instead. > > The fix is to either change the client from "http-remoting" to just > "remoting", or to change your server to use HTTP upgrade instead. > Information on this should be in the user docs. > > On 06/29/2016 10:08 AM, Marlow, Andrew wrote: > > Hello everyone, > > > > This is an appeal for help to resolve the error JBREM000200 that I get > > when a process connects to wildfly to do some JMS work. Details follow:- > > > > I am trying to switch from JBoss-as-7.1.1.Final to Wildfly 9.0.1.Final. > > My project runs on Microsoft Windows and Red Hat Linux (RHEL 5.11). I am > > using java jdk 1.8.0_60. The switch to wildfly worked fine on Windows, > > once I found out what the config file changes were, especially the > > switch from remote port 4777 to undertow http port 8080. However, on > > linux the wildfly server get an error as soon as one of my processes > > connects to it. The wildfly log is not very busy. Wildfly starts with > > not much logged then I get a one line error report for every connection > > attempt: > > > > 2016-06-29 15:09:09,555 ERROR [org.jboss.remoting.remote.connection] > > (default I/O-6) JBREM000200: Remote connection failed: > > java.io.IOException: XNIO000804: Received an invalid message length of > > 1195725856 > > > > The log of the process that connects contains a bit more detail: > > > > Error: NamingException detected during EndPointFactory JMS Server queue > > initialisation: Failed to connect to any server. Servers tried: > > [http-remoting://:8180 (java.io.EOFException: XNIO000812: > > Connection closed unexpectedly)] : Failed to connect to any server. > > Servers tried: [http-remoting://:8180 > > (java.io.EOFException: XNIO000812: Connection closed unexpectedly)] > > Cause unknown. : Stack trace: javax.naming.CommunicationException: > > Failed to connect to any server. Servers tried: > > [http-remoting://:8180 (java.io.EOFException: XNIO000812: > > Connection closed unexpectedly)] > > > > at > > > org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:244) > > > > at > > > org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149) > > > > at > > > org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130) > > > > at > > > org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272) > > > > at > > > org.jboss.naming.remote.client.RemoteContext.lookupInternal(RemoteContext.java:104) > > > > at > > > org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:93) > > > > at > > > org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:146) > > > > at javax.naming.InitialContext.lookup(InitialContext.java:417) > > > > I am using port 8180 because port 8080 is already taken (jenkins). > > > > I have googled for this causes of this error. I found several hits that > > suggested various ?solutions?. I tried them all. None of them worked. > > Here?s what I have tried: > > > > ?I ensured that no other process was using 8180. Some wildfly users have > > been in environments where a rogue process was writing to the undertow > > port. I used netstat in a loop to monitor any process using 8180. It > > just showed wildfly listening on it until my app made the connection > > attempt. Then it showed my app as well. No other apps. > > > > ?I tried using the port number offset feature. This used different port > > numbers but the problem remained. > > > > ?xml config, disable section security-realm-name=?ApplicationRealm?. > > This made no difference. > > > > ?In the interfaces section, interface name=?public? replace inet-address > > value=${jboss.bind.address:0.0.0.0} with value = > > ??. This did make a difference ? I lost > > connectivity completely. This was fixed by me changing localhost in my > > remoting URL to the ip address as a dotted quad. Then I got the invalid > > message length error back. > > > > This seems like a very deep mystery to me. It might force me to abandon > > using wildfly on linux and say that it is only supported on windows. Any > > help will be much appreciated. > > > > Regards, > > > > Andrew Marlow. > > > > http://www.andrewpetermarlow.co.uk > > > > _____________ > > The information contained in this message is proprietary and/or > > confidential. If you are not the intended recipient, please: (i) delete > > the message and all copies; (ii) do not disclose, distribute or use the > > message in any manner; and (iii) notify the sender immediately. In > > addition, please be aware that any message addressed to our domain is > > subject to archiving and review by persons other than the intended > > recipient. Thank you. > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/221cae1b/attachment-0001.html From Andrew.Marlow at fisglobal.com Wed Jun 29 13:07:22 2016 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Wed, 29 Jun 2016 17:07:22 +0000 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> Message-ID: Apologies for top-posting, I am forced to use LookOut! I never knew about HTTP Upgrade. I knew that wildfly multiplexed all the old jboss ports onto one http port but didn?t know this was how it was done. The client is most definately using http-remoting. I thought wildfly was as well, here is the end of the config file: Maybe this is where I am going wrong somehow.... From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of Toma? Cerar Sent: 29 June 2016 16:18 On Wed, Jun 29, 2016 at 5:15 PM, David M. Lloyd > wrote: JBoss Remoting uses a feature called "HTTP Upgrade", which basically allows a client to connect to an HTTP port and then send a special HTTP request which allows an "upgrade" to another arbitrary protocol. Later versions of WildFly use this feature by default to reduce the count of bound ports. What is probably happening is that you are connecting to a port that has a plain Remoting listener on it, but the client is using "http-remoting" which means "JBoss Remoting over HTTP Upgrade". So the client sends an HTTP request, but the server interprets it as garbage because it is expecting a Remoting framed packet instead. The fix is to either change the client from "http-remoting" to just "remoting", or to change your server to use HTTP upgrade instead. Information on this should be in the user docs. On 06/29/2016 10:08 AM, Marlow, Andrew wrote: > Hello everyone, > > This is an appeal for help to resolve the error JBREM000200 that I get > when a process connects to wildfly to do some JMS work. [snip] _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/9587b027/attachment.html From david.lloyd at redhat.com Wed Jun 29 13:15:18 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 29 Jun 2016 12:15:18 -0500 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> Message-ID: <57740226.4040807@redhat.com> This is just the socket bindings; it's the connectors that determine what the protocol is. On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > Apologies for top-posting, I am forced to use LookOut! > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all the > old jboss ports onto one http port but didn?t know this was how it was done. > > The client is most definately using http-remoting. I thought wildfly was > as well, here is the end of the config file: > > default-interface="public" > port-offset="${jboss.socket.binding.port-offset:0}"> > > port="${jboss.management.http.port:9991}"/> > > port="${jboss.management.https.port:9993}"/> > > > > > > > > > > > > > > port="5445"/> > > interface="messaging" port="5455"/> > > > > > > > > > > Maybe this is where I am going wrong somehow.... > > *From:*wildfly-dev-bounces at lists.jboss.org > [mailto:wildfly-dev-bounces at lists.jboss.org] *On Behalf Of *Toma? Cerar > *Sent:* 29 June 2016 16:18 > > On Wed, Jun 29, 2016 at 5:15 PM, David M. Lloyd > wrote: > > JBoss Remoting uses a feature called "HTTP Upgrade", which basically > allows a client to connect to an HTTP port and then send a special HTTP > request which allows an "upgrade" to another arbitrary protocol. Later > versions of WildFly use this feature by default to reduce the count of > bound ports. > > What is probably happening is that you are connecting to a port that has > a plain Remoting listener on it, but the client is using "http-remoting" > which means "JBoss Remoting over HTTP Upgrade". So the client sends an > HTTP request, but the server interprets it as garbage because it is > expecting a Remoting framed packet instead. > > The fix is to either change the client from "http-remoting" to just > "remoting", or to change your server to use HTTP upgrade instead. > Information on this should be in the user docs. > > > On 06/29/2016 10:08 AM, Marlow, Andrew wrote: > > Hello everyone, > > > > This is an appeal for help to resolve the error JBREM000200 that I get > > when a process connects to wildfly to do some JMS work. > > [snip] > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete > the message and all copies; (ii) do not disclose, distribute or use the > message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is > subject to archiving and review by persons other than the intended > recipient. Thank you. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From Andrew.Marlow at fisglobal.com Wed Jun 29 13:33:57 2016 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Wed, 29 Jun 2016 17:33:57 +0000 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: <57740226.4040807@redhat.com> References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> Message-ID: The connectors section of the config file is: false true 102400 -----Original Message----- From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd Sent: 29 June 2016 18:15 To: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 This is just the socket bindings; it's the connectors that determine what the protocol is. On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > Apologies for top-posting, I am forced to use LookOut! > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all > the old jboss ports onto one http port but didn?t know this was how it was done. > > The client is most definately using http-remoting. I thought wildfly > was as well, here is the end of the config file: > > default-interface="public" > port-offset="${jboss.socket.binding.port-offset:0}"> [snip] _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From anmiller at redhat.com Wed Jun 29 13:38:21 2016 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 29 Jun 2016 11:38:21 -0600 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> Message-ID: That's for messaging not for remoting. Andy On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew < Andrew.Marlow at fisglobal.com> wrote: > The connectors section of the config file is: > > > > false > true > 102400 > > > socket-binding="http"> > value="http-acceptor"/> > > socket-binding="http"> > value="http-acceptor-throughput"/> > > > > > > > name="http-acceptor"/> > name="http-acceptor-throughput"> > > > > > > > -----Original Message----- > From: wildfly-dev-bounces at lists.jboss.org [mailto: > wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd > Sent: 29 June 2016 18:15 > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an > invalid message length of 1195725856 > > This is just the socket bindings; it's the connectors that determine what > the protocol is. > > On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > > Apologies for top-posting, I am forced to use LookOut! > > > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all > > the old jboss ports onto one http port but didn?t know this was how it > was done. > > > > The client is most definately using http-remoting. I thought wildfly > > was as well, here is the end of the config file: > > > > > default-interface="public" > > port-offset="${jboss.socket.binding.port-offset:0}"> > > [snip] > > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/9d3d0270/attachment.html From Andrew.Marlow at fisglobal.com Wed Jun 29 13:41:58 2016 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Wed, 29 Jun 2016 17:41:58 +0000 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> Message-ID: Ah yes, so it is. How about this: From: Andrig Miller [mailto:anmiller at redhat.com] Sent: 29 June 2016 18:38 To: Marlow, Andrew Cc: wildfly-dev Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 That's for messaging not for remoting. Andy On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew > wrote: The connectors section of the config file is: false true 102400 -----Original Message----- From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd Sent: 29 June 2016 18:15 To: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 This is just the socket bindings; it's the connectors that determine what the protocol is. On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > Apologies for top-posting, I am forced to use LookOut! > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all > the old jboss ports onto one http port but didn?t know this was how it was done. > > The client is most definately using http-remoting. I thought wildfly > was as well, here is the end of the config file: > > default-interface="public" > port-offset="${jboss.socket.binding.port-offset:0}"> [snip] _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/ce8238f1/attachment-0001.html From anmiller at redhat.com Wed Jun 29 14:06:24 2016 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 29 Jun 2016 12:06:24 -0600 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> Message-ID: What did your configuration look like on Windows? You said it was working on Windows. It seems strange that it would work on Windows and fail on Linux. Perhaps the entire configuration could be posted. Andy On Wed, Jun 29, 2016 at 11:41 AM, Marlow, Andrew < Andrew.Marlow at fisglobal.com> wrote: > Ah yes, so it is. How about this: > > > > > > > > socket-binding="remoting"/> > > connector-ref="default"/> > > > > > > > > *From:* Andrig Miller [mailto:anmiller at redhat.com] > *Sent:* 29 June 2016 18:38 > *To:* Marlow, Andrew > *Cc:* wildfly-dev > > *Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an > invalid message length of 1195725856 > > > > That's for messaging not for remoting. > > Andy > > > > On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew < > Andrew.Marlow at fisglobal.com> wrote: > > The connectors section of the config file is: > > > > false > true > 102400 > > > socket-binding="http"> > value="http-acceptor"/> > > socket-binding="http"> > value="http-acceptor-throughput"/> > > > > > > > name="http-acceptor"/> > name="http-acceptor-throughput"> > > > > > > > -----Original Message----- > From: wildfly-dev-bounces at lists.jboss.org [mailto: > wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd > Sent: 29 June 2016 18:15 > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an > invalid message length of 1195725856 > > This is just the socket bindings; it's the connectors that determine what > the protocol is. > > On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > > Apologies for top-posting, I am forced to use LookOut! > > > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all > > the old jboss ports onto one http port but didn?t know this was how it > was done. > > > > The client is most definately using http-remoting. I thought wildfly > > was as well, here is the end of the config file: > > > > > default-interface="public" > > port-offset="${jboss.socket.binding.port-offset:0}"> > > [snip] > > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > > Andrig (Andy) T. Miller > > Global Platform Director, Middleware > > Red Hat, Inc. > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/5df93978/attachment.html From david.lloyd at redhat.com Wed Jun 29 14:12:48 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 29 Jun 2016 13:12:48 -0500 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> Message-ID: <57740FA0.6080103@redhat.com> So in this case your "connector" is using the regular Remoting protocol and it's using the "remoting" socket binding, which you have defined as port 8180. Then you connect with http-remoting and it blows up. If you want to connect with http-remoting then you need to make sure that your http-connector is referencing the connector which is listening on the port you're connecting to. On 06/29/2016 12:41 PM, Marlow, Andrew wrote: > Ah yes, so it is. How about this: > > > > > > socket-binding="remoting"/> > > connector-ref="default"/> > > > > *From:*Andrig Miller [mailto:anmiller at redhat.com] > *Sent:* 29 June 2016 18:38 > *To:* Marlow, Andrew > *Cc:* wildfly-dev > *Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an > invalid message length of 1195725856 > > That's for messaging not for remoting. > > Andy > > On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew > > wrote: > > The connectors section of the config file is: > > > > false > true > 102400 > > > socket-binding="http"> > value="http-acceptor"/> > > name="http-connector-throughput" socket-binding="http"> > value="http-acceptor-throughput"/> > > > > > > > name="http-acceptor"/> > name="http-acceptor-throughput"> > > > > > > > -----Original Message----- > From: wildfly-dev-bounces at lists.jboss.org > > [mailto:wildfly-dev-bounces at lists.jboss.org > ] On Behalf Of David M. > Lloyd > Sent: 29 June 2016 18:15 > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received > an invalid message length of 1195725856 > > This is just the socket bindings; it's the connectors that determine > what the protocol is. > > On 06/29/2016 12:07 PM, Marlow, Andrew wrote: > > Apologies for top-posting, I am forced to use LookOut! > > > > I never knew about HTTP Upgrade. I knew that wildfly multiplexed all > > the old jboss ports onto one http port but didn?t know this was how it was done. > > > > The client is most definately using http-remoting. I thought wildfly > > was as well, here is the end of the config file: > > > > > default-interface="public" > > port-offset="${jboss.socket.binding.port-offset:0}"> > > [snip] > > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) > delete the message and all copies; (ii) do not disclose, distribute > or use the message in any manner; and (iii) notify the sender > immediately. In addition, please be aware that any message addressed > to our domain is subject to archiving and review by persons other > than the intended recipient. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > > Andrig (Andy) T. Miller > > Global Platform Director, Middleware > > Red Hat, Inc. > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete > the message and all copies; (ii) do not disclose, distribute or use the > message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is > subject to archiving and review by persons other than the intended > recipient. Thank you. > > _____________ > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete > the message and all copies; (ii) do not disclose, distribute or use the > message in any manner; and (iii) notify the sender immediately. In > addition, please be aware that any message addressed to our domain is > subject to archiving and review by persons other than the intended > recipient. Thank you. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From claudio at claudius.com.br Wed Jun 29 14:31:53 2016 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 29 Jun 2016 15:31:53 -0300 Subject: [wildfly-dev] Capabilities and capability-reference not registered in github Message-ID: Hi, looking at current wildfly capabilities, I see the following org.wildfly.batch.configuration org.wildfly.batch.job.repository org.wildfly.batch.thread.pool org.wildfly.clustering.infinispan.cache-container.cache.store.jdbc.data-source org.wildfly.clustering.infinispan.cache-container.cache.store.remote.outbound-socket-binding org.wildfly.clustering.protocol.socket-binding org.wildfly.clustering.singleton.default-policy org.wildfly.clustering.singleton.policy org.wildfly.clustering.singleton.singleton-policy.election-policy.socket-binding-preference org.wildfly.clustering.transport.diagnostics-socket-binding org.wildfly.data-source org.wildfly.domain.profile org.wildfly.domain.server-config org.wildfly.domain.server-group org.wildfly.domain.socket-binding-group org.wildfly.extension.sar-deployment org.wildfly.extension.undertow.handler org.wildfly.io.buffer-pool org.wildfly.io.max-threads org.wildfly.io.worker org.wildfly.jsr77 org.wildfly.management.jmx org.wildfly.management.jmx.remote org.wildfly.management.native-interface org.wildfly.network.interface org.wildfly.network.outbound-socket-binding org.wildfly.network.socket-binding org.wildfly.remoting.endpoint org.wildfly.request-controller org.wildfly.security org.wildfly.transactions org.wildfly.undertow.listener But they differ from the https://github.com/wildfly/wildfly-capabilities/ Do you plan to update the git repo ? -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From Andrew.Marlow at fisglobal.com Wed Jun 29 14:38:27 2016 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Wed, 29 Jun 2016 18:38:27 +0000 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: <57740FA0.6080103@redhat.com> References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> <57740FA0.6080103@redhat.com> Message-ID: Thankyou to David for identifying the problem. It is indeed a mystery why this works on windows. Never mind, once I've got the config working on linux I will try the config on windows. If Windows continues to work then that will be my new config file. Now I just need to know how to change the config. Sorry I'm being a bit slow here but I don't quite see how to say that I want http-remoting instead of remoting. When I change "remoting" to "http-remoting" in the socket-binding-group section wildfly complains that it doesn't like it. The error is:- 19:23:43,096 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "remoting"), ("connector" => "remoting-connector") ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.remoting-connector is missing [jboss.binding.remoting]"]} Maybe I need to add something to my global modules list. Here is what it is right now: Please note: I am reluctant to post the entire config because the project is proprietary and contains proprietary bits. -----Original Message----- From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd Sent: 29 June 2016 19:13 To: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 So in this case your "connector" is using the regular Remoting protocol and it's using the "remoting" socket binding, which you have defined as port 8180. Then you connect with http-remoting and it blows up. If you want to connect with http-remoting then you need to make sure that your http-connector is referencing the connector which is listening on the port you're connecting to. On 06/29/2016 12:41 PM, Marlow, Andrew wrote: > Ah yes, so it is. How about this: > > > > > > socket-binding="remoting"/> > > connector-ref="default"/> > > > > *From:*Andrig Miller [mailto:anmiller at redhat.com] > *Sent:* 29 June 2016 18:38 > *To:* Marlow, Andrew > *Cc:* wildfly-dev > *Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received > an invalid message length of 1195725856 > > That's for messaging not for remoting. > > Andy > > On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew > > wrote: > > The connectors section of the config file is: > > > > false > true > 102400 > > > > > > > > > > > > > > name="http-acceptor"/> > name="http-acceptor-throughput"> > > > > > [snip] _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From claudio at claudius.com.br Wed Jun 29 14:47:00 2016 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 29 Jun 2016 15:47:00 -0300 Subject: [wildfly-dev] Capabilities and capability-reference not registered in github In-Reply-To: References: Message-ID: Also, FYI only these are used (have capability-reference) org.wildfly.batch.job.repository org.wildfly.batch.thread.pool org.wildfly.clustering.singleton.policy org.wildfly.data-source org.wildfly.domain.profile org.wildfly.domain.server-group org.wildfly.domain.socket-binding-group org.wildfly.io.buffer-pool org.wildfly.io.worker org.wildfly.network.interface org.wildfly.network.outbound-socket-binding org.wildfly.network.socket-binding -- claudio at claudius.com.br http://www.claudius.com.br From david.lloyd at redhat.com Wed Jun 29 14:52:06 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 29 Jun 2016 13:52:06 -0500 Subject: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 In-Reply-To: References: <5773E607.8020304@redhat.com> <57740226.4040807@redhat.com> <57740FA0.6080103@redhat.com> Message-ID: <577418D6.3020900@redhat.com> You already have an http-remoting connector set up. It's referencing the web connector "default", which in turn (I can only guess based on your bindings config, since you haven't shared your web server config) is likely listening on port 8280. So if you connect to that port using "http-remoting:", *or* connect to port 8180 using "remoting:", you'll be good to go. You just can't connect to 8180 using "http-remoting" or 8280 using "remoting", as attempting either of these will result in error. On 06/29/2016 01:38 PM, Marlow, Andrew wrote: > Thankyou to David for identifying the problem. It is indeed a mystery why this works on windows. Never mind, once I've got the config working on linux I will try the config on windows. If Windows continues to work then that will be my new config file. > > Now I just need to know how to change the config. Sorry I'm being a bit slow here but I don't quite see how to say that I want http-remoting instead of remoting. When I change "remoting" to "http-remoting" in the > socket-binding-group section wildfly complains that it doesn't like it. The error is:- > > 19:23:43,096 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "remoting"), > ("connector" => "remoting-connector") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.remoting-connector is missing [jboss.binding.remoting]"]} > > Maybe I need to add something to my global modules list. Here is what it is right now: > > > > > > > > > > > > > > > > > > > > Please note: I am reluctant to post the entire config because the project is proprietary and contains proprietary bits. > > -----Original Message----- > From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of David M. Lloyd > Sent: 29 June 2016 19:13 > To: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received an invalid message length of 1195725856 > > So in this case your "connector" is using the regular Remoting protocol and it's using the "remoting" socket binding, which you have defined as port 8180. Then you connect with http-remoting and it blows up. > > If you want to connect with http-remoting then you need to make sure that your http-connector is referencing the connector which is listening on the port you're connecting to. > > On 06/29/2016 12:41 PM, Marlow, Andrew wrote: >> Ah yes, so it is. How about this: >> >> >> >> >> >> > socket-binding="remoting"/> >> >> > connector-ref="default"/> >> >> >> >> *From:*Andrig Miller [mailto:anmiller at redhat.com] >> *Sent:* 29 June 2016 18:38 >> *To:* Marlow, Andrew >> *Cc:* wildfly-dev >> *Subject:* Re: [wildfly-dev] JBREM000200 error: XNI0000804: Received >> an invalid message length of 1195725856 >> >> That's for messaging not for remoting. >> >> Andy >> >> On Wed, Jun 29, 2016 at 11:33 AM, Marlow, Andrew >> > wrote: >> >> The connectors section of the config file is: >> >> >> >> false >> true >> 102400 >> >> >> >> >> >> >> >> >> >> >> >> >> >> > name="http-acceptor"/> >> > name="http-acceptor-throughput"> >> >> >> >> >> > > [snip] > > > _____________ > The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From brian.stansberry at redhat.com Wed Jun 29 17:43:09 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 29 Jun 2016 16:43:09 -0500 Subject: [wildfly-dev] Capabilities and capability-reference not registered in github In-Reply-To: References: Message-ID: <688F8256-1D04-4E00-8CF8-1538171C0CD1@redhat.com> Yes, people who created capabilities need to file the descriptions. Myself included it seems. :( -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat > On Jun 29, 2016, at 1:31 PM, Claudio Miranda wrote: > > Hi, looking at current wildfly capabilities, I see the following > > org.wildfly.batch.configuration > org.wildfly.batch.job.repository > org.wildfly.batch.thread.pool > org.wildfly.clustering.infinispan.cache-container.cache.store.jdbc.data-source > org.wildfly.clustering.infinispan.cache-container.cache.store.remote.outbound-socket-binding > org.wildfly.clustering.protocol.socket-binding > org.wildfly.clustering.singleton.default-policy > org.wildfly.clustering.singleton.policy > org.wildfly.clustering.singleton.singleton-policy.election-policy.socket-binding-preference > org.wildfly.clustering.transport.diagnostics-socket-binding > org.wildfly.data-source > org.wildfly.domain.profile > org.wildfly.domain.server-config > org.wildfly.domain.server-group > org.wildfly.domain.socket-binding-group > org.wildfly.extension.sar-deployment > org.wildfly.extension.undertow.handler > org.wildfly.io.buffer-pool > org.wildfly.io.max-threads > org.wildfly.io.worker > org.wildfly.jsr77 > org.wildfly.management.jmx > org.wildfly.management.jmx.remote > org.wildfly.management.native-interface > org.wildfly.network.interface > org.wildfly.network.outbound-socket-binding > org.wildfly.network.socket-binding > org.wildfly.remoting.endpoint > org.wildfly.request-controller > org.wildfly.security > org.wildfly.transactions > org.wildfly.undertow.listener > > But they differ from the https://github.com/wildfly/wildfly-capabilities/ > > Do you plan to update the git repo ? > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/a44a0d55/attachment-0001.html From brian.stansberry at redhat.com Wed Jun 29 17:55:23 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 29 Jun 2016 16:55:23 -0500 Subject: [wildfly-dev] Capabilities and capability-reference not registered in github In-Reply-To: References: Message-ID: <9C098C24-AE70-4EEC-9B3F-81C1B4D680E1@redhat.com> There can be a few reasons for that. One is capabilities can require others without a reference attrribute in the model. (I think such attributes what you meant by capability-reference.) Capabilities that are not dynamically named (i.e. there?s only one of the type) are not referenced via attributes. A number of things for example require org.wildfly.management.jmx. Another is the introduction of capabilities in the code is incomplete, so things may still use other services without having done the proper wiring via capabilities. A third is only a capability can require a capability. That means if something needs a capability it itself has to register a capability. We need to know who the dependents are so we know what will happen if a depended-on capability is removed. But it?s possible no other capability will require the dependent. It?s debatable but I think that?s ok. For example org,wildly.jsr77 depends on org.wildfly.management.jmx but nothing depends on it. But it seems useful to me to know that a server has capability org,wildly.jsr77 present. > On Jun 29, 2016, at 1:47 PM, Claudio Miranda wrote: > > Also, FYI only these are used (have capability-reference) > > org.wildfly.batch.job.repository > org.wildfly.batch.thread.pool > org.wildfly.clustering.singleton.policy > org.wildfly.data-source > org.wildfly.domain.profile > org.wildfly.domain.server-group > org.wildfly.domain.socket-binding-group > org.wildfly.io.buffer-pool > org.wildfly.io.worker > org.wildfly.network.interface > org.wildfly.network.outbound-socket-binding > org.wildfly.network.socket-binding > > -- > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160629/c6b31d56/attachment.html