From darran.lofthouse at jboss.com Wed Nov 1 09:22:01 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 01 Nov 2017 13:22:01 +0000 Subject: [wildfly-dev] EE Features in WildFly Core Message-ID: Just sending this e-mail to check how we feel about EE APIs leaking into WildFly Core. The WildFly Elytron subsystem already contains JACC related configuration so has a dependency on the JACC APIs - JASPIC is about to be added next which will also need a dependency on the JASPIC API so I wanted to check if we are happy with this or if we want to get this corrected. I see a few options but other inspiration is also welcome. 1 - Do Nothing Just continue adding EE related security configuration to the WildFly Elytron subsystem. 2 - Move the Elytron subsystem to WildFly We have been over this in the past so I think we agree this would not work for us. 3 - Dynamically exclude portions of the model if not being used for EE management. This would help the subsystem be specific for it's server process but TBH does not solve the underlying problem as it would still be within WildFly Core. 4 - Add an elytron-ee subsystem to WildFly Capabilities allow two subsystems to work together well, main issue now security related config could be across two subsystems although very minor difference in the addres. 5 - Any other ideas? Regards, Darran Lofthouse. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171101/cd949b8b/attachment.html From brian.stansberry at redhat.com Wed Nov 1 10:52:59 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 1 Nov 2017 09:52:59 -0500 Subject: [wildfly-dev] EE Features in WildFly Core In-Reply-To: References: Message-ID: I think for now, 1 - Do Nothing because the provisioning stuff is soon enough going to allow something like 3. How? A package related to elytron will have an optional dependency on a package related to jaspic. Since it's optional it won't be included in a default provisioned server. A jaspic "feature" (part of the elytron configuration) will have a hard dependency on that jaspic package. So if the provisioning spec includes that feature, the package will be included in the install. Something in full could possibly also have a hard dependency on jaspic. (Maybe not I don't know the EE details.) If so having that thing present would also ensure the jaspic package is included. The semi-edge case is the user provisions something with no hard dep on the jaspic package, and then wants to come along with the CLI/HAL and configure jaspic. Won't work. The management handlers should deal with that with some nice error message. Another variant is the jaspic package is an optional dep but is included by default, avoiding the semi-edge case. So the dist is bigger than needed, but the provisioning tool makes it easier to exclude it than it is now, since the provisioning file can declare that the jaspic package isn't wanted via a simple exclude element. Bottom line is I think the provisioning tooling is going to ease the pain of slimming enough that jumping through hoops to make our feature packs smaller becomes less necessary. On Wed, Nov 1, 2017 at 8:22 AM, Darran Lofthouse wrote: > Just sending this e-mail to check how we feel about EE APIs leaking into > WildFly Core. The WildFly Elytron subsystem already contains JACC related > configuration so has a dependency on the JACC APIs - JASPIC is about to be > added next which will also need a dependency on the JASPIC API so I wanted > to check if we are happy with this or if we want to get this corrected. > > I see a few options but other inspiration is also welcome. > > 1 - Do Nothing > > Just continue adding EE related security configuration to the WildFly > Elytron subsystem. > > 2 - Move the Elytron subsystem to WildFly > > We have been over this in the past so I think we agree this would not work > for us. > > 3 - Dynamically exclude portions of the model if not being used for EE > management. > > This would help the subsystem be specific for it's server process but TBH > does not solve the underlying problem as it would still be within WildFly > Core. > > 4 - Add an elytron-ee subsystem to WildFly > > Capabilities allow two subsystems to work together well, main issue now > security related config could be across two subsystems although very minor > difference in the addres. > > 5 - Any other ideas? > > Regards, > Darran Lofthouse. > > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171101/4cbb4976/attachment.html From jperkins at redhat.com Wed Nov 1 13:11:45 2017 From: jperkins at redhat.com (James Perkins) Date: Wed, 1 Nov 2017 10:11:45 -0700 Subject: [wildfly-dev] EE Features in WildFly Core In-Reply-To: References: Message-ID: I'm a +1 to what Brian said. I also think if we keep adding EE stuff to core then we've defeated the purpose of the split. While for dev it's kind of a PITA the split is good for things like Arquillian where they can have a dependency on WildFly Core and not require a dependency on any version of WildFly Full. The same is likely true for any project that just manages a server. On Wed, Nov 1, 2017 at 7:52 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > I think for now, 1 - Do Nothing because the provisioning stuff is soon > enough going to allow something like 3. How? > > A package related to elytron will have an optional dependency on a package > related to jaspic. Since it's optional it won't be included in a default > provisioned server. > > A jaspic "feature" (part of the elytron configuration) will have a hard > dependency on that jaspic package. So if the provisioning spec includes > that feature, the package will be included in the install. > > Something in full could possibly also have a hard dependency on jaspic. > (Maybe not I don't know the EE details.) If so having that thing present > would also ensure the jaspic package is included. > > The semi-edge case is the user provisions something with no hard dep on > the jaspic package, and then wants to come along with the CLI/HAL and > configure jaspic. Won't work. The management handlers should deal with that > with some nice error message. > > Another variant is the jaspic package is an optional dep but is included > by default, avoiding the semi-edge case. So the dist is bigger than needed, > but the provisioning tool makes it easier to exclude it than it is now, > since the provisioning file can declare that the jaspic package isn't > wanted via a simple exclude element. > > Bottom line is I think the provisioning tooling is going to ease the pain > of slimming enough that jumping through hoops to make our feature packs > smaller becomes less necessary. > > > On Wed, Nov 1, 2017 at 8:22 AM, Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> Just sending this e-mail to check how we feel about EE APIs leaking into >> WildFly Core. The WildFly Elytron subsystem already contains JACC related >> configuration so has a dependency on the JACC APIs - JASPIC is about to be >> added next which will also need a dependency on the JASPIC API so I wanted >> to check if we are happy with this or if we want to get this corrected. >> >> I see a few options but other inspiration is also welcome. >> >> 1 - Do Nothing >> >> Just continue adding EE related security configuration to the WildFly >> Elytron subsystem. >> >> 2 - Move the Elytron subsystem to WildFly >> >> We have been over this in the past so I think we agree this would not >> work for us. >> >> 3 - Dynamically exclude portions of the model if not being used for EE >> management. >> >> This would help the subsystem be specific for it's server process but TBH >> does not solve the underlying problem as it would still be within WildFly >> Core. >> >> 4 - Add an elytron-ee subsystem to WildFly >> >> Capabilities allow two subsystems to work together well, main issue now >> security related config could be across two subsystems although very minor >> difference in the addres. >> >> 5 - Any other ideas? >> >> Regards, >> Darran Lofthouse. >> >> >> _______________________________________________ >> 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 > 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/20171101/75df0d8c/attachment-0001.html From darran.lofthouse at jboss.com Thu Nov 2 04:24:40 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 02 Nov 2017 08:24:40 +0000 Subject: [wildfly-dev] EE Features in WildFly Core In-Reply-To: References: Message-ID: To clarify "Do nothing" means we add more EE features to Core - i.e. JASPIC is now on it's way. On Wed, 1 Nov 2017 at 17:20 James Perkins wrote: > I'm a +1 to what Brian said. > > I also think if we keep adding EE stuff to core then we've defeated the > purpose of the split. While for dev it's kind of a PITA the split is good > for things like Arquillian where they can have a dependency on WildFly Core > and not require a dependency on any version of WildFly Full. The same is > likely true for any project that just manages a server. > > On Wed, Nov 1, 2017 at 7:52 AM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> I think for now, 1 - Do Nothing because the provisioning stuff is soon >> enough going to allow something like 3. How? >> >> A package related to elytron will have an optional dependency on a >> package related to jaspic. Since it's optional it won't be included in a >> default provisioned server. >> >> A jaspic "feature" (part of the elytron configuration) will have a hard >> dependency on that jaspic package. So if the provisioning spec includes >> that feature, the package will be included in the install. >> >> Something in full could possibly also have a hard dependency on jaspic. >> (Maybe not I don't know the EE details.) If so having that thing present >> would also ensure the jaspic package is included. >> >> The semi-edge case is the user provisions something with no hard dep on >> the jaspic package, and then wants to come along with the CLI/HAL and >> configure jaspic. Won't work. The management handlers should deal with that >> with some nice error message. >> >> Another variant is the jaspic package is an optional dep but is included >> by default, avoiding the semi-edge case. So the dist is bigger than needed, >> but the provisioning tool makes it easier to exclude it than it is now, >> since the provisioning file can declare that the jaspic package isn't >> wanted via a simple exclude element. >> >> Bottom line is I think the provisioning tooling is going to ease the pain >> of slimming enough that jumping through hoops to make our feature packs >> smaller becomes less necessary. >> >> >> On Wed, Nov 1, 2017 at 8:22 AM, Darran Lofthouse < >> darran.lofthouse at jboss.com> wrote: >> >>> Just sending this e-mail to check how we feel about EE APIs leaking into >>> WildFly Core. The WildFly Elytron subsystem already contains JACC related >>> configuration so has a dependency on the JACC APIs - JASPIC is about to be >>> added next which will also need a dependency on the JASPIC API so I wanted >>> to check if we are happy with this or if we want to get this corrected. >>> >>> I see a few options but other inspiration is also welcome. >>> >>> 1 - Do Nothing >>> >>> Just continue adding EE related security configuration to the WildFly >>> Elytron subsystem. >>> >>> 2 - Move the Elytron subsystem to WildFly >>> >>> We have been over this in the past so I think we agree this would not >>> work for us. >>> >>> 3 - Dynamically exclude portions of the model if not being used for EE >>> management. >>> >>> This would help the subsystem be specific for it's server process but >>> TBH does not solve the underlying problem as it would still be within >>> WildFly Core. >>> >>> 4 - Add an elytron-ee subsystem to WildFly >>> >>> Capabilities allow two subsystems to work together well, main issue now >>> security related config could be across two subsystems although very minor >>> difference in the addres. >>> >>> 5 - Any other ideas? >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> _______________________________________________ >>> 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 >> 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 > _______________________________________________ > 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/20171102/2634d41a/attachment.html From rory.odonnell at oracle.com Fri Nov 3 06:21:46 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Nov 2017 10:21:46 +0000 Subject: [wildfly-dev] JDK 10 b29 Early Access is available on jdk.java.net Message-ID: <5d959ad3-1ce2-3f27-d1ad-deb192af8da8@oracle.com> Hi Jason/Tomaz, JDK 10 Early Access? build 29 is available at : - jdk.java.net/10/ JDK 10 Early Access Release Notes are available [1] JDK 10 Schedule, Status & Features are available [2] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [3] , feedback via the mailing list to Mark please. Feedback - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://jdk.java.net/10/release-notes [2] http://openjdk.java.net/projects/jdk/10/ [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.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/20171103/5b7b8adb/attachment.html From david.lloyd at redhat.com Fri Nov 3 10:03:52 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 3 Nov 2017 09:03:52 -0500 Subject: [wildfly-dev] Introducing a new thread pool implementation Message-ID: For WildFly 12 I intend to introduce a new thread pool implementation [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor in the main codebases of WildFly and WildFly Core, and also in several support projects such as JBoss MSC and XNIO. The thread pool has the following desirable characteristics: ? Idle threads are always reused before queueing tasks or starting new threads ? The most recently used idle thread is always preferred, which allows the pool to shrink when it is not fully utilized ? Useful core/max thread pool size distinction ? API-equivalent to ThreadPoolExecutor ? Performance parity with common ThreadPoolExecutor configurations ? Suitable as a replacement for other jboss-threads thread pool types as well In addition, it presents the following features: ? Configure via a builder API ? Configurable exception handler ? Integrated task queue with optional size limit ? Full complement of standard metrics, which can be disabled ? Configurable rejection handler in the form of a handoff executor ? An optional growth-resistance algorithm which can be applied to larger pools to create growth resistance between the core and maximum pool size ? An optional post-terminate task ? A few system property based adjustments that can be applied for experimental purposes ? A global flag which can be set via system property to recommend that the new thread pool should be disabled, allowing an emergency fallback in case of an unexpected problem Design-wise, the thread pool is based on a special lock-free/wait-free combination FIFO/LIFO queue algorithm. See [3] for a more complete explanation of internal operation, if you're curious about the gritty details. This change has a few implications with regards to the application server: ? Thread pools with a core- and max-size which were locked together may now have these variables decoupled in a safe and useful manner ? Thread pool configurations in the management model which previously featured only a max size can now have a core size attribute introduced Most of the thread pools we use are built and configured within the wildfly-core code base; that is where the first part of this change will be done. Later on there will be a follow-up change for WildFly proper, but this of course can not happen until the core change is merged and a core release done, so expect that part somewhat later. The initial WIP change to wildfly-core can be found here [4]. Note that no pull request will be opened until all the components are Final. I have done a good deal of testing already, but I will be doing more CI testing on other platforms and configurations before submitting the PR. I've made an attempt to link up all the JIRAs that are related to this effort from [1] (either directly or indirectly). If you find another JIRA that you think is related, or if you have questions or concerns, ask on this list, or you can ping me directly on HipChat or IRC. Thanks! [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread pool implementation [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 [3] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807a689506af0b70791d93ae81cc1cR67 [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool -- - DML From anmiller at redhat.com Fri Nov 3 11:17:09 2017 From: anmiller at redhat.com (Andrig Miller) Date: Fri, 3 Nov 2017 09:17:09 -0600 Subject: [wildfly-dev] Introducing a new thread pool implementation In-Reply-To: References: Message-ID: I think it would be wise for the performance team to test this out at scale using our lab, as I'm sure you would agree. If you could point us at a particular build, or point us at what to build, we can do that testing in parallel and give feedback on how this is working. Thanks. Andy On Fri, Nov 3, 2017 at 8:03 AM, David Lloyd wrote: > For WildFly 12 I intend to introduce a new thread pool implementation > [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor > in the main codebases of WildFly and WildFly Core, and also in several > support projects such as JBoss MSC and XNIO. > > The thread pool has the following desirable characteristics: > > ? Idle threads are always reused before queueing tasks or starting new > threads > ? The most recently used idle thread is always preferred, which allows > the pool to shrink when it is not fully utilized > ? Useful core/max thread pool size distinction > ? API-equivalent to ThreadPoolExecutor > ? Performance parity with common ThreadPoolExecutor configurations > ? Suitable as a replacement for other jboss-threads thread pool types as > well > > In addition, it presents the following features: > > ? Configure via a builder API > ? Configurable exception handler > ? Integrated task queue with optional size limit > ? Full complement of standard metrics, which can be disabled > ? Configurable rejection handler in the form of a handoff executor > ? An optional growth-resistance algorithm which can be applied to > larger pools to create growth resistance between the core and maximum > pool size > ? An optional post-terminate task > ? A few system property based adjustments that can be applied for > experimental purposes > ? A global flag which can be set via system property to recommend that > the new thread pool should be disabled, allowing an emergency fallback > in case of an unexpected problem > > Design-wise, the thread pool is based on a special lock-free/wait-free > combination FIFO/LIFO queue algorithm. See [3] for a more complete > explanation of internal operation, if you're curious about the gritty > details. > > This change has a few implications with regards to the application server: > ? Thread pools with a core- and max-size which were locked together > may now have these variables decoupled in a safe and useful manner > ? Thread pool configurations in the management model which previously > featured only a max size can now have a core size attribute introduced > > Most of the thread pools we use are built and configured within the > wildfly-core code base; that is where the first part of this change > will be done. Later on there will be a follow-up change for WildFly > proper, but this of course can not happen until the core change is > merged and a core release done, so expect that part somewhat later. > The initial WIP change to wildfly-core can be found here [4]. Note > that no pull request will be opened until all the components are > Final. I have done a good deal of testing already, but I will be > doing more CI testing on other platforms and configurations before > submitting the PR. > > I've made an attempt to link up all the JIRAs that are related to this > effort from [1] (either directly or indirectly). If you find another > JIRA that you think is related, or if you have questions or concerns, > ask on this list, or you can ping me directly on HipChat or IRC. > > Thanks! > > [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread > pool implementation > [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 > [3] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff- > f5807a689506af0b70791d93ae81cc1cR67 > [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool > > -- > - DML > > _______________________________________________ > 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/20171103/8413b64b/attachment-0001.html From david.lloyd at redhat.com Fri Nov 3 11:33:09 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 3 Nov 2017 10:33:09 -0500 Subject: [wildfly-dev] Introducing a new thread pool implementation In-Reply-To: References: Message-ID: The proposed change can be found here: https://github.com/dmlloyd/wildfly-core/tree/threadpool You can build that wildfly-core and then build a wildfly which uses the produced build. The whole process with -DskipTests should take under 10 minutes. I would be very happy to know what the performance team finds, particularly in high-contention scenarios. Thanks! On Fri, Nov 3, 2017 at 10:17 AM, Andrig Miller wrote: > I think it would be wise for the performance team to test this out at scale > using our lab, as I'm sure you would agree. > > If you could point us at a particular build, or point us at what to build, > we can do that testing in parallel and give feedback on how this is working. > > Thanks. > > Andy > > On Fri, Nov 3, 2017 at 8:03 AM, David Lloyd wrote: >> >> For WildFly 12 I intend to introduce a new thread pool implementation >> [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor >> in the main codebases of WildFly and WildFly Core, and also in several >> support projects such as JBoss MSC and XNIO. >> >> The thread pool has the following desirable characteristics: >> >> ? Idle threads are always reused before queueing tasks or starting new >> threads >> ? The most recently used idle thread is always preferred, which allows >> the pool to shrink when it is not fully utilized >> ? Useful core/max thread pool size distinction >> ? API-equivalent to ThreadPoolExecutor >> ? Performance parity with common ThreadPoolExecutor configurations >> ? Suitable as a replacement for other jboss-threads thread pool types as >> well >> >> In addition, it presents the following features: >> >> ? Configure via a builder API >> ? Configurable exception handler >> ? Integrated task queue with optional size limit >> ? Full complement of standard metrics, which can be disabled >> ? Configurable rejection handler in the form of a handoff executor >> ? An optional growth-resistance algorithm which can be applied to >> larger pools to create growth resistance between the core and maximum >> pool size >> ? An optional post-terminate task >> ? A few system property based adjustments that can be applied for >> experimental purposes >> ? A global flag which can be set via system property to recommend that >> the new thread pool should be disabled, allowing an emergency fallback >> in case of an unexpected problem >> >> Design-wise, the thread pool is based on a special lock-free/wait-free >> combination FIFO/LIFO queue algorithm. See [3] for a more complete >> explanation of internal operation, if you're curious about the gritty >> details. >> >> This change has a few implications with regards to the application server: >> ? Thread pools with a core- and max-size which were locked together >> may now have these variables decoupled in a safe and useful manner >> ? Thread pool configurations in the management model which previously >> featured only a max size can now have a core size attribute introduced >> >> Most of the thread pools we use are built and configured within the >> wildfly-core code base; that is where the first part of this change >> will be done. Later on there will be a follow-up change for WildFly >> proper, but this of course can not happen until the core change is >> merged and a core release done, so expect that part somewhat later. >> The initial WIP change to wildfly-core can be found here [4]. Note >> that no pull request will be opened until all the components are >> Final. I have done a good deal of testing already, but I will be >> doing more CI testing on other platforms and configurations before >> submitting the PR. >> >> I've made an attempt to link up all the JIRAs that are related to this >> effort from [1] (either directly or indirectly). If you find another >> JIRA that you think is related, or if you have questions or concerns, >> ask on this list, or you can ping me directly on HipChat or IRC. >> >> Thanks! >> >> [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread >> pool implementation >> [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 >> [3] >> https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807a689506af0b70791d93ae81cc1cR67 >> [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool >> >> -- >> - DML >> >> _______________________________________________ >> 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. -- - DML From anmiller at redhat.com Fri Nov 3 11:35:34 2017 From: anmiller at redhat.com (Andrig Miller) Date: Fri, 3 Nov 2017 09:35:34 -0600 Subject: [wildfly-dev] Introducing a new thread pool implementation In-Reply-To: References: Message-ID: Sounds good. If we have time this next week, we will see about getting a first test done during our face to face week. It's a very busy week though, so we may not be able to until after next week. Thanks for the pointers. Andy On Fri, Nov 3, 2017 at 9:33 AM, David Lloyd wrote: > The proposed change can be found here: > https://github.com/dmlloyd/wildfly-core/tree/threadpool > > You can build that wildfly-core and then build a wildfly which uses > the produced build. The whole process with -DskipTests should take > under 10 minutes. I would be very happy to know what the performance > team finds, particularly in high-contention scenarios. Thanks! > > On Fri, Nov 3, 2017 at 10:17 AM, Andrig Miller > wrote: > > I think it would be wise for the performance team to test this out at > scale > > using our lab, as I'm sure you would agree. > > > > If you could point us at a particular build, or point us at what to > build, > > we can do that testing in parallel and give feedback on how this is > working. > > > > Thanks. > > > > Andy > > > > On Fri, Nov 3, 2017 at 8:03 AM, David Lloyd > wrote: > >> > >> For WildFly 12 I intend to introduce a new thread pool implementation > >> [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor > >> in the main codebases of WildFly and WildFly Core, and also in several > >> support projects such as JBoss MSC and XNIO. > >> > >> The thread pool has the following desirable characteristics: > >> > >> ? Idle threads are always reused before queueing tasks or starting new > >> threads > >> ? The most recently used idle thread is always preferred, which allows > >> the pool to shrink when it is not fully utilized > >> ? Useful core/max thread pool size distinction > >> ? API-equivalent to ThreadPoolExecutor > >> ? Performance parity with common ThreadPoolExecutor configurations > >> ? Suitable as a replacement for other jboss-threads thread pool types as > >> well > >> > >> In addition, it presents the following features: > >> > >> ? Configure via a builder API > >> ? Configurable exception handler > >> ? Integrated task queue with optional size limit > >> ? Full complement of standard metrics, which can be disabled > >> ? Configurable rejection handler in the form of a handoff executor > >> ? An optional growth-resistance algorithm which can be applied to > >> larger pools to create growth resistance between the core and maximum > >> pool size > >> ? An optional post-terminate task > >> ? A few system property based adjustments that can be applied for > >> experimental purposes > >> ? A global flag which can be set via system property to recommend that > >> the new thread pool should be disabled, allowing an emergency fallback > >> in case of an unexpected problem > >> > >> Design-wise, the thread pool is based on a special lock-free/wait-free > >> combination FIFO/LIFO queue algorithm. See [3] for a more complete > >> explanation of internal operation, if you're curious about the gritty > >> details. > >> > >> This change has a few implications with regards to the application > server: > >> ? Thread pools with a core- and max-size which were locked together > >> may now have these variables decoupled in a safe and useful manner > >> ? Thread pool configurations in the management model which previously > >> featured only a max size can now have a core size attribute introduced > >> > >> Most of the thread pools we use are built and configured within the > >> wildfly-core code base; that is where the first part of this change > >> will be done. Later on there will be a follow-up change for WildFly > >> proper, but this of course can not happen until the core change is > >> merged and a core release done, so expect that part somewhat later. > >> The initial WIP change to wildfly-core can be found here [4]. Note > >> that no pull request will be opened until all the components are > >> Final. I have done a good deal of testing already, but I will be > >> doing more CI testing on other platforms and configurations before > >> submitting the PR. > >> > >> I've made an attempt to link up all the JIRAs that are related to this > >> effort from [1] (either directly or indirectly). If you find another > >> JIRA that you think is related, or if you have questions or concerns, > >> ask on this list, or you can ping me directly on HipChat or IRC. > >> > >> Thanks! > >> > >> [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread > >> pool implementation > >> [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 > >> [3] > >> https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff- > f5807a689506af0b70791d93ae81cc1cR67 > >> [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool > >> > >> -- > >> - DML > >> > >> _______________________________________________ > >> 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. > > > > -- > - DML > -- 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/20171103/05908988/attachment.html From dandread at redhat.com Fri Nov 3 13:08:42 2017 From: dandread at redhat.com (Dimitris Andreadis) Date: Fri, 3 Nov 2017 18:08:42 +0100 Subject: [wildfly-dev] Introducing a new thread pool implementation In-Reply-To: References: Message-ID: <5094a4ee-7f81-5aca-e820-a66d338a99ce@redhat.com> Every time you re-design a new thread pool, a kitten dies. /me ducks :) On 03/11/2017 15:03, David Lloyd wrote: > For WildFly 12 I intend to introduce a new thread pool implementation > [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor > in the main codebases of WildFly and WildFly Core, and also in several > support projects such as JBoss MSC and XNIO. > > The thread pool has the following desirable characteristics: > > ? Idle threads are always reused before queueing tasks or starting new threads > ? The most recently used idle thread is always preferred, which allows > the pool to shrink when it is not fully utilized > ? Useful core/max thread pool size distinction > ? API-equivalent to ThreadPoolExecutor > ? Performance parity with common ThreadPoolExecutor configurations > ? Suitable as a replacement for other jboss-threads thread pool types as well > > In addition, it presents the following features: > > ? Configure via a builder API > ? Configurable exception handler > ? Integrated task queue with optional size limit > ? Full complement of standard metrics, which can be disabled > ? Configurable rejection handler in the form of a handoff executor > ? An optional growth-resistance algorithm which can be applied to > larger pools to create growth resistance between the core and maximum > pool size > ? An optional post-terminate task > ? A few system property based adjustments that can be applied for > experimental purposes > ? A global flag which can be set via system property to recommend that > the new thread pool should be disabled, allowing an emergency fallback > in case of an unexpected problem > > Design-wise, the thread pool is based on a special lock-free/wait-free > combination FIFO/LIFO queue algorithm. See [3] for a more complete > explanation of internal operation, if you're curious about the gritty > details. > > This change has a few implications with regards to the application server: > ? Thread pools with a core- and max-size which were locked together > may now have these variables decoupled in a safe and useful manner > ? Thread pool configurations in the management model which previously > featured only a max size can now have a core size attribute introduced > > Most of the thread pools we use are built and configured within the > wildfly-core code base; that is where the first part of this change > will be done. Later on there will be a follow-up change for WildFly > proper, but this of course can not happen until the core change is > merged and a core release done, so expect that part somewhat later. > The initial WIP change to wildfly-core can be found here [4]. Note > that no pull request will be opened until all the components are > Final. I have done a good deal of testing already, but I will be > doing more CI testing on other platforms and configurations before > submitting the PR. > > I've made an attempt to link up all the JIRAs that are related to this > effort from [1] (either directly or indirectly). If you find another > JIRA that you think is related, or if you have questions or concerns, > ask on this list, or you can ping me directly on HipChat or IRC. > > Thanks! > > [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread > pool implementation > [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 > [3] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807a689506af0b70791d93ae81cc1cR67 > [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool > From anilsaldhana at gmail.com Fri Nov 3 23:46:40 2017 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Fri, 3 Nov 2017 22:46:40 -0500 Subject: [wildfly-dev] Introducing a new thread pool implementation In-Reply-To: <5094a4ee-7f81-5aca-e820-a66d338a99ce@redhat.com> References: <5094a4ee-7f81-5aca-e820-a66d338a99ce@redhat.com> Message-ID: <5337BF58-F4E0-4D75-B174-5445290F3AB5@gmail.com> Any thoughts on getting developers not to use Classes and interfaces that are there since JDK 1.0? :-) /me ducks behind Dimitris. > On Nov 3, 2017, at 12:08 PM, Dimitris Andreadis wrote: > > Every time you re-design a new thread pool, a kitten dies. > > /me ducks :) > >> On 03/11/2017 15:03, David Lloyd wrote: >> For WildFly 12 I intend to introduce a new thread pool implementation >> [1] [2] that will replace most, if not all, uses of ThreadPoolExecutor >> in the main codebases of WildFly and WildFly Core, and also in several >> support projects such as JBoss MSC and XNIO. >> >> The thread pool has the following desirable characteristics: >> >> ? Idle threads are always reused before queueing tasks or starting new threads >> ? The most recently used idle thread is always preferred, which allows >> the pool to shrink when it is not fully utilized >> ? Useful core/max thread pool size distinction >> ? API-equivalent to ThreadPoolExecutor >> ? Performance parity with common ThreadPoolExecutor configurations >> ? Suitable as a replacement for other jboss-threads thread pool types as well >> >> In addition, it presents the following features: >> >> ? Configure via a builder API >> ? Configurable exception handler >> ? Integrated task queue with optional size limit >> ? Full complement of standard metrics, which can be disabled >> ? Configurable rejection handler in the form of a handoff executor >> ? An optional growth-resistance algorithm which can be applied to >> larger pools to create growth resistance between the core and maximum >> pool size >> ? An optional post-terminate task >> ? A few system property based adjustments that can be applied for >> experimental purposes >> ? A global flag which can be set via system property to recommend that >> the new thread pool should be disabled, allowing an emergency fallback >> in case of an unexpected problem >> >> Design-wise, the thread pool is based on a special lock-free/wait-free >> combination FIFO/LIFO queue algorithm. See [3] for a more complete >> explanation of internal operation, if you're curious about the gritty >> details. >> >> This change has a few implications with regards to the application server: >> ? Thread pools with a core- and max-size which were locked together >> may now have these variables decoupled in a safe and useful manner >> ? Thread pool configurations in the management model which previously >> featured only a max size can now have a core size attribute introduced >> >> Most of the thread pools we use are built and configured within the >> wildfly-core code base; that is where the first part of this change >> will be done. Later on there will be a follow-up change for WildFly >> proper, but this of course can not happen until the core change is >> merged and a core release done, so expect that part somewhat later. >> The initial WIP change to wildfly-core can be found here [4]. Note >> that no pull request will be opened until all the components are >> Final. I have done a good deal of testing already, but I will be >> doing more CI testing on other platforms and configurations before >> submitting the PR. >> >> I've made an attempt to link up all the JIRAs that are related to this >> effort from [1] (either directly or indirectly). If you find another >> JIRA that you think is related, or if you have questions or concerns, >> ask on this list, or you can ping me directly on HipChat or IRC. >> >> Thanks! >> >> [1] https://issues.jboss.org/browse/JBTHR-38 - Introduce new thread >> pool implementation >> [2] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128 >> [3] https://github.com/jbossas/jboss-threads/commit/be95b8d6b42128#diff-f5807a689506af0b70791d93ae81cc1cR67 >> [4] https://github.com/dmlloyd/wildfly-core/tree/threadpool >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jai.forums2013 at gmail.com Tue Nov 7 07:31:07 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 7 Nov 2017 18:01:07 +0530 Subject: [wildfly-dev] Incorrect log message about allowed elements in configuration files? Message-ID: <4899c54d-1c11-9f86-318f-6391af1e6da1@gmail.com> I was experimenting with something on the just released WildFly 11 and lazily added the "system-properties" element within the server element, after the socket-binding-group in standalone.xml. Something like this: ??? ..... ??? ??? ... ??? .... ??? ??? ??????? ??? Then booted the standalone server and ran into this improved error message at startup: 17:51:32,950 ERROR [org.jboss.as.controller] (Controller Boot Thread) OPVDX001: Validation error in standalone.xml ----------------------------------- | |? 510:???? |? 511: |? 512: *** **|?????????? ^^^^ 'system-properties' isn't an allowed element here* | | *Elements allowed here are: * |????????????????? deployment-overlays?? management *system-properties* |????????????????? deployments?????????? paths vault |????????????????? extensions??????????? profile |????????????????? interfaces??????????? socket-binding-group | |? 513:???????? |? 514:???? |? 515: | | 'system-properties' is allowed in elements: | - server | " | | The primary underlying error message was: | > ParseError at [row,col]:[512,5] | > Message: WFLYCTL0198: Unexpected element | >?? '{urn:jboss:domain:5.0}system-properties' encountered | I understand why it errored out (it expects the system-properties to be after the "extensions" element, than at the end) and I fixed the config to get past it. However, the interesting bit is that the error message that it threw states that "system-properties" isn't allowed at that location and the elements that are allowed there displays a bunch of elements which also includes "system-properties". I haven't looked up the code to see how that log message is generated and if it's just a logging issue or something more. Thought of noting it here in the list. -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171107/6b2da630/attachment.html From brian.stansberry at redhat.com Tue Nov 7 13:06:37 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 7 Nov 2017 12:06:37 -0600 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: Since we're done with WF 11, I think it's time to move forward on this. There's still some discussion to have about decomposing the docs so the relevant doc bits are aligned with the feature packs they come from, but I haven't heard any argument against moving off Confluence and having the docs included in the source tree. Since we don't have the current docs decomposed in any way, I see no reason not to go ahead with bringing the docs in wildfly/wildfly master and then we can deal with decomposition as a later step. On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar wrote: > Hey guys, > > TL;DR > I've converted confluence docs asciidoc [1] [2] ones that will be part of > WildFly codebase, > take a look at them and let me know if there are any big issues. > > > ---- > full version: > > as most of you already know, I was working on moving our confluence based > [1] documentation to asciidoc based one. > > result can be seen at [7] or rendered to html at [8] > > A good side effect of conversion is that now docs are also browsable > directly on GitHub. > For example [2] or [3] > > Currently I kept same structure as we had in confluence, which in practice > means > we have set of "guides" that than have lots of sub pages / includes that > produce "big" guides. > Currently such guides are: > - Admin Guide > - Developer Guide > - Getting started guide > - Getting Started Developing Applications Guide > - High Availability Guide > - Extending WildFly guide > - JavaEE 7(6 actually) Tutorial > - Elytron security guide > - quickstarts > - Testsuite > > Problem is that some of this guide as such make sense, but not all of them > do. > In some cases we have duplicated docs for same thing, in others we content > in wrong segment. > For example instead of having all subsystem reference docs under admin > guide, > some are under Developer Guide and some even under HA guide. > > Going forward we should "refactor" docs a bit, so we would end up with 3-4 > high quality guides. > We should also go trough all docs and remove/update the outdated content. > > Plan is also to have documentation now part of WildFly codebase. > So when we would submit PR with new feature, it would also include > documentation for it as well. > > Rendered docs can be build as part of our build / release process and can > be rendered to different formats. > for example default is HTML [5] or PDF [6] > > I've send experimental PR to show how docs would fit into WildFly build [4] > > Please take look at current docs and if you have any comments / > suggestions what we can improve before merging it let me know. > At this point I've not done much content-wise changes but just conversion > + formatting ones. > Content updates can come after this is merged. > > -- > tomaz > > [1] https://docs.jboss.org/author/display/WFLY/Documentation > [2] https://github.com/ctomc/docs-playground/blob/master/ > admin-guide/Operating_modes.adoc > [3] https://github.com/ctomc/docs-playground/blob/master/ > developer-guide/EJB3_Reference_Guide.adoc > [4] https://github.com/wildfly/wildfly/pull/10523 > [5] https://ctomc.github.io/docs-playground/Admin_Guide.html > [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf > [7] https://github.com/ctomc/docs-playground > [8] https://ctomc.github.io/docs-playground/ > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171107/7531a2dc/attachment.html From ema at redhat.com Tue Nov 7 20:47:12 2017 From: ema at redhat.com (Jim Ma) Date: Wed, 8 Nov 2017 09:47:12 +0800 Subject: [wildfly-dev] Undertow elytron ApplicationSecurityDomainService Message-ID: WebSerivce subsystem has a user reported issue [1] which ws endpoint can't declare an undertow subsystem application security domain in jboss-web.xml. I had a quick look and it looks we need an injector to get undertow's ApplicationSecurityDomain and finally get the elytron security domain like what we handle ejb application security domain right now [2]. To make this work, I write some workaround code [3], and this may better explain what ws integration code expects to fix this issue. Darren and Stuart, can you please have a look and let me know your ideas and thoughts about this issue? [1]https://developer.jboss.org/message/977628 [2] https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java#L100 [3] https://github.com/jimma/wildfly/commit/d93b8ac89e388c54a10ce627780486143267e052 Thanks, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171108/cf055da4/attachment.html From darran.lofthouse at jboss.com Wed Nov 8 05:19:02 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 08 Nov 2017 10:19:02 +0000 Subject: [wildfly-dev] Undertow elytron ApplicationSecurityDomainService In-Reply-To: References: Message-ID: The notion of the application security domain resources was something we introduced so we could support legacy security by default and provide the administrator a mechanism to switch to using WildFly Elytron - now that WildFly 11 is out I am looking at how we can add configuration directly to the deployment. Additionally for my work after WildFly 11 I am also going to be looking at the options to inject a few key WildFly Elytron resources. Overall rather than adding further service dependencies, could it be better to attach something to the DeploymentUnit so it can be used later? Regards, Darran Lofthouse. On Wed, 8 Nov 2017 at 01:47 Jim Ma wrote: > WebSerivce subsystem has a user reported issue [1] which ws endpoint can't > declare an undertow subsystem application security domain in jboss-web.xml. > I had a quick look and it looks we need an injector to get undertow's > ApplicationSecurityDomain and finally get the elytron security domain like > what we handle ejb application security domain right now [2]. > To make this work, I write some workaround code [3], and this may better > explain what ws integration code expects to fix this issue. Darren and > Stuart, can you please have a look and let me know your ideas and thoughts > about this issue? > > [1]https://developer.jboss.org/message/977628 > [2] > https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java#L100 > [3] > https://github.com/jimma/wildfly/commit/d93b8ac89e388c54a10ce627780486143267e052 > > Thanks, > Jim > > _______________________________________________ > 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/20171108/75b5b5df/attachment-0001.html From david.lloyd at redhat.com Wed Nov 8 08:04:21 2017 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 8 Nov 2017 07:04:21 -0600 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: I would suggest that we ensure that our produced AsciiDoc files conform to [1] (generated from [2]). Beyond that, I support this initiative wholeheartedly. [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ [2] https://github.com/redhat-documentation/asciidoc-markup-conventions On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry wrote: > Since we're done with WF 11, I think it's time to move forward on this. > There's still some discussion to have about decomposing the docs so the > relevant doc bits are aligned with the feature packs they come from, but I > haven't heard any argument against moving off Confluence and having the docs > included in the source tree. Since we don't have the current docs decomposed > in any way, I see no reason not to go ahead with bringing the docs in > wildfly/wildfly master and then we can deal with decomposition as a later > step. > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar wrote: >> >> Hey guys, >> >> TL;DR >> I've converted confluence docs asciidoc [1] [2] ones that will be part of >> WildFly codebase, >> take a look at them and let me know if there are any big issues. >> >> >> ---- >> full version: >> >> as most of you already know, I was working on moving our confluence based >> [1] documentation to asciidoc based one. >> >> result can be seen at [7] or rendered to html at [8] >> >> A good side effect of conversion is that now docs are also browsable >> directly on GitHub. >> For example [2] or [3] >> >> Currently I kept same structure as we had in confluence, which in practice >> means >> we have set of "guides" that than have lots of sub pages / includes that >> produce "big" guides. >> Currently such guides are: >> - Admin Guide >> - Developer Guide >> - Getting started guide >> - Getting Started Developing Applications Guide >> - High Availability Guide >> - Extending WildFly guide >> - JavaEE 7(6 actually) Tutorial >> - Elytron security guide >> - quickstarts >> - Testsuite >> >> Problem is that some of this guide as such make sense, but not all of them >> do. >> In some cases we have duplicated docs for same thing, in others we content >> in wrong segment. >> For example instead of having all subsystem reference docs under admin >> guide, >> some are under Developer Guide and some even under HA guide. >> >> Going forward we should "refactor" docs a bit, so we would end up with 3-4 >> high quality guides. >> We should also go trough all docs and remove/update the outdated content. >> >> Plan is also to have documentation now part of WildFly codebase. >> So when we would submit PR with new feature, it would also include >> documentation for it as well. >> >> Rendered docs can be build as part of our build / release process and can >> be rendered to different formats. >> for example default is HTML [5] or PDF [6] >> >> I've send experimental PR to show how docs would fit into WildFly build >> [4] >> >> Please take look at current docs and if you have any comments / >> suggestions what we can improve before merging it let me know. >> At this point I've not done much content-wise changes but just conversion >> + formatting ones. >> Content updates can come after this is merged. >> >> -- >> tomaz >> >> [1] https://docs.jboss.org/author/display/WFLY/Documentation >> [2] >> https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc >> [3] >> https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc >> [4] https://github.com/wildfly/wildfly/pull/10523 >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf >> [7] https://github.com/ctomc/docs-playground >> [8] https://ctomc.github.io/docs-playground/ >> >> _______________________________________________ >> 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 > Red Hat > > _______________________________________________ > 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 Nov 8 11:05:38 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 8 Nov 2017 10:05:38 -0600 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: Sounds like a good goal, but I don't think Tomaz should be responsible for correcting all our docs to make them conform. For many of these I doubt the Confluence markup includes relevant metadata that would have allowed that (e.g. that a given literal was a filename, hence [filename]`thename` instead of `thename`. We'd need to assign owners to various pages and have them correct them. An obvious initial owner being the component lead for the component that's most relevant to the page. On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd wrote: > I would suggest that we ensure that our produced AsciiDoc files > conform to [1] (generated from [2]). Beyond that, I support this > initiative wholeheartedly. > > [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ > [2] https://github.com/redhat-documentation/asciidoc-markup-conventions > > On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry > wrote: > > Since we're done with WF 11, I think it's time to move forward on this. > > There's still some discussion to have about decomposing the docs so the > > relevant doc bits are aligned with the feature packs they come from, but > I > > haven't heard any argument against moving off Confluence and having the > docs > > included in the source tree. Since we don't have the current docs > decomposed > > in any way, I see no reason not to go ahead with bringing the docs in > > wildfly/wildfly master and then we can deal with decomposition as a later > > step. > > > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar > wrote: > >> > >> Hey guys, > >> > >> TL;DR > >> I've converted confluence docs asciidoc [1] [2] ones that will be part > of > >> WildFly codebase, > >> take a look at them and let me know if there are any big issues. > >> > >> > >> ---- > >> full version: > >> > >> as most of you already know, I was working on moving our confluence > based > >> [1] documentation to asciidoc based one. > >> > >> result can be seen at [7] or rendered to html at [8] > >> > >> A good side effect of conversion is that now docs are also browsable > >> directly on GitHub. > >> For example [2] or [3] > >> > >> Currently I kept same structure as we had in confluence, which in > practice > >> means > >> we have set of "guides" that than have lots of sub pages / includes that > >> produce "big" guides. > >> Currently such guides are: > >> - Admin Guide > >> - Developer Guide > >> - Getting started guide > >> - Getting Started Developing Applications Guide > >> - High Availability Guide > >> - Extending WildFly guide > >> - JavaEE 7(6 actually) Tutorial > >> - Elytron security guide > >> - quickstarts > >> - Testsuite > >> > >> Problem is that some of this guide as such make sense, but not all of > them > >> do. > >> In some cases we have duplicated docs for same thing, in others we > content > >> in wrong segment. > >> For example instead of having all subsystem reference docs under admin > >> guide, > >> some are under Developer Guide and some even under HA guide. > >> > >> Going forward we should "refactor" docs a bit, so we would end up with > 3-4 > >> high quality guides. > >> We should also go trough all docs and remove/update the outdated > content. > >> > >> Plan is also to have documentation now part of WildFly codebase. > >> So when we would submit PR with new feature, it would also include > >> documentation for it as well. > >> > >> Rendered docs can be build as part of our build / release process and > can > >> be rendered to different formats. > >> for example default is HTML [5] or PDF [6] > >> > >> I've send experimental PR to show how docs would fit into WildFly build > >> [4] > >> > >> Please take look at current docs and if you have any comments / > >> suggestions what we can improve before merging it let me know. > >> At this point I've not done much content-wise changes but just > conversion > >> + formatting ones. > >> Content updates can come after this is merged. > >> > >> -- > >> tomaz > >> > >> [1] https://docs.jboss.org/author/display/WFLY/Documentation > >> [2] > >> https://github.com/ctomc/docs-playground/blob/master/admin- > guide/Operating_modes.adoc > >> [3] > >> https://github.com/ctomc/docs-playground/blob/master/ > developer-guide/EJB3_Reference_Guide.adoc > >> [4] https://github.com/wildfly/wildfly/pull/10523 > >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html > >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf > >> [7] https://github.com/ctomc/docs-playground > >> [8] https://ctomc.github.io/docs-playground/ > >> > >> _______________________________________________ > >> 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 > > Red Hat > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171108/7ae52256/attachment.html From bmcwhirt at redhat.com Wed Nov 8 19:39:41 2017 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 09 Nov 2017 00:39:41 +0000 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: We have recent used he doc teams ?modular documentation templates? and I think they are lovely and also makes the docs team happy. Ask your doctor if modular documentation templates are right for you. Bob On Wed, Nov 8, 2017 at 12:40 PM Brian Stansberry < brian.stansberry at redhat.com> wrote: > Sounds like a good goal, but I don't think Tomaz should be responsible for > correcting all our docs to make them conform. For many of these I doubt the > Confluence markup includes relevant metadata that would have allowed that > (e.g. that a given literal was a filename, hence [filename]`thename` > instead of `thename`. We'd need to assign owners to various pages and have > them correct them. An obvious initial owner being the component lead for > the component that's most relevant to the page. > > On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd > wrote: > >> I would suggest that we ensure that our produced AsciiDoc files >> conform to [1] (generated from [2]). Beyond that, I support this >> initiative wholeheartedly. >> >> [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ >> [2] https://github.com/redhat-documentation/asciidoc-markup-conventions >> >> On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry >> wrote: >> > Since we're done with WF 11, I think it's time to move forward on this. >> > There's still some discussion to have about decomposing the docs so the >> > relevant doc bits are aligned with the feature packs they come from, >> but I >> > haven't heard any argument against moving off Confluence and having the >> docs >> > included in the source tree. Since we don't have the current docs >> decomposed >> > in any way, I see no reason not to go ahead with bringing the docs in >> > wildfly/wildfly master and then we can deal with decomposition as a >> later >> > step. >> > >> > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar >> wrote: >> >> >> >> Hey guys, >> >> >> >> TL;DR >> >> I've converted confluence docs asciidoc [1] [2] ones that will be part >> of >> >> WildFly codebase, >> >> take a look at them and let me know if there are any big issues. >> >> >> >> >> >> ---- >> >> full version: >> >> >> >> as most of you already know, I was working on moving our confluence >> based >> >> [1] documentation to asciidoc based one. >> >> >> >> result can be seen at [7] or rendered to html at [8] >> >> >> >> A good side effect of conversion is that now docs are also browsable >> >> directly on GitHub. >> >> For example [2] or [3] >> >> >> >> Currently I kept same structure as we had in confluence, which in >> practice >> >> means >> >> we have set of "guides" that than have lots of sub pages / includes >> that >> >> produce "big" guides. >> >> Currently such guides are: >> >> - Admin Guide >> >> - Developer Guide >> >> - Getting started guide >> >> - Getting Started Developing Applications Guide >> >> - High Availability Guide >> >> - Extending WildFly guide >> >> - JavaEE 7(6 actually) Tutorial >> >> - Elytron security guide >> >> - quickstarts >> >> - Testsuite >> >> >> >> Problem is that some of this guide as such make sense, but not all of >> them >> >> do. >> >> In some cases we have duplicated docs for same thing, in others we >> content >> >> in wrong segment. >> >> For example instead of having all subsystem reference docs under admin >> >> guide, >> >> some are under Developer Guide and some even under HA guide. >> >> >> >> Going forward we should "refactor" docs a bit, so we would end up with >> 3-4 >> >> high quality guides. >> >> We should also go trough all docs and remove/update the outdated >> content. >> >> >> >> Plan is also to have documentation now part of WildFly codebase. >> >> So when we would submit PR with new feature, it would also include >> >> documentation for it as well. >> >> >> >> Rendered docs can be build as part of our build / release process and >> can >> >> be rendered to different formats. >> >> for example default is HTML [5] or PDF [6] >> >> >> >> I've send experimental PR to show how docs would fit into WildFly build >> >> [4] >> >> >> >> Please take look at current docs and if you have any comments / >> >> suggestions what we can improve before merging it let me know. >> >> At this point I've not done much content-wise changes but just >> conversion >> >> + formatting ones. >> >> Content updates can come after this is merged. >> >> >> >> -- >> >> tomaz >> >> >> >> [1] https://docs.jboss.org/author/display/WFLY/Documentation >> >> [2] >> >> >> https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc >> >> [3] >> >> >> https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc >> >> [4] https://github.com/wildfly/wildfly/pull/10523 >> >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html >> >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf >> >> [7] https://github.com/ctomc/docs-playground >> >> [8] https://ctomc.github.io/docs-playground/ >> >> >> >> _______________________________________________ >> >> 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 >> > Red Hat >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> - DML >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > 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/20171109/1f0b5fa4/attachment-0001.html From tomaz.cerar at gmail.com Thu Nov 9 09:19:37 2017 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Thu, 9 Nov 2017 15:19:37 +0100 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: <5a0463f8.bbf4500a.b9c25.a95a@mx.google.com> I've updated PR https://github.com/wildfly/wildfly/pull/10523 That brings in converted confluence documentation. It is synced with todays content in confluence. This is just a start, going forward we should - Split docs between core & full - Each subsystem could have docs folder that would be than agreggated - Publish docs somewhere. Maybe use GH for start http://wildfly.github.io/ - Restrucutre docs into few books instead of what we have now. -- tomaz From: Bob McWhirter Sent: ?etrtek, 09. november 2017 01:48 To: Brian Stansberry Cc: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] WildFly asciidoc based documentation We have recent used he doc teams ?modular documentation templates? and I think they are lovely and also makes the docs team happy.? Ask your doctor if modular documentation templates are right for you.? Bob On Wed, Nov 8, 2017 at 12:40 PM Brian Stansberry wrote: Sounds like a good goal, but I don't think Tomaz should be responsible for correcting all our docs to make them conform. For many of these I doubt the Confluence markup includes relevant metadata that would have allowed that (e.g. that a given literal was a filename, hence [filename]`thename` instead of `thename`. We'd need to assign owners to various pages and have them correct them. An obvious initial owner being the component lead for the component that's most relevant to the page. On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd wrote: I would suggest that we ensure that our produced AsciiDoc files conform to [1] (generated from [2]).? Beyond that, I support this initiative wholeheartedly. [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ [2] https://github.com/redhat-documentation/asciidoc-markup-conventions On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry wrote: > Since we're done with WF 11, I think it's time to move forward on this. > There's still some discussion to have about decomposing the docs so the > relevant doc bits are aligned with the feature packs they come from, but I > haven't heard any argument against moving off Confluence and having the docs > included in the source tree. Since we don't have the current docs decomposed > in any way, I see no reason not to go ahead with bringing the docs in > wildfly/wildfly master and then we can deal with decomposition as a later > step. > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar wrote: >> >> Hey guys, >> >> TL;DR >> I've converted confluence docs asciidoc [1] [2] ones that will be part of >> WildFly codebase, >> take a look at them and let me know if there are any big issues. >> >> >> ---- >> full version: >> >> as most of you already know, I was working on moving our confluence based >> [1] documentation to asciidoc based one. >> >> result can be seen at [7] or rendered to html at [8] >> >> A good side effect of conversion is that now docs are also browsable >> directly on GitHub. >> For example [2] or [3] >> >> Currently I kept same structure as we had in confluence, which in practice >> means >> we have set of "guides" that than have lots of sub pages / includes that >> produce "big" guides. >> Currently such guides are: >> - Admin Guide >> - Developer Guide >> - Getting started guide >> - Getting Started Developing Applications Guide >> - High Availability Guide >> - Extending WildFly guide >> - JavaEE 7(6 actually) Tutorial >> - Elytron security guide >> - quickstarts >> - Testsuite >> >> Problem is that some of this guide as such make sense, but not all of them >> do. >> In some cases we have duplicated docs for same thing, in others we content >> in wrong segment. >> For example instead of having all subsystem reference docs under admin >> guide, >> some are under Developer Guide and some even under HA guide. >> >> Going forward we should "refactor" docs a bit, so we would end up with 3-4 >> high quality guides. >> We should also go trough all docs and remove/update the outdated content. >> >> Plan is also to have documentation now part of WildFly codebase. >> So when we would submit PR with new feature, it would also include >> documentation for it as well. >> >> Rendered docs can be build as part of our build / release process and can >> be rendered to different formats. >> for example default is HTML [5] or PDF [6] >> >> I've send experimental PR to show how docs would fit into WildFly build >> [4] >> >> Please take look at current docs and if you have any comments / >> suggestions what we can improve before merging it let me know. >> At this point I've not done much content-wise changes but just conversion >> + formatting ones. >> Content updates can come after this is merged. >> >> -- >> tomaz >> >> [1] https://docs.jboss.org/author/display/WFLY/Documentation >> [2] >> https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc >> [3] >> https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc >> [4] https://github.com/wildfly/wildfly/pull/10523 >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf >> [7] https://github.com/ctomc/docs-playground >> [8] https://ctomc.github.io/docs-playground/ >> >> _______________________________________________ >> 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 > Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML -- Brian Stansberry Manager, Senior Principal Software Engineer 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/20171109/eaaafe58/attachment.html From brian.stansberry at redhat.com Thu Nov 9 09:28:16 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 9 Nov 2017 08:28:16 -0600 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: <5a0463f8.bbf4500a.b9c25.a95a@mx.google.com> References: <5a0463f8.bbf4500a.b9c25.a95a@mx.google.com> Message-ID: On Thu, Nov 9, 2017 at 8:19 AM, Toma? Cerar wrote: > I've updated PR https://github.com/wildfly/wildfly/pull/10523 > > That brings in converted confluence documentation. > > It is synced with todays content in confluence. > > > > This is just a start, going forward we should > > > > - Split docs between core & full > - Each subsystem could have docs folder that would be than agreggated > - Publish docs somewhere. Maybe use GH for start > http://wildfly.github.io/ > - Restrucutre docs into few books instead of what we have now. > > As we get into this last bit, we should look into the modular stuff Bob mentioned. It sounds like it would mean a large scale rewrite, so if we start doing things that are more than just moving some files around we should consider the bigger picture. > > -- > > tomaz > > > > > > *From: *Bob McWhirter > *Sent: *?etrtek, 09. november 2017 01:48 > *To: *Brian Stansberry > *Cc: *wildfly-dev at lists.jboss.org > *Subject: *Re: [wildfly-dev] WildFly asciidoc based documentation > > > > We have recent used he doc teams ?modular documentation templates? and I > think they are lovely and also makes the docs team happy. > > > > Ask your doctor if modular documentation templates are right for you. > > > > Bob > > > > On Wed, Nov 8, 2017 at 12:40 PM Brian Stansberry < > brian.stansberry at redhat.com> wrote: > > Sounds like a good goal, but I don't think Tomaz should be responsible for > correcting all our docs to make them conform. For many of these I doubt the > Confluence markup includes relevant metadata that would have allowed that > (e.g. that a given literal was a filename, hence [filename]`thename` > instead of `thename`. We'd need to assign owners to various pages and have > them correct them. An obvious initial owner being the component lead for > the component that's most relevant to the page. > > > > On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd > wrote: > > I would suggest that we ensure that our produced AsciiDoc files > conform to [1] (generated from [2]). Beyond that, I support this > initiative wholeheartedly. > > [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ > [2] https://github.com/redhat-documentation/asciidoc-markup-conventions > > > On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry > wrote: > > Since we're done with WF 11, I think it's time to move forward on this. > > There's still some discussion to have about decomposing the docs so the > > relevant doc bits are aligned with the feature packs they come from, but > I > > haven't heard any argument against moving off Confluence and having the > docs > > included in the source tree. Since we don't have the current docs > decomposed > > in any way, I see no reason not to go ahead with bringing the docs in > > wildfly/wildfly master and then we can deal with decomposition as a later > > step. > > > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar > wrote: > >> > >> Hey guys, > >> > >> TL;DR > >> I've converted confluence docs asciidoc [1] [2] ones that will be part > of > >> WildFly codebase, > >> take a look at them and let me know if there are any big issues. > >> > >> > >> ---- > >> full version: > >> > >> as most of you already know, I was working on moving our confluence > based > >> [1] documentation to asciidoc based one. > >> > >> result can be seen at [7] or rendered to html at [8] > >> > >> A good side effect of conversion is that now docs are also browsable > >> directly on GitHub. > >> For example [2] or [3] > >> > >> Currently I kept same structure as we had in confluence, which in > practice > >> means > >> we have set of "guides" that than have lots of sub pages / includes that > >> produce "big" guides. > >> Currently such guides are: > >> - Admin Guide > >> - Developer Guide > >> - Getting started guide > >> - Getting Started Developing Applications Guide > >> - High Availability Guide > >> - Extending WildFly guide > >> - JavaEE 7(6 actually) Tutorial > >> - Elytron security guide > >> - quickstarts > >> - Testsuite > >> > >> Problem is that some of this guide as such make sense, but not all of > them > >> do. > >> In some cases we have duplicated docs for same thing, in others we > content > >> in wrong segment. > >> For example instead of having all subsystem reference docs under admin > >> guide, > >> some are under Developer Guide and some even under HA guide. > >> > >> Going forward we should "refactor" docs a bit, so we would end up with > 3-4 > >> high quality guides. > >> We should also go trough all docs and remove/update the outdated > content. > >> > >> Plan is also to have documentation now part of WildFly codebase. > >> So when we would submit PR with new feature, it would also include > >> documentation for it as well. > >> > >> Rendered docs can be build as part of our build / release process and > can > >> be rendered to different formats. > >> for example default is HTML [5] or PDF [6] > >> > >> I've send experimental PR to show how docs would fit into WildFly build > >> [4] > >> > >> Please take look at current docs and if you have any comments / > >> suggestions what we can improve before merging it let me know. > >> At this point I've not done much content-wise changes but just > conversion > >> + formatting ones. > >> Content updates can come after this is merged. > >> > >> -- > >> tomaz > >> > >> [1] https://docs.jboss.org/author/display/WFLY/Documentation > >> [2] > >> https://github.com/ctomc/docs-playground/blob/master/admin- > guide/Operating_modes.adoc > >> [3] > >> https://github.com/ctomc/docs-playground/blob/master/ > developer-guide/EJB3_Reference_Guide.adoc > >> [4] https://github.com/wildfly/wildfly/pull/10523 > >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html > >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf > >> [7] https://github.com/ctomc/docs-playground > >> [8] https://ctomc.github.io/docs-playground/ > >> > >> _______________________________________________ > >> 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 > > Red Hat > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > - DML > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171109/7aef403a/attachment-0001.html From tomaz.cerar at gmail.com Thu Nov 9 10:50:57 2017 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Thu, 9 Nov 2017 16:50:57 +0100 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: <5a0463f8.bbf4500a.b9c25.a95a@mx.google.com> Message-ID: <5a047960.f1ae500a.5d340.8428@mx.google.com> https://github.com/redhat-documentation/modular-docs -- tomaz From: Brian Stansberry Sent: ?etrtek, 09. november 2017 15:28 To: Toma? Cerar Cc: Bob McWhirter; wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] WildFly asciidoc based documentation On Thu, Nov 9, 2017 at 8:19 AM, Toma? Cerar wrote: I've updated PR https://github.com/wildfly/wildfly/pull/10523 That brings in converted confluence documentation. It is synced with todays content in confluence. ? This is just a start, going forward we should ? ? Split docs between core & full ? Each subsystem could have docs folder that would be than agreggated ? Publish docs somewhere. Maybe use GH for start http://wildfly.github.io/ ? Restrucutre docs into few books instead of what we have now. As we get into this last bit, we should look into the modular stuff Bob mentioned. It sounds like it would mean a large scale rewrite, so if we start doing things that are more than just moving some files around we should consider the bigger picture. ? -- tomaz ? ? From: Bob McWhirter Sent: ?etrtek, 09. november 2017 01:48 To: Brian Stansberry Cc: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] WildFly asciidoc based documentation ? We have recent used he doc teams ?modular documentation templates? and I think they are lovely and also makes the docs team happy.? ? Ask your doctor if modular documentation templates are right for you.? ? Bob ? On Wed, Nov 8, 2017 at 12:40 PM Brian Stansberry wrote: Sounds like a good goal, but I don't think Tomaz should be responsible for correcting all our docs to make them conform. For many of these I doubt the Confluence markup includes relevant metadata that would have allowed that (e.g. that a given literal was a filename, hence [filename]`thename` instead of `thename`. We'd need to assign owners to various pages and have them correct them. An obvious initial owner being the component lead for the component that's most relevant to the page. ? On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd wrote: I would suggest that we ensure that our produced AsciiDoc files conform to [1] (generated from [2]).? Beyond that, I support this initiative wholeheartedly. [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ [2] https://github.com/redhat-documentation/asciidoc-markup-conventions On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry wrote: > Since we're done with WF 11, I think it's time to move forward on this. > There's still some discussion to have about decomposing the docs so the > relevant doc bits are aligned with the feature packs they come from, but I > haven't heard any argument against moving off Confluence and having the docs > included in the source tree. Since we don't have the current docs decomposed > in any way, I see no reason not to go ahead with bringing the docs in > wildfly/wildfly master and then we can deal with decomposition as a later > step. > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar wrote: >> >> Hey guys, >> >> TL;DR >> I've converted confluence docs asciidoc [1] [2] ones that will be part of >> WildFly codebase, >> take a look at them and let me know if there are any big issues. >> >> >> ---- >> full version: >> >> as most of you already know, I was working on moving our confluence based >> [1] documentation to asciidoc based one. >> >> result can be seen at [7] or rendered to html at [8] >> >> A good side effect of conversion is that now docs are also browsable >> directly on GitHub. >> For example [2] or [3] >> >> Currently I kept same structure as we had in confluence, which in practice >> means >> we have set of "guides" that than have lots of sub pages / includes that >> produce "big" guides. >> Currently such guides are: >> - Admin Guide >> - Developer Guide >> - Getting started guide >> - Getting Started Developing Applications Guide >> - High Availability Guide >> - Extending WildFly guide >> - JavaEE 7(6 actually) Tutorial >> - Elytron security guide >> - quickstarts >> - Testsuite >> >> Problem is that some of this guide as such make sense, but not all of them >> do. >> In some cases we have duplicated docs for same thing, in others we content >> in wrong segment. >> For example instead of having all subsystem reference docs under admin >> guide, >> some are under Developer Guide and some even under HA guide. >> >> Going forward we should "refactor" docs a bit, so we would end up with 3-4 >> high quality guides. >> We should also go trough all docs and remove/update the outdated content. >> >> Plan is also to have documentation now part of WildFly codebase. >> So when we would submit PR with new feature, it would also include >> documentation for it as well. >> >> Rendered docs can be build as part of our build / release process and can >> be rendered to different formats. >> for example default is HTML [5] or PDF [6] >> >> I've send experimental PR to show how docs would fit into WildFly build >> [4] >> >> Please take look at current docs and if you have any comments / >> suggestions what we can improve before merging it let me know. >> At this point I've not done much content-wise changes but just conversion >> + formatting ones. >> Content updates can come after this is merged. >> >> -- >> tomaz >> >> [1] https://docs.jboss.org/author/display/WFLY/Documentation >> [2] >> https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc >> [3] >> https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc >> [4] https://github.com/wildfly/wildfly/pull/10523 >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf >> [7] https://github.com/ctomc/docs-playground >> [8] https://ctomc.github.io/docs-playground/ >> >> _______________________________________________ >> 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 > Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML ? -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat _______________________________________________ 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171109/d7891bc8/attachment.html From brian.stansberry at redhat.com Thu Nov 9 11:41:48 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 9 Nov 2017 10:41:48 -0600 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: <5a047960.f1ae500a.5d340.8428@mx.google.com> References: <5a0463f8.bbf4500a.b9c25.a95a@mx.google.com> <5a047960.f1ae500a.5d340.8428@mx.google.com> Message-ID: See also https://opensource.com/article/17/9/modular-documentation On Thu, Nov 9, 2017 at 9:50 AM, Toma? Cerar wrote: > https://github.com/redhat-documentation/modular-docs > > > > -- > > tomaz > > > > *From: *Brian Stansberry > *Sent: *?etrtek, 09. november 2017 15:28 > *To: *Toma? Cerar > *Cc: *Bob McWhirter ; wildfly-dev at lists.jboss.org > > *Subject: *Re: [wildfly-dev] WildFly asciidoc based documentation > > > > > > On Thu, Nov 9, 2017 at 8:19 AM, Toma? Cerar wrote: > > I've updated PR https://github.com/wildfly/wildfly/pull/10523 > > That brings in converted confluence documentation. > > It is synced with todays content in confluence. > > > > This is just a start, going forward we should > > > > - Split docs between core & full > - Each subsystem could have docs folder that would be than agreggated > - Publish docs somewhere. Maybe use GH for start > http://wildfly.github.io/ > - Restrucutre docs into few books instead of what we have now. > > As we get into this last bit, we should look into the modular stuff Bob > mentioned. It sounds like it would mean a large scale rewrite, so if we > start doing things that are more than just moving some files around we > should consider the bigger picture. > > > > > > -- > > tomaz > > > > > > *From: *Bob McWhirter > *Sent: *?etrtek, 09. november 2017 01:48 > *To: *Brian Stansberry > *Cc: *wildfly-dev at lists.jboss.org > *Subject: *Re: [wildfly-dev] WildFly asciidoc based documentation > > > > We have recent used he doc teams ?modular documentation templates? and I > think they are lovely and also makes the docs team happy. > > > > Ask your doctor if modular documentation templates are right for you. > > > > Bob > > > > On Wed, Nov 8, 2017 at 12:40 PM Brian Stansberry < > brian.stansberry at redhat.com> wrote: > > Sounds like a good goal, but I don't think Tomaz should be responsible for > correcting all our docs to make them conform. For many of these I doubt the > Confluence markup includes relevant metadata that would have allowed that > (e.g. that a given literal was a filename, hence [filename]`thename` > instead of `thename`. We'd need to assign owners to various pages and have > them correct them. An obvious initial owner being the component lead for > the component that's most relevant to the page. > > > > On Wed, Nov 8, 2017 at 7:04 AM, David Lloyd > wrote: > > I would suggest that we ensure that our produced AsciiDoc files > conform to [1] (generated from [2]). Beyond that, I support this > initiative wholeheartedly. > > [1] https://redhat-documentation.github.io/asciidoc-markup-conventions/ > [2] https://github.com/redhat-documentation/asciidoc-markup-conventions > > > On Tue, Nov 7, 2017 at 12:06 PM, Brian Stansberry > wrote: > > Since we're done with WF 11, I think it's time to move forward on this. > > There's still some discussion to have about decomposing the docs so the > > relevant doc bits are aligned with the feature packs they come from, but > I > > haven't heard any argument against moving off Confluence and having the > docs > > included in the source tree. Since we don't have the current docs > decomposed > > in any way, I see no reason not to go ahead with bringing the docs in > > wildfly/wildfly master and then we can deal with decomposition as a later > > step. > > > > On Tue, Sep 19, 2017 at 7:58 AM, Toma? Cerar > wrote: > >> > >> Hey guys, > >> > >> TL;DR > >> I've converted confluence docs asciidoc [1] [2] ones that will be part > of > >> WildFly codebase, > >> take a look at them and let me know if there are any big issues. > >> > >> > >> ---- > >> full version: > >> > >> as most of you already know, I was working on moving our confluence > based > >> [1] documentation to asciidoc based one. > >> > >> result can be seen at [7] or rendered to html at [8] > >> > >> A good side effect of conversion is that now docs are also browsable > >> directly on GitHub. > >> For example [2] or [3] > >> > >> Currently I kept same structure as we had in confluence, which in > practice > >> means > >> we have set of "guides" that than have lots of sub pages / includes that > >> produce "big" guides. > >> Currently such guides are: > >> - Admin Guide > >> - Developer Guide > >> - Getting started guide > >> - Getting Started Developing Applications Guide > >> - High Availability Guide > >> - Extending WildFly guide > >> - JavaEE 7(6 actually) Tutorial > >> - Elytron security guide > >> - quickstarts > >> - Testsuite > >> > >> Problem is that some of this guide as such make sense, but not all of > them > >> do. > >> In some cases we have duplicated docs for same thing, in others we > content > >> in wrong segment. > >> For example instead of having all subsystem reference docs under admin > >> guide, > >> some are under Developer Guide and some even under HA guide. > >> > >> Going forward we should "refactor" docs a bit, so we would end up with > 3-4 > >> high quality guides. > >> We should also go trough all docs and remove/update the outdated > content. > >> > >> Plan is also to have documentation now part of WildFly codebase. > >> So when we would submit PR with new feature, it would also include > >> documentation for it as well. > >> > >> Rendered docs can be build as part of our build / release process and > can > >> be rendered to different formats. > >> for example default is HTML [5] or PDF [6] > >> > >> I've send experimental PR to show how docs would fit into WildFly build > >> [4] > >> > >> Please take look at current docs and if you have any comments / > >> suggestions what we can improve before merging it let me know. > >> At this point I've not done much content-wise changes but just > conversion > >> + formatting ones. > >> Content updates can come after this is merged. > >> > >> -- > >> tomaz > >> > >> [1] https://docs.jboss.org/author/display/WFLY/Documentation > >> [2] > >> https://github.com/ctomc/docs-playground/blob/master/admin- > guide/Operating_modes.adoc > >> [3] > >> https://github.com/ctomc/docs-playground/blob/master/ > developer-guide/EJB3_Reference_Guide.adoc > >> [4] https://github.com/wildfly/wildfly/pull/10523 > >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html > >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf > >> [7] https://github.com/ctomc/docs-playground > >> [8] https://ctomc.github.io/docs-playground/ > >> > >> _______________________________________________ > >> 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 > > Red Hat > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > - DML > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > _______________________________________________ > 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 > > Red Hat > > > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171109/2e19d7ae/attachment-0001.html From ema at redhat.com Mon Nov 13 22:30:13 2017 From: ema at redhat.com (Jim Ma) Date: Tue, 14 Nov 2017 11:30:13 +0800 Subject: [wildfly-dev] Undertow elytron ApplicationSecurityDomainService In-Reply-To: References: Message-ID: Hi Darren, Any comments/thoughts about this topic ? Thanks, Jim On Wed, Nov 8, 2017 at 9:47 AM, Jim Ma wrote: > WebSerivce subsystem has a user reported issue [1] which ws endpoint can't > declare an undertow subsystem application security domain in jboss-web.xml. > I had a quick look and it looks we need an injector to get undertow's > ApplicationSecurityDomain and finally get the elytron security domain like > what we handle ejb application security domain right now [2]. > To make this work, I write some workaround code [3], and this may better > explain what ws integration code expects to fix this issue. Darren and > Stuart, can you please have a look and let me know your ideas and thoughts > about this issue? > > [1]https://developer.jboss.org/message/977628 > [2] https://github.com/wildfly/wildfly/blob/master/webservices/server- > integration/src/main/java/org/jboss/as/webservices/service/ > EndpointService.java#L100 > [3] https://github.com/jimma/wildfly/commit/d93b8ac89e388c54a10ce627780486 > 143267e052 > > Thanks, > Jim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171114/581d47a1/attachment.html From ema at redhat.com Tue Nov 14 01:14:46 2017 From: ema at redhat.com (Jim Ma) Date: Tue, 14 Nov 2017 14:14:46 +0800 Subject: [wildfly-dev] Undertow elytron ApplicationSecurityDomainService In-Reply-To: References: Message-ID: Hi Darran, Please ignore my previous asking comments email. One guy here just reminded me that you already replied, but I didn't get this dev list email. Let me check what's wrong with my email setting. Let me reply here. >> Overall rather than adding further service dependencies, could it be better to attach something to the DeploymentUnit so it can be used later? I think this works as long as we can finally get elytron security domain from DeploymentUnit. Can you please point me the attachment key once this is added in undertow security integration code? Thanks, Jim On Tue, Nov 14, 2017 at 11:30 AM, Jim Ma wrote: > Hi Darren, > Any comments/thoughts about this topic ? > Thanks, > Jim > > > On Wed, Nov 8, 2017 at 9:47 AM, Jim Ma wrote: > >> WebSerivce subsystem has a user reported issue [1] which ws endpoint >> can't declare an undertow subsystem application security domain in >> jboss-web.xml. I had a quick look and it looks we need an injector to get >> undertow's ApplicationSecurityDomain and finally get the elytron security >> domain like what we handle ejb application security domain right now [2]. >> To make this work, I write some workaround code [3], and this may better >> explain what ws integration code expects to fix this issue. Darren and >> Stuart, can you please have a look and let me know your ideas and thoughts >> about this issue? >> >> [1]https://developer.jboss.org/message/977628 >> [2] https://github.com/wildfly/wildfly/blob/master/webservic >> es/server-integration/src/main/java/org/jboss/as/ >> webservices/service/EndpointService.java#L100 >> [3] https://github.com/jimma/wildfly/commit/d93b8ac89e388c54 >> a10ce627780486143267e052 >> >> Thanks, >> Jim >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171114/199a6c96/attachment.html From darran.lofthouse at jboss.com Thu Nov 16 06:27:49 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 16 Nov 2017 11:27:49 +0000 Subject: [wildfly-dev] Undertow elytron ApplicationSecurityDomainService In-Reply-To: References: Message-ID: I don't think we currently do have it but I am working on web application security at the moment, I could probably look into this next. On Tue, 14 Nov 2017 at 06:15 Jim Ma wrote: > Hi Darran, > > Please ignore my previous asking comments email. One guy here just > reminded me that you already replied, but I didn't get this dev list email. > Let me check what's wrong with my email setting. > > Let me reply here. > > >> Overall rather than adding further service dependencies, could it be > better to attach something to the DeploymentUnit so it can be used later? > > I think this works as long as we can finally get elytron security domain > from DeploymentUnit. Can you please point me the attachment key once this > is added in undertow security integration code? > > Thanks, > Jim > > On Tue, Nov 14, 2017 at 11:30 AM, Jim Ma wrote: > >> Hi Darren, >> Any comments/thoughts about this topic ? >> Thanks, >> Jim >> >> >> On Wed, Nov 8, 2017 at 9:47 AM, Jim Ma wrote: >> >>> WebSerivce subsystem has a user reported issue [1] which ws endpoint >>> can't declare an undertow subsystem application security domain in >>> jboss-web.xml. I had a quick look and it looks we need an injector to get >>> undertow's ApplicationSecurityDomain and finally get the elytron security >>> domain like what we handle ejb application security domain right now [2]. >>> To make this work, I write some workaround code [3], and this may better >>> explain what ws integration code expects to fix this issue. Darren and >>> Stuart, can you please have a look and let me know your ideas and thoughts >>> about this issue? >>> >>> [1]https://developer.jboss.org/message/977628 >>> [2] >>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java#L100 >>> [3] >>> https://github.com/jimma/wildfly/commit/d93b8ac89e388c54a10ce627780486143267e052 >>> >>> Thanks, >>> Jim >>> >>> >> > _______________________________________________ > 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/20171116/d0250d01/attachment.html From jdenise at redhat.com Fri Nov 17 10:47:27 2017 From: jdenise at redhat.com (Jean-Francois Denise) Date: Fri, 17 Nov 2017 16:47:27 +0100 Subject: [wildfly-dev] security/elytron CLI commands Message-ID: <7c8de310-84a7-6fae-01d6-484a453205bf@redhat.com> Hi, discussing with Darran on how to extend the CLI to help configure elytron, he suggested that we should move the discussion to this list. I have started a document [1] in order to collect feedbacks on new CLI commands to address security configuration. Feel free to comment on the document. Thank-you. JF [1] https://developer.jboss.org/wiki/SSLCommandsForCLI From bburke at redhat.com Fri Nov 17 11:46:01 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 17 Nov 2017 11:46:01 -0500 Subject: [wildfly-dev] kube-ping in distro? Message-ID: Are you guys planning on including kube-ping in future releases of Wildfly? -- Bill Burke Red Hat From mazz at redhat.com Mon Nov 20 11:41:49 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 20 Nov 2017 11:41:49 -0500 (EST) Subject: [wildfly-dev] strange JMX attribute values for domain servers In-Reply-To: <487429641.42755295.1511195514967.JavaMail.zimbra@redhat.com> Message-ID: <1302733137.42768478.1511196109689.JavaMail.zimbra@redhat.com> I'm seeing strange JMX attributes when looking at domain mode and its MBeans. In short, if a host wildfly server is up and running, there is no status in the "server" MBean but there is status in the "server-config" MBean. When the server is down, there is serverStatus in the "server" MBean as well as in the "server-config" MBean. Running a stock, out-of-box WildFly 11.0.0.Final using "domain.sh": 1. SERVER-ONE: 1a. MBean "jboss.as:host=master,server-config=server-one" has attribute "status" of value "STARTED". 1b. MBean "jboss.as:host=master,server=server-one" has no attributes at all - jconsole shows me no attributes for this MBean 2. SERVER-TWO: 2a. MBean "jboss.as:host=master,server-config=server-two" has attribute "status" of value "STARTED". 2b. MBean "jboss.as:host=master,server=server-two" has no attributes at all - jconsole shows me no attributes for this MBean 3. SERVER-THREE: 3a. MBean "jboss.as:host=master,server-config=server-three" has attribute "status" of value "DISABLED". 3b. MBean "jboss.as:host=master,server=server-three" interestingly has attribute "serverState" of value "STOPPED" This doesn't make sense to me. I believe the "server" MBean for a started server should have a serverState of values something like "running" or "restart-required" or "reload-required". But instead, they don't have any attributes at all. Thoughts? From brian.stansberry at redhat.com Mon Nov 20 14:45:55 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 20 Nov 2017 13:45:55 -0600 Subject: [wildfly-dev] security/elytron CLI commands In-Reply-To: <7c8de310-84a7-6fae-01d6-484a453205bf@redhat.com> References: <7c8de310-84a7-6fae-01d6-484a453205bf@redhat.com> Message-ID: +1 to discussing on the list. That sounds pretty good. You don't want to add things that will conflict with other things you might want to do later, but these actions sound quite targeted to their particular use case and have names that are also specific. On Fri, Nov 17, 2017 at 9:47 AM, Jean-Francois Denise wrote: > Hi, > > discussing with Darran on how to extend the CLI to help configure > elytron, he suggested that we should move the discussion to this list. I > have started a document [1] in order to collect feedbacks on new CLI > commands to address security configuration. Feel free to comment on the > document. > Thank-you. > JF > [1] https://developer.jboss.org/wiki/SSLCommandsForCLI > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171120/cfedb58e/attachment.html From ochaloup at redhat.com Tue Nov 21 12:20:55 2017 From: ochaloup at redhat.com (Ondra Chaloupka) Date: Tue, 21 Nov 2017 18:20:55 +0100 Subject: [wildfly-dev] Registering a WS handler to deal with error at Narayana/XTS/WFTC integration Message-ID: Hi guys, I wonder if there is somebody to help me with this issue[1]? Issue: Any call leaving EJB is checked if there is no active transaction[2]. WFLY code communicate with WFTC which maintains its own notion about active transactions (and Narayana code maintains its own too). If there is a transaction imported from incoming WS call (XTS trasaction) then Narayana code suspends transactions at its side before EJB checker is called. But in case of WFTC the notion about the transaction status is untouched. Thus EJB checker then throws exceptions. Solution: I'm thinking to create a new WS handler which would suspend the WFTC transaction similar how Narayana code does so[3]. But I need to add a new WS handler as dependency to the app deployment for that works[4]. Thus I would need a special WFLY module containing the handler, depending on WFTC, Narayana, XTS and WS modules. There is no such module having that kind of dependencies currently. Creating a special module for single java class sounds me wrong. Would have somebody an idea of handling this type of situation? I would think is there some option to create a dynamic module programmatically to register the WS handler? I was checking about options to register WS handler in instance but that seems not possible in WFLY integration code. Thank you for any thought Ondra [1] https://issues.jboss.org/browse/WFLY-9455: Unable to roll back active transaction thrown for EJB bridge transactions [2] https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/deployment/TransactionRollbackSetupAction.java#L134 [3] https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/org/jboss/jbossts/txbridge/inbound/JaxWSTxInboundBridgeHandler.java#L118 [4] https://github.com/wildfly/wildfly/blob/master/xts/src/main/java/org/jboss/as/xts/XTSDependenciesDeploymentProcessor.java#L116 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171121/4e6a6076/attachment.html From jdenise at redhat.com Thu Nov 23 09:25:17 2017 From: jdenise at redhat.com (Jean-Francois Denise) Date: Thu, 23 Nov 2017 15:25:17 +0100 Subject: [wildfly-dev] security/elytron CLI commands In-Reply-To: References: <7c8de310-84a7-6fae-01d6-484a453205bf@redhat.com> Message-ID: <787d198f-242b-fc69-6903-50e32f23d402@redhat.com> Farah, brought to my attention the key-store future operations[1] that will allow to bypass keytool. With this, key-store management seems to deserve its own set of "a la keytool" commands. I have updated the document[2] to reflect the separation. JF [1] https://developer.jboss.org/wiki/AnalysisDesign-AdvancedElytronKey-storeManipulationOperations [2] https://developer.jboss.org/wiki/SSLCommandsForCLI On 20/11/17 20:45, Brian Stansberry wrote: > +1 to discussing on the list. > > That sounds pretty good. You don't want to add things that will > conflict with other things you might want to do later, but these > actions sound quite targeted to their particular use case and have > names that are also specific. > > On Fri, Nov 17, 2017 at 9:47 AM, Jean-Francois Denise > > wrote: > > Hi, > > discussing with Darran on how to extend the CLI to help configure > elytron, he suggested that we should move the discussion to this > list. I > have started a document [1] in order to collect feedbacks on new CLI > commands to address security configuration. Feel free to comment > on the > document. > Thank-you. > JF > [1] https://developer.jboss.org/wiki/SSLCommandsForCLI > > _______________________________________________ > 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 > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171123/86183b35/attachment.html From rhusar at redhat.com Thu Nov 23 19:26:22 2017 From: rhusar at redhat.com (Radoslav Husar) Date: Fri, 24 Nov 2017 01:26:22 +0100 Subject: [wildfly-dev] kube-ping in distro? In-Reply-To: References: Message-ID: Hey Bill, Yes, we are, see https://issues.jboss.org/browse/WFLY-9563 which is scheduled for WildFly 12. Mostly just waiting for the JGroups 4 upgrade PR to get merged. Just to note, the version of KUBE_PING to go forward with is the https://github.com/jgroups-extras/jgroups-kubernetes - let me know if you have some requirements/questions/etc. Thanks, Rado On Fri, Nov 17, 2017 at 5:46 PM, Bill Burke wrote: > Are you guys planning on including kube-ping in future releases of Wildfly? > > -- > Bill Burke > Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From bburke at redhat.com Tue Nov 28 09:20:54 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 28 Nov 2017 09:20:54 -0500 Subject: [wildfly-dev] kube-ping in distro? In-Reply-To: References: Message-ID: What's ETA on Wildfly 12? On Thu, Nov 23, 2017 at 7:26 PM, Radoslav Husar wrote: > Hey Bill, > > Yes, we are, see https://issues.jboss.org/browse/WFLY-9563 which is > scheduled for WildFly 12. Mostly just waiting for the JGroups 4 > upgrade PR to get merged. > > Just to note, the version of KUBE_PING to go forward with is the > https://github.com/jgroups-extras/jgroups-kubernetes - let me know if > you have some requirements/questions/etc. > > Thanks, > Rado > > On Fri, Nov 17, 2017 at 5:46 PM, Bill Burke wrote: >> Are you guys planning on including kube-ping in future releases of Wildfly? >> >> -- >> Bill Burke >> Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Bill Burke Red Hat From belaran at redhat.com Tue Nov 28 09:37:48 2017 From: belaran at redhat.com (Romain Pelisse) Date: Tue, 28 Nov 2017 15:37:48 +0100 Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set Message-ID: Hi, As reported on JBEAP-12374[1], there is some discrepancies between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those discrepancies - or the most relevant ones, are some fine tuning performed on the (POSIX) privileges (things such as removing the write privilege for member of the same group as the owner of the file). I've looked into this and because those files are produced by our own Maven plugin (as part of wildfly-build-tools), we can not simply modify the assembly.xml. Which actually is probably for the best, as it would made the assembly file quite cumbersome. Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian suggested I started a discussion here. So does anyone have a (strong) opinion about this issue and/or how to resolve it ? :) (For the record, I do think it is best to fix the privileges to follow what the RPM does for us for now, but if you feel this issue should not be addressed, and dev- the issue, I'm certainly not opposed to it either). [1] https://issues.jboss.org/browse/JBEAP-12374 [2] https://github.com/wildfly/wildfly-build-tools/pull/40 [3] https://issues.jboss.org/browse/WFLY-9574 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/c421fa9d/attachment-0001.html From rory.odonnell at oracle.com Tue Nov 28 10:41:31 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 28 Nov 2017 15:41:31 +0000 Subject: [wildfly-dev] JDK 10 Early Access b33 and JDK 8u162 Early Access b03 are available on jdk.java.net Message-ID: <2836dbdb-344c-0b25-5e76-51633386e014@oracle.com> Hi Jason/Tomaz, *JDK 10 Early Access? build 33 is available at : - **jdk.java.net/10/* Notable changes since previous email. JDK-8180019 - *javadoc treats failure to access a URL as an error , not a warning.* If javadoc cannot access the contents of a URL provided with the -link or -linkoffline options,the tool will now report an error. Previously, the tool continued with a warning, producing incorrect documentation output. JDK-8175094 *- **The java.security.acl APIs are deprecated, for removal**** *?The deprecated java.security.acl APIs are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK-8175091 *- The java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated, for removal* The deprecated java.security.{Certificate, Identity, IdentityScope, Signer} classes are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK 10 Schedule, Status & Features are available [1] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [2] *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://openjdk.java.net/projects/jdk/10/ [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.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/20171128/de99f060/attachment.html From brian.stansberry at redhat.com Tue Nov 28 13:16:54 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Nov 2017 12:16:54 -0600 Subject: [wildfly-dev] Reads of subsystem resources under a /deployment=x resource Message-ID: Hi Harald, Does HAL always include the "include-runtime=true" param when doing a read of resources under a /deployment=x resource? I'm asking because I noticed an annoying problem when trying to do some cleanup of whether runtime-only resources correctly report themselves as such.[1] It turns out we have a bug where must subsystem resources under /deployment=* don't report themselves as runtime-only, which means they show up in an op like this, even though they should not: https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg The "subsystem=undertow" child should not appear because the op used "include-runtime=false". So that's a bug. I probably won't fix that bug any time soon, because "include-runtime=false" is the default behavior. Which mean this is a bug that some users may be counting on. :( One example being Arquillian -- see [2]. But I'm wondering whether HAL is an example of that. If it is, it's something that should be corrected. At some point we may have to correct this. Jean-Francois Denise, I have the same question for you re: CLI. Emmanuel Hugonnet -- I'm hoping this isn't a significant problem for your provisioning feature-spec work. If it is maybe we can find a way to work around. These resource types are not relevant on an admin-only server and my guess any feature-spec generation would use an admin-only process. [1] https://issues.jboss.org/browse/WFCORE-3432. [2] https://issues.jboss.org/browse/WFARQ-35 Cheers, -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/b3846000/attachment.html From jperkins at redhat.com Tue Nov 28 13:34:31 2017 From: jperkins at redhat.com (James Perkins) Date: Tue, 28 Nov 2017 10:34:31 -0800 Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set In-Reply-To: References: Message-ID: Why does the RPM change permissions? If there is a file permissions issue we should be fixing this in the feature pack itself not the changing the permissions within the provisioning system. There could be reasons why file permissions are the way they are and we shouldn't make assumptions based on a file extension. On Tue, Nov 28, 2017 at 6:37 AM, Romain Pelisse wrote: > Hi, > > As reported on JBEAP-12374[1], there is some discrepancies between the ZIP > file we provided for Widlfy/EAP and the RPM generate. Most of those > discrepancies - or the most relevant ones, are some fine tuning performed > on the (POSIX) privileges (things such as removing the write privilege for > member of the same group as the owner of the file). > > I've looked into this and because those files are produced by our own > Maven plugin (as part of wildfly-build-tools), we can not simply modify the > assembly.xml. Which actually is probably for the best, as it would made the > assembly file quite cumbersome. > > Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but when > I reported the problem on WFLY-9574[3], Brian suggested I started a > discussion here. So does anyone have a (strong) opinion about this issue > and/or how to resolve it ? :) > > (For the record, I do think it is best to fix the privileges to follow > what the RPM does for us for now, but if you feel this issue should not be > addressed, and dev- the issue, I'm certainly not opposed to it either). > > [1] https://issues.jboss.org/browse/JBEAP-12374 > [2] https://github.com/wildfly/wildfly-build-tools/pull/40 > [3] https://issues.jboss.org/browse/WFLY-9574 > > _______________________________________________ > 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/20171128/890667c8/attachment.html From hpehl at redhat.com Tue Nov 28 14:17:12 2017 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 28 Nov 2017 20:17:12 +0100 Subject: [wildfly-dev] Reads of subsystem resources under a /deployment=x resource In-Reply-To: References: Message-ID: I've checked HAL.next and we only use "include-runtime=true" when reading deployment related resources This applies for both standalone and domain mode. I didn't check HAL.current yet, but I'm quite sure we use the same semantics here. So fixing the bug shouldn't affect neither HAL.next nor HAL.current. Cheers Harald > On 28. Nov 2017, at 19:16, Brian Stansberry wrote: > > Hi Harald, > > Does HAL always include the "include-runtime=true" param when doing a read of resources under a /deployment=x resource? > > I'm asking because I noticed an annoying problem when trying to do some cleanup of whether runtime-only resources correctly report themselves as such.[1] It turns out we have a bug where must subsystem resources under /deployment=* don't report themselves as runtime-only, which means they show up in an op like this, even though they should not: > > https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg > The "subsystem=undertow" child should not appear because the op used "include-runtime=false". So that's a bug. > > I probably won't fix that bug any time soon, because "include-runtime=false" is the default behavior. Which mean this is a bug that some users may be counting on. :( One example being Arquillian -- see [2]. But I'm wondering whether HAL is an example of that. If it is, it's something that should be corrected. At some point we may have to correct this. > > Jean-Francois Denise, I have the same question for you re: CLI. > > Emmanuel Hugonnet -- I'm hoping this isn't a significant problem for your provisioning feature-spec work. If it is maybe we can find a way to work around. These resource types are not relevant on an admin-only server and my guess any feature-spec generation would use an admin-only process. > > [1] https://issues.jboss.org/browse/WFCORE-3432 . > [2] https://issues.jboss.org/browse/WFARQ-35 > > Cheers, > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/d436bd51/attachment-0001.html From jdenise at redhat.com Tue Nov 28 15:43:49 2017 From: jdenise at redhat.com (Jean-Francois Denise) Date: Tue, 28 Nov 2017 21:43:49 +0100 Subject: [wildfly-dev] Reads of subsystem resources under a /deployment=x resource In-Reply-To: References: Message-ID: <11b06f4e-506f-2fad-3602-429fbd12c9a4@redhat.com> Brian, CLI has 3 calls to /deployment=x:read-resource that don't have include-runtime=true. But from what I see, if suddenly subsystems are not returned, it wouldn't change anything. JF On 28/11/17 20:17, Harald Pehl wrote: > I've checked HAL.next and we only use "include-runtime=true" when > reading deployment related resources This applies for both standalone > and domain mode. > > I didn't check HAL.current yet, but I'm quite sure we use the same > semantics here. So fixing the bug shouldn't affect neither HAL.next > nor HAL.current. > > Cheers > Harald > >> On 28. Nov 2017, at 19:16, Brian Stansberry >> > wrote: >> >> Hi Harald, >> >> Does HAL always include the "include-runtime=true" param when doing a >> read of resources under a /deployment=x resource? >> >> I'm asking because I noticed an annoying problem when trying to do >> some cleanup of whether runtime-only resources correctly report >> themselves as such.[1] It turns out we have a bug where must >> subsystem resources under /deployment=* don't report themselves as >> runtime-only, which means they show up in an op like this, even >> though they should not: >> >> https://paste.fedoraproject.org/paste/4WGJ7~UpeJvR0tqtEDYfNg >> >> >> The "subsystem=undertow" child should not appear because the op used >> "include-runtime=false". So that's a bug. >> >> I probably won't fix that bug any time soon, because >> "include-runtime=false" is the default behavior. Which mean this is a >> bug that some users may be counting on. :( One example being >> Arquillian -- see [2]. But I'm wondering whether HAL is an example of >> that. If it is, it's something that should be corrected. At some >> point we may have to correct this. >> >> Jean-Francois Denise, I have the same question for you re: CLI. >> >> Emmanuel Hugonnet -- I'm hoping this isn't a significant problem for >> your provisioning feature-spec work. If it is maybe we can find a way >> to work around. These resource types are not relevant on an >> admin-only server and my guess any feature-spec generation would use >> an admin-only process. >> >> [1] https://issues.jboss.org/browse/WFCORE-3432. >> [2] https://issues.jboss.org/browse/WFARQ-35 >> >> Cheers, >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> 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/20171128/041d07ad/attachment.html From brian.stansberry at redhat.com Tue Nov 28 15:44:40 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Nov 2017 14:44:40 -0600 Subject: [wildfly-dev] strange JMX attribute values for domain servers In-Reply-To: <1302733137.42768478.1511196109689.JavaMail.zimbra@redhat.com> References: <487429641.42755295.1511195514967.JavaMail.zimbra@redhat.com> <1302733137.42768478.1511196109689.JavaMail.zimbra@redhat.com> Message-ID: Once a managed server is launched and registers with the HC the 'server' resources are just proxies to the remote process. To access the attributes of those resources you'd have to proxy to the remote process, which happens transparently with WildFly management but which we don't support for JMX. Probably we shouldn't expose the mbean at all, although that may be easier said than done. When the server isn't launched yet there's a kind of non-proxy placeholder resource for it on the HC that is the registration point for ops like start (which is why a resource even exists.) It exposes a few minimal attributes, which seemed like a minor nice thing to do but I can see how it can be confusing: [domain at localhost:9990 server=server-three] ls -l ATTRIBUTE VALUE TYPE launch-type DOMAIN STRING runtime-configuration-state stopped STRING server-state STOPPED STRING It seems a bunch of us have been getting wildfly-dev mails routed to our spam folders, so apologies if we seem to be ignoring things. On Mon, Nov 20, 2017 at 10:41 AM, John Mazzitelli wrote: > I'm seeing strange JMX attributes when looking at domain mode and its > MBeans. > > In short, if a host wildfly server is up and running, there is no status > in the "server" MBean but there is status in the "server-config" MBean. > When the server is down, there is serverStatus in the "server" MBean as > well as in the "server-config" MBean. > > Running a stock, out-of-box WildFly 11.0.0.Final using "domain.sh": > > 1. SERVER-ONE: > > 1a. MBean "jboss.as:host=master,server-config=server-one" has attribute > "status" of value "STARTED". > 1b. MBean "jboss.as:host=master,server=server-one" has no attributes at > all - jconsole shows me no attributes for this MBean > > 2. SERVER-TWO: > > 2a. MBean "jboss.as:host=master,server-config=server-two" has attribute > "status" of value "STARTED". > 2b. MBean "jboss.as:host=master,server=server-two" has no attributes at > all - jconsole shows me no attributes for this MBean > > 3. SERVER-THREE: > > 3a. MBean "jboss.as:host=master,server-config=server-three" has attribute > "status" of value "DISABLED". > 3b. MBean "jboss.as:host=master,server=server-three" interestingly has > attribute "serverState" of value "STOPPED" > > This doesn't make sense to me. I believe the "server" MBean for a started > server should have a serverState of values something like "running" or > "restart-required" or "reload-required". But instead, they don't have any > attributes at all. > > Thoughts? > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/d17af8e6/attachment.html From brian.stansberry at redhat.com Tue Nov 28 16:00:09 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Nov 2017 15:00:09 -0600 Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set In-Reply-To: References: Message-ID: I think we need to start with the assumption that the permissions we have in the zip are the way they are for a reason and evaluate possible changes based on discussion here of each type of change. Maybe the RPM settings are better, maybe they are not. Or maybe they are better but the improvement is not worth the disruption a change may cause to our end users, who may rely on the current zip settings. Or maybe what we have in the zip is clearly wrong and doesn't follow our own intent. I expect we'll probably see a little of each category, although hopefully some changes for WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse wrote: > Hi, > > As reported on JBEAP-12374[1], there is some discrepancies between the ZIP > file we provided for Widlfy/EAP and the RPM generate. Most of those > discrepancies - or the most relevant ones, are some fine tuning performed > on the (POSIX) privileges (things such as removing the write privilege for > member of the same group as the owner of the file). > > I've looked into this and because those files are produced by our own > Maven plugin (as part of wildfly-build-tools), we can not simply modify the > assembly.xml. Which actually is probably for the best, as it would made the > assembly file quite cumbersome. > > Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but when > I reported the problem on WFLY-9574[3], Brian suggested I started a > discussion here. So does anyone have a (strong) opinion about this issue > and/or how to resolve it ? :) > > (For the record, I do think it is best to fix the privileges to follow > what the RPM does for us for now, but if you feel this issue should not be > addressed, and dev- the issue, I'm certainly not opposed to it either). > > [1] https://issues.jboss.org/browse/JBEAP-12374 > [2] https://github.com/wildfly/wildfly-build-tools/pull/40 > [3] https://issues.jboss.org/browse/WFLY-9574 > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/96df32c8/attachment.html From brian.stansberry at redhat.com Tue Nov 28 16:08:57 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Nov 2017 15:08:57 -0600 Subject: [wildfly-dev] kube-ping in distro? In-Reply-To: References: Message-ID: We're thinking late January but that's not firm yet. On Tue, Nov 28, 2017 at 8:20 AM, Bill Burke wrote: > What's ETA on Wildfly 12? > > On Thu, Nov 23, 2017 at 7:26 PM, Radoslav Husar wrote: > > Hey Bill, > > > > Yes, we are, see https://issues.jboss.org/browse/WFLY-9563 which is > > scheduled for WildFly 12. Mostly just waiting for the JGroups 4 > > upgrade PR to get merged. > > > > Just to note, the version of KUBE_PING to go forward with is the > > https://github.com/jgroups-extras/jgroups-kubernetes - let me know if > > you have some requirements/questions/etc. > > > > Thanks, > > Rado > > > > On Fri, Nov 17, 2017 at 5:46 PM, Bill Burke wrote: > >> Are you guys planning on including kube-ping in future releases of > Wildfly? > >> > >> -- > >> Bill Burke > >> Red Hat > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Bill Burke > Red Hat > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171128/2f21a73c/attachment-0001.html From belaran at redhat.com Wed Nov 29 04:12:03 2017 From: belaran at redhat.com (Romain Pelisse) Date: Wed, 29 Nov 2017 10:12:03 +0100 Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set In-Reply-To: References: Message-ID: Well, the diff is between the RPM and the zipfile is pretty long, but it boils down to the 3 set of differences I've pointed out on WFLY-9574: - *.properties and .jar* files are associated with the mask rw-rw-r-- giving access to it to any other users and allowing group member to modify the file - the RPM distribution fixes that by removing the write privileges for the group (rw-r--r--). I personnaly don't see the value of letting the group members modify those files, I just can see how this could be exploited, so I would say it falls into "clearly wrong and not our intent". A case might be made for the .properties files, but for jars file I really don't see a valid use case (unless of course, any of you know one) ; - *some directories* like 'domain/tmp/auth' have too restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't really agree with) and - *other directories*, likes 'domain' have again a too permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses. So we need to find an agreement on those three items, and then see how we proceed to implement the fix (if needed). On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > I think we need to start with the assumption that the permissions we have > in the zip are the way they are for a reason and evaluate possible changes > based on discussion here of each type of change. Maybe the RPM settings are > better, maybe they are not. Or maybe they are better but the improvement is > not worth the disruption a change may cause to our end users, who may rely > on the current zip settings. Or maybe what we have in the zip is clearly > wrong and doesn't follow our own intent. I expect we'll probably see a > little of each category, although hopefully some changes for WF 11 removed > the "clearly wrong and doesn't follow our intent" cases. :) > > On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse > wrote: > >> Hi, >> >> As reported on JBEAP-12374[1], there is some discrepancies between the >> ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those >> discrepancies - or the most relevant ones, are some fine tuning performed >> on the (POSIX) privileges (things such as removing the write privilege for >> member of the same group as the owner of the file). >> >> I've looked into this and because those files are produced by our own >> Maven plugin (as part of wildfly-build-tools), we can not simply modify the >> assembly.xml. Which actually is probably for the best, as it would made the >> assembly file quite cumbersome. >> >> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but >> when I reported the problem on WFLY-9574[3], Brian suggested I started a >> discussion here. So does anyone have a (strong) opinion about this issue >> and/or how to resolve it ? :) >> >> (For the record, I do think it is best to fix the privileges to follow >> what the RPM does for us for now, but if you feel this issue should not be >> addressed, and dev- the issue, I'm certainly not opposed to it either). >> >> [1] https://issues.jboss.org/browse/JBEAP-12374 >> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >> [3] https://issues.jboss.org/browse/WFLY-9574 >> >> _______________________________________________ >> 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 > Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171129/940a03be/attachment.html From mazz at redhat.com Wed Nov 29 09:33:08 2017 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 29 Nov 2017 09:33:08 -0500 (EST) Subject: [wildfly-dev] feature pack domain host.xml override In-Reply-To: <807788818.47637512.1511965500340.JavaMail.zimbra@redhat.com> Message-ID: <963473494.47645690.1511965988684.JavaMail.zimbra@redhat.com> How I can get a domain "host.xml" found in a feature pack to get placed in the domain/configuration/host.xml location of the generated WF distro? I have this: https://github.com/hawkular/hawkular-agent/blob/master/hawkular-javaagent-wildfly-dist/server-provisioning-plain-wildfly.xml and I want the "host.xml" that is in that hawkular feature pack's "configuration/domain/host.xml" location to be deployed properly (in the correct spot in the final WF distro that gets laid down). As a side question: is it possible to take the existing WF feature pack's host.xml and simple inject things in its settings but leaving the rest alone? The idea is that I want the slave servers to start with a -javagent cmdline option (e.g. to get the Prometheus JMX Exporter agent or the Jolokia agent to run in all slave servers spawned by the host controller). [this message was sent on November 29, 2017 at 9:33 EST - these mailing lists have had huge delays in delivering things recently, let's see how long it takes this one to get delivered] From stuart.w.douglas at gmail.com Wed Nov 29 17:50:18 2017 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 30 Nov 2017 09:50:18 +1100 Subject: [wildfly-dev] feature pack domain host.xml override In-Reply-To: <963473494.47645690.1511965988684.JavaMail.zimbra@redhat.com> References: <807788818.47637512.1511965500340.JavaMail.zimbra@redhat.com> <963473494.47645690.1511965988684.JavaMail.zimbra@redhat.com> Message-ID: It should be located in configuration/host/host.xml (see the current WF feature pack build for an example). Stuart On Thu, Nov 30, 2017 at 1:33 AM, John Mazzitelli wrote: > How I can get a domain "host.xml" found in a feature pack to get placed in > the domain/configuration/host.xml location of the generated WF distro? > > I have this: > > https://github.com/hawkular/hawkular-agent/blob/master/ > hawkular-javaagent-wildfly-dist/server-provisioning-plain-wildfly.xml > > and I want the "host.xml" that is in that hawkular feature pack's > "configuration/domain/host.xml" location to be deployed properly (in the > correct spot in the final WF distro that gets laid down). > > As a side question: is it possible to take the existing WF feature pack's > host.xml and simple inject things in its settings but leaving the > rest alone? > > The idea is that I want the slave servers to start with a -javagent > cmdline option (e.g. to get the Prometheus JMX Exporter agent or the > Jolokia agent to run in all slave servers spawned by the host controller). > > > [this message was sent on November 29, 2017 at 9:33 EST - these mailing > lists have had huge delays in delivering things recently, let's see how > long it takes this one to get delivered] > _______________________________________________ > 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/20171130/7c55e22c/attachment.html From brian.stansberry at redhat.com Thu Nov 30 13:17:20 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 30 Nov 2017 12:17:20 -0600 Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set In-Reply-To: References: Message-ID: Seems I forgot to "Reply to All" yesterday. The following was meant to be sent to wildfly-dev. On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Before getting into the specifics, first a general note re: perms. > > Our general permission set for is rwxr-xr-x for directories and rwxr--r-- > for files. If someone thinks that's wrong in general; speak up. ;). > Otherwise I think any deviation from that we should justify. Not that > deviations are wrong, just that they need to have a reason. > > On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse > wrote: > >> Well, the diff is between the RPM and the zipfile is pretty long, but it >> boils down to the 3 set of differences I've pointed out on WFLY-9574: >> >> >> - *.properties and .jar* files are associated with the mask rw-rw-r-- >> giving access to it to any other users and allowing group member to modify >> the file - the RPM distribution fixes that by removing the write privileges >> for the group (rw-r--r--). I personnaly don't see the value of letting the >> group members modify those files, I just can see how this could be >> exploited, so I would say it falls into "clearly wrong and not our intent". >> A case might be made for the .properties files, but for jars file I really >> don't see a valid use case (unless of course, any of you know one) ; >> >> There are a few different things here, so let's deal with them separately. > > For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as > rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I > don't see why they should vary from the general standard. And the > module.xml file should be consistent, since there's not much point in > locking people from touching jars but letting them change what jars get > loaded. > > For properties files, let's consider them on a more fine-grained basis. > For example, the properties files used by the security realms have > different kinds of data than logging.properties does. > > The perms on the security realm property files are rw-------, not > rw-rw-r--. > > The logging.properties files are rw-r--r-- which is consistent with the > domain|host|standalone.xml files and with the general standard. > > >> >> - >> - *some directories* like 'domain/tmp/auth' have too restrictive mask >> like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't really >> agree with) and >> >> >> - *other directories*, likes 'domain' have again a too permissive >> mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses. >> >> In the unzip I see these directories as rwxr-xr-x, which I think is fine. > > Are you concerned with any other directories besides $JBOSS_HOME/domain > and $JBOSS_HOME/standalone? > >> So we need to find an agreement on those three items, and then see how we >> proceed to implement the fix (if needed). >> >> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry < >> brian.stansberry at redhat.com> wrote: >> >>> I think we need to start with the assumption that the permissions we >>> have in the zip are the way they are for a reason and evaluate possible >>> changes based on discussion here of each type of change. Maybe the RPM >>> settings are better, maybe they are not. Or maybe they are better but the >>> improvement is not worth the disruption a change may cause to our end >>> users, who may rely on the current zip settings. Or maybe what we have in >>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll >>> probably see a little of each category, although hopefully some changes for >>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :) >>> >>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse >>> wrote: >>> >>>> Hi, >>>> >>>> As reported on JBEAP-12374[1], there is some discrepancies between the >>>> ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those >>>> discrepancies - or the most relevant ones, are some fine tuning performed >>>> on the (POSIX) privileges (things such as removing the write privilege for >>>> member of the same group as the owner of the file). >>>> >>>> I've looked into this and because those files are produced by our own >>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the >>>> assembly.xml. Which actually is probably for the best, as it would made the >>>> assembly file quite cumbersome. >>>> >>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but >>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a >>>> discussion here. So does anyone have a (strong) opinion about this issue >>>> and/or how to resolve it ? :) >>>> >>>> (For the record, I do think it is best to fix the privileges to follow >>>> what the RPM does for us for now, but if you feel this issue should not be >>>> addressed, and dev- the issue, I'm certainly not opposed to it either). >>>> >>>> [1] https://issues.jboss.org/browse/JBEAP-12374 >>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40 >>>> [3] https://issues.jboss.org/browse/WFLY-9574 >>>> >>>> _______________________________________________ >>>> 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 >>> Red Hat >>> >> >> > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171130/8ee3afbf/attachment-0001.html From asoldano at redhat.com Thu Nov 30 18:50:48 2017 From: asoldano at redhat.com (Alessio Soldano) Date: Fri, 1 Dec 2017 00:50:48 +0100 Subject: [wildfly-dev] Policies for merging PRs on master Message-ID: As suggested by Brian, I'd like to draw attention to the discussion on https://github.com/wildfly/wildfly/pull/10604 . The PR is an upgrade of the webservices stack, including JBossWS, Apache CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and better JDK 9 compatibility. Now, due to the upgrade of the JAXB API spec jar, the PR is essentially stalled since 20 days; the new spec is released as an alpha (as it's been tested within JBossWS only) and that does not satisfy a rule that requires any artifact being pulled to be Final. We're talking about a spec jar, we could simply re-tag that as Final, chances are we won't need changes any time soon there anyway, but as Tomaz pointed out, in principle that would be dishonest. While I see the point in requiring that only sufficiently stable upgrades are applied to the codebase, I'm wondering whether, maybe, we're going a bit too far with the rules. Brian wrote on this topic: "how to determine that something is good enough to go in without using master as a test bed" ? Opinions? Cheers Alessio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171201/56151bc8/attachment.html