From rory.odonnell at oracle.com Fri Jan 4 04:50:11 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 4 Jan 2019 09:50:11 +0000 Subject: [wildfly-dev] JDK 12 Early Access build 26 & JDK 13 Early Access builds available Message-ID: Hi David & Richard,* * Happy New Year! *OpenJDK builds *- JDK 12 Early Access build 26 is available at http://jdk.java.net/12/ * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes since last email o Distrust TLS server certificates anchored by Symantec Root CAs (JDK-8207258 ) o Customizing the generation of a PKCS12 keystore (JDK-8076190 ) o Compact Number Formatting Support (JDK-8177552 ) *OpenJDK builds *- JDK 13 - Early Access build 2 is available at http://jdk.java.net/13/ * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Changes in this build *jpackage EA builds* * This is an early access build of JEP 343: Packaging Tool , aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * Please send feedback via e-mail to core-libs-dev at openjdk.java.net *Quality Outreach report for December 2018* * The report for December 2018 is available here Rgds,Rory -- 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/20190104/b8a23810/attachment.html From jason.greene at redhat.com Mon Jan 7 15:21:49 2019 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 7 Jan 2019 14:21:49 -0600 Subject: [wildfly-dev] New WildFly Project Lead Message-ID: [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. Turn the page. -Jason From brian.stansberry at redhat.com Mon Jan 7 16:58:00 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 7 Jan 2019 15:58:00 -0600 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Thanks, Jason! It's a great privilege to work with the WildFly community and to work on open source software. I owe a great debt to all of you. I'm basically a self-taught engineer, and by far the best way to learn I've seen is to collaborate with the people in this community, looking at your ideas and the code you write and listening to your feedback on my ideas and code. Jason, it's also a tremendous honor and privilege working with you. Your leadership of JBoss AS and WildFly has been off the charts outstanding. I have very big shoes to fill. 2019 should be another exciting year for WildFly. We'll continue the quarterly release cadence that we started last year with WildFly 12, so the next major, WildFly 16, should be out in less than two months. This year Jakarta EE will be a priority, both getting Jarkarta EE 8 certification and helping drive EE forward. Another major focus will be continuing to improve the usability of WildFly on the cloud -- enhanced observability, enhanced ability to tailor your installation to your specific requirements, enhanced ability to use external services instead of in-vm resources for things like messaging and caching, and development of an OpenShift operator[1] for Wildfly. And plenty of other goodies too! Besides following this list and JIRA, I recommend that people interested in the development of WildFly occasionally check out the wildfly-proposals github repo[2]. For any new feature going into WildFly there will be a document added to that repo where the feature requirements will be discussed and sometimes some design details. Participating in the review of proposals there (via PR comments) is a great way to help ensure features meet your needs. [1] https://blog.openshift.com/introducing-the-operator-framework/ [2] https://github.com/wildfly/wildfly-proposals/pulls Best regards, Brian On Mon, Jan 7, 2019 at 2:26 PM Jason Greene wrote: > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > 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/20190107/7901cf62/attachment.html From bgeorges at redhat.com Mon Jan 7 19:20:16 2019 From: bgeorges at redhat.com (Bruno Georges) Date: Tue, 8 Jan 2019 01:20:16 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: <6106A8AF-D2FE-4AAA-8668-1020979ECC37@redhat.com> Congratulations Brian! This is awesome news! Jason, I can?t find the words to express how grateful I am for the amazing work you pulled over the years and how you led the Team to take us where we are today. I totally agree that with Brian at the Helm, Wildfly is in safe hands and it will disrupt again. Bruno > On 7 Jan 2019, at 9:21 PM, Jason Greene wrote: > > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kkhan at redhat.com Tue Jan 8 07:37:38 2019 From: kkhan at redhat.com (Kabir Khan) Date: Tue, 8 Jan 2019 12:37:38 +0000 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: <6106A8AF-D2FE-4AAA-8668-1020979ECC37@redhat.com> References: <6106A8AF-D2FE-4AAA-8668-1020979ECC37@redhat.com> Message-ID: +100 - Congratulations Brian! On Tue, Jan 8, 2019 at 12:21 AM Bruno Georges wrote: > Congratulations Brian! This is awesome news! > Jason, I can?t find the words to express how grateful I am for the amazing > work you pulled over the years and how you led the Team to take us where we > are today. > I totally agree that with Brian at the Helm, Wildfly is in safe hands and > it will disrupt again. > > Bruno > > > On 7 Jan 2019, at 9:21 PM, Jason Greene wrote: > > > > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > > > Turn the page. > > > > -Jason > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/33167df9/attachment-0001.html From tom.jenkinson at redhat.com Tue Jan 8 07:49:32 2019 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Tue, 8 Jan 2019 12:49:32 +0000 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: <6106A8AF-D2FE-4AAA-8668-1020979ECC37@redhat.com> Message-ID: Congratulations Brian! On Tue, 8 Jan 2019 at 12:43, Kabir Khan wrote: > +100 - Congratulations Brian! > > On Tue, Jan 8, 2019 at 12:21 AM Bruno Georges wrote: > >> Congratulations Brian! This is awesome news! >> Jason, I can?t find the words to express how grateful I am for the >> amazing work you pulled over the years and how you led the Team to take us >> where we are today. >> I totally agree that with Brian at the Helm, Wildfly is in safe hands and >> it will disrupt again. >> >> Bruno >> >> > On 7 Jan 2019, at 9:21 PM, Jason Greene >> wrote: >> > >> > [Also Posted to Wildfly Blog: >> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >> > >> > I am very excited to announce that Brian Stansberry (@bestansberry) >> will be taking on the role of WildFly project lead. Brian has been a major >> contributor to the project for almost 15 years now. During this time, he >> led a number of critical and complex subsystems including Clustering, >> Management, and most recently the cross-cutting cloud integration work. He >> is also one of our most active reviewers, and has helped many contributors >> navigate deep WildFly internals. Congratulations Brian! >> > >> > It?s been a great journey, so I want to think each and every one of you >> for your contributions and support over the years. Our work as a community >> has frequently pushed the envelope, and led to WildFly being one of the >> most innovative and popular application servers available. While I will be >> moving on from this role, I won?t be too far way, still participating but >> tackling a new challenge (I?ll have more to say about that in the future). >> > >> > With Brian at the helm, and all the great folks contributing to the >> project, I know WildFly has a bright future. I look forward to seeing the >> next chapter. >> > >> > Turn the page. >> > >> > -Jason >> > >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/168dd216/attachment.html From jperkins at redhat.com Tue Jan 8 09:33:57 2019 From: jperkins at redhat.com (James Perkins) Date: Tue, 8 Jan 2019 06:33:57 -0800 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! On Mon, Jan 7, 2019 at 12:26 PM Jason Greene wrote: > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > 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/20190108/e738b595/attachment.html From tadamski at redhat.com Tue Jan 8 10:21:57 2019 From: tadamski at redhat.com (Tomasz Adamski) Date: Tue, 8 Jan 2019 16:21:57 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! On Tue, Jan 8, 2019 at 3:43 PM James Perkins wrote: > Congratulations Brian! > > On Mon, Jan 7, 2019 at 12:26 PM Jason Greene > wrote: > >> [Also Posted to Wildfly Blog: >> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >> >> I am very excited to announce that Brian Stansberry (@bestansberry) will >> be taking on the role of WildFly project lead. Brian has been a major >> contributor to the project for almost 15 years now. During this time, he >> led a number of critical and complex subsystems including Clustering, >> Management, and most recently the cross-cutting cloud integration work. He >> is also one of our most active reviewers, and has helped many contributors >> navigate deep WildFly internals. Congratulations Brian! >> >> It?s been a great journey, so I want to think each and every one of you >> for your contributions and support over the years. Our work as a community >> has frequently pushed the envelope, and led to WildFly being one of the >> most innovative and popular application servers available. While I will be >> moving on from this role, I won?t be too far way, still participating but >> tackling a new challenge (I?ll have more to say about that in the future). >> >> With Brian at the helm, and all the great folks contributing to the >> project, I know WildFly has a bright future. I look forward to seeing the >> next chapter. >> >> Turn the page. >> >> -Jason >> >> >> >> _______________________________________________ >> 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 -- Regards, Tomek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/69f9fc13/attachment.html From hpehl at redhat.com Tue Jan 8 11:01:17 2019 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 8 Jan 2019 17:01:17 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! > On 8. Jan 2019, at 16:21, Tomasz Adamski wrote: > > Congratulations Brian! > > > On Tue, Jan 8, 2019 at 3:43 PM James Perkins > wrote: > Congratulations Brian! > > On Mon, Jan 7, 2019 at 12:26 PM Jason Greene > wrote: > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/ ] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > 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 > > -- > Regards, > Tomek > _______________________________________________ > 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/20190108/e36a14a5/attachment-0001.html From belaran at redhat.com Tue Jan 8 11:02:32 2019 From: belaran at redhat.com (Romain Pelisse) Date: Tue, 8 Jan 2019 17:02:32 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! On Tue, Jan 8, 2019 at 5:02 PM Harald Pehl wrote: > Congratulations Brian! > > On 8. Jan 2019, at 16:21, Tomasz Adamski wrote: > > Congratulations Brian! > > > On Tue, Jan 8, 2019 at 3:43 PM James Perkins wrote: > >> Congratulations Brian! >> >> On Mon, Jan 7, 2019 at 12:26 PM Jason Greene >> wrote: >> >>> [Also Posted to Wildfly Blog: >>> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >>> >>> I am very excited to announce that Brian Stansberry (@bestansberry) will >>> be taking on the role of WildFly project lead. Brian has been a major >>> contributor to the project for almost 15 years now. During this time, he >>> led a number of critical and complex subsystems including Clustering, >>> Management, and most recently the cross-cutting cloud integration work. He >>> is also one of our most active reviewers, and has helped many contributors >>> navigate deep WildFly internals. Congratulations Brian! >>> >>> It?s been a great journey, so I want to think each and every one of you >>> for your contributions and support over the years. Our work as a community >>> has frequently pushed the envelope, and led to WildFly being one of the >>> most innovative and popular application servers available. While I will be >>> moving on from this role, I won?t be too far way, still participating but >>> tackling a new challenge (I?ll have more to say about that in the future). >>> >>> With Brian at the helm, and all the great folks contributing to the >>> project, I know WildFly has a bright future. I look forward to seeing the >>> next chapter. >>> >>> Turn the page. >>> >>> -Jason >>> >>> >>> >>> _______________________________________________ >>> 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 > > > > -- > Regards, > Tomek > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/d19c4443/attachment.html From rsvoboda at redhat.com Tue Jan 8 11:10:30 2019 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Tue, 8 Jan 2019 17:10:30 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian, enjoy the wild flight! On Tue, Jan 8, 2019 at 5:04 PM Romain Pelisse wrote: > Congratulations Brian! > > On Tue, Jan 8, 2019 at 5:02 PM Harald Pehl wrote: > >> Congratulations Brian! >> >> On 8. Jan 2019, at 16:21, Tomasz Adamski wrote: >> >> Congratulations Brian! >> >> >> On Tue, Jan 8, 2019 at 3:43 PM James Perkins wrote: >> >>> Congratulations Brian! >>> >>> On Mon, Jan 7, 2019 at 12:26 PM Jason Greene >>> wrote: >>> >>>> [Also Posted to Wildfly Blog: >>>> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >>>> >>>> I am very excited to announce that Brian Stansberry (@bestansberry) >>>> will be taking on the role of WildFly project lead. Brian has been a major >>>> contributor to the project for almost 15 years now. During this time, he >>>> led a number of critical and complex subsystems including Clustering, >>>> Management, and most recently the cross-cutting cloud integration work. He >>>> is also one of our most active reviewers, and has helped many contributors >>>> navigate deep WildFly internals. Congratulations Brian! >>>> >>>> It?s been a great journey, so I want to think each and every one of you >>>> for your contributions and support over the years. Our work as a community >>>> has frequently pushed the envelope, and led to WildFly being one of the >>>> most innovative and popular application servers available. While I will be >>>> moving on from this role, I won?t be too far way, still participating but >>>> tackling a new challenge (I?ll have more to say about that in the future). >>>> >>>> With Brian at the helm, and all the great folks contributing to the >>>> project, I know WildFly has a bright future. I look forward to seeing the >>>> next chapter. >>>> >>>> Turn the page. >>>> >>>> -Jason >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> Regards, >> Tomek >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/1ea72b2a/attachment.html From ingo at redhat.com Tue Jan 8 11:45:37 2019 From: ingo at redhat.com (Ingo Weiss) Date: Tue, 8 Jan 2019 16:45:37 +0000 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: <20190108164537.di4ab34x6mjsgl3r@frankc> Congratulations Brian! Well done! On 2019-01-07 14:21:49-0600, Jason Greene wrote: > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/85f2ae59/attachment.bin From brian.stansberry at redhat.com Tue Jan 8 12:53:23 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 8 Jan 2019 11:53:23 -0600 Subject: [wildfly-dev] CI testing with the security manager enabled Message-ID: FYI about some small changes in how we test PRs... tl;dr; We are running the entire testsuite with a security manager enabled as one of the CI jobs run when PRs are tested. If a PR fails this test, there will need to be some form of correction before merging. For quite a while now one of the jobs that runs when you submit or update a PR turns on the JVM security manager for the WF processes being tested. But until this year that job only ran a relatively small portion of the overall testsuite. Now it has been modified to run the entire testsuite. The effect of this is PRs that introduce failures when the security manager is enabled will be detected before merge. For a long time my colleagues in Red Hat QE have run the entire suite with the security manager enabled and filed bug reports for issues. Now we'll catch these before merging, a much more efficient way of dealing with them. The 3,000 meter overview of how WildFly works with a security manager installed is the code WildFly ships (including libraries from other projects) is intended to have full permissions to do what it wants, but code in deployments needs to be granted permissions. Whether a particular call that results in a security manager check results in the deployment code needing a permission depends on whether the call stack involves deployment code, and if does, whether WildFly code higher in the stack used a privileged block to limit the part of the stack the security manager evaluates for permissions. If your PR has a failure in the security manager job, here's what you can do: Do some thinking about whether the failure is because a deployment you are introducing in the test is doing something for which it's reasonable that the deployment would need permissions. For example, it's directly opening an HttpClient, or is directly reading a system property or is directly reading a file. 1) If the answer is CLEARLY YES, then a) modify the test to stop doing that or b) use the utils in the WildFly testsuite codebase to add a permissions.xml to the test deployment such that it gets the permissions it needs.[1] 2) If the answer is CLEARLY NO, then WildFly should have been using a privileged block for something, or is doing something unnecessary, so a) if it was your PR that introduced the problem, fix the PR. b) else file a WFLY or WFCORE JIRA showing the problem, including a stack trace of the security manager failure. You can then use a utility in the WildFly testsuite code to ignore the test in the security manager test.[2] Include a note in the JIRA that you've done this so removing the ignore can be part of resolving the JIRA. 3) If the answer is NOT SURE, do not just add a permission in a permissions.xml! Don't sweep a possible problem under the rug. Instead, try to have a discussion with the PR reviewers or in chat or here to get some feedback, and once you've gone as far as you're willing with that, file a JIRA for the problem and ignore the test when the security manager is enabled[2]. My thanks to the many folks over the years who've worked to get all but a tiny fraction of our thousands of tests passing with a security manager. And especially to James Perkins and Martin Choma who've really pushed on this this year. [1] For example, https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/wildfly/test/integration/microprofile/config/smallrye/app/MicroProfileConfigTestCase.java#L71 This grants the deployment the permission to read a lot of system properties. That looks scary but it's just because the test wants to read a lot of properties. [2] For example, https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java#L70 Please include the comment showing the issue that was filed; that helps make it easier to find and remove these once the JIRA is resolved. Best regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/e88eaf1c/attachment-0001.html From emartins at redhat.com Tue Jan 8 13:06:37 2019 From: emartins at redhat.com (Eduardo Martins) Date: Tue, 8 Jan 2019 18:06:37 +0000 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Jason: WildFly is something special and much thanks to you! You are a natural born innovator, never afraid to go against the flow, a great leader. Very excited to see what comes next from you! Brian: It?s not easy to replace Jason, but you will not ?just" succeed, as usual! I?m proud to have you as leader, make it count :-) ?E > On 7 Jan 2019, at 20:21, Jason Greene wrote: > > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jperkins at redhat.com Tue Jan 8 13:31:58 2019 From: jperkins at redhat.com (James Perkins) Date: Tue, 8 Jan 2019 10:31:58 -0800 Subject: [wildfly-dev] CI testing with the security manager enabled In-Reply-To: References: Message-ID: Seems like a good time to bring this back up :) David did some slides [1] a while back now with useful information about the security manager and when/how to use privileged blocks. Reviewing [2] is specifically useful when you're writing a privileged block. [1]: http://word-bits.flurg.com/presentations/security-manager/index.html#/ [2]: http://word-bits.flurg.com/presentations/security-manager/index.html#/safe-privilege On Tue, Jan 8, 2019 at 10:15 AM Brian Stansberry < brian.stansberry at redhat.com> wrote: > FYI about some small changes in how we test PRs... > > tl;dr; We are running the entire testsuite with a security manager enabled > as one of the CI jobs run when PRs are tested. If a PR fails this test, > there will need to be some form of correction before merging. > > > For quite a while now one of the jobs that runs when you submit or update > a PR turns on the JVM security manager for the WF processes being tested. > But until this year that job only ran a relatively small portion of the > overall testsuite. Now it has been modified to run the entire testsuite. > > The effect of this is PRs that introduce failures when the security > manager is enabled will be detected before merge. For a long time my > colleagues in Red Hat QE have run the entire suite with the security > manager enabled and filed bug reports for issues. Now we'll catch these > before merging, a much more efficient way of dealing with them. > > The 3,000 meter overview of how WildFly works with a security manager > installed is the code WildFly ships (including libraries from other > projects) is intended to have full permissions to do what it wants, but > code in deployments needs to be granted permissions. Whether a particular > call that results in a security manager check results in the deployment > code needing a permission depends on whether the call stack involves > deployment code, and if does, whether WildFly code higher in the stack used > a privileged block to limit the part of the stack the security manager > evaluates for permissions. > > If your PR has a failure in the security manager job, here's what you can > do: > > Do some thinking about whether the failure is because a deployment you are > introducing in the test is doing something for which it's reasonable that > the deployment would need permissions. For example, it's directly opening > an HttpClient, or is directly reading a system property or is directly > reading a file. > > 1) If the answer is CLEARLY YES, then > > a) modify the test to stop doing that or > b) use the utils in the WildFly testsuite codebase to add a > permissions.xml to the test deployment such that it gets the permissions it > needs.[1] > > 2) If the answer is CLEARLY NO, then WildFly should have been using a > privileged block for something, or is doing something unnecessary, so > > a) if it was your PR that introduced the problem, fix the PR. > b) else file a WFLY or WFCORE JIRA showing the problem, including a stack > trace of the security manager failure. You can then use a utility in the > WildFly testsuite code to ignore the test in the security manager test.[2] > Include a note in the JIRA that you've done this so removing the ignore can > be part of resolving the JIRA. > > 3) If the answer is NOT SURE, do not just add a permission in a > permissions.xml! Don't sweep a possible problem under the rug. Instead, try > to have a discussion with the PR reviewers or in chat or here to get some > feedback, and once you've gone as far as you're willing with that, file a > JIRA for the problem and ignore the test when the security manager is > enabled[2]. > > > My thanks to the many folks over the years who've worked to get all but a > tiny fraction of our thousands of tests passing with a security manager. > And especially to James Perkins and Martin Choma who've really pushed on > this this year. > > [1] For example, > > > https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/wildfly/test/integration/microprofile/config/smallrye/app/MicroProfileConfigTestCase.java#L71 > > This grants the deployment the permission to read a lot of system > properties. That looks scary but it's just because the test wants to read a > lot of properties. > > [2] For example, > > > https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java#L70 > > Please include the comment showing the issue that was filed; that helps > make it easier to find and remove these once the JIRA is resolved. > > Best regards, > Brian > _______________________________________________ > 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/20190108/1181fe6a/attachment.html From smaestri at redhat.com Tue Jan 8 13:56:08 2019 From: smaestri at redhat.com (Stefano Maestri) Date: Tue, 8 Jan 2019 19:56:08 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulation Brian! S. On Mon, Jan 7, 2019 at 9:26 PM Jason Greene wrote: > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > 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/20190108/564ab99a/attachment.html From pskopek at redhat.com Tue Jan 8 14:09:47 2019 From: pskopek at redhat.com (Peter Skopek) Date: Tue, 8 Jan 2019 20:09:47 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congrats Brian! WildFly is in good hands! Peter On Mon, Jan 7, 2019 at 9:26 PM Jason Greene wrote: > > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Tue Jan 8 15:36:20 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 8 Jan 2019 14:36:20 -0600 Subject: [wildfly-dev] CI testing with the security manager enabled In-Reply-To: References: Message-ID: Thanks, James. +1 to being careful about privileged blocks. If one of these tests fail because some call path was missing permissions, that's not so much a security problem as it is a usability problem with a workaround. The software is harder to use. Probably the worst thing to do in such a case is to fix the usability problem by introducing an incorrect privileged block, as that converts the usability problem into a security problem. On Tue, Jan 8, 2019 at 12:33 PM James Perkins wrote: > Seems like a good time to bring this back up :) David did some slides [1] > a while back now with useful information about the security manager and > when/how to use privileged blocks. Reviewing [2] is specifically useful > when you're writing a privileged block. > > [1]: > http://word-bits.flurg.com/presentations/security-manager/index.html#/ > [2]: > http://word-bits.flurg.com/presentations/security-manager/index.html#/safe-privilege > > On Tue, Jan 8, 2019 at 10:15 AM Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> FYI about some small changes in how we test PRs... >> >> tl;dr; We are running the entire testsuite with a security manager >> enabled as one of the CI jobs run when PRs are tested. If a PR fails this >> test, there will need to be some form of correction before merging. >> >> >> For quite a while now one of the jobs that runs when you submit or update >> a PR turns on the JVM security manager for the WF processes being tested. >> But until this year that job only ran a relatively small portion of the >> overall testsuite. Now it has been modified to run the entire testsuite. >> >> The effect of this is PRs that introduce failures when the security >> manager is enabled will be detected before merge. For a long time my >> colleagues in Red Hat QE have run the entire suite with the security >> manager enabled and filed bug reports for issues. Now we'll catch these >> before merging, a much more efficient way of dealing with them. >> >> The 3,000 meter overview of how WildFly works with a security manager >> installed is the code WildFly ships (including libraries from other >> projects) is intended to have full permissions to do what it wants, but >> code in deployments needs to be granted permissions. Whether a particular >> call that results in a security manager check results in the deployment >> code needing a permission depends on whether the call stack involves >> deployment code, and if does, whether WildFly code higher in the stack used >> a privileged block to limit the part of the stack the security manager >> evaluates for permissions. >> >> If your PR has a failure in the security manager job, here's what you can >> do: >> >> Do some thinking about whether the failure is because a deployment you >> are introducing in the test is doing something for which it's reasonable >> that the deployment would need permissions. For example, it's directly >> opening an HttpClient, or is directly reading a system property or is >> directly reading a file. >> >> 1) If the answer is CLEARLY YES, then >> >> a) modify the test to stop doing that or >> b) use the utils in the WildFly testsuite codebase to add a >> permissions.xml to the test deployment such that it gets the permissions it >> needs.[1] >> >> 2) If the answer is CLEARLY NO, then WildFly should have been using a >> privileged block for something, or is doing something unnecessary, so >> >> a) if it was your PR that introduced the problem, fix the PR. >> b) else file a WFLY or WFCORE JIRA showing the problem, including a stack >> trace of the security manager failure. You can then use a utility in the >> WildFly testsuite code to ignore the test in the security manager test.[2] >> Include a note in the JIRA that you've done this so removing the ignore can >> be part of resolving the JIRA. >> >> 3) If the answer is NOT SURE, do not just add a permission in a >> permissions.xml! Don't sweep a possible problem under the rug. Instead, try >> to have a discussion with the PR reviewers or in chat or here to get some >> feedback, and once you've gone as far as you're willing with that, file a >> JIRA for the problem and ignore the test when the security manager is >> enabled[2]. >> >> >> My thanks to the many folks over the years who've worked to get all but a >> tiny fraction of our thousands of tests passing with a security manager. >> And especially to James Perkins and Martin Choma who've really pushed on >> this this year. >> >> [1] For example, >> >> >> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/wildfly/test/integration/microprofile/config/smallrye/app/MicroProfileConfigTestCase.java#L71 >> >> This grants the deployment the permission to read a lot of system >> properties. That looks scary but it's just because the test wants to read a >> lot of properties. >> >> [2] For example, >> >> >> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java#L70 >> >> Please include the comment showing the issue that was filed; that helps >> make it easier to find and remove these once the JIRA is resolved. >> >> Best regards, >> Brian >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190108/de0f0725/attachment.html From chaowan at redhat.com Tue Jan 8 20:57:56 2019 From: chaowan at redhat.com (Chao Wang) Date: Wed, 9 Jan 2019 09:57:56 +0800 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! On 1/8/19 4:21 AM, Jason Greene wrote: > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ema at redhat.com Tue Jan 8 20:58:28 2019 From: ema at redhat.com (Jim Ma) Date: Wed, 9 Jan 2019 09:58:28 +0800 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: <754b968b-aa15-c50c-3ff1-684eed1ce288@redhat.com> Congrats Brian! On 01/08/2019 04:21 AM, Jason Greene wrote: > [Also Posted to Wildfly Blog: http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you for your contributions and support over the years. Our work as a community has frequently pushed the envelope, and led to WildFly being one of the most innovative and popular application servers available. While I will be moving on from this role, I won?t be too far way, still participating but tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the project, I know WildFly has a bright future. I look forward to seeing the next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From lgao at redhat.com Tue Jan 8 21:38:18 2019 From: lgao at redhat.com (Lin Gao) Date: Wed, 9 Jan 2019 10:38:18 +0800 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! Best Regards On Tue, Jan 8, 2019 at 7:23 AM Brian Stansberry wrote: > Thanks, Jason! > > It's a great privilege to work with the WildFly community and to work on > open source software. I owe a great debt to all of you. I'm basically a > self-taught engineer, and by far the best way to learn I've seen is to > collaborate with the people in this community, looking at your ideas and > the code you write and listening to your feedback on my ideas and code. > > Jason, it's also a tremendous honor and privilege working with you. Your > leadership of JBoss AS and WildFly has been off the charts outstanding. I > have very big shoes to fill. > > 2019 should be another exciting year for WildFly. We'll continue the > quarterly release cadence that we started last year with WildFly 12, so the > next major, WildFly 16, should be out in less than two months. This year > Jakarta EE will be a priority, both getting Jarkarta EE 8 certification and > helping drive EE forward. Another major focus will be continuing to improve > the usability of WildFly on the cloud -- enhanced observability, enhanced > ability to tailor your installation to your specific requirements, enhanced > ability to use external services instead of in-vm resources for things like > messaging and caching, and development of an OpenShift operator[1] for > Wildfly. And plenty of other goodies too! > > Besides following this list and JIRA, I recommend that people interested > in the development of WildFly occasionally check out the wildfly-proposals > github repo[2]. For any new feature going into WildFly there will be a > document added to that repo where the feature requirements will be > discussed and sometimes some design details. Participating in the review of > proposals there (via PR comments) is a great way to help ensure features > meet your needs. > > [1] https://blog.openshift.com/introducing-the-operator-framework/ > [2] https://github.com/wildfly/wildfly-proposals/pulls > > Best regards, > Brian > > > > On Mon, Jan 7, 2019 at 2:26 PM Jason Greene > wrote: > >> [Also Posted to Wildfly Blog: >> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >> >> I am very excited to announce that Brian Stansberry (@bestansberry) will >> be taking on the role of WildFly project lead. Brian has been a major >> contributor to the project for almost 15 years now. During this time, he >> led a number of critical and complex subsystems including Clustering, >> Management, and most recently the cross-cutting cloud integration work. He >> is also one of our most active reviewers, and has helped many contributors >> navigate deep WildFly internals. Congratulations Brian! >> >> It?s been a great journey, so I want to think each and every one of you >> for your contributions and support over the years. Our work as a community >> has frequently pushed the envelope, and led to WildFly being one of the >> most innovative and popular application servers available. While I will be >> moving on from this role, I won?t be too far way, still participating but >> tackling a new challenge (I?ll have more to say about that in the future). >> >> With Brian at the helm, and all the great folks contributing to the >> project, I know WildFly has a bright future. I look forward to seeing the >> next chapter. >> >> Turn the page. >> >> -Jason >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Lin Gao Senior Software Engineer JBoss Sustaining Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190109/c7fdcdb7/attachment-0001.html From mmarusic at redhat.com Wed Jan 9 04:31:02 2019 From: mmarusic at redhat.com (Marek Marusic) Date: Wed, 9 Jan 2019 10:31:02 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations Brian! Marek Marusic Associate Software Engineer - JBOSS SET TEAM Red Hat Purky?ova 111, 612 00 Brno mmarusic at redhat.com TRIED. TESTED. TRUSTED. On Wed, Jan 9, 2019 at 3:39 AM Lin Gao wrote: > Congratulations Brian! > > Best Regards > > On Tue, Jan 8, 2019 at 7:23 AM Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> Thanks, Jason! >> >> It's a great privilege to work with the WildFly community and to work on >> open source software. I owe a great debt to all of you. I'm basically a >> self-taught engineer, and by far the best way to learn I've seen is to >> collaborate with the people in this community, looking at your ideas and >> the code you write and listening to your feedback on my ideas and code. >> >> Jason, it's also a tremendous honor and privilege working with you. Your >> leadership of JBoss AS and WildFly has been off the charts outstanding. I >> have very big shoes to fill. >> >> 2019 should be another exciting year for WildFly. We'll continue the >> quarterly release cadence that we started last year with WildFly 12, so the >> next major, WildFly 16, should be out in less than two months. This year >> Jakarta EE will be a priority, both getting Jarkarta EE 8 certification and >> helping drive EE forward. Another major focus will be continuing to improve >> the usability of WildFly on the cloud -- enhanced observability, enhanced >> ability to tailor your installation to your specific requirements, enhanced >> ability to use external services instead of in-vm resources for things like >> messaging and caching, and development of an OpenShift operator[1] for >> Wildfly. And plenty of other goodies too! >> >> Besides following this list and JIRA, I recommend that people interested >> in the development of WildFly occasionally check out the wildfly-proposals >> github repo[2]. For any new feature going into WildFly there will be a >> document added to that repo where the feature requirements will be >> discussed and sometimes some design details. Participating in the review of >> proposals there (via PR comments) is a great way to help ensure features >> meet your needs. >> >> [1] https://blog.openshift.com/introducing-the-operator-framework/ >> [2] https://github.com/wildfly/wildfly-proposals/pulls >> >> Best regards, >> Brian >> >> >> >> On Mon, Jan 7, 2019 at 2:26 PM Jason Greene >> wrote: >> >>> [Also Posted to Wildfly Blog: >>> http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] >>> >>> I am very excited to announce that Brian Stansberry (@bestansberry) will >>> be taking on the role of WildFly project lead. Brian has been a major >>> contributor to the project for almost 15 years now. During this time, he >>> led a number of critical and complex subsystems including Clustering, >>> Management, and most recently the cross-cutting cloud integration work. He >>> is also one of our most active reviewers, and has helped many contributors >>> navigate deep WildFly internals. Congratulations Brian! >>> >>> It?s been a great journey, so I want to think each and every one of you >>> for your contributions and support over the years. Our work as a community >>> has frequently pushed the envelope, and led to WildFly being one of the >>> most innovative and popular application servers available. While I will be >>> moving on from this role, I won?t be too far way, still participating but >>> tackling a new challenge (I?ll have more to say about that in the future). >>> >>> With Brian at the helm, and all the great folks contributing to the >>> project, I know WildFly has a bright future. I look forward to seeing the >>> next chapter. >>> >>> Turn the page. >>> >>> -Jason >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Lin Gao > Senior Software Engineer > JBoss Sustaining Engineering Team > > _______________________________________________ > 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/20190109/2b43b4a1/attachment.html From ttarrant at redhat.com Wed Jan 9 09:29:28 2019 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 9 Jan 2019 15:29:28 +0100 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: <1b592a4e-1d35-909f-3002-19d6bb1015a6@redhat.com> On 1/7/19 9:21 PM, Jason Greene wrote: > I am very excited to announce that Brian Stansberry (@bestansberry) will be taking on the role of WildFly project lead. Brian has been a major contributor to the project for almost 15 years now. During this time, he led a number of critical and complex subsystems including Clustering, Management, and most recently the cross-cutting cloud integration work. He is also one of our most active reviewers, and has helped many contributors navigate deep WildFly internals. Congratulations Brian! Brian just fits that role as much as the role fits Brian. A perfect match. Thanks Jason for your great leadership. Thanks Brian for your great leadership. Tristan From sguilhen at redhat.com Wed Jan 9 11:24:46 2019 From: sguilhen at redhat.com (Stefan Guilhen) Date: Wed, 9 Jan 2019 14:24:46 -0200 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Congratulations, Brian! WildFly has indeed a bright future in your hands! On Mon, Jan 7, 2019 at 6:26 PM Jason Greene wrote: > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- STEFAN GUILHEN PRINCIPAL SOFTWARE ENGINEER Red Hat sguilhen at redhat.com M: +55-11-98117-7332 @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190109/38c9bc45/attachment.html From frainone at redhat.com Fri Jan 11 07:29:48 2019 From: frainone at redhat.com (Flavia Rainone) Date: Fri, 11 Jan 2019 10:29:48 -0200 Subject: [wildfly-dev] New WildFly Project Lead In-Reply-To: References: Message-ID: Brian, This is very well deserved, congratulations! :-) On Mon, Jan 7, 2019 at 6:26 PM Jason Greene wrote: > [Also Posted to Wildfly Blog: > http://wildfly.org/staging/news/2019/01/07/New-Project-Lead/] > > I am very excited to announce that Brian Stansberry (@bestansberry) will > be taking on the role of WildFly project lead. Brian has been a major > contributor to the project for almost 15 years now. During this time, he > led a number of critical and complex subsystems including Clustering, > Management, and most recently the cross-cutting cloud integration work. He > is also one of our most active reviewers, and has helped many contributors > navigate deep WildFly internals. Congratulations Brian! > > It?s been a great journey, so I want to think each and every one of you > for your contributions and support over the years. Our work as a community > has frequently pushed the envelope, and led to WildFly being one of the > most innovative and popular application servers available. While I will be > moving on from this role, I won?t be too far way, still participating but > tackling a new challenge (I?ll have more to say about that in the future). > > With Brian at the helm, and all the great folks contributing to the > project, I know WildFly has a bright future. I look forward to seeing the > next chapter. > > Turn the page. > > -Jason > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Flavia Rainone Principal Software Engineer Red Hat TRIED. TESTED. TRUSTED -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190111/0560ad89/attachment-0001.html From sanne at hibernate.org Tue Jan 15 11:03:04 2019 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 15 Jan 2019 16:03:04 +0000 Subject: [wildfly-dev] wildfly-gradle plugin In-Reply-To: References: Message-ID: hi Ahmed! Good point, I didn't make an example for that. Such defails are controlled in the provisioning.xml file; add copy-module-artifacts="true" in the server-provisioning, that's in the main element. For example see the main example at [1] I'll add an example to the README. 1 - https://github.com/wildfly/wildfly-build-tools/ Thanks, Sanne On Tue, 15 Jan 2019 at 14:59, ahmed galal wrote: > > good day sanne > > i was trying to use wildfly-gradle plugin to run some tests on the materialized server using arquillian. > but the plugin creates a thin version of the server , ho can i configure the plugin to generate a fat version of the server with all the jars ? so i can run it directly from the build directory? From ehugonne at redhat.com Wed Jan 16 05:28:12 2019 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Wed, 16 Jan 2019 11:28:12 +0100 Subject: [wildfly-dev] Should I fail or should I undefine ? Message-ID: <06399f42-91d2-1b07-885c-aefd27b9e0ec@redhat.com> Hello, I was looking into introducing new metrics and got into a discussion with Jeff about what is the proper way to handle the fact that the service is missing. Currently if the JMSBridge is not available as a service then reading any read only runtime attribute fails with a: { ??? "outcome" => "failed", ??? "result" => 0, ??? "failure-description" => "WFLYCTL0216: Management resource '[ ??? (\"subsystem\" => \"messaging-activemq\"), ??? (\"jms-bridge\" => \"test\") ]' not found", ??? "rolled-back" => true } So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)" will fail in admin-only mode. This feels strange to me as i would expect an "undefined" result and not a failure. In the same way, trying to get the number of processed messages by the bridge should return undefined since the bridge is not running. Do we have a rule so that this behaviour is consistent ? Cheers, Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190116/ea540d9c/attachment.bin From jmesnil at redhat.com Wed Jan 16 05:56:48 2019 From: jmesnil at redhat.com (Jean-Frederic Mesnil) Date: Wed, 16 Jan 2019 11:56:48 +0100 Subject: [wildfly-dev] Should I fail or should I undefine ? In-Reply-To: <06399f42-91d2-1b07-885c-aefd27b9e0ec@redhat.com> References: <06399f42-91d2-1b07-885c-aefd27b9e0ec@redhat.com> Message-ID: > On 16 Jan 2019, at 11:28, Emmanuel Hugonnet wrote: > > Hello, > > I was looking into introducing new metrics and got into a discussion with Jeff about what is the proper way to handle the fact that the > service is missing. > > Currently if the JMSBridge is not available as a service then reading any read only runtime attribute fails with a: > > { > "outcome" => "failed", > "result" => 0, > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"messaging-activemq\"), > (\"jms-bridge\" => \"test\") > ]' not found", > "rolled-back" => true > } > > So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)" will fail in admin-only mode. This feels strange to me as i > would expect an "undefined" result and not a failure. In the same way, trying to get the number of processed messages by the bridge should > return undefined since the bridge is not running. Do we have a rule so that this behaviour is consistent ? Let?s focus on runtime attribute (and put metric aside). My argument to Emmanuel is all about consistency. The resource (jams-bridge) has runtime operations (start, pause) and corresponding runtime attribute (started, paused). When the server is in admin-only, the runtime operations MUST fail (although the reported failure description could be improved). I argue that the read-attribute operation should behave in a consistent fashion. When the user queries the `started` attribute, the read-attribute operation MUST fail because the server is not in the proper stage to determine the value. Otherwise, we end up with an attribute that can be in a 3-state (true/false/undefined). ?Undefined? means we don?t know the value of the attribute. This is not a correct response to me. We *know* that the server is in admin-only and that the attribute value can not be determined without the runtime, hence the failure. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Wed Jan 16 18:06:18 2019 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 16 Jan 2019 17:06:18 -0600 Subject: [wildfly-dev] Should I fail or should I undefine ? In-Reply-To: References: <06399f42-91d2-1b07-885c-aefd27b9e0ec@redhat.com> Message-ID: On Wed, Jan 16, 2019 at 5:01 AM Jean-Frederic Mesnil wrote: > > > > On 16 Jan 2019, at 11:28, Emmanuel Hugonnet wrote: > > > > Hello, > > > > I was looking into introducing new metrics and got into a discussion > with Jeff about what is the proper way to handle the fact that the > > service is missing. > > > > Currently if the JMSBridge is not available as a service then reading > any read only runtime attribute fails with a: > > > > { > > "outcome" => "failed", > > "result" => 0, > > "failure-description" => "WFLYCTL0216: Management resource '[ > > (\"subsystem\" => \"messaging-activemq\"), > > (\"jms-bridge\" => \"test\") > > ]' not found", > > "rolled-back" => true > > } > > > > So > "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)" > will fail in admin-only mode. This feels strange to me as i > > would expect an "undefined" result and not a failure. In the same way, > trying to get the number of processed messages by the bridge should > > return undefined since the bridge is not running. Do we have a rule so > that this behaviour is consistent ? > > Let?s focus on runtime attribute (and put metric aside). > > My argument to Emmanuel is all about consistency. The resource > (jams-bridge) has runtime operations (start, pause) and corresponding > runtime attribute (started, paused). > > When the server is in admin-only, the runtime operations MUST fail > (although > the reported failure description could be improved). > > I argue that the read-attribute operation should behave in a consistent > fashion. > When the user queries the `started` attribute, the read-attribute > operation MUST fail because the server is not in the proper stage to > determine the value. > Otherwise, we end up with an attribute that can be in a 3-state > (true/false/undefined). > ?Undefined? means we don?t know the value of the attribute. This is not a > correct response to me. We *know* that the server is in admin-only and that > the attribute value can not be determined without the runtime, hence the > failure. > > tl;dr; I think failing is ok, but only if it truly is a tri-state. I'll start my reply with a bit of a tangent. The previous discussion of this is at http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004225.html which got encapsulated as the requirements of https://issues.jboss.org/browse/WFCORE-831. I don't think we should alter any of the default behavior of metrics there. I also know for some of your metrics subsystem work you looked at ways to not get the WFCORE-831 undefined metric value, as you were making a request for a specific purpose and you were prepared to deal with no value. That seems like a good way to deal with cases where the caller doesn't want undefined metric values. End tangent; now to the question about non-metric runtime only attributes. First, the requirements of section VIII of https://issues.jboss.org/browse/WFCORE-831 apply. You can't return 'undefined' if the description doesn't say that's a possible value. Second, stating undefined is possible and returning that is an option but your argument about consistency with other runtime-only behavior of the resource is valid. Third, if an attribute already says it may return undefined and now we change that and fail instead, that''s an API breaking change, so no good. Fourth, failing is bad if it's reasonably avoidable. For example, if the service for a bridge is not even installed, then it seems like that bridge is neither started nor paused. (Apologies if I'm missing some subtlety about a bridge.) Those attributes are arguably a tri-state but arguably not, and it seems good to resolve such debates in the direction of not failing. Particularly if some generic op like :read-resource(include-runtime=true) would otherwise work for the resource. jeff > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > 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/20190116/f6bab26d/attachment-0001.html From rory.odonnell at oracle.com Mon Jan 21 06:00:12 2019 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 21 Jan 2019 11:00:12 +0000 Subject: [wildfly-dev] JDK 12 enters Rampdown Phase Two Message-ID: <03f02c16-957d-6c9d-f8bb-025c291614d7@oracle.com> ?Hi David & Richard,* * **OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase Two. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o Per the JDK Release Process [3] we now turn our focusto P1 and P2 bugs. **OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version?2, with the Classpath Exception . * Release Notes: o http://jdk.java.net/13/release-notes * Changes in this build Blog Updates from Java SE Product Management since last email. * Oracle Java SE Releases FAQ [3] * Oracle Java SE Support Roadmap [4] Rgds,Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html [3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq [4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.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/20190121/2b50c63f/attachment.html