From manovotn at redhat.com  Mon Apr  1 05:10:21 2019
From: manovotn at redhat.com (Matej Novotny)
Date: Mon, 1 Apr 2019 05:10:21 -0400 (EDT)
Subject: [wildfly-dev] Question about usage of jboss spec versions
In-Reply-To: <CAMquZP7eSK7mqAFPBZhHPN_81C5ttHk1tGJJ-o16Ujp=PH2QvQ@mail.gmail.com>
References: <1148476998.16316094.1553870961423.JavaMail.zimbra@redhat.com>
	<536985657.16317410.1553871416719.JavaMail.zimbra@redhat.com>
	<CAMquZP7eSK7mqAFPBZhHPN_81C5ttHk1tGJJ-o16Ujp=PH2QvQ@mail.gmail.com>
Message-ID: <1710738168.16554011.1554109821578.JavaMail.zimbra@redhat.com>

Ah, that explains it, thanks a lot!

Matej

----- Original Message -----
> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> To: "Matej Novotny" <manovotn at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Sunday, March 31, 2019 8:00:54 PM
> Subject: Re: [wildfly-dev] Question about usage of jboss spec versions
> 
> For the longest time java ee related spec apis ware not officially
> available in any maven repository.
> 
> Only lately with latest version of Java/Jakarta EE spec apis are starting
> to appear properly in maven central.
> 
> Another reason is as Petr said, some service loader configs (w)are
> different and in some cases even some impl classes (w)are added.
> 
> --
> tomaz
> 
> On Fri, Mar 29, 2019 at 4:08 PM Matej Novotny <manovotn at redhat.com> wrote:
> 
> > Hello,
> >
> > This is probably stupid question but I was recently wondering, what's the
> > actual reason why WFLY (and other RH technologies) use jboss versions of
> > all the specs?
> > For instance https://github.com/jboss/jboss-annotations-api_spec instead
> > of just picking up the javax.annotation artifact.
> >
> > The contents are pretty much the same, so I think I have to be missing
> > something trivial and obvious..
> > Is it historical reasons? Or perhaps a matter of licenses and
> > productization?
> >
> > Matej
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 


From tdiesler at redhat.com  Mon Apr  1 10:51:22 2019
From: tdiesler at redhat.com (Thomas Diesler)
Date: Mon, 1 Apr 2019 16:51:22 +0200
Subject: [wildfly-dev] WildFly-Camel 10.0.0
Message-ID: <DDE1F4C0-FE60-4919-8751-E015B1E20F30@redhat.com>

WildFly-Camel 10.0.0 provides Camel-2.23.1 integration with WildFly-16.0.0

This is a major update release that comes with a new WildFly version.

Component upgrades include

WildFly-16.0.0
Galleon-3.0.1
Hawtio-2.5.0
In addition to that, we also resolved a number of other tasks and bugs <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelog.md>.

For details please see the 10.0.0 Milestone <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone%3A10.0.0>.

Enjoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190401/a0e56303/attachment.html 

From brian.stansberry at redhat.com  Mon Apr  1 16:32:49 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 1 Apr 2019 15:32:49 -0500
Subject: [wildfly-dev] WildFly-Camel 10.0.0
In-Reply-To: <DDE1F4C0-FE60-4919-8751-E015B1E20F30@redhat.com>
References: <DDE1F4C0-FE60-4919-8751-E015B1E20F30@redhat.com>
Message-ID: <CAPhbRDZ=4MLgtTMapqUuN9rQ9cfB9V56Tn2-Uie=ZCQpC-WwAQ@mail.gmail.com>

Great! Congrats!

On Mon, Apr 1, 2019 at 11:46 AM Thomas Diesler <tdiesler at redhat.com> wrote:

> WildFly-Camel 10.0.0 provides Camel-2.23.1 integration with WildFly-16.0.0
>
> This is a major update release that comes with a new WildFly version.
>
> Component upgrades include
>
>    - WildFly-16.0.0
>    - Galleon-3.0.1
>    - Hawtio-2.5.0
>
> In addition to that, we also resolved a number of other tasks and bugs
> <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelog.md>
> .
>
> For details please see the 10.0.0 Milestone
> <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone%3A10.0.0>
> .
>
> Enjoy
> _______________________________________________
> 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/20190401/3683eb10/attachment.html 

From brian.stansberry at redhat.com  Tue Apr  2 15:24:09 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 2 Apr 2019 14:24:09 -0500
Subject: [wildfly-dev] Removal of commons-cli,
	commons-lang and commons-lang3 modules
Message-ID: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>

Currently WildFly includes 3 JBoss Modules modules that are not used in our
runtime. I would like to remove these in WildFly 17:

org.apache.commons.cli
org.apache.commons.lang[1]
org.apache.commons.lang3

All three have the "jboss.api" = "private" property set in their
module.xml, meaning they are marked for internal use only and we are free
to remove them. End user applications should not have referenced these
modules, and if they do we log a WARN on boot advising not to do that.

However, other projects that extend WildFly (i.e. write their own
subsystems) may be using these modules, so I wanted to notify any such
folks that these will likely be going away and you'll need to provide these
yourselves.ed.

Best regards,
Brian

[1] This one is referenced in a commented out module.xml section related to
My Faces 1.1 support. I've checked with Farah Juma and that is no longer
relevant and the comment can be removed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190402/0f0751a5/attachment.html 

From jperkins at redhat.com  Tue Apr  2 17:07:57 2019
From: jperkins at redhat.com (James Perkins)
Date: Tue, 2 Apr 2019 14:07:57 -0700
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
Message-ID: <CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>

I believe the org.wildfly.security:wildfly-elytron-tool does use
org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
issue. That could be why it was originally there.

On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Currently WildFly includes 3 JBoss Modules modules that are not used in
> our runtime. I would like to remove these in WildFly 17:
>
> org.apache.commons.cli
> org.apache.commons.lang[1]
> org.apache.commons.lang3
>
> All three have the "jboss.api" = "private" property set in their
> module.xml, meaning they are marked for internal use only and we are free
> to remove them. End user applications should not have referenced these
> modules, and if they do we log a WARN on boot advising not to do that.
>
> However, other projects that extend WildFly (i.e. write their own
> subsystems) may be using these modules, so I wanted to notify any such
> folks that these will likely be going away and you'll need to provide these
> yourselves.ed.
>
> Best regards,
> Brian
>
> [1] This one is referenced in a commented out module.xml section related
> to My Faces 1.1 support. I've checked with Farah Juma and that is no longer
> relevant and the comment can be removed.
>
> _______________________________________________
> 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/20190402/ec932adc/attachment.html 

From darran.lofthouse at jboss.com  Wed Apr  3 04:43:10 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 3 Apr 2019 08:43:10 +0000
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
Message-ID: <CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>

+1 the tool is a shaded jar so should not need to depend on another module.

We may want to look at shading again but that would be a different topic.

On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com> wrote:

> I believe the org.wildfly.security:wildfly-elytron-tool does use
> org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
> issue. That could be why it was originally there.
>
> On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Currently WildFly includes 3 JBoss Modules modules that are not used in
>> our runtime. I would like to remove these in WildFly 17:
>>
>> org.apache.commons.cli
>> org.apache.commons.lang[1]
>> org.apache.commons.lang3
>>
>> All three have the "jboss.api" = "private" property set in their
>> module.xml, meaning they are marked for internal use only and we are free
>> to remove them. End user applications should not have referenced these
>> modules, and if they do we log a WARN on boot advising not to do that.
>>
>> However, other projects that extend WildFly (i.e. write their own
>> subsystems) may be using these modules, so I wanted to notify any such
>> folks that these will likely be going away and you'll need to provide these
>> yourselves.ed.
>>
>> Best regards,
>> Brian
>>
>> [1] This one is referenced in a commented out module.xml section related
>> to My Faces 1.1 support. I've checked with Farah Juma and that is no longer
>> relevant and the comment can be removed.
>>
>> _______________________________________________
>> 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/20190403/b0fb1702/attachment-0001.html 

From fnasser at redhat.com  Wed Apr  3 10:36:26 2019
From: fnasser at redhat.com (Fernando Nasser)
Date: Wed, 3 Apr 2019 10:36:26 -0400
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
Message-ID: <6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>

On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
> +1 the tool is a shaded jar so should not need to depend on another
> module.
>
> We may want to look at shading again but that would be a different topic.


Indeed.?

Who monitors/detects the shaded code does not contain a CVE and fix it
if it does?

Are the people who "shaded" it responsible for supporting/maintaining
that code?


>
> On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com
> <mailto:jperkins at redhat.com>> wrote:
>
>     I believe the org.wildfly.security:wildfly-elytron-tool does use
>     org.apache.commons.lang3. However IIRC it's now shaded in so
>     likely not an issue. That could be why it was originally there.
>
>     On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>
>         Currently WildFly includes 3 JBoss Modules modules that are
>         not used in our runtime. I would like to remove these in
>         WildFly 17:
>
>         org.apache.commons.cli
>         org.apache.commons.lang[1]
>         org.apache.commons.lang3
>
>         All three have the "jboss.api" = "private" property set in
>         their module.xml, meaning they are marked for internal use
>         only and we are free to remove them. End user applications
>         should not have referenced these modules, and if they do we
>         log a WARN on boot advising not to do that.
>
>         However, other projects that extend WildFly (i.e. write their
>         own subsystems) may be using these modules, so I wanted to
>         notify any such folks that these will likely be going away and
>         you'll need to provide these yourselves.ed.
>
>         Best regards,
>         Brian
>
>         [1] This one is referenced in a commented out module.xml
>         section related to My Faces 1.1 support. I've checked with
>         Farah Juma and that is no longer relevant and the comment can
>         be removed.
>
>         _______________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto: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 <mailto: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/20190403/e6fc1c40/attachment.html 

From darran.lofthouse at redhat.com  Wed Apr  3 10:51:15 2019
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 3 Apr 2019 14:51:15 +0000
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
Message-ID: <CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>

Certainly a topic for the future.

On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser at redhat.com> wrote:

> On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
>
> +1 the tool is a shaded jar so should not need to depend on another module.
>
> We may want to look at shading again but that would be a different topic.
>
>
> Indeed.
>
> Who monitors/detects the shaded code does not contain a CVE and fix it if
> it does?
>
> Are the people who "shaded" it responsible for supporting/maintaining that
> code?
>
>
>
> On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com> wrote:
>
>> I believe the org.wildfly.security:wildfly-elytron-tool does use
>> org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
>> issue. That could be why it was originally there.
>>
>> On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Currently WildFly includes 3 JBoss Modules modules that are not used in
>>> our runtime. I would like to remove these in WildFly 17:
>>>
>>> org.apache.commons.cli
>>> org.apache.commons.lang[1]
>>> org.apache.commons.lang3
>>>
>>> All three have the "jboss.api" = "private" property set in their
>>> module.xml, meaning they are marked for internal use only and we are free
>>> to remove them. End user applications should not have referenced these
>>> modules, and if they do we log a WARN on boot advising not to do that.
>>>
>>> However, other projects that extend WildFly (i.e. write their own
>>> subsystems) may be using these modules, so I wanted to notify any such
>>> folks that these will likely be going away and you'll need to provide these
>>> yourselves.ed.
>>>
>>> Best regards,
>>> Brian
>>>
>>> [1] This one is referenced in a commented out module.xml section related
>>> to My Faces 1.1 support. I've checked with Farah Juma and that is no longer
>>> relevant and the comment can be removed.
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190403/0cd79d6c/attachment.html 

From fnasser at redhat.com  Wed Apr  3 11:03:43 2019
From: fnasser at redhat.com (Fernando Nasser)
Date: Wed, 3 Apr 2019 11:03:43 -0400
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
Message-ID: <891a39f8-77cf-7277-ed11-ece3b6cdd6ca@redhat.com>

On 2019-04-03 10:51 a.m., Darran Lofthouse wrote:
> Certainly a topic for the future.


It is more like a "Back to the Future" case ;-)


We discuss this, get rid of all shaded code, then we gradually forget
and the cycle starts again.




>
> On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser at redhat.com
> <mailto:fnasser at redhat.com>> wrote:
>
>     On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
>>     +1 the tool is a shaded jar so should not need to depend on
>>     another module.
>>
>>     We may want to look at shading again but that would be a
>>     different topic.
>
>
>     Indeed.?
>
>     Who monitors/detects the shaded code does not contain a CVE and
>     fix it if it does?
>
>     Are the people who "shaded" it responsible for
>     supporting/maintaining that code?
>
>
>>
>>     On Tue, Apr 2, 2019 at 10:13 PM James Perkins
>>     <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
>>
>>         I believe the org.wildfly.security:wildfly-elytron-tool does
>>         use org.apache.commons.lang3. However IIRC it's now shaded in
>>         so likely not an issue. That could be why it was originally
>>         there.
>>
>>         On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry
>>         <brian.stansberry at redhat.com
>>         <mailto:brian.stansberry at redhat.com>> wrote:
>>
>>             Currently WildFly includes 3 JBoss Modules modules that
>>             are not used in our runtime. I would like to remove these
>>             in WildFly 17:
>>
>>             org.apache.commons.cli
>>             org.apache.commons.lang[1]
>>             org.apache.commons.lang3
>>
>>             All three have the "jboss.api" = "private" property set
>>             in their module.xml, meaning they are marked for internal
>>             use only and we are free to remove them. End user
>>             applications should not have referenced these modules,
>>             and if they do we log a WARN on boot advising not to do that.
>>
>>             However, other projects that extend WildFly (i.e. write
>>             their own subsystems) may be using these modules, so I
>>             wanted to notify any such folks that these will likely be
>>             going away and you'll need to provide these yourselves.ed.
>>
>>             Best regards,
>>             Brian
>>
>>             [1] This one is referenced in a commented out module.xml
>>             section related to My Faces 1.1 support. I've checked
>>             with Farah Juma and that is no longer relevant and the
>>             comment can be removed.
>>
>>             _______________________________________________
>>             wildfly-dev mailing list
>>             wildfly-dev at lists.jboss.org
>>             <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org <mailto: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/20190403/49bd2338/attachment-0001.html 

From dvilkola at redhat.com  Wed Apr  3 11:40:16 2019
From: dvilkola at redhat.com (Diana Vilkolakova)
Date: Wed, 3 Apr 2019 17:40:16 +0200
Subject: [wildfly-dev] [WFCORE-4362] Proposal for Configurable certificate
 authority used by a certificate-authority-account
Message-ID: <CAHvwbVe8wjXkaBaZXekD4gaMUZp+W-hsRA-mYGKFtPD4oXsqhA@mail.gmail.com>

Hello All,
I've created a proposal [1] for [WFCORE-4362] Make the certificate
authority used by a certificate-authority-account configurable. All
feedback is welcomed.

[1]: https://github.com/wildfly/wildfly-proposals/pull/192
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190403/e67f021a/attachment.html 

From brian.stansberry at redhat.com  Wed Apr  3 12:40:28 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 3 Apr 2019 11:40:28 -0500
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
Message-ID: <CAPhbRDZi8OJ5+w6VxLKVjkObKKeF035k0_3Cb0j8axLYAiUd3g@mail.gmail.com>

On Wed, Apr 3, 2019 at 3:43 AM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> +1 the tool is a shaded jar so should not need to depend on another module.
>
> We may want to look at shading again but that would be a different topic.
>

Yes. Unless the supported use cases for the tool will change such that we
can require that it be run as a JBoss Modules modular app with the module
path including a WildFly installation's 'modules' dir (I doubt that), then
how this tool is built is not related to removing the module.


> On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com> wrote:
>
>> I believe the org.wildfly.security:wildfly-elytron-tool does use
>> org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
>> issue. That could be why it was originally there.
>>
>> On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Currently WildFly includes 3 JBoss Modules modules that are not used in
>>> our runtime. I would like to remove these in WildFly 17:
>>>
>>> org.apache.commons.cli
>>> org.apache.commons.lang[1]
>>> org.apache.commons.lang3
>>>
>>> All three have the "jboss.api" = "private" property set in their
>>> module.xml, meaning they are marked for internal use only and we are free
>>> to remove them. End user applications should not have referenced these
>>> modules, and if they do we log a WARN on boot advising not to do that.
>>>
>>> However, other projects that extend WildFly (i.e. write their own
>>> subsystems) may be using these modules, so I wanted to notify any such
>>> folks that these will likely be going away and you'll need to provide these
>>> yourselves.ed.
>>>
>>> Best regards,
>>> Brian
>>>
>>> [1] This one is referenced in a commented out module.xml section related
>>> to My Faces 1.1 support. I've checked with Farah Juma and that is no longer
>>> relevant and the comment can be removed.
>>>
>>> _______________________________________________
>>> 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/20190403/49da2637/attachment.html 

From ema at redhat.com  Thu Apr  4 05:40:04 2019
From: ema at redhat.com (Jim Ma)
Date: Thu, 4 Apr 2019 17:40:04 +0800
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
Message-ID: <872bfa30-d88b-5721-e527-30e624740e02@redhat.com>

WebService subsystem uses org.apache.commons.lang3 now : 
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/cxf/impl/main/module.xml#L81
We can look at remove it after delete it from CXF future release first.

Cheers,
Jim

On 4/3/19 3:24 AM, Brian Stansberry wrote:
> Currently WildFly includes 3 JBoss Modules modules that are not used 
> in our runtime. I would like to remove these in WildFly 17:
>
> org.apache.commons.cli
> org.apache.commons.lang[1]
> org.apache.commons.lang3
>
> All three have the "jboss.api" = "private" property set in their 
> module.xml, meaning they are marked for internal use only and we are 
> free to remove them. End user applications should not have referenced 
> these modules, and if they do we log a WARN on boot advising not to do 
> that.
>
> However, other projects that extend WildFly (i.e. write their own 
> subsystems) may be using these modules, so I wanted to notify any such 
> folks that these will likely be going away and you'll need to provide 
> these yourselves.ed.
>
> Best regards,
> Brian
>
> [1] This one is referenced in a commented out module.xml section 
> related to My Faces 1.1 support. I've checked with Farah Juma and that 
> is no longer relevant and the comment can be removed.
>
>
> _______________________________________________
> 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/20190404/7c19e7ba/attachment.html 

From cdewolf at redhat.com  Thu Apr  4 05:57:02 2019
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Thu, 4 Apr 2019 11:57:02 +0200
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
Message-ID: <c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>

Define the end-state.

If commons-lang3 is part of that end-state it makes no sense to remove 
it from the matrix. Were it not for CXF it could however be removed from 
the runtime.

Don't drive into a road which could potentially be a dead-end.

Carlo

On 03-04-19 16:51, Darran Lofthouse wrote:
> Certainly a topic for the future.
>
> On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser at redhat.com 
> <mailto:fnasser at redhat.com>> wrote:
>
>     On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
>>     +1 the tool is a shaded jar so should not need to depend on
>>     another module.
>>
>>     We may want to look at shading again but that would be a
>>     different topic.
>
>
>     Indeed.
>
>     Who monitors/detects the shaded code does not contain a CVE and
>     fix it if it does?
>
>     Are the people who "shaded" it responsible for
>     supporting/maintaining that code?
>
>
>>
>>     On Tue, Apr 2, 2019 at 10:13 PM James Perkins
>>     <jperkins at redhat.com <mailto:jperkins at redhat.com>> wrote:
>>
>>         I believe the org.wildfly.security:wildfly-elytron-tool does
>>         use org.apache.commons.lang3. However IIRC it's now shaded in
>>         so likely not an issue. That could be why it was originally
>>         there.
>>
>>         On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry
>>         <brian.stansberry at redhat.com
>>         <mailto:brian.stansberry at redhat.com>> wrote:
>>
>>             Currently WildFly includes 3 JBoss Modules modules that
>>             are not used in our runtime. I would like to remove these
>>             in WildFly 17:
>>
>>             org.apache.commons.cli
>>             org.apache.commons.lang[1]
>>             org.apache.commons.lang3
>>
>>             All three have the "jboss.api" = "private" property set
>>             in their module.xml, meaning they are marked for internal
>>             use only and we are free to remove them. End user
>>             applications should not have referenced these modules,
>>             and if they do we log a WARN on boot advising not to do that.
>>
>>             However, other projects that extend WildFly (i.e. write
>>             their own subsystems) may be using these modules, so I
>>             wanted to notify any such folks that these will likely be
>>             going away and you'll need to provide these yourselves.ed.
>>
>>             Best regards,
>>             Brian
>>
>>             [1] This one is referenced in a commented out module.xml
>>             section related to My Faces 1.1 support. I've checked
>>             with Farah Juma and that is no longer relevant and the
>>             comment can be removed.
>>
>>             _______________________________________________
>>             wildfly-dev mailing list
>>             wildfly-dev at lists.jboss.org
>>             <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev at lists.jboss.org  <mailto: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/20190404/04329a08/attachment-0001.html 

From darran.lofthouse at redhat.com  Thu Apr  4 06:04:09 2019
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 4 Apr 2019 10:04:09 +0000
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
Message-ID: <CAMxVf4PU2w04x3W8B0qM7nU1cK2tLBFTFEzWPn73fAr3xg9qFg@mail.gmail.com>

At this point in time there are no plans to modify how wildfly-elytron-tool
is packaged so I would suggest for now we don't take into account how it
could hypothetically be changed in the future.

On Thu, Apr 4, 2019 at 10:57 AM Carlo de Wolf <cdewolf at redhat.com> wrote:

> Define the end-state.
>
> If commons-lang3 is part of that end-state it makes no sense to remove it
> from the matrix. Were it not for CXF it could however be removed from the
> runtime.
>
> Don't drive into a road which could potentially be a dead-end.
>
> Carlo
>
> On 03-04-19 16:51, Darran Lofthouse wrote:
>
> Certainly a topic for the future.
>
> On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser at redhat.com> wrote:
>
>> On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
>>
>> +1 the tool is a shaded jar so should not need to depend on another
>> module.
>>
>> We may want to look at shading again but that would be a different topic.
>>
>>
>> Indeed.
>>
>> Who monitors/detects the shaded code does not contain a CVE and fix it if
>> it does?
>>
>> Are the people who "shaded" it responsible for supporting/maintaining
>> that code?
>>
>>
>>
>> On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com>
>> wrote:
>>
>>> I believe the org.wildfly.security:wildfly-elytron-tool does use
>>> org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
>>> issue. That could be why it was originally there.
>>>
>>> On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> Currently WildFly includes 3 JBoss Modules modules that are not used in
>>>> our runtime. I would like to remove these in WildFly 17:
>>>>
>>>> org.apache.commons.cli
>>>> org.apache.commons.lang[1]
>>>> org.apache.commons.lang3
>>>>
>>>> All three have the "jboss.api" = "private" property set in their
>>>> module.xml, meaning they are marked for internal use only and we are free
>>>> to remove them. End user applications should not have referenced these
>>>> modules, and if they do we log a WARN on boot advising not to do that.
>>>>
>>>> However, other projects that extend WildFly (i.e. write their own
>>>> subsystems) may be using these modules, so I wanted to notify any such
>>>> folks that these will likely be going away and you'll need to provide these
>>>> yourselves.ed.
>>>>
>>>> Best regards,
>>>> Brian
>>>>
>>>> [1] This one is referenced in a commented out module.xml section
>>>> related to My Faces 1.1 support. I've checked with Farah Juma and that is
>>>> no longer relevant and the comment can be removed.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/df5b994b/attachment.html 

From hpehl at redhat.com  Thu Apr  4 07:04:12 2019
From: hpehl at redhat.com (Harald Pehl)
Date: Thu, 4 Apr 2019 13:04:12 +0200
Subject: [wildfly-dev] HAL subsystem
Message-ID: <A528EB6C-E30C-4F05-9EFF-B81EB56904B8@redhat.com>

The management console uses various settings which need to survive a browser 
restart. Currently these settings are stored client side only either as cookie or 
in the browser local storage:

# Cookie

- Google Analytics on/off
- Page size
- Poll on/off
- Poll time

# Local Storage

- Management endpoints (for HAL standalone mode)
- Pinned items in the finder
- JavaScript extensions
- Macros

Using the browser to store settings has the advantage of being very flexible. 
The settings are also not bound to a specific WildFly instance. For some 
settings like the management endpoints this is a requirement and won't change. 

However other settings make more sense if they are stored on the server side. 
That's why I'd like to propose a dedicated subsystem for HAL. It should hold 
the current settings (except the management endpoints). It should be extendable
to store additional settings (currently there's an RFE to customize the 
visibility of notifications in HAL). 

Another advantage is that settings and data like macros could be properly 
secured using RBAC. 

I would like to hear your opinion about a dedicated subsystem for HAL. 
Does it makes sense? How should it look like? Any feedback and comments are 
welcome!

// Harald

From brian.stansberry at redhat.com  Thu Apr  4 13:07:13 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 4 Apr 2019 12:07:13 -0500
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
Message-ID: <CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>

On Thu, Apr 4, 2019 at 4:58 AM Carlo de Wolf <cdewolf at redhat.com> wrote:

> Define the end-state.
>
> If commons-lang3 is part of that end-state it makes no sense to remove it
> from the matrix. Were it not for CXF it could however be removed from the
> runtime.
>
> Don't drive into a road which could potentially be a dead-end.
>

I'm not aiming in this thread at removing things we use.  My only aim was
to remove cruft.  I missed the use of org.apache.commons.lang3. (Thansk,
Jim!) It's used so I won't be removing it.

Same for commons.cli.

So this is really just about org.apache.commons.lang


> Carlo
>
> On 03-04-19 16:51, Darran Lofthouse wrote:
>
> Certainly a topic for the future.
>
> On Wed, Apr 3, 2019 at 3:36 PM Fernando Nasser <fnasser at redhat.com> wrote:
>
>> On 2019-04-03 4:43 a.m., Darran Lofthouse wrote:
>>
>> +1 the tool is a shaded jar so should not need to depend on another
>> module.
>>
>> We may want to look at shading again but that would be a different topic.
>>
>>
>> Indeed.
>>
>> Who monitors/detects the shaded code does not contain a CVE and fix it if
>> it does?
>>
>> Are the people who "shaded" it responsible for supporting/maintaining
>> that code?
>>
>>
>>
>> On Tue, Apr 2, 2019 at 10:13 PM James Perkins <jperkins at redhat.com>
>> wrote:
>>
>>> I believe the org.wildfly.security:wildfly-elytron-tool does use
>>> org.apache.commons.lang3. However IIRC it's now shaded in so likely not an
>>> issue. That could be why it was originally there.
>>>
>>> On Tue, Apr 2, 2019 at 12:34 PM Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> Currently WildFly includes 3 JBoss Modules modules that are not used in
>>>> our runtime. I would like to remove these in WildFly 17:
>>>>
>>>> org.apache.commons.cli
>>>> org.apache.commons.lang[1]
>>>> org.apache.commons.lang3
>>>>
>>>> All three have the "jboss.api" = "private" property set in their
>>>> module.xml, meaning they are marked for internal use only and we are free
>>>> to remove them. End user applications should not have referenced these
>>>> modules, and if they do we log a WARN on boot advising not to do that.
>>>>
>>>> However, other projects that extend WildFly (i.e. write their own
>>>> subsystems) may be using these modules, so I wanted to notify any such
>>>> folks that these will likely be going away and you'll need to provide these
>>>> yourselves.ed.
>>>>
>>>> Best regards,
>>>> Brian
>>>>
>>>> [1] This one is referenced in a commented out module.xml section
>>>> related to My Faces 1.1 support. I've checked with Farah Juma and that is
>>>> no longer relevant and the comment can be removed.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/6670198d/attachment-0001.html 

From jperkins at redhat.com  Thu Apr  4 14:11:36 2019
From: jperkins at redhat.com (James Perkins)
Date: Thu, 4 Apr 2019 11:11:36 -0700
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
	<CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
Message-ID: <CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>

On Thu, Apr 4, 2019 at 10:26 AM Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Same for commons.cli.
>
> So this is really just about org.apache.commons.lang
>

It looks like org.apache.commons.lang is used in org.apache.openjpa too
[1]. It's also commented out in com.microsoft.azure.storage [2].

[1]:
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/openjpa/main/module.xml#L44

[2]:
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/com/microsoft/azure/storage/main/module.xml#L38


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/2ec9234f/attachment.html 

From smarlow at redhat.com  Thu Apr  4 14:32:55 2019
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 4 Apr 2019 14:32:55 -0400
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
	<CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
	<CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
Message-ID: <d7f94ac3-ae8c-4f84-e50d-11c934709514@redhat.com>



On 4/4/19 2:11 PM, James Perkins wrote:
> 
> 
> On Thu, Apr 4, 2019 at 10:26 AM Brian Stansberry 
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> 
>     Same for commons.cli.
> 
>     So this is really just about org.apache.commons.lang
> 
> 

I'll see if we can remove org.apache.commons.lang from the openjpa 
module [1].

> It looks like org.apache.commons.lang is used in org.apache.openjpa too 
> [1]. It's also commented out in com.microsoft.azure.storage [2].
> 
> [1]: 
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/openjpa/main/module.xml#L44 
> 
> [2]: 
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/com/microsoft/azure/storage/main/module.xml#L38
> 
> 
> -- 
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From brian.stansberry at redhat.com  Thu Apr  4 14:48:13 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 4 Apr 2019 13:48:13 -0500
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
	<CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
	<CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
Message-ID: <CAPhbRDZZxMHuF=qS1Ok+RLhPDgLyEEp-svBFUedzCz5Nd9KCzA@mail.gmail.com>

On Thu, Apr 4, 2019 at 1:11 PM James Perkins <jperkins at redhat.com> wrote:

>
>
> On Thu, Apr 4, 2019 at 10:26 AM Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Same for commons.cli.
>>
>> So this is really just about org.apache.commons.lang
>>
>
> It looks like org.apache.commons.lang is used in org.apache.openjpa too
> [1].
>

Thanks. I had to cancel my eye check appointment last week; perhaps I
should get that re-scheduled ASAP.

> It's also commented out in com.microsoft.azure.storage [2].
>

> [1]:
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/openjpa/main/module.xml#L44
>
> [2]:
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/com/microsoft/azure/storage/main/module.xml#L38
>
>
> --
> James R. Perkins
> JBoss by 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/20190404/f1fdf9c1/attachment.html 

From smarlow at redhat.com  Thu Apr  4 14:59:15 2019
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 4 Apr 2019 14:59:15 -0400
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <d7f94ac3-ae8c-4f84-e50d-11c934709514@redhat.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
	<CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
	<CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
	<d7f94ac3-ae8c-4f84-e50d-11c934709514@redhat.com>
Message-ID: <CAJtdNN5v6Oa2oEFZrhODp62kYa+aYtyjEDTsPB47myXrNYBMkw@mail.gmail.com>

Looks like I should be able to remove org.apache.commons.lang from the
OpenJPA module.  Will create a pr later.

On Thu, Apr 4, 2019 at 2:32 PM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 4/4/19 2:11 PM, James Perkins wrote:
> >
> >
> > On Thu, Apr 4, 2019 at 10:26 AM Brian Stansberry
> > <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
> wrote:
> >
> >     Same for commons.cli.
> >
> >     So this is really just about org.apache.commons.lang
> >
> >
>
> I'll see if we can remove org.apache.commons.lang from the openjpa
> module [1].
>
> > It looks like org.apache.commons.lang is used in org.apache.openjpa too
> > [1]. It's also commented out in com.microsoft.azure.storage [2].
> >
> > [1]:
> >
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/apache/openjpa/main/module.xml#L44
> >
> > [2]:
> >
> https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/com/microsoft/azure/storage/main/module.xml#L38
> >
> >
> > --
> > 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/20190404/76a7d466/attachment.html 

From smarlow at redhat.com  Thu Apr  4 16:20:31 2019
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 4 Apr 2019 16:20:31 -0400
Subject: [wildfly-dev] Removal of commons-cli,
 commons-lang and commons-lang3 modules
In-Reply-To: <CAJtdNN5v6Oa2oEFZrhODp62kYa+aYtyjEDTsPB47myXrNYBMkw@mail.gmail.com>
References: <CAPhbRDa75vYDGkfu4ecQzEQFERRaQaRo+jp+d1JV+1Xwy=iv=g@mail.gmail.com>
	<CADGwLpg1mZcheYe9Vmsgu+mFAof9_naTifPL26zqbZq1qie=Ww@mail.gmail.com>
	<CAMxVf4MocPTnq3LgCjk4V22J2DF2+5ibuTDXrCG1pTMW_677BQ@mail.gmail.com>
	<6281cc31-9502-2926-06f6-fcc02d38a1e8@redhat.com>
	<CAMxVf4OZUQ3yfPP0kvg5_rDP+t3Vie=+UcUcn+YZ7S_ceB0q9g@mail.gmail.com>
	<c49d63f3-df84-ef36-46bb-6b0d594669c8@redhat.com>
	<CAPhbRDYPULHhbZY53gb-Y8fU-KNpv+XuJwX18ww0UUD2dVRD5w@mail.gmail.com>
	<CADGwLphuwP9LU-yEoreYjNtsuVCQJjzrDj5pAENzQmgjwTu7VQ@mail.gmail.com>
	<d7f94ac3-ae8c-4f84-e50d-11c934709514@redhat.com>
	<CAJtdNN5v6Oa2oEFZrhODp62kYa+aYtyjEDTsPB47myXrNYBMkw@mail.gmail.com>
Message-ID: <CAJtdNN6Esv3nHmf0eHONgsZx6XrwV7afKbJDBXB5_wD3_QXngA@mail.gmail.com>

https://github.com/wildfly/wildfly/pull/12208 is for removing the
org.apache.commons.lang dependency from the OpenJPA module.

On Thu, Apr 4, 2019 at 2:59 PM Scott Marlow <smarlow at redhat.com> wrote:

> Looks like I should be able to remove org.apache.commons.lang from the
> OpenJPA module.  Will create a pr later.
>

>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190404/b3d34e6f/attachment.html 

From brian.stansberry at redhat.com  Thu Apr  4 17:17:11 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 4 Apr 2019 16:17:11 -0500
Subject: [wildfly-dev] HAL subsystem
In-Reply-To: <A528EB6C-E30C-4F05-9EFF-B81EB56904B8@redhat.com>
References: <A528EB6C-E30C-4F05-9EFF-B81EB56904B8@redhat.com>
Message-ID: <CAPhbRDasM5W0vuGUbTQWvs4YHpxWmFJ_D4w0q=zYWxgNpHq0MQ@mail.gmail.com>

I can't see storing this kind of thing in standalone.xml or host.xml, so
this means some other form of persistent store. The use cases around
managing that store would have to be gone through carefully.

The content repository can be used for that kind of thing, but it's not
meant to be directly managed. So no supported copying of your content from
one instance to another, etc, at least not without specific tooling we'd
have to provide.

People would also expect to be able to migrate this content when upgrading.
Which is just a variant of copying your content from one instance to
another.

For a domain the content repository is a domain-wide store (which is
actually a pro, since it means any host that is in sync with the domain can
become master and know it will have the needed data.)

How would this relate to possible uses of HAL in cloud environments?

On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <hpehl at redhat.com> wrote:

> The management console uses various settings which need to survive a
> browser
> restart. Currently these settings are stored client side only either as
> cookie or
> in the browser local storage:
>
> # Cookie
>
> - Google Analytics on/off
> - Page size
> - Poll on/off
> - Poll time
>
> # Local Storage
>
> - Management endpoints (for HAL standalone mode)
> - Pinned items in the finder
> - JavaScript extensions
> - Macros
>
> Using the browser to store settings has the advantage of being very
> flexible.
> The settings are also not bound to a specific WildFly instance. For some
> settings like the management endpoints this is a requirement and won't
> change.
>
> However other settings make more sense if they are stored on the server
> side.
> That's why I'd like to propose a dedicated subsystem for HAL. It should
> hold
> the current settings (except the management endpoints). It should be
> extendable
> to store additional settings (currently there's an RFE to customize the
> visibility of notifications in HAL).
>
> Another advantage is that settings and data like macros could be properly
> secured using RBAC.
>

How so?

I assume content would be per user so access to parts of the content would
be restricted based on userid.

Perhaps some kind of administrative operations that give access to other
users content, use of which would be limited based on the WildFly RBAC
roles?

>
> I would like to hear your opinion about a dedicated subsystem for HAL.
> Does it makes sense? How should it look like? Any feedback and comments
> are
> welcome!
>
> // Harald
> _______________________________________________
> 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/20190404/5ef6dd85/attachment-0001.html 

From darran.lofthouse at jboss.com  Fri Apr  5 05:44:52 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 5 Apr 2019 09:44:52 +0000
Subject: [wildfly-dev] JDBC Security Realm Enhancements
Message-ID: <CAMxVf4OJSL5B04QR=dbw9qfhhtZfJL+siR7zO1skfG6SF2dNOg@mail.gmail.com>

I have just submitted the following proposal to add a couple of small
enhancements to the JDBC SecurityRealm: -

https://github.com/wildfly/wildfly-proposals/pull/193

The proposal is predominantly to complete some paperwork for development
that has already taken place.

This brings two main changes: -
 1 - Where we load hashes and digests from a database we presently only
support base64 encoding, this enhancement adds support for hex encoding.
 2 - Adding support for storing passwords using modular crypt, this
supports a variety of password types and allows hashes, salts, and
iteration counts to be combined into a single field.

Regards,
Darran Lofthouse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190405/3d2c1c43/attachment.html 

From hpehl at redhat.com  Fri Apr  5 06:40:16 2019
From: hpehl at redhat.com (Harald Pehl)
Date: Fri, 5 Apr 2019 12:40:16 +0200
Subject: [wildfly-dev] HAL subsystem
In-Reply-To: <CAPhbRDasM5W0vuGUbTQWvs4YHpxWmFJ_D4w0q=zYWxgNpHq0MQ@mail.gmail.com>
References: <A528EB6C-E30C-4F05-9EFF-B81EB56904B8@redhat.com>
	<CAPhbRDasM5W0vuGUbTQWvs4YHpxWmFJ_D4w0q=zYWxgNpHq0MQ@mail.gmail.com>
Message-ID: <EB5E2ED0-9557-47C2-A3A8-4864AB7FF4E9@redhat.com>

I agree that some of this data might not fit in standalone.xml or domain.xml, 
but I'd like to get away from storing all kind of HAL related settings and data 
in the browser local storage. 

In the meantime there's another RFE coming up to customise the browser 
title for the console. 

What I'm looking for is an way to store these kind of data in the management 
model in a way that is extendable and future proof. 

I don't have any cloud specific use cases in mind, but I suppose that having a
place for HAL to store settings will also be a plus for HAL running in an OpenShift
environment. 

I mentioned RBAC, because I'd like to protect macros which is not possible atm.
Macros should only be visible and executable for specific roles.

> On 4. Apr 2019, at 23:17, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> I can't see storing this kind of thing in standalone.xml or host.xml, so this means some other form of persistent store. The use cases around managing that store would have to be gone through carefully.
> 
> The content repository can be used for that kind of thing, but it's not meant to be directly managed. So no supported copying of your content from one instance to another, etc, at least not without specific tooling we'd have to provide. 
> 
> People would also expect to be able to migrate this content when upgrading. Which is just a variant of copying your content from one instance to another.
> 
> For a domain the content repository is a domain-wide store (which is actually a pro, since it means any host that is in sync with the domain can become master and know it will have the needed data.)
> 
> How would this relate to possible uses of HAL in cloud environments?
> 
> On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <hpehl at redhat.com <mailto:hpehl at redhat.com>> wrote:
> The management console uses various settings which need to survive a browser 
> restart. Currently these settings are stored client side only either as cookie or 
> in the browser local storage:
> 
> # Cookie
> 
> - Google Analytics on/off
> - Page size
> - Poll on/off
> - Poll time
> 
> # Local Storage
> 
> - Management endpoints (for HAL standalone mode)
> - Pinned items in the finder
> - JavaScript extensions
> - Macros
> 
> Using the browser to store settings has the advantage of being very flexible. 
> The settings are also not bound to a specific WildFly instance. For some 
> settings like the management endpoints this is a requirement and won't change. 
> 
> However other settings make more sense if they are stored on the server side. 
> That's why I'd like to propose a dedicated subsystem for HAL. It should hold 
> the current settings (except the management endpoints). It should be extendable
> to store additional settings (currently there's an RFE to customize the 
> visibility of notifications in HAL). 
> 
> Another advantage is that settings and data like macros could be properly 
> secured using RBAC. 
> 
> How so?
> 
> I assume content would be per user so access to parts of the content would be restricted based on userid.
> 
> Perhaps some kind of administrative operations that give access to other users content, use of which would be limited based on the WildFly RBAC roles?
> 
> I would like to hear your opinion about a dedicated subsystem for HAL. 
> Does it makes sense? How should it look like? Any feedback and comments are 
> welcome!
> 
> // Harald
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev <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/20190405/545dacc5/attachment.html 

From brian.stansberry at redhat.com  Fri Apr  5 13:31:58 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 5 Apr 2019 12:31:58 -0500
Subject: [wildfly-dev] HAL subsystem
In-Reply-To: <EB5E2ED0-9557-47C2-A3A8-4864AB7FF4E9@redhat.com>
References: <A528EB6C-E30C-4F05-9EFF-B81EB56904B8@redhat.com>
	<CAPhbRDasM5W0vuGUbTQWvs4YHpxWmFJ_D4w0q=zYWxgNpHq0MQ@mail.gmail.com>
	<EB5E2ED0-9557-47C2-A3A8-4864AB7FF4E9@redhat.com>
Message-ID: <CAPhbRDb4a5ofs-e9n99CSE3bt2VYOT_1t+-6PV6F5haoLbvcDQ@mail.gmail.com>

On Fri, Apr 5, 2019 at 5:40 AM Harald Pehl <hpehl at redhat.com> wrote:

> I agree that some of this data might not fit in standalone.xml or
> domain.xml,
> but I'd like to get away from storing all kind of HAL related settings and
> data
> in the browser local storage.
>
> In the meantime there's another RFE coming up to customise the browser
> title for the console.
>
> What I'm looking for is an way to store these kind of data in the
> management
> model in a way that is extendable and future proof.
>
> I don't have any cloud specific use cases in mind, but I suppose that
> having a
> place for HAL to store settings will also be a plus for HAL running in an
> OpenShift
> environment.
>

Me too.

I mention OpenShift because that kind of use case helps clarify that things
that have to be worked through re: the management of persistent data.


> I mentioned RBAC, because I'd like to protect macros which is not possible
> atm.
> Macros should only be visible and executable for specific roles.
>

Shared macros? Or user-specific ones? I suppose all the things you listed
could have some concept of shared settings, as well as user-specific ones.

My question is kind of a tangent from the RBAC point. :) I can certainly
see why you'd want RBAC to control shared resources.

>
> On 4. Apr 2019, at 23:17, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
> I can't see storing this kind of thing in standalone.xml or host.xml, so
> this means some other form of persistent store. The use cases around
> managing that store would have to be gone through carefully.
>
> The content repository can be used for that kind of thing, but it's not
> meant to be directly managed. So no supported copying of your content from
> one instance to another, etc, at least not without specific tooling we'd
> have to provide.
>
> People would also expect to be able to migrate this content when
> upgrading. Which is just a variant of copying your content from one
> instance to another.
>
> For a domain the content repository is a domain-wide store (which is
> actually a pro, since it means any host that is in sync with the domain can
> become master and know it will have the needed data.)
>
> How would this relate to possible uses of HAL in cloud environments?
>
>
> On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <hpehl at redhat.com> wrote:
>
>> The management console uses various settings which need to survive a
>> browser
>> restart. Currently these settings are stored client side only either as
>> cookie or
>> in the browser local storage:
>>
>> # Cookie
>>
>> - Google Analytics on/off
>> - Page size
>> - Poll on/off
>> - Poll time
>>
>> # Local Storage
>>
>> - Management endpoints (for HAL standalone mode)
>> - Pinned items in the finder
>> - JavaScript extensions
>> - Macros
>>
>> Using the browser to store settings has the advantage of being very
>> flexible.
>> The settings are also not bound to a specific WildFly instance. For some
>> settings like the management endpoints this is a requirement and won't
>> change.
>>
>> However other settings make more sense if they are stored on the server
>> side.
>> That's why I'd like to propose a dedicated subsystem for HAL. It should
>> hold
>> the current settings (except the management endpoints). It should be
>> extendable
>> to store additional settings (currently there's an RFE to customize the
>> visibility of notifications in HAL).
>>
>> Another advantage is that settings and data like macros could be properly
>>
>> secured using RBAC.
>>
>
> How so?
>
> I assume content would be per user so access to parts of the content would
> be restricted based on userid.
>
> Perhaps some kind of administrative operations that give access to other
> users content, use of which would be limited based on the WildFly RBAC
> roles?
>
>>
>> I would like to hear your opinion about a dedicated subsystem for HAL.
>> Does it makes sense? How should it look like? Any feedback and comments
>> are
>> welcome!
>>
>> // Harald
>> _______________________________________________
>> 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/20190405/9ec1431b/attachment-0001.html 

From mstefank at redhat.com  Mon Apr  8 04:51:03 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Mon, 8 Apr 2019 10:51:03 +0200
Subject: [wildfly-dev]  Tyr - pull request format checker
Message-ID: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>

Hi,

I would like to present my side project Tyr [1] which is a tool that can
verify GitHub pull request structure by a YAML definition (example in [2])
provided by a user. The PR author sees the violations immediately in the PR
status which allows to correct mistakes right away when the PR is created.

I've recorded a short demo available at [3].

The validation is fully configurable and can be extended with for instance
analysis document links and similar.

I would like to include this functionality in wildfly repository. Thoughts?

[1] https://github.com/xstefank/tyr
[2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
[3] https://youtu.be/qZRcMQ6qIpg

Martin Stefanko

Software Engineer
Middleware Runtimes Sustaining Engineering Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190408/1f48072d/attachment.html 

From darran.lofthouse at jboss.com  Mon Apr  8 05:26:03 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 8 Apr 2019 09:26:03 +0000
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
Message-ID: <CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>

Couple of questions.

Where does this need to run?

How does this get maintained regarding things like uptime?


On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com> wrote:

> Hi,
>
> I would like to present my side project Tyr [1] which is a tool that can
> verify GitHub pull request structure by a YAML definition (example in [2])
> provided by a user. The PR author sees the violations immediately in the PR
> status which allows to correct mistakes right away when the PR is created.
>
> I've recorded a short demo available at [3].
>
> The validation is fully configurable and can be extended with for instance
> analysis document links and similar.
>
> I would like to include this functionality in wildfly repository. Thoughts?
>
> [1] https://github.com/xstefank/tyr
> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
> [3] https://youtu.be/qZRcMQ6qIpg
>
> Martin Stefanko
>
> Software Engineer
> Middleware Runtimes Sustaining Engineering Team
> 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/20190408/768e33d5/attachment.html 

From mstefank at redhat.com  Mon Apr  8 06:24:43 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Mon, 8 Apr 2019 12:24:43 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
Message-ID: <CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>

I can run it my openshift online instance so uptime would be maintained by
me for the time being. I have already several instances running like this
for some time. During F2F we've also discussed possibility to use Prow
project <https://github.com/kubernetes/test-infra/tree/master/prow> for
wildlfy which would require a platform to run (my openshift cannot cover
this) and Tyr would nicely integrate with Prow (already tested). However, I
am not aware if there has been any movement with Prow setup for wildfly
repository recently.

Martin


On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> Couple of questions.
>
> Where does this need to run?
>
> How does this get maintained regarding things like uptime?
>
>
> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> Hi,
>>
>> I would like to present my side project Tyr [1] which is a tool that can
>> verify GitHub pull request structure by a YAML definition (example in [2])
>> provided by a user. The PR author sees the violations immediately in the PR
>> status which allows to correct mistakes right away when the PR is created.
>>
>> I've recorded a short demo available at [3].
>>
>> The validation is fully configurable and can be extended with for
>> instance analysis document links and similar.
>>
>> I would like to include this functionality in wildfly repository.
>> Thoughts?
>>
>> [1] https://github.com/xstefank/tyr
>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>> [3] https://youtu.be/qZRcMQ6qIpg
>>
>> Martin Stefanko
>>
>> Software Engineer
>> Middleware Runtimes Sustaining Engineering Team
>> 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/20190408/6580f8af/attachment.html 

From darran.lofthouse at jboss.com  Mon Apr  8 06:27:33 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 8 Apr 2019 10:27:33 +0000
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
Message-ID: <CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>

I think if we were to add something to the PR process is should not rely on
a single individual to maintain it, if that person is busy, asleep, sick or
on holiday then there will be no one to deal with down time and other
issues,

On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com> wrote:

> I can run it my openshift online instance so uptime would be maintained by
> me for the time being. I have already several instances running like this
> for some time. During F2F we've also discussed possibility to use Prow
> project <https://github.com/kubernetes/test-infra/tree/master/prow> for
> wildlfy which would require a platform to run (my openshift cannot cover
> this) and Tyr would nicely integrate with Prow (already tested). However, I
> am not aware if there has been any movement with Prow setup for wildfly
> repository recently.
>
> Martin
>
>
> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> Couple of questions.
>>
>> Where does this need to run?
>>
>> How does this get maintained regarding things like uptime?
>>
>>
>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to present my side project Tyr [1] which is a tool that can
>>> verify GitHub pull request structure by a YAML definition (example in [2])
>>> provided by a user. The PR author sees the violations immediately in the PR
>>> status which allows to correct mistakes right away when the PR is created.
>>>
>>> I've recorded a short demo available at [3].
>>>
>>> The validation is fully configurable and can be extended with for
>>> instance analysis document links and similar.
>>>
>>> I would like to include this functionality in wildfly repository.
>>> Thoughts?
>>>
>>> [1] https://github.com/xstefank/tyr
>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>
>>> Martin Stefanko
>>>
>>> Software Engineer
>>> Middleware Runtimes Sustaining Engineering Team
>>> 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/20190408/b0ca0967/attachment-0001.html 

From mstefank at redhat.com  Mon Apr  8 08:31:38 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Mon, 8 Apr 2019 14:31:38 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
Message-ID: <CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>

Yes, understandable. Maybe it can be run where pull-player is being run
then? CC Ken.

Martin


On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> I think if we were to add something to the PR process is should not rely
> on a single individual to maintain it, if that person is busy, asleep, sick
> or on holiday then there will be no one to deal with down time and other
> issues,
>
> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> I can run it my openshift online instance so uptime would be maintained
>> by me for the time being. I have already several instances running like
>> this for some time. During F2F we've also discussed possibility to use Prow
>> project <https://github.com/kubernetes/test-infra/tree/master/prow> for
>> wildlfy which would require a platform to run (my openshift cannot cover
>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>> am not aware if there has been any movement with Prow setup for wildfly
>> repository recently.
>>
>> Martin
>>
>>
>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>> darran.lofthouse at jboss.com> wrote:
>>
>>> Couple of questions.
>>>
>>> Where does this need to run?
>>>
>>> How does this get maintained regarding things like uptime?
>>>
>>>
>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to present my side project Tyr [1] which is a tool that
>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>> the PR status which allows to correct mistakes right away when the PR is
>>>> created.
>>>>
>>>> I've recorded a short demo available at [3].
>>>>
>>>> The validation is fully configurable and can be extended with for
>>>> instance analysis document links and similar.
>>>>
>>>> I would like to include this functionality in wildfly repository.
>>>> Thoughts?
>>>>
>>>> [1] https://github.com/xstefank/tyr
>>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>
>>>> Martin Stefanko
>>>>
>>>> Software Engineer
>>>> Middleware Runtimes Sustaining Engineering Team
>>>> 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/20190408/396829de/attachment.html 

From jpallich at redhat.com  Mon Apr  8 09:28:22 2019
From: jpallich at redhat.com (Jiri Pallich)
Date: Mon, 8 Apr 2019 15:28:22 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
Message-ID: <CAL_eFE3w8BM+dhdF8RhtFY81ppAprdrunZecHfUtUqb1ryZk=Q@mail.gmail.com>

Nice!

Will raise the awareness of this on the Runtimes PM Call. I would not be
afraid running it in the "private" openshift as a pilot. I agree with
Darran that long-term there should be a supported way how to run and
maintain this tool.

Cheers,
Jiri

On Mon, Apr 8, 2019 at 2:54 PM Martin Stefanko <mstefank at redhat.com> wrote:

> Yes, understandable. Maybe it can be run where pull-player is being run
> then? CC Ken.
>
> Martin
>
>
> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> I think if we were to add something to the PR process is should not rely
>> on a single individual to maintain it, if that person is busy, asleep, sick
>> or on holiday then there will be no one to deal with down time and other
>> issues,
>>
>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> I can run it my openshift online instance so uptime would be maintained
>>> by me for the time being. I have already several instances running like
>>> this for some time. During F2F we've also discussed possibility to use Prow
>>> project <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>> wildlfy which would require a platform to run (my openshift cannot cover
>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>> am not aware if there has been any movement with Prow setup for wildfly
>>> repository recently.
>>>
>>> Martin
>>>
>>>
>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> Couple of questions.
>>>>
>>>> Where does this need to run?
>>>>
>>>> How does this get maintained regarding things like uptime?
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to present my side project Tyr [1] which is a tool that
>>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>>> the PR status which allows to correct mistakes right away when the PR is
>>>>> created.
>>>>>
>>>>> I've recorded a short demo available at [3].
>>>>>
>>>>> The validation is fully configurable and can be extended with for
>>>>> instance analysis document links and similar.
>>>>>
>>>>> I would like to include this functionality in wildfly repository.
>>>>> Thoughts?
>>>>>
>>>>> [1] https://github.com/xstefank/tyr
>>>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>
>>>>> Martin Stefanko
>>>>>
>>>>> Software Engineer
>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>> Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 


Jiri Pallich
Senior Program Manager
Middleware Runtimes and RHOAR (Red Hat Openshift Application Runtimes)

Tel.: +420 532 294 393
Cell: +420 775 158 118
Email: jpallich at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190408/1404ac8f/attachment.html 

From brian.stansberry at redhat.com  Mon Apr  8 09:38:01 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 8 Apr 2019 08:38:01 -0500
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
Message-ID: <CAPhbRDaA51eMwguH0+KhMxiLX6Ubzd=bmB46YVCXV6js80OiTw@mail.gmail.com>

The checks look pretty reasonable -- not overly rigid, which is good.

Does the commit check run against all commits in the PR?

On Mon, Apr 8, 2019 at 3:52 AM Martin Stefanko <mstefank at redhat.com> wrote:

> Hi,
>
> I would like to present my side project Tyr [1] which is a tool that can
> verify GitHub pull request structure by a YAML definition (example in [2])
> provided by a user. The PR author sees the violations immediately in the PR
> status which allows to correct mistakes right away when the PR is created.
>
> I've recorded a short demo available at [3].
>
> The validation is fully configurable and can be extended with for instance
> analysis document links and similar.
>
> I would like to include this functionality in wildfly repository. Thoughts?
>
> [1] https://github.com/xstefank/tyr
> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
> [3] https://youtu.be/qZRcMQ6qIpg
>
> Martin Stefanko
>
> Software Engineer
> Middleware Runtimes Sustaining Engineering Team
> 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/20190408/cae7e8cd/attachment-0001.html 

From brian.stansberry at redhat.com  Mon Apr  8 09:42:46 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 8 Apr 2019 08:42:46 -0500
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
Message-ID: <CAPhbRDZTWvjiZGaHf5sMYh51V34bSXM9i+1JyamrE1O9LXNN=g@mail.gmail.com>

Tangent from the question about where to run it:

What happens if it is down?  I figure nothing really, i.e. the check just
isn't performed, which is a quite reasonable failure mode. :)

AIUI this also has no impact on ability to merge PRs; i.e. we can ignore
the result same as we can ignore CI job results. Also good.

On Mon, Apr 8, 2019 at 7:54 AM Martin Stefanko <mstefank at redhat.com> wrote:

> Yes, understandable. Maybe it can be run where pull-player is being run
> then? CC Ken.
>
> Martin
>
>
> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> I think if we were to add something to the PR process is should not rely
>> on a single individual to maintain it, if that person is busy, asleep, sick
>> or on holiday then there will be no one to deal with down time and other
>> issues,
>>
>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> I can run it my openshift online instance so uptime would be maintained
>>> by me for the time being. I have already several instances running like
>>> this for some time. During F2F we've also discussed possibility to use Prow
>>> project <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>> wildlfy which would require a platform to run (my openshift cannot cover
>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>> am not aware if there has been any movement with Prow setup for wildfly
>>> repository recently.
>>>
>>> Martin
>>>
>>>
>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> Couple of questions.
>>>>
>>>> Where does this need to run?
>>>>
>>>> How does this get maintained regarding things like uptime?
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to present my side project Tyr [1] which is a tool that
>>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>>> the PR status which allows to correct mistakes right away when the PR is
>>>>> created.
>>>>>
>>>>> I've recorded a short demo available at [3].
>>>>>
>>>>> The validation is fully configurable and can be extended with for
>>>>> instance analysis document links and similar.
>>>>>
>>>>> I would like to include this functionality in wildfly repository.
>>>>> Thoughts?
>>>>>
>>>>> [1] https://github.com/xstefank/tyr
>>>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>
>>>>> Martin Stefanko
>>>>>
>>>>> Software Engineer
>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>> Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
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/20190408/25273543/attachment.html 

From kwills at redhat.com  Mon Apr  8 10:15:08 2019
From: kwills at redhat.com (Ken Wills)
Date: Mon, 8 Apr 2019 09:15:08 -0500
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
Message-ID: <CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>

On Mon, Apr 8, 2019 at 7:32 AM Martin Stefanko <mstefank at redhat.com> wrote:

> Yes, understandable. Maybe it can be run where pull-player is being run
> then? CC Ken.
>

We can run it in CI somewhere if we need to, I'll need to review the docs
and see whats required to run it.

For the initial version, I think we should just try it in OS though, then
we can move it at some point in the future.

Ken



>
> Martin
>
>
> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> I think if we were to add something to the PR process is should not rely
>> on a single individual to maintain it, if that person is busy, asleep, sick
>> or on holiday then there will be no one to deal with down time and other
>> issues,
>>
>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> I can run it my openshift online instance so uptime would be maintained
>>> by me for the time being. I have already several instances running like
>>> this for some time. During F2F we've also discussed possibility to use Prow
>>> project <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>> wildlfy which would require a platform to run (my openshift cannot cover
>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>> am not aware if there has been any movement with Prow setup for wildfly
>>> repository recently.
>>>
>>> Martin
>>>
>>>
>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> Couple of questions.
>>>>
>>>> Where does this need to run?
>>>>
>>>> How does this get maintained regarding things like uptime?
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to present my side project Tyr [1] which is a tool that
>>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>>> the PR status which allows to correct mistakes right away when the PR is
>>>>> created.
>>>>>
>>>>> I've recorded a short demo available at [3].
>>>>>
>>>>> The validation is fully configurable and can be extended with for
>>>>> instance analysis document links and similar.
>>>>>
>>>>> I would like to include this functionality in wildfly repository.
>>>>> Thoughts?
>>>>>
>>>>> [1] https://github.com/xstefank/tyr
>>>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>
>>>>> Martin Stefanko
>>>>>
>>>>> Software Engineer
>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>> 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/20190408/a908de6a/attachment.html 

From mstefank at redhat.com  Tue Apr  9 01:46:23 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Tue, 9 Apr 2019 07:46:23 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
Message-ID: <CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>

> Does the commit check run against all commits in the PR?

Not currently, I've added additional checks to verify there is only one
commit in the PR :) But this should be possible to do, however, force
pushing your way through commit history will not be an easy task.

> What happens if it is down?  I figure nothing really, i.e. the check just
isn't performed, which is a quite reasonable failure mode. :)

> AIUI this also has no impact on ability to merge PRs; i.e. we can ignore
the result same as we can ignore CI job results. Also good.

Absolutely right. There will be only one additional status in the list.
Everything can be ignored.

> We can run it in CI somewhere if we need to, I'll need to review the docs
and see whats required to run it.

Ken, I will take this with you offline when it's decided that we can set it
up.

Martin


On Mon, Apr 8, 2019 at 4:15 PM Ken Wills <kwills at redhat.com> wrote:

>
> On Mon, Apr 8, 2019 at 7:32 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> Yes, understandable. Maybe it can be run where pull-player is being run
>> then? CC Ken.
>>
>
> We can run it in CI somewhere if we need to, I'll need to review the docs
> and see whats required to run it.
>
> For the initial version, I think we should just try it in OS though, then
> we can move it at some point in the future.
>
> Ken
>
>
>
>>
>> Martin
>>
>>
>> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
>> darran.lofthouse at jboss.com> wrote:
>>
>>> I think if we were to add something to the PR process is should not rely
>>> on a single individual to maintain it, if that person is busy, asleep, sick
>>> or on holiday then there will be no one to deal with down time and other
>>> issues,
>>>
>>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>>> wrote:
>>>
>>>> I can run it my openshift online instance so uptime would be maintained
>>>> by me for the time being. I have already several instances running like
>>>> this for some time. During F2F we've also discussed possibility to use Prow
>>>> project <https://github.com/kubernetes/test-infra/tree/master/prow>
>>>> for wildlfy which would require a platform to run (my openshift cannot
>>>> cover this) and Tyr would nicely integrate with Prow (already tested).
>>>> However, I am not aware if there has been any movement with Prow setup for
>>>> wildfly repository recently.
>>>>
>>>> Martin
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>>> darran.lofthouse at jboss.com> wrote:
>>>>
>>>>> Couple of questions.
>>>>>
>>>>> Where does this need to run?
>>>>>
>>>>> How does this get maintained regarding things like uptime?
>>>>>
>>>>>
>>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to present my side project Tyr [1] which is a tool that
>>>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>>>> the PR status which allows to correct mistakes right away when the PR is
>>>>>> created.
>>>>>>
>>>>>> I've recorded a short demo available at [3].
>>>>>>
>>>>>> The validation is fully configurable and can be extended with for
>>>>>> instance analysis document links and similar.
>>>>>>
>>>>>> I would like to include this functionality in wildfly repository.
>>>>>> Thoughts?
>>>>>>
>>>>>> [1] https://github.com/xstefank/tyr
>>>>>> [2] https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>>
>>>>>> Martin Stefanko
>>>>>>
>>>>>> Software Engineer
>>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>>> 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/20190409/101fac41/attachment-0001.html 

From darran.lofthouse at jboss.com  Tue Apr  9 06:33:58 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 9 Apr 2019 11:33:58 +0100
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
Message-ID: <CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>

Overall if for a tool we don't care if it down and consider it's output to
be something to ignore it would seem to offer little value, I would suggest
we aim for it to be available with useful output.

Will this just be adding a comment or will this also be influencing the
status of the pull request - i.e. will these reports be affecting the tick
or the cross visible next to a PR?  When looking at the PR queue the ones
with the green ticks are the easiest to jump into, provided no changes are
required to the code they are potentially ready to merge - adding false
crosses would affect this.

On Tue, Apr 9, 2019 at 6:47 AM Martin Stefanko <mstefank at redhat.com> wrote:

> > Does the commit check run against all commits in the PR?
>
> Not currently, I've added additional checks to verify there is only one
> commit in the PR :) But this should be possible to do, however, force
> pushing your way through commit history will not be an easy task.
>

I think instead it should be checking all commits, it often makes sense to
break work into logical chunks - often it is easier to review commit by
commit.

As an example it is a bad practice to bump a subsystem version and add to
it within a single commit, GitHub provides no way to diff files like
schemas when that happens so the only way to check is to pull the PR
locally and manually diff. I suspect the manual diff is a very rare event
if it happens at all.  Component upgrades whilst could be in a single
commit often make sense to be in individual commits.  When working on an
issue and encountering a related but different bug it makes sense to use a
separate Jira issue and commit, it is not always practical to submit this
fix in it's own PR.  If working on a piece of work and another engineer
also follows on you need to ensure you don't modify any shared commits
etc...

Overall the human code review is still mandatory and part of that review
would consider the commits and if they make sense.

I think something that could be useful could be to list the checks to be
applied somewhere to make it easier to discuss individually, as this would
be a change to the WildFly Core and WildFly pull requests it could even
make sense to submit as a proposal to the wildfly-proposals repo.


>
> > What happens if it is down?  I figure nothing really, i.e. the check
> just isn't performed, which is a quite reasonable failure mode. :)
>
> > AIUI this also has no impact on ability to merge PRs; i.e. we can
> ignore the result same as we can ignore CI job results. Also good.
>
> Absolutely right. There will be only one additional status in the list.
> Everything can be ignored.
>

Absolutely everything we add to the status list we should be aiming to be
accurate, CI is complex and a never ending task to keep on top of
intermittent issues and flaky tests but the objective is still to reach
that point.  We should not be adding something else to this list
deliberately with false negative reviews.


>
> > We can run it in CI somewhere if we need to, I'll need to review the
> docs and see whats required to run it.
>
> Ken, I will take this with you offline when it's decided that we can set
> it up.
>
> Martin
>
>
> On Mon, Apr 8, 2019 at 4:15 PM Ken Wills <kwills at redhat.com> wrote:
>
>>
>> On Mon, Apr 8, 2019 at 7:32 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> Yes, understandable. Maybe it can be run where pull-player is being run
>>> then? CC Ken.
>>>
>>
>> We can run it in CI somewhere if we need to, I'll need to review the docs
>> and see whats required to run it.
>>
>> For the initial version, I think we should just try it in OS though, then
>> we can move it at some point in the future.
>>
>> Ken
>>
>>
>>
>>>
>>> Martin
>>>
>>>
>>> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> I think if we were to add something to the PR process is should not
>>>> rely on a single individual to maintain it, if that person is busy, asleep,
>>>> sick or on holiday then there will be no one to deal with down time and
>>>> other issues,
>>>>
>>>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>>>> wrote:
>>>>
>>>>> I can run it my openshift online instance so uptime would be
>>>>> maintained by me for the time being. I have already several instances
>>>>> running like this for some time. During F2F we've also discussed
>>>>> possibility to use Prow project
>>>>> <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>>>> wildlfy which would require a platform to run (my openshift cannot cover
>>>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>>>> am not aware if there has been any movement with Prow setup for wildfly
>>>>> repository recently.
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>>>> darran.lofthouse at jboss.com> wrote:
>>>>>
>>>>>> Couple of questions.
>>>>>>
>>>>>> Where does this need to run?
>>>>>>
>>>>>> How does this get maintained regarding things like uptime?
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to present my side project Tyr [1] which is a tool that
>>>>>>> can verify GitHub pull request structure by a YAML definition (example in
>>>>>>> [2]) provided by a user. The PR author sees the violations immediately in
>>>>>>> the PR status which allows to correct mistakes right away when the PR is
>>>>>>> created.
>>>>>>>
>>>>>>> I've recorded a short demo available at [3].
>>>>>>>
>>>>>>> The validation is fully configurable and can be extended with for
>>>>>>> instance analysis document links and similar.
>>>>>>>
>>>>>>> I would like to include this functionality in wildfly repository.
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> [1] https://github.com/xstefank/tyr
>>>>>>> [2]
>>>>>>> https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>>>
>>>>>>> Martin Stefanko
>>>>>>>
>>>>>>> Software Engineer
>>>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>>>> Red Hat
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190409/73b64277/attachment.html 

From brian.stansberry at redhat.com  Tue Apr  9 10:20:06 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 9 Apr 2019 09:20:06 -0500
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
Message-ID: <CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>

On Tue, Apr 9, 2019 at 5:39 AM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> Overall if for a tool we don't care if it down and consider it's output to
> be something to ignore it would seem to offer little value, I would suggest
> we aim for it to be available with useful output.
>
>
Yes.


> Will this just be adding a comment or will this also be influencing the
> status of the pull request - i.e. will these reports be affecting the tick
> or the cross visible next to a PR?  When looking at the PR queue the ones
> with the green ticks are the easiest to jump into, provided no changes are
> required to the code they are potentially ready to merge - adding false
> crosses would affect this.
>
> On Tue, Apr 9, 2019 at 6:47 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> > Does the commit check run against all commits in the PR?
>>
>> Not currently, I've added additional checks to verify there is only one
>> commit in the PR :) But this should be possible to do, however, force
>> pushing your way through commit history will not be an easy task.
>>
>
> I think instead it should be checking all commits, it often makes sense to
> break work into logical chunks - often it is easier to review commit by
> commit.
>

For sure I don't want rejection of PRs with multiple commits.  It's
perfectly valid to write PRs with multiple commits.

>
> As an example it is a bad practice to bump a subsystem version and add to
> it within a single commit, GitHub provides no way to diff files like
> schemas when that happens so the only way to check is to pull the PR
> locally and manually diff. I suspect the manual diff is a very rare event
> if it happens at all.  Component upgrades whilst could be in a single
> commit often make sense to be in individual commits.  When working on an
> issue and encountering a related but different bug it makes sense to use a
> separate Jira issue and commit, it is not always practical to submit this
> fix in it's own PR.  If working on a piece of work and another engineer
> also follows on you need to ensure you don't modify any shared commits
> etc...
>
> Overall the human code review is still mandatory and part of that review
> would consider the commits and if they make sense.
>

Yes.

I see this tool as helping to encourage people to follow proper practice
and save humans doing code review having to nag people over such things, or
not having the energy to nag, instead accepting things they don't really
want.


> I think something that could be useful could be to list the checks to be
> applied somewhere to make it easier to discuss individually, as this would
> be a change to the WildFly Core and WildFly pull requests it could even
> make sense to submit as a proposal to the wildfly-proposals repo.
>

>
>>
>> > What happens if it is down?  I figure nothing really, i.e. the check
>> just isn't performed, which is a quite reasonable failure mode. :)
>>
>> > AIUI this also has no impact on ability to merge PRs; i.e. we can
>> ignore the result same as we can ignore CI job results. Also good.
>>
>> Absolutely right. There will be only one additional status in the list.
>> Everything can be ignored.
>>
>
> Absolutely everything we add to the status list we should be aiming to be
> accurate, CI is complex and a never ending task to keep on top of
> intermittent issues and flaky tests but the objective is still to reach
> that point.  We should not be adding something else to this list
> deliberately with false negative reviews.
>

Yes, we want it to be accurate. We also want it to be available.

I think a key way to keep this accurate is to resist the temptation to have
it do more than it should. Don't come up with rules that sound right but
turn out to have valid exceptions or that people just won't follow.

OTOH if the mergers decide they want to do something I don't want a tool
preventing us doing it, which is what my questions were driving at. We're
way smarter than the tool.


>
>
>>
>> > We can run it in CI somewhere if we need to, I'll need to review the
>> docs and see whats required to run it.
>>
>> Ken, I will take this with you offline when it's decided that we can set
>> it up.
>>
>> Martin
>>
>>
>> On Mon, Apr 8, 2019 at 4:15 PM Ken Wills <kwills at redhat.com> wrote:
>>
>>>
>>> On Mon, Apr 8, 2019 at 7:32 AM Martin Stefanko <mstefank at redhat.com>
>>> wrote:
>>>
>>>> Yes, understandable. Maybe it can be run where pull-player is being run
>>>> then? CC Ken.
>>>>
>>>
>>> We can run it in CI somewhere if we need to, I'll need to review the
>>> docs and see whats required to run it.
>>>
>>> For the initial version, I think we should just try it in OS though,
>>> then we can move it at some point in the future.
>>>
>>> Ken
>>>
>>>
>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
>>>> darran.lofthouse at jboss.com> wrote:
>>>>
>>>>> I think if we were to add something to the PR process is should not
>>>>> rely on a single individual to maintain it, if that person is busy, asleep,
>>>>> sick or on holiday then there will be no one to deal with down time and
>>>>> other issues,
>>>>>
>>>>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I can run it my openshift online instance so uptime would be
>>>>>> maintained by me for the time being. I have already several instances
>>>>>> running like this for some time. During F2F we've also discussed
>>>>>> possibility to use Prow project
>>>>>> <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>>>>> wildlfy which would require a platform to run (my openshift cannot cover
>>>>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>>>>> am not aware if there has been any movement with Prow setup for wildfly
>>>>>> repository recently.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>>>>> darran.lofthouse at jboss.com> wrote:
>>>>>>
>>>>>>> Couple of questions.
>>>>>>>
>>>>>>> Where does this need to run?
>>>>>>>
>>>>>>> How does this get maintained regarding things like uptime?
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to present my side project Tyr [1] which is a tool
>>>>>>>> that can verify GitHub pull request structure by a YAML definition (example
>>>>>>>> in [2]) provided by a user. The PR author sees the violations immediately
>>>>>>>> in the PR status which allows to correct mistakes right away when the PR is
>>>>>>>> created.
>>>>>>>>
>>>>>>>> I've recorded a short demo available at [3].
>>>>>>>>
>>>>>>>> The validation is fully configurable and can be extended with for
>>>>>>>> instance analysis document links and similar.
>>>>>>>>
>>>>>>>> I would like to include this functionality in wildfly repository.
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> [1] https://github.com/xstefank/tyr
>>>>>>>> [2]
>>>>>>>> https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>>>>
>>>>>>>> Martin Stefanko
>>>>>>>>
>>>>>>>> Software Engineer
>>>>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>>>>> Red Hat
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
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/20190409/8f9478da/attachment-0001.html 

From mstefank at redhat.com  Tue Apr  9 11:44:11 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Tue, 9 Apr 2019 17:44:11 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
Message-ID: <CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>

The idea is only to verify pull request structure by rules defined by
Wildfly - so for instance if we require that every commit is prefixed with
[WFLY-XXX] or WFLY-XXX
<https://github.com/wildfly/wildfly/blob/master/.github/PULL_REQUEST_TEMPLATE.md>
.

>Will this just be adding a comment or will this also be influencing the
status of the pull request - i.e. will these reports be affecting the tick
or the cross visible next to a PR?  When looking at the PR queue the ones
with the green ticks are the easiest to jump into, provided no changes are
required to the code they are potentially ready to merge - adding false
crosses would affect this.

I found that status is better way to do this because it doesn't show in the
PR log like comments or adding/removing labels do and it's able to
demonstrate errors with the cross next to the commit so the author can
immediately see that something is wrong and fix it with a few quick actions
when the PR is created. Once the status in tyr check is green, assuming no
changes to PR structure are made afterwards, it will not influence other
statuses posted by CI.

It boils down to what we really expect from the PR: if prefixing with
[WFLY-XXX] or WFLY-XXX is a requirement than we should mandate that every
PR has such title. There is also an option to specify when to skip tyr
check altogether by skip patterns configurable in PR title, commit message
or description (e.g. title with "No issue required"). I can also add an
option to disable tyr check by authorized comment from a reviewer if needed.

> For sure I don't want rejection of PRs with multiple commits.  It's
perfectly valid to write PRs with multiple commits.

There shouldn't be any problem in adjusting this.

> Absolutely everything we add to the status list we should be aiming to be
accurate, CI is complex and a never ending task to keep on top of
intermittent issues and flaky tests but the objective is still to reach
that point.  We should not be adding something else to this list
deliberately with false negative reviews.

I would say it again depends on what we expect from the PR - it either has
a link to the issue or it does not so there is no possibility of false
negatives.

> I think a key way to keep this accurate is to resist the temptation to
have it do more than it should. Don't come up with rules that sound right
but turn out to have valid exceptions or that people just won't follow.

Agreed. My initial starting point was PR template
<https://github.com/wildfly/wildfly/blob/master/.github/PULL_REQUEST_TEMPLATE.md>
but
all rules can be adjusted as needed. And this will be configurable anytime
so if some rules won't get adopted as expected we can update or remove them.

> OTOH if the mergers decide they want to do something I don't want a tool
preventing us doing it, which is what my questions were driving at. We're
way smarter than the tool.

The status should not prevent a possibility of merge but if the cross next
to the commit would be a problem we can add an override to disable tyr
check (meaning make it pass manually) with a comment or similar as
suggested above.

Martin


On Tue, Apr 9, 2019 at 4:20 PM Brian Stansberry <brian.stansberry at redhat.com>
wrote:

>
>
> On Tue, Apr 9, 2019 at 5:39 AM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> Overall if for a tool we don't care if it down and consider it's output
>> to be something to ignore it would seem to offer little value, I would
>> suggest we aim for it to be available with useful output.
>>
>>
> Yes.
>
>
>> Will this just be adding a comment or will this also be influencing the
>> status of the pull request - i.e. will these reports be affecting the tick
>> or the cross visible next to a PR?  When looking at the PR queue the ones
>> with the green ticks are the easiest to jump into, provided no changes are
>> required to the code they are potentially ready to merge - adding false
>> crosses would affect this.
>>
>> On Tue, Apr 9, 2019 at 6:47 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> > Does the commit check run against all commits in the PR?
>>>
>>> Not currently, I've added additional checks to verify there is only one
>>> commit in the PR :) But this should be possible to do, however, force
>>> pushing your way through commit history will not be an easy task.
>>>
>>
>> I think instead it should be checking all commits, it often makes sense
>> to break work into logical chunks - often it is easier to review commit by
>> commit.
>>
>
> For sure I don't want rejection of PRs with multiple commits.  It's
> perfectly valid to write PRs with multiple commits.
>
>>
>> As an example it is a bad practice to bump a subsystem version and add to
>> it within a single commit, GitHub provides no way to diff files like
>> schemas when that happens so the only way to check is to pull the PR
>> locally and manually diff. I suspect the manual diff is a very rare event
>> if it happens at all.  Component upgrades whilst could be in a single
>> commit often make sense to be in individual commits.  When working on an
>> issue and encountering a related but different bug it makes sense to use a
>> separate Jira issue and commit, it is not always practical to submit this
>> fix in it's own PR.  If working on a piece of work and another engineer
>> also follows on you need to ensure you don't modify any shared commits
>> etc...
>>
>> Overall the human code review is still mandatory and part of that review
>> would consider the commits and if they make sense.
>>
>
> Yes.
>
> I see this tool as helping to encourage people to follow proper practice
> and save humans doing code review having to nag people over such things, or
> not having the energy to nag, instead accepting things they don't really
> want.
>
>
>> I think something that could be useful could be to list the checks to be
>> applied somewhere to make it easier to discuss individually, as this would
>> be a change to the WildFly Core and WildFly pull requests it could even
>> make sense to submit as a proposal to the wildfly-proposals repo.
>>
>
>>
>>>
>>> > What happens if it is down?  I figure nothing really, i.e. the check
>>> just isn't performed, which is a quite reasonable failure mode. :)
>>>
>>> > AIUI this also has no impact on ability to merge PRs; i.e. we can
>>> ignore the result same as we can ignore CI job results. Also good.
>>>
>>> Absolutely right. There will be only one additional status in the list.
>>> Everything can be ignored.
>>>
>>
>> Absolutely everything we add to the status list we should be aiming to be
>> accurate, CI is complex and a never ending task to keep on top of
>> intermittent issues and flaky tests but the objective is still to reach
>> that point.  We should not be adding something else to this list
>> deliberately with false negative reviews.
>>
>
> Yes, we want it to be accurate. We also want it to be available.
>
> I think a key way to keep this accurate is to resist the temptation to
> have it do more than it should. Don't come up with rules that sound right
> but turn out to have valid exceptions or that people just won't follow.
>
> OTOH if the mergers decide they want to do something I don't want a tool
> preventing us doing it, which is what my questions were driving at. We're
> way smarter than the tool.
>
>
>>
>>
>>>
>>> > We can run it in CI somewhere if we need to, I'll need to review the
>>> docs and see whats required to run it.
>>>
>>> Ken, I will take this with you offline when it's decided that we can set
>>> it up.
>>>
>>> Martin
>>>
>>>
>>> On Mon, Apr 8, 2019 at 4:15 PM Ken Wills <kwills at redhat.com> wrote:
>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 7:32 AM Martin Stefanko <mstefank at redhat.com>
>>>> wrote:
>>>>
>>>>> Yes, understandable. Maybe it can be run where pull-player is being
>>>>> run then? CC Ken.
>>>>>
>>>>
>>>> We can run it in CI somewhere if we need to, I'll need to review the
>>>> docs and see whats required to run it.
>>>>
>>>> For the initial version, I think we should just try it in OS though,
>>>> then we can move it at some point in the future.
>>>>
>>>> Ken
>>>>
>>>>
>>>>
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On Mon, Apr 8, 2019 at 12:27 PM Darran Lofthouse <
>>>>> darran.lofthouse at jboss.com> wrote:
>>>>>
>>>>>> I think if we were to add something to the PR process is should not
>>>>>> rely on a single individual to maintain it, if that person is busy, asleep,
>>>>>> sick or on holiday then there will be no one to deal with down time and
>>>>>> other issues,
>>>>>>
>>>>>> On Mon, Apr 8, 2019 at 11:25 AM Martin Stefanko <mstefank at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I can run it my openshift online instance so uptime would be
>>>>>>> maintained by me for the time being. I have already several instances
>>>>>>> running like this for some time. During F2F we've also discussed
>>>>>>> possibility to use Prow project
>>>>>>> <https://github.com/kubernetes/test-infra/tree/master/prow> for
>>>>>>> wildlfy which would require a platform to run (my openshift cannot cover
>>>>>>> this) and Tyr would nicely integrate with Prow (already tested). However, I
>>>>>>> am not aware if there has been any movement with Prow setup for wildfly
>>>>>>> repository recently.
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 8, 2019 at 11:26 AM Darran Lofthouse <
>>>>>>> darran.lofthouse at jboss.com> wrote:
>>>>>>>
>>>>>>>> Couple of questions.
>>>>>>>>
>>>>>>>> Where does this need to run?
>>>>>>>>
>>>>>>>> How does this get maintained regarding things like uptime?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 8, 2019 at 9:52 AM Martin Stefanko <mstefank at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I would like to present my side project Tyr [1] which is a tool
>>>>>>>>> that can verify GitHub pull request structure by a YAML definition (example
>>>>>>>>> in [2]) provided by a user. The PR author sees the violations immediately
>>>>>>>>> in the PR status which allows to correct mistakes right away when the PR is
>>>>>>>>> created.
>>>>>>>>>
>>>>>>>>> I've recorded a short demo available at [3].
>>>>>>>>>
>>>>>>>>> The validation is fully configurable and can be extended with for
>>>>>>>>> instance analysis document links and similar.
>>>>>>>>>
>>>>>>>>> I would like to include this functionality in wildfly repository.
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> [1] https://github.com/xstefank/tyr
>>>>>>>>> [2]
>>>>>>>>> https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30
>>>>>>>>> [3] https://youtu.be/qZRcMQ6qIpg
>>>>>>>>>
>>>>>>>>> Martin Stefanko
>>>>>>>>>
>>>>>>>>> Software Engineer
>>>>>>>>> Middleware Runtimes Sustaining Engineering Team
>>>>>>>>> Red Hat
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> 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/20190409/e310787f/attachment-0001.html 

From darran.lofthouse at jboss.com  Tue Apr  9 11:49:34 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 9 Apr 2019 16:49:34 +0100
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
Message-ID: <CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>

>
> > OTOH if the mergers decide they want to do something I don't want a tool
> preventing us doing it, which is what my questions were driving at. We're
> way smarter than the tool.
>
> The status should not prevent a possibility of merge but if the cross next
> to the commit would be a problem we can add an override to disable tyr
> check (meaning make it pass manually) with a comment or similar as
> suggested above.
>

The time the cross becomes a problem is if we adopt a set of verification
rules that we know will regularly trigger a failure to be ignored, if the
failure cases to be ignored are truly exceptional cases then the cross will
be useful.


>
> Martin
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190409/31fb0574/attachment.html 

From mstefank at redhat.com  Wed Apr 10 01:31:58 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Wed, 10 Apr 2019 07:31:58 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
	<CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
Message-ID: <CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>

> The time the cross becomes a problem is if we adopt a set of verification
rules that we know will regularly trigger a failure to be ignored, if the
failure cases to be ignored are truly exceptional cases then the cross will
be useful.

It would be beneficial to adjust rules as we'll see how useful they are as
time progresses. Configuration of rules is external to the service so it
will be possible.

Martin


On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> > OTOH if the mergers decide they want to do something I don't want a tool
>> preventing us doing it, which is what my questions were driving at. We're
>> way smarter than the tool.
>>
>> The status should not prevent a possibility of merge but if the cross
>> next to the commit would be a problem we can add an override to disable tyr
>> check (meaning make it pass manually) with a comment or similar as
>> suggested above.
>>
>
> The time the cross becomes a problem is if we adopt a set of verification
> rules that we know will regularly trigger a failure to be ignored, if the
> failure cases to be ignored are truly exceptional cases then the cross will
> be useful.
>
>
>>
>> Martin
>>
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190410/9d696239/attachment.html 

From darran.lofthouse at jboss.com  Wed Apr 10 05:10:39 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 10 Apr 2019 10:10:39 +0100
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
	<CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
	<CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>
Message-ID: <CAMxVf4MeP4fou+bNJR49avD4vQpMDh7mkrwWg059--aWKr6MXA@mail.gmail.com>

Do we have somewhere yet that we can start to look into an initial set of
rules to discuss what the initial set should be?

On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank at redhat.com> wrote:

> > The time the cross becomes a problem is if we adopt a set of
> verification rules that we know will regularly trigger a failure to be
> ignored, if the failure cases to be ignored are truly exceptional cases
> then the cross will be useful.
>
> It would be beneficial to adjust rules as we'll see how useful they are as
> time progresses. Configuration of rules is external to the service so it
> will be possible.
>
> Martin
>
>
> On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> > OTOH if the mergers decide they want to do something I don't want a
>>> tool preventing us doing it, which is what my questions were driving at.
>>> We're way smarter than the tool.
>>>
>>> The status should not prevent a possibility of merge but if the cross
>>> next to the commit would be a problem we can add an override to disable tyr
>>> check (meaning make it pass manually) with a comment or similar as
>>> suggested above.
>>>
>>
>> The time the cross becomes a problem is if we adopt a set of verification
>> rules that we know will regularly trigger a failure to be ignored, if the
>> failure cases to be ignored are truly exceptional cases then the cross will
>> be useful.
>>
>>
>>>
>>> Martin
>>>
>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190410/ad8afc4d/attachment.html 

From mstefank at redhat.com  Wed Apr 10 06:35:06 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Wed, 10 Apr 2019 12:35:06 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4MeP4fou+bNJR49avD4vQpMDh7mkrwWg059--aWKr6MXA@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
	<CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
	<CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>
	<CAMxVf4MeP4fou+bNJR49avD4vQpMDh7mkrwWg059--aWKr6MXA@mail.gmail.com>
Message-ID: <CAEEDSKXOYbB0f0B9OzOn8RWT4kWzY3fWZPEf2b-WZnxNk5mHuw@mail.gmail.com>

For the demo I've started with this
<https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30>. For
additional checks I have only something to verify that issue in title
matches the link in the description. Any ideas are welcome!

I was also thinking about making distinction between issues / bugs and
features if that would be useful.

I've created a google document to track this -
https://docs.google.com/document/d/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBNRdZp8I/edit?usp=sharing
.

Martin


On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> Do we have somewhere yet that we can start to look into an initial set of
> rules to discuss what the initial set should be?
>
> On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> > The time the cross becomes a problem is if we adopt a set of
>> verification rules that we know will regularly trigger a failure to be
>> ignored, if the failure cases to be ignored are truly exceptional cases
>> then the cross will be useful.
>>
>> It would be beneficial to adjust rules as we'll see how useful they are
>> as time progresses. Configuration of rules is external to the service so it
>> will be possible.
>>
>> Martin
>>
>>
>> On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <
>> darran.lofthouse at jboss.com> wrote:
>>
>>> > OTOH if the mergers decide they want to do something I don't want a
>>>> tool preventing us doing it, which is what my questions were driving at.
>>>> We're way smarter than the tool.
>>>>
>>>> The status should not prevent a possibility of merge but if the cross
>>>> next to the commit would be a problem we can add an override to disable tyr
>>>> check (meaning make it pass manually) with a comment or similar as
>>>> suggested above.
>>>>
>>>
>>> The time the cross becomes a problem is if we adopt a set of
>>> verification rules that we know will regularly trigger a failure to be
>>> ignored, if the failure cases to be ignored are truly exceptional cases
>>> then the cross will be useful.
>>>
>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190410/d1d18b19/attachment-0001.html 

From darran.lofthouse at jboss.com  Wed Apr 10 06:54:22 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 10 Apr 2019 11:54:22 +0100
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAEEDSKXOYbB0f0B9OzOn8RWT4kWzY3fWZPEf2b-WZnxNk5mHuw@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
	<CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
	<CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>
	<CAMxVf4MeP4fou+bNJR49avD4vQpMDh7mkrwWg059--aWKr6MXA@mail.gmail.com>
	<CAEEDSKXOYbB0f0B9OzOn8RWT4kWzY3fWZPEf2b-WZnxNk5mHuw@mail.gmail.com>
Message-ID: <CAMxVf4O8LXUX+eNJGriqdv3rZMK8crsyzeKv9aAUz=8N_+B3AA@mail.gmail.com>

As an open source project may be better to document somewhere visible to
the community.

>From the initial rules I would suggest drop the "NO JIRA REQUIRED" from
commit messages and PR titles, the commit messages and potentially the
titles end up in the history of the project and have no meaning outside of
the tool.

At the moment it looks like the template only covers WildFly so may need a
second template to cover WildFly Core.

I think from the perspective of the tool making it mandatory for each
commit in the PR to contain a Jira ID either with or without the brackets
is fine - unless you want to guarantee whitespace around the Jira ID maybe
the regular expression could be simplified to ignore the brackets.

Also I think it is reasonable for the tool to expect a link in each PR
which should also relate to the project the PR is against.

Regards,
Darran Lofthouse.



On Wed, Apr 10, 2019 at 11:35 AM Martin Stefanko <mstefank at redhat.com>
wrote:

> For the demo I've started with this
> <https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30>. For
> additional checks I have only something to verify that issue in title
> matches the link in the description. Any ideas are welcome!
>
> I was also thinking about making distinction between issues / bugs and
> features if that would be useful.
>
> I've created a google document to track this -
> https://docs.google.com/document/d/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBNRdZp8I/edit?usp=sharing
> .
>
> Martin
>
>
> On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> Do we have somewhere yet that we can start to look into an initial set of
>> rules to discuss what the initial set should be?
>>
>> On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank at redhat.com>
>> wrote:
>>
>>> > The time the cross becomes a problem is if we adopt a set of
>>> verification rules that we know will regularly trigger a failure to be
>>> ignored, if the failure cases to be ignored are truly exceptional cases
>>> then the cross will be useful.
>>>
>>> It would be beneficial to adjust rules as we'll see how useful they are
>>> as time progresses. Configuration of rules is external to the service so it
>>> will be possible.
>>>
>>> Martin
>>>
>>>
>>> On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> > OTOH if the mergers decide they want to do something I don't want a
>>>>> tool preventing us doing it, which is what my questions were driving at.
>>>>> We're way smarter than the tool.
>>>>>
>>>>> The status should not prevent a possibility of merge but if the cross
>>>>> next to the commit would be a problem we can add an override to disable tyr
>>>>> check (meaning make it pass manually) with a comment or similar as
>>>>> suggested above.
>>>>>
>>>>
>>>> The time the cross becomes a problem is if we adopt a set of
>>>> verification rules that we know will regularly trigger a failure to be
>>>> ignored, if the failure cases to be ignored are truly exceptional cases
>>>> then the cross will be useful.
>>>>
>>>>
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190410/8c4ce7b9/attachment.html 

From mstefank at redhat.com  Wed Apr 10 07:41:01 2019
From: mstefank at redhat.com (Martin Stefanko)
Date: Wed, 10 Apr 2019 13:41:01 +0200
Subject: [wildfly-dev] Tyr - pull request format checker
In-Reply-To: <CAMxVf4O8LXUX+eNJGriqdv3rZMK8crsyzeKv9aAUz=8N_+B3AA@mail.gmail.com>
References: <CAEEDSKU-GZocZdhh_5LXrswhWCMCdFGGj8XRKrErtA5Ndb0p1w@mail.gmail.com>
	<CAMxVf4MnRw2rZGxB8MkzDae5_HzrposstP-OB5xb00YSi_M9Eg@mail.gmail.com>
	<CAEEDSKV_YfEsoZmx4RhfpL9La-A9nrbf6Hb1bPoBpDAhJhgcrQ@mail.gmail.com>
	<CAMxVf4N1GKVbm4gQkmnxiFuiN3ZO9WG+RqRrX7d77ULgM+hhuw@mail.gmail.com>
	<CAEEDSKW60t7Pgcsp=d+VBcD2g92ECPRXKtvBbgatRGjoXyujKg@mail.gmail.com>
	<CAMw35_pD1yq2+myT+tuMq60Y7YzqQ4nf9czqwdanJGUYWwTm3w@mail.gmail.com>
	<CAEEDSKW0V-ViWN9_7+AuPPYpvv=8rZOmES1-RYfmZt_baC2XAg@mail.gmail.com>
	<CAMxVf4MXHrRWmLHwqrPsFyNGTjHNx8cZN9KyrVg3hAh-19N7vA@mail.gmail.com>
	<CAPhbRDY133y-uJnvwb2hfo2MNFq-TK=u=tkxsSsbamQHy1Os0g@mail.gmail.com>
	<CAEEDSKXkXnkZX6CXtKDpfb2XaM-jF9xidf_E=zntHiUxX_KFbQ@mail.gmail.com>
	<CAMxVf4Pu0wY_TZ7CLWzxw4jgqYhLt2QRtjr9eZZ8c53BR86vOQ@mail.gmail.com>
	<CAEEDSKWMjig5Mn1jKyWV2OHWONYo61TZFC8U+kdtcH=tujJUww@mail.gmail.com>
	<CAMxVf4MeP4fou+bNJR49avD4vQpMDh7mkrwWg059--aWKr6MXA@mail.gmail.com>
	<CAEEDSKXOYbB0f0B9OzOn8RWT4kWzY3fWZPEf2b-WZnxNk5mHuw@mail.gmail.com>
	<CAMxVf4O8LXUX+eNJGriqdv3rZMK8crsyzeKv9aAUz=8N_+B3AA@mail.gmail.com>
Message-ID: <CAEEDSKW8+Z0YbSRbNTdFB_KjuvHteuB8Ow+PQZ=GbgDQK7zx3A@mail.gmail.com>

Thanks Darran, all valid suggestions.

I've moved the document to my personal public account [1] - it should be
accessible to anyone now.

I will incorporate your suggestions in the gist.

[1]
https://docs.google.com/document/d/13DScS-WyQipblfDG-hjFJ12mQ7OM18TsAY-vIo6qAr8/edit?usp=sharing

Thank you,
Martin


On Wed, Apr 10, 2019 at 12:54 PM Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> As an open source project may be better to document somewhere visible to
> the community.
>
> From the initial rules I would suggest drop the "NO JIRA REQUIRED" from
> commit messages and PR titles, the commit messages and potentially the
> titles end up in the history of the project and have no meaning outside of
> the tool.
>
> At the moment it looks like the template only covers WildFly so may need a
> second template to cover WildFly Core.
>
> I think from the perspective of the tool making it mandatory for each
> commit in the PR to contain a Jira ID either with or without the brackets
> is fine - unless you want to guarantee whitespace around the Jira ID maybe
> the regular expression could be simplified to ignore the brackets.
>
> Also I think it is reasonable for the tool to expect a link in each PR
> which should also relate to the project the PR is against.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On Wed, Apr 10, 2019 at 11:35 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> For the demo I've started with this
>> <https://gist.github.com/xstefank/3a79f2f199ee1e449a44c607120a9d30>. For
>> additional checks I have only something to verify that issue in title
>> matches the link in the description. Any ideas are welcome!
>>
>> I was also thinking about making distinction between issues / bugs and
>> features if that would be useful.
>>
>> I've created a google document to track this -
>> https://docs.google.com/document/d/1ZuD5fyOlGTVDh96jiuM6jTdofm4fG6gZqdfBNRdZp8I/edit?usp=sharing
>> .
>>
>> Martin
>>
>>
>> On Wed, Apr 10, 2019 at 11:10 AM Darran Lofthouse <
>> darran.lofthouse at jboss.com> wrote:
>>
>>> Do we have somewhere yet that we can start to look into an initial set
>>> of rules to discuss what the initial set should be?
>>>
>>> On Wed, Apr 10, 2019 at 6:32 AM Martin Stefanko <mstefank at redhat.com>
>>> wrote:
>>>
>>>> > The time the cross becomes a problem is if we adopt a set of
>>>> verification rules that we know will regularly trigger a failure to be
>>>> ignored, if the failure cases to be ignored are truly exceptional cases
>>>> then the cross will be useful.
>>>>
>>>> It would be beneficial to adjust rules as we'll see how useful they are
>>>> as time progresses. Configuration of rules is external to the service so it
>>>> will be possible.
>>>>
>>>> Martin
>>>>
>>>>
>>>> On Tue, Apr 9, 2019 at 5:49 PM Darran Lofthouse <
>>>> darran.lofthouse at jboss.com> wrote:
>>>>
>>>>> > OTOH if the mergers decide they want to do something I don't want a
>>>>>> tool preventing us doing it, which is what my questions were driving at.
>>>>>> We're way smarter than the tool.
>>>>>>
>>>>>> The status should not prevent a possibility of merge but if the cross
>>>>>> next to the commit would be a problem we can add an override to disable tyr
>>>>>> check (meaning make it pass manually) with a comment or similar as
>>>>>> suggested above.
>>>>>>
>>>>>
>>>>> The time the cross becomes a problem is if we adopt a set of
>>>>> verification rules that we know will regularly trigger a failure to be
>>>>> ignored, if the failure cases to be ignored are truly exceptional cases
>>>>> then the cross will be useful.
>>>>>
>>>>>
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190410/9b3ae36c/attachment.html 

From jucook at redhat.com  Fri Apr 12 10:47:14 2019
From: jucook at redhat.com (Justin Cook)
Date: Fri, 12 Apr 2019 10:47:14 -0400
Subject: [wildfly-dev] [ELY-1778] Proposal for Enhanced Audit Logging -
 Feature Parity with Legacy in Elytron
Message-ID: <CABXKk4A-4G88Hh3M3TNEAnS16g8Raik9SeRdE-m20F=1y+NySQ@mail.gmail.com>

Hello All,
I've created a proposal [1] to enhance audit logging by feature parity with
legacy audit logging in Elytron. Any feedback is welcome.

[1] https://github.com/wildfly/wildfly-proposals/pull/196
<https://github.com/wildfly/wildfly-proposals/pull/184>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190412/411b4398/attachment-0001.html 

From bgeorges at redhat.com  Mon Apr 15 03:38:24 2019
From: bgeorges at redhat.com (Bruno Georges)
Date: Mon, 15 Apr 2019 09:38:24 +0200
Subject: [wildfly-dev] Undertow / Netty
Message-ID: <CAHuv7RQ9Gm1=Wb5RM3kVc=G=y+ZfOcK57VYfWYeEi=WN1Cv_2Q@mail.gmail.com>

Hi,

Norman Ping me earlier and wanted to let you know that He is happy to
answer any questions if you need any help.

He also also reminded that of course contributions are always welcome :)

Bruno.
-- 
--
Bruno Georges
Director, Software Engineering
Red Hat Middleware
m: +41 79 265 77 32
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190415/cd685370/attachment.html 

From hpehl at redhat.com  Mon Apr 15 03:42:35 2019
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 15 Apr 2019 09:42:35 +0200
Subject: [wildfly-dev] HAL / Customise window title
Message-ID: <46F22AD6-C655-4CCE-8EC1-7265950DF2F5@redhat.com>

I just want to let you know about a new feature in HAL which is planed to ship 
with the upcoming WF 17 release.  

The feature is about to customize the browser title and is described in the 
issue [1] and analysis document [2]. 

Any feedback and comments are welcome.

// Harald

[1] https://issues.jboss.org/browse/HAL-1578
[2] https://github.com/wildfly/wildfly-proposals/blob/d2dd1a34817e8d8206ffd1b6fad0efba10b37631/console/HAL-1578_Customise_Browser_Title.adoc

From emartins at redhat.com  Thu Apr 18 04:18:23 2019
From: emartins at redhat.com (Eduardo Martins)
Date: Thu, 18 Apr 2019 09:18:23 +0100
Subject: [wildfly-dev] Rethinking WildFly BOMs
Message-ID: <85CDDB32-115B-433A-BDBE-C18B85EE1771@redhat.com>

Hello all, I have prepared a document with respect to a major rework of the WildFly BOMs project, with focus on automating most of its maintenance.

https://docs.google.com/document/d/1kRRyg_PZ3NYaNnq0PdDatTQ0wkUtJG2-bsA0CkoTHdM/edit?usp=sharing <https://docs.google.com/document/d/1kRRyg_PZ3NYaNnq0PdDatTQ0wkUtJG2-bsA0CkoTHdM/edit?usp=sharing>

Please have a look at it, specially if you consume any BOM or you are involved with BOMs or WildFly component development somehow, and if not asking too much please provide some feedback.

I am aware that the document has a lot to digest and I suggest feedback is provided through Google Docs comments.

Thank in advance,

?E

WildFly BOMs Lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190418/480d7e43/attachment.html 

From jperkins at redhat.com  Thu Apr 18 14:15:31 2019
From: jperkins at redhat.com (James Perkins)
Date: Thu, 18 Apr 2019 11:15:31 -0700
Subject: [wildfly-dev] [WFLY-11031] Add proposal for JSON access logging.
In-Reply-To: <CADGwLpiTracH4=tsBmE2CiDOUiajZvFh5iB7qQOhedT-Xz7Vvw@mail.gmail.com>
References: <CADGwLpiTracH4=tsBmE2CiDOUiajZvFh5iB7qQOhedT-Xz7Vvw@mail.gmail.com>
Message-ID: <CADGwLpgGqNBRvwtSYKeV7pxtSvJhKk2CQVrBpv759VEgAxKOkA@mail.gmail.com>

Hello All,
It's been longer than I'd want to really get into this, but now that I've
got a start on it I'd like some feedback on the best way to deal with the
pattern attribute. For the file it currently just uses a pattern like %h %l
%u %t %r %s %b %{i,Referer} %{i,User-Agent}. The problem is that doesn't
really provide a key for the value. What I'm currently using is that same
pattern and using the ExchangeAttributeBuilder.getName() as the key.
However if the value of getName() changes at some point the data would end
up with a different key. This approach doesn't seem ideal.

One option would be to switch to some kind of property format type of thing
like:

attributes={"remoteHost"="%h", "identityUsername"="%l"}

I'm not sure how user friendly that is though.

The other option would be to limit it to known exchange attributes, but
that would require a change every time a new attribute is added to Undertow
itself or we'd have to allow for some kind of custom attribute.

Any opinions are welcome. Ideally we want something user friendly that's
going to produce consistent keys as that would be part of the structured
data contract.

On Mon, Feb 18, 2019 at 8:10 AM James Perkins <jperkins at redhat.com> wrote:

> Hello All,
> I've created a proposal [1] for JSON access logging. Any feedback is
> welcome.
>
> [1]: https://github.com/wildfly/wildfly-proposals/pull/176
>
> --
> James R. Perkins
> JBoss by Red Hat
>


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190418/1925a4bb/attachment.html 

From brian.stansberry at redhat.com  Thu Apr 18 15:41:32 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 18 Apr 2019 14:41:32 -0500
Subject: [wildfly-dev] [WFLY-11031] Add proposal for JSON access logging.
In-Reply-To: <CADGwLpgGqNBRvwtSYKeV7pxtSvJhKk2CQVrBpv759VEgAxKOkA@mail.gmail.com>
References: <CADGwLpiTracH4=tsBmE2CiDOUiajZvFh5iB7qQOhedT-Xz7Vvw@mail.gmail.com>
	<CADGwLpgGqNBRvwtSYKeV7pxtSvJhKk2CQVrBpv759VEgAxKOkA@mail.gmail.com>
Message-ID: <CAPhbRDZ+88U5xNq24XinHQFYqU3m6ycGmSeRO5HY4amt+fU4bQ@mail.gmail.com>

On Thu, Apr 18, 2019 at 1:20 PM James Perkins <jperkins at redhat.com> wrote:

> Hello All,
> It's been longer than I'd want to really get into this, but now that I've
> got a start on it I'd like some feedback on the best way to deal with the
> pattern attribute. For the file it currently just uses a pattern like %h
> %l %u %t %r %s %b %{i,Referer} %{i,User-Agent}. The problem is that
> doesn't really provide a key for the value. What I'm currently using is
> that same pattern and using the ExchangeAttributeBuilder.getName() as the
> key. However if the value of getName() changes at some point the data
> would end up with a different key. This approach doesn't seem ideal.
>
> One option would be to switch to some kind of property format type of
> thing like:
>
> attributes={"remoteHost"="%h", "identityUsername"="%l"}
>
> I'm not sure how user friendly that is though.
>
> The other option would be to limit it to known exchange attributes, but
> that would require a change every time a new attribute is added to Undertow
> itself or we'd have to allow for some kind of custom attribute.
>

> Any opinions are welcome. Ideally we want something user friendly that's
> going to produce consistent keys as that would be part of the structured
> data contract.
>

That pattern string also provides order. I suppose that's not as important
with structured data though.

Perhaps two alternative attributes, one that's a pattern String and then
one that's complex like your example?  The pattern string is documented
with the values it supports and the names of the keys it will use for those
values. (Those keys are set in the WF code, not pulled from
ExchangeAttributeBuilder.) If you want other key names or other values you
have to use the complex attribute.

That's kind of kludgy but it makes the hopefully common case simple.


> On Mon, Feb 18, 2019 at 8:10 AM James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> I've created a proposal [1] for JSON access logging. Any feedback is
>> welcome.
>>
>> [1]: https://github.com/wildfly/wildfly-proposals/pull/176
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>>
>
>
> --
> 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/20190418/61a4f8ed/attachment.html 

From brian.stansberry at redhat.com  Thu Apr 18 15:56:20 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 18 Apr 2019 14:56:20 -0500
Subject: [wildfly-dev] Rethinking WildFly BOMs
In-Reply-To: <85CDDB32-115B-433A-BDBE-C18B85EE1771@redhat.com>
References: <85CDDB32-115B-433A-BDBE-C18B85EE1771@redhat.com>
Message-ID: <CAPhbRDZ1i3BaguVdwkb0nNj+Ow4Xq8LX+KY0ACDYEj7Ci70dRw@mail.gmail.com>

Hi Eduardo,

Thanks for this. I encourage the leads for the components involved in our
boms to have a look.  My impression is this would be EJB, JMS, Web
Services, REST, JPA, Clustering, Security.  The first three we provide
specific client boms, and the rest are part of the overall 'javaee8' bom.

- Brian

On Thu, Apr 18, 2019 at 3:19 AM Eduardo Martins <emartins at redhat.com> wrote:

> Hello all, I have prepared a document with respect to a major rework of
> the WildFly BOMs project, with focus on automating most of its maintenance.
>
>
> https://docs.google.com/document/d/1kRRyg_PZ3NYaNnq0PdDatTQ0wkUtJG2-bsA0CkoTHdM/edit?usp=sharing
>
> Please have a look at it, specially if you consume any BOM or you are
> involved with BOMs or WildFly component development somehow, and if not
> asking too much please provide some feedback.
>
> I am aware that the document has a lot to digest and I suggest feedback is
> provided through Google Docs comments.
>
> Thank in advance,
>
> ?E
>
> WildFly BOMs Lead
>
> _______________________________________________
> 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/20190418/baea5cad/attachment-0001.html 

From jperkins at redhat.com  Thu Apr 18 16:19:41 2019
From: jperkins at redhat.com (James Perkins)
Date: Thu, 18 Apr 2019 13:19:41 -0700
Subject: [wildfly-dev] [WFLY-11031] Add proposal for JSON access logging.
In-Reply-To: <CAPhbRDZ+88U5xNq24XinHQFYqU3m6ycGmSeRO5HY4amt+fU4bQ@mail.gmail.com>
References: <CADGwLpiTracH4=tsBmE2CiDOUiajZvFh5iB7qQOhedT-Xz7Vvw@mail.gmail.com>
	<CADGwLpgGqNBRvwtSYKeV7pxtSvJhKk2CQVrBpv759VEgAxKOkA@mail.gmail.com>
	<CAPhbRDZ+88U5xNq24XinHQFYqU3m6ycGmSeRO5HY4amt+fU4bQ@mail.gmail.com>
Message-ID: <CADGwLphCCG3Zt8cc+Q_OO-U+MC0RBXr4e2AZhJBqT7etfvLr_Q@mail.gmail.com>

On Thu, Apr 18, 2019 at 12:41 PM Brian Stansberry <
brian.stansberry at redhat.com> wrote:

>
>
> On Thu, Apr 18, 2019 at 1:20 PM James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> It's been longer than I'd want to really get into this, but now that I've
>> got a start on it I'd like some feedback on the best way to deal with the
>> pattern attribute. For the file it currently just uses a pattern like %h
>> %l %u %t %r %s %b %{i,Referer} %{i,User-Agent}. The problem is that
>> doesn't really provide a key for the value. What I'm currently using is
>> that same pattern and using the ExchangeAttributeBuilder.getName() as
>> the key. However if the value of getName() changes at some point the
>> data would end up with a different key. This approach doesn't seem ideal.
>>
>> One option would be to switch to some kind of property format type of
>> thing like:
>>
>> attributes={"remoteHost"="%h", "identityUsername"="%l"}
>>
>> I'm not sure how user friendly that is though.
>>
>> The other option would be to limit it to known exchange attributes, but
>> that would require a change every time a new attribute is added to Undertow
>> itself or we'd have to allow for some kind of custom attribute.
>>
>
>> Any opinions are welcome. Ideally we want something user friendly that's
>> going to produce consistent keys as that would be part of the structured
>> data contract.
>>
>
> That pattern string also provides order. I suppose that's not as important
> with structured data though.
>

Yeah order doesn't seem all that important, however I do my best to keep it
in the order defined.


>
> Perhaps two alternative attributes, one that's a pattern String and then
> one that's complex like your example?  The pattern string is documented
> with the values it supports and the names of the keys it will use for those
> values. (Those keys are set in the WF code, not pulled from
> ExchangeAttributeBuilder.) If you want other key names or other values
> you have to use the complex attribute.
>

My main concern there is just that there are currently 38 possible
attribute builders in Undertow. I'm not sure if it's possible or not for a
user to provide there own attributes, but if it is we'd have to find a way
to allow for that as well. Having a limit may not necessarily be a bad
thing though.

Another kind of oddity in the pattern I forgot to mention is it allows for
constants which seems a bit weird to support in JSON. I was thinking of
just add a "constants" array or some similar name.

I suppose another benefit to not using a pattern would be the parser
wouldn't need to be copied from Undertow. However the
ExchangeAttributeBuilder does include a priority that wouldn't be respected.

For one more kludgy option we could just use the pattern and allow for
something like "remoteUser=%u" where remoteUser would be a key override and
we just have a defined set of default keys. If it's an unknown attribute to
WildFly, then a key is required. Again a bit kludgy I guess.


>
> That's kind of kludgy but it makes the hopefully common case simple.
>
>
>> On Mon, Feb 18, 2019 at 8:10 AM James Perkins <jperkins at redhat.com>
>> wrote:
>>
>>> Hello All,
>>> I've created a proposal [1] for JSON access logging. Any feedback is
>>> welcome.
>>>
>>> [1]: https://github.com/wildfly/wildfly-proposals/pull/176
>>>
>>> --
>>> James R. Perkins
>>> JBoss by Red Hat
>>>
>>
>>
>> --
>> 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
>


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190418/7259c121/attachment.html 

From rory.odonnell at oracle.com  Fri Apr 19 07:51:02 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 19 Apr 2019 12:51:02 +0100
Subject: [wildfly-dev] JDK 13 - Early Access build 17 is available
Message-ID: <56c05822-331b-0d32-8826-9398c59bbb23@oracle.com>


Hi David & Richard,

We are looking for feedback from you, does WildFly app server works with 
JDK 13 b17 ?

Thanks in advance.
**

*OpenJDK builds *- JDK 13 - Early Access build 17 is available at 
http://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 <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Changes in this build
    <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B16%22%3A%3A%22jdk-13%2B17%22-%22jdk-13%2B16%22%29&revcount=1000>
  * Release notes [1]

*Significant changes since the last availability email*

  * build 16 - Update the default enabled cipher suites preference
    (JDK-8163326 <https://bugs.openjdk.java.net/browse/JDK-8163326>)
  * build 16 - Add new keytool -showinfo -tls command for displaying TLS
    configuration information (JDK-8219861
    <https://bugs.openjdk.java.net/browse/JDK-8219861>)
  * build 15? -*New Japanese Era Name **(JDK-8205432
    <https://bugs.openjdk.java.net/browse/JDK-8205432>)*
  * build 15? - Accessing REIWA era in java.time.chrono.JapaneseEra
    (JDK-8174268 <https://bugs.openjdk.java.net/browse/JDK-8174268>)
  * build 15? - Duplicated RSA services are no longer supported by
    SunJSSE provider (JDK-8220016
    <https://bugs.openjdk.java.net/browse/JDK-8220016>)
  * build 15? - Use server cipher suites preference by default
    (JDK-8168261 <https://bugs.openjdk.java.net/browse/JDK-8168261>)
  * build 15? - The Swing Motif Look and Feel is deprecated and
    unsupported on macOS (JDK-8177960
    <https://bugs.openjdk.java.net/browse/JDK-8177960>)
  * build 15? - Remove support for javadoc "frames" mode (JDK-8215599
    <https://bugs.openjdk.java.net/browse/JDK-8215599>)

Bug fix reported by Open Source Projects? :

  * build 15? - Unable to read certain PKCS12 keystores from
    SequenceInputStream (JDK-8157404)
    <https://bugs.openjdk.java.net/browse/JDK-8157404>

*April 2019 CPU Released*

  * As part of the Apr 2019 Critical Patch Update?we released OpenJDK
    12.0.1? under the GNU General Public License, version?2, with the
    Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. [2]
  * One change previously announced in the Java Cryptographic Roadmap [3]

*Request for feedback *-? switch expressions in JDK 12? , feedback via 
amber-dev list [4]

Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] http://jdk.java.net/12
[3] https://java.com/en/jre-jdk-cryptoroadmap.html
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.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/20190419/d090ed25/attachment.html 

From brian.stansberry at redhat.com  Tue Apr 23 14:01:50 2019
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 23 Apr 2019 13:01:50 -0500
Subject: [wildfly-dev] Use of Zulip for real-time chat about WildFly
Message-ID: <CAPhbRDYpVpxtANY-dbVorNbdDXWFpFO-ukLca+uU6WiaZo=36A@mail.gmail.com>

Hi everyone,

I'm pleased to say that we've been able to complete our migration to using
Zulip for chat discussions about using and developing WildFly. Folks who
are interested in chatting about WildFly are welcome to sign up at
https://wildfly.zulipchat.com/. Kabir Khan put up a blog post today at
https://wildfly.org/news/2019/04/23/Zulip-Chat/ with further details.

My deepest thanks to those who worked on this, particularly Kabir.

Best regards,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190423/67e52ff6/attachment-0001.html 

From ropalka at redhat.com  Wed Apr 24 07:10:42 2019
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 24 Apr 2019 13:10:42 +0200
Subject: [wildfly-dev] JDK 13 - Early Access build 17 is available
In-Reply-To: <56c05822-331b-0d32-8826-9398c59bbb23@oracle.com>
References: <56c05822-331b-0d32-8826-9398c59bbb23@oracle.com>
Message-ID: <CABSyOEEDZbSBj9frQzh2bCZBnZO+Gms1P5TO9i4veO6HVwnFNQ@mail.gmail.com>

Hi Rory,

   WildFly community app server works like a charm with JDK 13 b17.

Rgds, Rio

On Fri, Apr 19, 2019 at 2:05 PM Rory O'Donnell <rory.odonnell at oracle.com>
wrote:

>
> Hi David & Richard,
>
> We are looking for feedback from you, does WildFly app server works with
> JDK 13 b17 ?
>
> Thanks in advance.
>
> *OpenJDK builds  *- JDK 13 - Early Access build 17 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
>       <http://openjdk.java.net/legal/gplv2+ce.html>.
>    - Changes in this build
>
>    <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B16%22%3A%3A%22jdk-13%2B17%22-%22jdk-13%2B16%22%29&revcount=1000>
>    - Release notes [1]
>
> *Significant changes since the last availability email*
>
>    - build 16 - Update the default enabled cipher suites preference (
>    JDK-8163326 <https://bugs.openjdk.java.net/browse/JDK-8163326>)
>    - build 16 -  Add new keytool -showinfo -tls command for displaying
>    TLS configuration information (JDK-8219861
>    <https://bugs.openjdk.java.net/browse/JDK-8219861>)
>    - build 15  -* New Japanese Era Name **(JDK-8205432
>    <https://bugs.openjdk.java.net/browse/JDK-8205432>)*
>    - build 15  - Accessing REIWA era in java.time.chrono.JapaneseEra (
>    JDK-8174268 <https://bugs.openjdk.java.net/browse/JDK-8174268>)
>    - build 15  - Duplicated RSA services are no longer supported by
>    SunJSSE provider (JDK-8220016
>    <https://bugs.openjdk.java.net/browse/JDK-8220016>)
>    - build 15  - Use server cipher suites preference by default (
>    JDK-8168261 <https://bugs.openjdk.java.net/browse/JDK-8168261>)
>    - build 15  - The Swing Motif Look and Feel is deprecated and
>    unsupported on macOS (JDK-8177960
>    <https://bugs.openjdk.java.net/browse/JDK-8177960>)
>    - build 15  - Remove support for javadoc "frames" mode (JDK-8215599
>    <https://bugs.openjdk.java.net/browse/JDK-8215599>)
>
> Bug fix reported by Open Source Projects  :
>
>    - build 15  - Unable to read certain PKCS12 keystores from
>    SequenceInputStream (JDK-8157404)
>    <https://bugs.openjdk.java.net/browse/JDK-8157404>
>
>
>
> *April 2019 CPU Released*
>
>    - As part of the Apr 2019 Critical Patch Update we released OpenJDK
>    12.0.1  under the GNU General Public License, version 2, with the
>    Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. [2]
>    - One change previously announced in the Java Cryptographic Roadmap [3]
>
> *Request for feedback *-  switch expressions in JDK 12  , feedback via
> amber-dev list [4]
>
> Rgds,Rory
> [1] http://jdk.java.net/13/release-notes
> [2] http://jdk.java.net/12
> [3] https://java.com/en/jre-jdk-cryptoroadmap.html
> [4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.html
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190424/4d27ce88/attachment.html 

From rory.odonnell at oracle.com  Wed Apr 24 07:15:29 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 24 Apr 2019 12:15:29 +0100
Subject: [wildfly-dev] JDK 13 - Early Access build 17 is available
In-Reply-To: <CABSyOEEDZbSBj9frQzh2bCZBnZO+Gms1P5TO9i4veO6HVwnFNQ@mail.gmail.com>
References: <56c05822-331b-0d32-8826-9398c59bbb23@oracle.com>
	<CABSyOEEDZbSBj9frQzh2bCZBnZO+Gms1P5TO9i4veO6HVwnFNQ@mail.gmail.com>
Message-ID: <8f5426d6-8061-14bc-857d-ccddcde1f4ca@oracle.com>

Many thanks Richard!

On 24/04/2019 12:10, Richard Opalka wrote:
> Hi Rory,
>
> ?? WildFly community app server works like a charm with JDK 13 b17.
>
> Rgds, Rio
>
> On Fri, Apr 19, 2019 at 2:05 PM Rory O'Donnell 
> <rory.odonnell at oracle.com <mailto:rory.odonnell at oracle.com>> wrote:
>
>
>     Hi David & Richard,
>
>     We are looking for feedback from you, does WildFly app server
>     works with JDK 13 b17 ?
>
>     Thanks in advance.
>     **
>
>     *OpenJDK builds *- JDK 13 - Early Access build 17 is available at
>     http://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 <http://openjdk.java.net/legal/gplv2+ce.html>.
>       * Changes in this build
>         <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B16%22%3A%3A%22jdk-13%2B17%22-%22jdk-13%2B16%22%29&revcount=1000>
>       * Release notes [1]
>
>     *Significant changes since the last availability email*
>
>       * build 16 - Update the default enabled cipher suites preference
>         (JDK-8163326 <https://bugs.openjdk.java.net/browse/JDK-8163326>)
>       * build 16 - Add new keytool -showinfo -tls command for
>         displaying TLS configuration information (JDK-8219861
>         <https://bugs.openjdk.java.net/browse/JDK-8219861>)
>       * build 15? -*New Japanese Era Name **(JDK-8205432
>         <https://bugs.openjdk.java.net/browse/JDK-8205432>)*
>       * build 15? - Accessing REIWA era in
>         java.time.chrono.JapaneseEra (JDK-8174268
>         <https://bugs.openjdk.java.net/browse/JDK-8174268>)
>       * build 15? - Duplicated RSA services are no longer supported by
>         SunJSSE provider (JDK-8220016
>         <https://bugs.openjdk.java.net/browse/JDK-8220016>)
>       * build 15? - Use server cipher suites preference by default
>         (JDK-8168261 <https://bugs.openjdk.java.net/browse/JDK-8168261>)
>       * build 15? - The Swing Motif Look and Feel is deprecated and
>         unsupported on macOS (JDK-8177960
>         <https://bugs.openjdk.java.net/browse/JDK-8177960>)
>       * build 15? - Remove support for javadoc "frames" mode
>         (JDK-8215599 <https://bugs.openjdk.java.net/browse/JDK-8215599>)
>
>     Bug fix reported by Open Source Projects? :
>
>       * build 15? - Unable to read certain PKCS12 keystores from
>         SequenceInputStream (JDK-8157404)
>         <https://bugs.openjdk.java.net/browse/JDK-8157404>
>
>     *April 2019 CPU Released*
>
>       * As part of the Apr 2019 Critical Patch Update?we released
>         OpenJDK 12.0.1? under the GNU General Public License,
>         version?2, with the Classpath Exception
>         <http://openjdk.java.net/legal/gplv2+ce.html>. [2]
>       * One change previously announced in the Java Cryptographic
>         Roadmap [3]
>
>     *Request for feedback *-? switch expressions in JDK 12? , feedback
>     via amber-dev list [4]
>
>     Rgds,Rory
>
>     [1] http://jdk.java.net/13/release-notes
>     [2] http://jdk.java.net/12
>     [3] https://java.com/en/jre-jdk-cryptoroadmap.html
>     [4]
>     https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.html
>
>     -- 
>     Rgds, Rory O'Donnell
>     Quality Engineering Manager
>     Oracle EMEA, Dublin, Ireland
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> -- 
> --
> Richard Opalka
> Principal Software Engineer
> Red Hat JBoss Middleware
> Mobile: +420 731 186 942
> E-mail: ropalka at redhat.com <mailto:ropalka at redhat.com>
>
-- 
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/20190424/e2175c7e/attachment-0001.html 

From jperkins at redhat.com  Mon Apr 29 11:22:51 2019
From: jperkins at redhat.com (James Perkins)
Date: Mon, 29 Apr 2019 08:22:51 -0700
Subject: [wildfly-dev] Dropping org.slf4j.ext Module
Message-ID: <CADGwLphXQ-8KROp7mVk_+7OBNCejJjmg8EyjhRnUVkJFUw1=pw@mail.gmail.com>

Hello All,
I'd like to propose we drop the org.slf4j.ext module [1]. Currently no
other modules depend on this module.

Does anyone have any objections to this?

[1]: https://issues.jboss.org/browse/WFCORE-4455

-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190429/24c5fbd9/attachment.html 

From fjuma at redhat.com  Mon Apr 29 15:26:24 2019
From: fjuma at redhat.com (Farah Juma)
Date: Mon, 29 Apr 2019 15:26:24 -0400
Subject: [wildfly-dev] [WFCORE-4361] Proposal on enhanced mapping of an
 X509Certificate to an underlying identity
Message-ID: <CAFv3guScr6ct3cPDjewFnoGejgn=T10Z-Hzkz9Ge5W3CXdQ2hQ@mail.gmail.com>

Hi,

I've created a proposal on enhanced mapping of an X509Certificate to an
underlying identity:

https://github.com/wildfly/wildfly-proposals/pull/203

Any feedback is welcome.

Thanks,
Farah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190429/770118a8/attachment.html