From david.lloyd at redhat.com  Sat Apr  1 15:01:41 2017
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Sat, 1 Apr 2017 14:01:41 -0500
Subject: [wildfly-dev] Version notifications at library init
In-Reply-To: <FC6010AA-CD33-4E06-AA8F-4A98AC70675F@redhat.com>
References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com>
	<84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com>
	<79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com>
	<DB017D97-2267-4CBF-9E60-DD80F8248420@redhat.com>
	<776883949.16589109.1490787897418.JavaMail.zimbra@redhat.com>
	<FC6010AA-CD33-4E06-AA8F-4A98AC70675F@redhat.com>
Message-ID: <b89786bc-b204-0522-bca1-9053e1c093d2@redhat.com>

On 03/29/2017 06:57 AM, Brian Stansberry wrote:
>
>> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <rsvoboda at redhat.com> wrote:
>>
>>
>>> Some existing ids would need to change to comply but that doesn?t seem like
>>> a big deal.
>>
>> Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs.
>>
>
> I think the likelihood that people are relying on parsing out our version # messages is really low. If they did a convention of reserving 0 for these might be a benefit for them too.
>
> Here?s what we log now (standalone-full-ha.xml):
>
> 06:49:15,205 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6
> 06:49:15,503 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1
> 06:49:15,638 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting
> 06:49:16,987 INFO  [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001: WildFly Elytron version 1.1.0.Beta33
> 06:49:17,202 INFO  [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2
> 06:49:17,208 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.5.0.Beta2
> 06:49:17,238 INFO  [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016: RESTEasy version 3.0.21.Final
> 06:49:17,271 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13
> 06:49:17,392 INFO  [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Beta1
> 06:49:17,407 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003: Undertow 1.4.11.Final starting
> 06:49:17,409 INFO  [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final)
> 06:49:17,705 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.0.Beta19
> 06:49:18,544 INFO  [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10)
>
> 8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final ?started? message is more likely what would be monitored and it shows the versions too.

It's even more now if you have a deployment, since many libraries are 
only initialized once applications begin using them.

-- 
- DML

From stuart.w.douglas at gmail.com  Sun Apr  2 21:45:59 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 3 Apr 2017 11:45:59 +1000
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
Message-ID: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>

Hi,

So this is a minor issue, but it annoys me so I thought I would see what
other people think about it. In the test suite I have noticed that some new
code is being added under the org.wildfly package, even though all the
existing code is still under org.jboss.as.

I don't think this is a good idea, as it means there is two potential
places to look for something, with no real reason why something is in a
particular package other than the date it was added.

I propose that we move all the org.wildfly code into org.jboss.as to keep
everything consistent (moving everything to org.wildfly would also be an
option, but it has implications for backporting and has the potential to
create a lot more work).

Does anyone have any objections to this? If not I will prepare some PR's.

Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170403/b9b03f34/attachment.html 

From darran.lofthouse at jboss.com  Mon Apr  3 05:18:35 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 3 Apr 2017 10:18:35 +0100
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
Message-ID: <4677171c-e442-52ac-0e3a-ee0a18a53abd@jboss.com>

Is this just for code added to existing testsuite projects or new 
projects as well?

If the latter may be better to coordinate a suitable time with Kabir a 
change like this could be applied.

Regards,
Darran Lofthouse.



On 03/04/17 02:45, Stuart Douglas wrote:
> Hi,
>
> So this is a minor issue, but it annoys me so I thought I would see what
> other people think about it. In the test suite I have noticed that some
> new code is being added under the org.wildfly package, even though all
> the existing code is still under org.jboss.as <http://org.jboss.as>.
>
> I don't think this is a good idea, as it means there is two potential
> places to look for something, with no real reason why something is in a
> particular package other than the date it was added.
>
> I propose that we move all the org.wildfly code into org.jboss.as
> <http://org.jboss.as> to keep everything consistent (moving everything
> to org.wildfly would also be an option, but it has implications for
> backporting and has the potential to create a lot more work).
>
> Does anyone have any objections to this? If not I will prepare some PR's.
>
> Stuart
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From stuart.w.douglas at gmail.com  Mon Apr  3 05:32:25 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 3 Apr 2017 19:32:25 +1000
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <4677171c-e442-52ac-0e3a-ee0a18a53abd@jboss.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<4677171c-e442-52ac-0e3a-ee0a18a53abd@jboss.com>
Message-ID: <CAAoo=c6s2QDD8d4xB2wWOYGhnoEcu0ne9Ot0jZjoEbGRuK8OjA@mail.gmail.com>

I mean for maven modules in the Wildfly code base that were using the
org.jboss.as package, and are now using a mix of the two.

Stuart

On Mon, Apr 3, 2017 at 7:18 PM, Darran Lofthouse <darran.lofthouse at jboss.com
> wrote:

> Is this just for code added to existing testsuite projects or new projects
> as well?
>
> If the latter may be better to coordinate a suitable time with Kabir a
> change like this could be applied.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On 03/04/17 02:45, Stuart Douglas wrote:
>
>> Hi,
>>
>> So this is a minor issue, but it annoys me so I thought I would see what
>> other people think about it. In the test suite I have noticed that some
>> new code is being added under the org.wildfly package, even though all
>> the existing code is still under org.jboss.as <http://org.jboss.as>.
>>
>> I don't think this is a good idea, as it means there is two potential
>> places to look for something, with no real reason why something is in a
>> particular package other than the date it was added.
>>
>> I propose that we move all the org.wildfly code into org.jboss.as
>> <http://org.jboss.as> to keep everything consistent (moving everything
>> to org.wildfly would also be an option, but it has implications for
>> backporting and has the potential to create a lot more work).
>>
>> Does anyone have any objections to this? If not I will prepare some PR's.
>>
>> Stuart
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170403/946debeb/attachment.html 

From dandread at redhat.com  Mon Apr  3 11:16:53 2017
From: dandread at redhat.com (Dimitris Andreadis)
Date: Mon, 3 Apr 2017 18:16:53 +0300
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <CAAoo=c6s2QDD8d4xB2wWOYGhnoEcu0ne9Ot0jZjoEbGRuK8OjA@mail.gmail.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<4677171c-e442-52ac-0e3a-ee0a18a53abd@jboss.com>
	<CAAoo=c6s2QDD8d4xB2wWOYGhnoEcu0ne9Ot0jZjoEbGRuK8OjA@mail.gmail.com>
Message-ID: <d0d305c7-e10e-7dd8-ad2e-831a5cd0f192@redhat.com>

Be careful of backwards compatibility!

On 03/04/2017 12:32, Stuart Douglas wrote:
> I mean for maven modules in the Wildfly code base that were using the
> org.jboss.as <http://org.jboss.as> package, and are now using a mix of
> the two.
>
> Stuart
>
> On Mon, Apr 3, 2017 at 7:18 PM, Darran Lofthouse
> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>
>     Is this just for code added to existing testsuite projects or new
>     projects as well?
>
>     If the latter may be better to coordinate a suitable time with Kabir
>     a change like this could be applied.
>
>     Regards,
>     Darran Lofthouse.
>
>
>
>     On 03/04/17 02:45, Stuart Douglas wrote:
>
>         Hi,
>
>         So this is a minor issue, but it annoys me so I thought I would
>         see what
>         other people think about it. In the test suite I have noticed
>         that some
>         new code is being added under the org.wildfly package, even
>         though all
>         the existing code is still under org.jboss.as
>         <http://org.jboss.as> <http://org.jboss.as>.
>
>         I don't think this is a good idea, as it means there is two
>         potential
>         places to look for something, with no real reason why something
>         is in a
>         particular package other than the date it was added.
>
>         I propose that we move all the org.wildfly code into
>         org.jboss.as <http://org.jboss.as>
>         <http://org.jboss.as> to keep everything consistent (moving
>         everything
>         to org.wildfly would also be an option, but it has implications for
>         backporting and has the potential to create a lot more work).
>
>         Does anyone have any objections to this? If not I will prepare
>         some PR's.
>
>         Stuart
>
>
>         _______________________________________________
>         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>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From brian.stansberry at redhat.com  Mon Apr  3 11:57:55 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 3 Apr 2017 10:57:55 -0500
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <d0d305c7-e10e-7dd8-ad2e-831a5cd0f192@redhat.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<4677171c-e442-52ac-0e3a-ee0a18a53abd@jboss.com>
	<CAAoo=c6s2QDD8d4xB2wWOYGhnoEcu0ne9Ot0jZjoEbGRuK8OjA@mail.gmail.com>
	<d0d305c7-e10e-7dd8-ad2e-831a5cd0f192@redhat.com>
Message-ID: <3E9B1A1E-C04B-4B1B-A109-6AA9965119E6@redhat.com>


> On Apr 3, 2017, at 10:16 AM, Dimitris Andreadis <dandread at redhat.com> wrote:
> 
> Be careful of backwards compatibility!
> 

Particularly with testsuite/shared in core. Best leave that alone.

Other testsuite modules shouldn?t be being used anywhere outside their own code base so breaking stuff is less of a concern.

>From Stuart?s original post I believe this is only about testsuite.

> On 03/04/2017 12:32, Stuart Douglas wrote:
>> I mean for maven modules in the Wildfly code base that were using the
>> org.jboss.as <http://org.jboss.as> package, and are now using a mix of
>> the two.
>> 
>> Stuart
>> 
>> On Mon, Apr 3, 2017 at 7:18 PM, Darran Lofthouse
>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>> 
>>    Is this just for code added to existing testsuite projects or new
>>    projects as well?
>> 
>>    If the latter may be better to coordinate a suitable time with Kabir
>>    a change like this could be applied.
>> 
>>    Regards,
>>    Darran Lofthouse.
>> 
>> 
>> 
>>    On 03/04/17 02:45, Stuart Douglas wrote:
>> 
>>        Hi,
>> 
>>        So this is a minor issue, but it annoys me so I thought I would
>>        see what
>>        other people think about it. In the test suite I have noticed
>>        that some
>>        new code is being added under the org.wildfly package, even
>>        though all
>>        the existing code is still under org.jboss.as
>>        <http://org.jboss.as> <http://org.jboss.as>.
>> 
>>        I don't think this is a good idea, as it means there is two
>>        potential
>>        places to look for something, with no real reason why something
>>        is in a
>>        particular package other than the date it was added.
>> 
>>        I propose that we move all the org.wildfly code into
>>        org.jboss.as <http://org.jboss.as>
>>        <http://org.jboss.as> to keep everything consistent (moving
>>        everything
>>        to org.wildfly would also be an option, but it has implications for
>>        backporting and has the potential to create a lot more work).
>> 
>>        Does anyone have any objections to this? If not I will prepare
>>        some PR's.
>> 
>>        Stuart
>> 
>> 
>>        _______________________________________________
>>        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>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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
JBoss by Red Hat





From ropalka at redhat.com  Wed Apr  5 16:52:32 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 5 Apr 2017 22:52:32 +0200
Subject: [wildfly-dev] [JBEAP-10083][MODULES-282] blocking EAP migration
	testing
Message-ID: <e0feaa42-d853-f505-0642-0845d9f3e04a@redhat.com>

Hi David & Peter,


    MODULES-241 fix appeared in EAP these days

and it introduced new regression - see [JBEAP-10083] comments.

    We have three possibilities at the moment:

  * Option 1) Revert [MODULES-241] commit completely

  * Option 2) Partially revert [MODULES-241] and bring in the hacky 
solution I proposed some time ago

    (see proposal branch: 
https://github.com/ropalka/jboss-modules/commits/MODULES-282)

  * Option 3) Provide a proper fix (we don't have it ATM)


I would guess Peter was working on the solution to solve some customer 
problem, right?

If we don't come with Option 3) solution on tomorrow then

I'd propose to go with Option 2) for now (I just verified locally it 
solves the migration problem

identified by QA and it fixes - although in an ugly way - the original 
issue).

Let me know what do you think?



Richard

PS: I'm going to reason about Option 3) now ...



From ropalka at redhat.com  Wed Apr  5 16:54:26 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 5 Apr 2017 22:54:26 +0200
Subject: [wildfly-dev] [JBEAP-10083][MODULES-282] blocking EAP migration
	testing
In-Reply-To: <e0feaa42-d853-f505-0642-0845d9f3e04a@redhat.com>
References: <e0feaa42-d853-f505-0642-0845d9f3e04a@redhat.com>
Message-ID: <375257d8-785f-34b6-5b93-90f6df671c9c@redhat.com>

Ooops, I forgot to delete wildfly-dev mailing list - sorry for the spam 
everybody.

Rio


On 04/05/2017 10:52 PM, Richard Opalka wrote:
> Hi David & Peter,
>
>
>    MODULES-241 fix appeared in EAP these days
>
> and it introduced new regression - see [JBEAP-10083] comments.
>
>    We have three possibilities at the moment:
>
>  * Option 1) Revert [MODULES-241] commit completely
>
>  * Option 2) Partially revert [MODULES-241] and bring in the hacky 
> solution I proposed some time ago
>
>    (see proposal branch: 
> https://github.com/ropalka/jboss-modules/commits/MODULES-282)
>
>  * Option 3) Provide a proper fix (we don't have it ATM)
>
>
> I would guess Peter was working on the solution to solve some customer 
> problem, right?
>
> If we don't come with Option 3) solution on tomorrow then
>
> I'd propose to go with Option 2) for now (I just verified locally it 
> solves the migration problem
>
> identified by QA and it fixes - although in an ugly way - the original 
> issue).
>
> Let me know what do you think?
>
>
>
> Richard
>
> PS: I'm going to reason about Option 3) now ...
>
>


From jcacek at redhat.com  Thu Apr  6 02:56:52 2017
From: jcacek at redhat.com (Josef Cacek)
Date: Thu, 6 Apr 2017 02:56:52 -0400 (EDT)
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
Message-ID: <1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>

I think, Tomaz should share his view (CC-ing)

During our discussion related to Elytron testing, his preference was to use org.wildfly package names.

-- Josef

----- Original Message -----
> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Monday, April 3, 2017 3:45:59 AM
> Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
> 
> Hi,
> 
> So this is a minor issue, but it annoys me so I thought I would see what
> other people think about it. In the test suite I have noticed that some new
> code is being added under the org.wildfly package, even though all the
> existing code is still under org.jboss.as .
> 
> I don't think this is a good idea, as it means there is two potential places
> to look for something, with no real reason why something is in a particular
> package other than the date it was added.
> 
> I propose that we move all the org.wildfly code into org.jboss.as to keep
> everything consistent (moving everything to org.wildfly would also be an
> option, but it has implications for backporting and has the potential to
> create a lot more work).
> 
> Does anyone have any objections to this? If not I will prepare some PR's.
> 
> Stuart
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From kabir.khan at jboss.com  Thu Apr  6 06:06:27 2017
From: kabir.khan at jboss.com (Kabir Khan)
Date: Thu, 6 Apr 2017 11:06:27 +0100
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>
Message-ID: <F24A7065-4C3D-49C4-A0EC-1E95B643A8E1@jboss.com>

If you are specifically talking about the testsuite/elytron module, I believe we can leave those under org.wildfly.test.integration.elytron. Stuart's gripe, as I read it, is mixing of the two packages within a module.
> On 6 Apr 2017, at 07:56, Josef Cacek <jcacek at redhat.com> wrote:
> 
> I think, Tomaz should share his view (CC-ing)
> 
> During our discussion related to Elytron testing, his preference was to use org.wildfly package names.
> 
> -- Josef
> 
> ----- Original Message -----
>> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> To: wildfly-dev at lists.jboss.org
>> Sent: Monday, April 3, 2017 3:45:59 AM
>> Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
>> 
>> Hi,
>> 
>> So this is a minor issue, but it annoys me so I thought I would see what
>> other people think about it. In the test suite I have noticed that some new
>> code is being added under the org.wildfly package, even though all the
>> existing code is still under org.jboss.as .
>> 
>> I don't think this is a good idea, as it means there is two potential places
>> to look for something, with no real reason why something is in a particular
>> package other than the date it was added.
>> 
>> I propose that we move all the org.wildfly code into org.jboss.as to keep
>> everything consistent (moving everything to org.wildfly would also be an
>> option, but it has implications for backporting and has the potential to
>> create a lot more work).
>> 
>> Does anyone have any objections to this? If not I will prepare some PR's.
>> 
>> Stuart
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From darran.lofthouse at jboss.com  Thu Apr  6 10:50:26 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 6 Apr 2017 15:50:26 +0100
Subject: [wildfly-dev] Elytron Test Profiles and PRs
Message-ID: <0b35d893-7447-5cd6-8556-ce8b295a4bbd@jboss.com>

Hello,

I have some PRs in the queue regarding additional Elytron testing in 
custom test runs so I just wanted to double check we are happy with the 
current strategy so I can continue merging.

Firstly as was discussed previously we have the new module in the 
testsuite that has Elytron specific tests added to it, this is executed 
as part of normal builds so regressions covered by these tests are 
fairly easy to pick up.

Secondly we have an option to run the WildFly build with -Delytron, by 
doing this some tests are automatically ignored but the testing now 
switches the configuration of the server for existing tests to configure 
the server to fully use an Elytron based configuration instead of the 
default legacy configuration.

The PR process has also been updated so now when you submit PRs against 
WildFly you don't just get an allTests run, in parallel you also get a 
-Delytron run potentially picking up regressions that would not be 
detected by the allTests run.

It probably is worth pointing out that although this additional testing 
is not picked up in an allTests run engineers are also likely used to 
skipping both the security manager tests locally and the tests for the 
operating system they don't use for development.

Regards,
Darran Lofthouse.

From jason.greene at redhat.com  Thu Apr  6 12:38:50 2017
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 6 Apr 2017 12:38:50 -0400 (EDT)
Subject: [wildfly-dev] Elytron Test Profiles and PRs
In-Reply-To: <0b35d893-7447-5cd6-8556-ce8b295a4bbd@jboss.com>
References: <0b35d893-7447-5cd6-8556-ce8b295a4bbd@jboss.com>
Message-ID: <9C5C9B3A-A157-4E82-8ED7-04A4B7698168@redhat.com>

+1

> On Apr 6, 2017, at 11:01 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> Hello,
> 
> I have some PRs in the queue regarding additional Elytron testing in 
> custom test runs so I just wanted to double check we are happy with the 
> current strategy so I can continue merging.
> 
> Firstly as was discussed previously we have the new module in the 
> testsuite that has Elytron specific tests added to it, this is executed 
> as part of normal builds so regressions covered by these tests are 
> fairly easy to pick up.
> 
> Secondly we have an option to run the WildFly build with -Delytron, by 
> doing this some tests are automatically ignored but the testing now 
> switches the configuration of the server for existing tests to configure 
> the server to fully use an Elytron based configuration instead of the 
> default legacy configuration.
> 
> The PR process has also been updated so now when you submit PRs against 
> WildFly you don't just get an allTests run, in parallel you also get a 
> -Delytron run potentially picking up regressions that would not be 
> detected by the allTests run.
> 
> It probably is worth pointing out that although this additional testing 
> is not picked up in an allTests run engineers are also likely used to 
> skipping both the security manager tests locally and the tests for the 
> operating system they don't use for development.
> 
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From stuart.w.douglas at gmail.com  Thu Apr  6 17:12:56 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 7 Apr 2017 07:12:56 +1000
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <F24A7065-4C3D-49C4-A0EC-1E95B643A8E1@jboss.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>
	<F24A7065-4C3D-49C4-A0EC-1E95B643A8E1@jboss.com>
Message-ID: <CAAoo=c7n1+UbaGAv54b6TY42kYpb3rycmC+84sxUT52PsUdA8g@mail.gmail.com>

Yes, I am only talking about existing test suite modules that are already
using the org.jboss.as package.

For example in integration/basic we now have
'org.wildfly.test.integration.ejb' and 'org.jboss.as.test.integration.ejb',
which are logically the same package, but now you have two different places
to look for ejb tests.

Stuart

On Thu, Apr 6, 2017 at 8:06 PM, Kabir Khan <kabir.khan at jboss.com> wrote:

> If you are specifically talking about the testsuite/elytron module, I
> believe we can leave those under org.wildfly.test.integration.elytron.
> Stuart's gripe, as I read it, is mixing of the two packages within a module.
> > On 6 Apr 2017, at 07:56, Josef Cacek <jcacek at redhat.com> wrote:
> >
> > I think, Tomaz should share his view (CC-ing)
> >
> > During our discussion related to Elytron testing, his preference was to
> use org.wildfly package names.
> >
> > -- Josef
> >
> > ----- Original Message -----
> >> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
> >> To: wildfly-dev at lists.jboss.org
> >> Sent: Monday, April 3, 2017 3:45:59 AM
> >> Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
> >>
> >> Hi,
> >>
> >> So this is a minor issue, but it annoys me so I thought I would see what
> >> other people think about it. In the test suite I have noticed that some
> new
> >> code is being added under the org.wildfly package, even though all the
> >> existing code is still under org.jboss.as .
> >>
> >> I don't think this is a good idea, as it means there is two potential
> places
> >> to look for something, with no real reason why something is in a
> particular
> >> package other than the date it was added.
> >>
> >> I propose that we move all the org.wildfly code into org.jboss.as to
> keep
> >> everything consistent (moving everything to org.wildfly would also be an
> >> option, but it has implications for backporting and has the potential to
> >> create a lot more work).
> >>
> >> Does anyone have any objections to this? If not I will prepare some
> PR's.
> >>
> >> Stuart
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170407/667e049b/attachment-0001.html 

From rory.odonnell at oracle.com  Fri Apr  7 05:34:04 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 7 Apr 2017 10:34:04 +0100
Subject: [wildfly-dev] JDK 9 Developer Preview is now available on java.net
Message-ID: <f3681ebf-b8cc-75aa-6c7d-f9be2a42254a@oracle.com>

Hi Jason/Tomaz,


      *JDK 9 Developer Preview is now available on java.net [1]
      *

Developer Preview milestone: - A reasonably stable build suitable for 
broad testing by the developer community is available.
JDK 9 Builds 163 and higher include all planned features.


*Attention annotation processing users and authors - * Request for 
feedback on annotation processing API changes made in JDK 9.

As has been done previously during Java SE 7 and Java SE 8, the JSR 269 
annotation processing API is undergoing a maintenance review (MR) as 
part of Java SE 9. Details of the changes in JDK 9 Early Access build 
163 & build 164 available here [2]

Please report experiences running processors under JDK 9 and feedback on 
the API changes to the compiler-dev mailing list.
(If you haven?t already subscribed to that list then please do so first, 
otherwise your message will be discarded as spam.)


Rgds, Rory

[1] https://jdk9.java.net/download/
[2] 
http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010896.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170407/66ad0b4e/attachment.html 

From tomaz.cerar at gmail.com  Fri Apr  7 07:23:33 2017
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 7 Apr 2017 13:23:33 +0200
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <CAAoo=c7n1+UbaGAv54b6TY42kYpb3rycmC+84sxUT52PsUdA8g@mail.gmail.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>
	<F24A7065-4C3D-49C4-A0EC-1E95B643A8E1@jboss.com>
	<CAAoo=c7n1+UbaGAv54b6TY42kYpb3rycmC+84sxUT52PsUdA8g@mail.gmail.com>
Message-ID: <CAMquZP5qfbLxRBJiq1BHmUYY+NYURSf9N-njr5qc7Zji9_Nm=A@mail.gmail.com>

Well I am all for using new packages and don't mind mixing them.

I consider org.jboss.as.testsuite.* packages as legacy and ridden with
problems as they usually contain most problematic testsuite code that
should need deeper look into,
I know that is not 100% accurate but still holds up to a point.

Said all that, I do agree that if same test functionality already exists in
either parent package it should stay there,
or if new stuff is added and author wants to add it to new package, it
should also result in migrating all other classes into same package.


--
tomaz


On Thu, Apr 6, 2017 at 11:12 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> Yes, I am only talking about existing test suite modules that are already
> using the org.jboss.as package.
>
> For example in integration/basic we now have 'org.wildfly.test.integration.ejb'
> and 'org.jboss.as.test.integration.ejb', which are logically the same
> package, but now you have two different places to look for ejb tests.
>
> Stuart
>
> On Thu, Apr 6, 2017 at 8:06 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>
>> If you are specifically talking about the testsuite/elytron module, I
>> believe we can leave those under org.wildfly.test.integration.elytron.
>> Stuart's gripe, as I read it, is mixing of the two packages within a module.
>> > On 6 Apr 2017, at 07:56, Josef Cacek <jcacek at redhat.com> wrote:
>> >
>> > I think, Tomaz should share his view (CC-ing)
>> >
>> > During our discussion related to Elytron testing, his preference was to
>> use org.wildfly package names.
>> >
>> > -- Josef
>> >
>> > ----- Original Message -----
>> >> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> >> To: wildfly-dev at lists.jboss.org
>> >> Sent: Monday, April 3, 2017 3:45:59 AM
>> >> Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
>> >>
>> >> Hi,
>> >>
>> >> So this is a minor issue, but it annoys me so I thought I would see
>> what
>> >> other people think about it. In the test suite I have noticed that
>> some new
>> >> code is being added under the org.wildfly package, even though all the
>> >> existing code is still under org.jboss.as .
>> >>
>> >> I don't think this is a good idea, as it means there is two potential
>> places
>> >> to look for something, with no real reason why something is in a
>> particular
>> >> package other than the date it was added.
>> >>
>> >> I propose that we move all the org.wildfly code into org.jboss.as to
>> keep
>> >> everything consistent (moving everything to org.wildfly would also be
>> an
>> >> option, but it has implications for backporting and has the potential
>> to
>> >> create a lot more work).
>> >>
>> >> Does anyone have any objections to this? If not I will prepare some
>> PR's.
>> >>
>> >> Stuart
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> 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/20170407/211c61b5/attachment.html 

From stuart.w.douglas at gmail.com  Sun Apr  9 19:10:14 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 10 Apr 2017 09:10:14 +1000
Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
In-Reply-To: <CAMquZP5qfbLxRBJiq1BHmUYY+NYURSf9N-njr5qc7Zji9_Nm=A@mail.gmail.com>
References: <CAAoo=c4O19ZsXwjtu12metE85XE4i+yu=705xXKyYHYgBbSxFw@mail.gmail.com>
	<1540200197.11464349.1491461812210.JavaMail.zimbra@redhat.com>
	<F24A7065-4C3D-49C4-A0EC-1E95B643A8E1@jboss.com>
	<CAAoo=c7n1+UbaGAv54b6TY42kYpb3rycmC+84sxUT52PsUdA8g@mail.gmail.com>
	<CAMquZP5qfbLxRBJiq1BHmUYY+NYURSf9N-njr5qc7Zji9_Nm=A@mail.gmail.com>
Message-ID: <CAAoo=c6dnvugnd2LBzC7sa62LADQ9261s=4Hto1TtMcavrNg=w@mail.gmail.com>

On Fri, Apr 7, 2017 at 9:23 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Well I am all for using new packages and don't mind mixing them.
>
> I consider org.jboss.as.testsuite.* packages as legacy and ridden with
> problems as they usually contain most problematic testsuite code that
> should need deeper look into,
> I know that is not 100% accurate but still holds up to a point.
>

That is because 99% of the tests are in org.jboss.as, so of course it has
the problematic tests as well.


>
> Said all that, I do agree that if same test functionality already exists
> in either parent package it should stay there,
> or if new stuff is added and author wants to add it to new package, it
> should also result in migrating all other classes into same package.
>

Moving existing tests to org.wildfly can be problematic, as is makes
backporting more difficult.

Stuart


>
>
> --
> tomaz
>
>
> On Thu, Apr 6, 2017 at 11:12 PM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Yes, I am only talking about existing test suite modules that are already
>> using the org.jboss.as package.
>>
>> For example in integration/basic we now have
>> 'org.wildfly.test.integration.ejb' and 'org.jboss.as.test.integration.ejb',
>> which are logically the same package, but now you have two different places
>> to look for ejb tests.
>>
>> Stuart
>>
>> On Thu, Apr 6, 2017 at 8:06 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>>
>>> If you are specifically talking about the testsuite/elytron module, I
>>> believe we can leave those under org.wildfly.test.integration.elytron.
>>> Stuart's gripe, as I read it, is mixing of the two packages within a module.
>>> > On 6 Apr 2017, at 07:56, Josef Cacek <jcacek at redhat.com> wrote:
>>> >
>>> > I think, Tomaz should share his view (CC-ing)
>>> >
>>> > During our discussion related to Elytron testing, his preference was
>>> to use org.wildfly package names.
>>> >
>>> > -- Josef
>>> >
>>> > ----- Original Message -----
>>> >> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
>>> >> To: wildfly-dev at lists.jboss.org
>>> >> Sent: Monday, April 3, 2017 3:45:59 AM
>>> >> Subject: [wildfly-dev] Mixing org.jboss.as and org.wildfly packages
>>> >>
>>> >> Hi,
>>> >>
>>> >> So this is a minor issue, but it annoys me so I thought I would see
>>> what
>>> >> other people think about it. In the test suite I have noticed that
>>> some new
>>> >> code is being added under the org.wildfly package, even though all the
>>> >> existing code is still under org.jboss.as .
>>> >>
>>> >> I don't think this is a good idea, as it means there is two potential
>>> places
>>> >> to look for something, with no real reason why something is in a
>>> particular
>>> >> package other than the date it was added.
>>> >>
>>> >> I propose that we move all the org.wildfly code into org.jboss.as to
>>> keep
>>> >> everything consistent (moving everything to org.wildfly would also be
>>> an
>>> >> option, but it has implications for backporting and has the potential
>>> to
>>> >> create a lot more work).
>>> >>
>>> >> Does anyone have any objections to this? If not I will prepare some
>>> PR's.
>>> >>
>>> >> Stuart
>>> >>
>>> >> _______________________________________________
>>> >> wildfly-dev mailing list
>>> >> wildfly-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> _______________________________________________
>> 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/20170410/01eef7bf/attachment-0001.html 

From ppalaga at redhat.com  Mon Apr 10 04:50:02 2017
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 10 Apr 2017 10:50:02 +0200
Subject: [wildfly-dev] Maven 3.5.0 - any known issues?
Message-ID: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>

Hi *,

as you may have noticed, Maven 3.5.0 has been released recently.

While having a colored console output is nice `mvn clean install 
-DskipTests` works, are there any issues/reasons known already why Maven 
3.5.0 should not be used for building WildFly & Co.?

Going through the relnotes [1] I found two potential sources of issues:

(1) Replaced Eclipse Aether with Maven Resolver - this will perhaps 
change the resolution in some cases.

(2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in 
our code at all?

[1] https://maven.apache.org/docs/3.5.0/release-notes.html

Thanks,

Peter

From ingo at redhat.com  Mon Apr 10 05:13:18 2017
From: ingo at redhat.com (Ingo Weiss)
Date: Mon, 10 Apr 2017 10:13:18 +0100
Subject: [wildfly-dev] Maven 3.5.0 - any known issues?
In-Reply-To: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>
References: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>
Message-ID: <20170410091318.evofbz6hwtmo4pi3@frankc.local>

On 2017-04-10 10:50:02+0200, Peter Palaga wrote:
> Hi *,
> 
> as you may have noticed, Maven 3.5.0 has been released recently.
> 
> While having a colored console output is nice `mvn clean install 
> -DskipTests` works, are there any issues/reasons known already why Maven 
> 3.5.0 should not be used for building WildFly & Co.?
> 
> Going through the relnotes [1] I found two potential sources of issues:
> 
> (1) Replaced Eclipse Aether with Maven Resolver - this will perhaps 
> change the resolution in some cases.
> 
> (2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in 
> our code at all?
> 
> [1] https://maven.apache.org/docs/3.5.0/release-notes.html
> 
> Thanks,
> 
> Peter
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

I ran a full mvn clean install on WildFly yesterday without issues.

-- 
Ingo Weiss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170410/67017a6d/attachment.bin 

From tomaz.cerar at gmail.com  Mon Apr 10 05:19:13 2017
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 10 Apr 2017 11:19:13 +0200
Subject: [wildfly-dev] Maven 3.5.0 - any known issues?
In-Reply-To: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>
References: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>
Message-ID: <CAMquZP6W0MwMCTaSgmhC9sZBs9H-Vb7ZzRUcNUH7AzPpJ+cQ5Q@mail.gmail.com>

There are no, up front known issues with maven 3.5,

there are few issues they fixed that will come on handy for us.

But moving WildFly build to require 3.5, is bit to early to say.
It at least needs some ground testing before we move to that.

As about your two questions.

1) maven resolver is just re-branded name aether project with some extra
fixes on top of it.
project has moved back to maven umbrella from eclipse one which is a good
thing as fixes can be more rapid.

2) we don't use ejb3 packaging, quickstarts use maven-ejb-plugin but that
is still there and fine.


My suggestion would be that developers on the team move to maven 3.5 as
soon as convenient,
and if no major problems are found after a while of usage we can start
discussing about requiring it.

In similar fashion we can start testing / moving to 3.5 on CI as well.

--
tomaz




On Mon, Apr 10, 2017 at 10:50 AM, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi *,
>
> as you may have noticed, Maven 3.5.0 has been released recently.
>
> While having a colored console output is nice `mvn clean install
> -DskipTests` works, are there any issues/reasons known already why Maven
> 3.5.0 should not be used for building WildFly & Co.?
>
> Going through the relnotes [1] I found two potential sources of issues:
>
> (1) Replaced Eclipse Aether with Maven Resolver - this will perhaps
> change the resolution in some cases.
>
> (2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in
> our code at all?
>
> [1] https://maven.apache.org/docs/3.5.0/release-notes.html
>
> Thanks,
>
> Peter
> _______________________________________________
> 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/20170410/253cce0f/attachment.html 

From ppalaga at redhat.com  Mon Apr 10 06:12:08 2017
From: ppalaga at redhat.com (Peter Palaga)
Date: Mon, 10 Apr 2017 12:12:08 +0200
Subject: [wildfly-dev] Maven 3.5.0 - any known issues?
In-Reply-To: <CAMquZP6W0MwMCTaSgmhC9sZBs9H-Vb7ZzRUcNUH7AzPpJ+cQ5Q@mail.gmail.com>
References: <7c69592b-7b1e-a655-6cb8-2a79b8715ead@redhat.com>
	<CAMquZP6W0MwMCTaSgmhC9sZBs9H-Vb7ZzRUcNUH7AzPpJ+cQ5Q@mail.gmail.com>
Message-ID: <cd8e12f4-a547-7c88-4964-da916a40b9e1@redhat.com>

Thanks for the feedback! I fully agree that devs should upgrade 
individually as it suits them and that we should consider upgrading the 
official recommendation only when there is enough certainty that it does 
not break anything and when it suits the schedule. -- P

On 04/10/2017 11:19 AM, Toma? Cerar wrote:
> There are no, up front known issues with maven 3.5,
>
> there are few issues they fixed that will come on handy for us.
>
> But moving WildFly build to require 3.5, is bit to early to say.
> It at least needs some ground testing before we move to that.
>
> As about your two questions.
>
> 1) maven resolver is just re-branded name aether project with some extra
> fixes on top of it.
> project has moved back to maven umbrella from eclipse one which is a
> good thing as fixes can be more rapid.
>
> 2) we don't use ejb3 packaging, quickstarts use maven-ejb-plugin but
> that is still there and fine.
>
>
> My suggestion would be that developers on the team move to maven 3.5 as
> soon as convenient,
> and if no major problems are found after a while of usage we can start
> discussing about requiring it.
>
> In similar fashion we can start testing / moving to 3.5 on CI as well.
>
> --
> tomaz
>
>
>
>
> On Mon, Apr 10, 2017 at 10:50 AM, Peter Palaga <ppalaga at redhat.com
> <mailto:ppalaga at redhat.com>> wrote:
>
>     Hi *,
>
>     as you may have noticed, Maven 3.5.0 has been released recently.
>
>     While having a colored console output is nice `mvn clean install
>     -DskipTests` works, are there any issues/reasons known already why Maven
>     3.5.0 should not be used for building WildFly & Co.?
>
>     Going through the relnotes [1] I found two potential sources of issues:
>
>     (1) Replaced Eclipse Aether with Maven Resolver - this will perhaps
>     change the resolution in some cases.
>
>     (2) Removed the artifact handler for ejb3 - do we use ejb3 packaging in
>     our code at all?
>
>     [1] https://maven.apache.org/docs/3.5.0/release-notes.html
>     <https://maven.apache.org/docs/3.5.0/release-notes.html>
>
>     Thanks,
>
>     Peter
>     _______________________________________________
>     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>
>
>


From brian.stansberry at redhat.com  Wed Apr 12 11:34:37 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 12 Apr 2017 10:34:37 -0500
Subject: [wildfly-dev] Approving PRs
Message-ID: <8D1938E7-6797-4B0A-ADA4-C52FCA356912@redhat.com>

If you review a PR and it?s good, please use the Git Hub review feature to say so instead of just leaving a comment. That makes the fact that someone has approved it visible at a glance in the PR queue[1] which is nice and saves opening the issue and scrolling through comments, CI run reports etc.

When you look at the files of the PR, e.g. [2], in the top right there is the green ?Review Changes? button. Click it, select Approve, add a comment if you like, and hit Submit.


[1] https://github.com/wildfly/wildfly-core/pulls
[2] https://github.com/wildfly/wildfly-core/pull/2326/files

Thanks,
-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From david.lloyd at redhat.com  Fri Apr 14 10:56:23 2017
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 14 Apr 2017 09:56:23 -0500
Subject: [wildfly-dev] The art, science,
	and torture of debugging test suite hangs
Message-ID: <a21cab45-116a-2f8a-fc6b-90eda624dfc4@redhat.com>

It's really a pain when you are developing a multifaceted change to the 
application server and it hangs.  Sometimes, if you're lucky, you can 
stick jconsole on there and figure out at least a general idea of what 
is going on, or reproduce the problem by running a test, a test class, 
or a test module in isolation with debugging turned on.  Sometimes 
you're not so lucky, or sometimes the hang happens in the manualmode 
test suite where you have to attach a debugger 9,000 times only to find 
out that the hang doesn't happen when you do that.

I think we should introduce a new build profile which activates the 
remote debugging port, but with suspend=n.  This would allow entire full 
test suite runs to be done while allowing debugger to be attached for 
exploratory surgery in the event that something goes wrong.  While it's 
possible that having debugging activated might actually prevent the hang 
you care about, at least there's a chance that something can be done.


-- 
- DML

From jperkins at redhat.com  Mon Apr 17 18:20:32 2017
From: jperkins at redhat.com (James Perkins)
Date: Mon, 17 Apr 2017 15:20:32 -0700
Subject: [wildfly-dev] The art, science,
 and torture of debugging test suite hangs
In-Reply-To: <a21cab45-116a-2f8a-fc6b-90eda624dfc4@redhat.com>
References: <a21cab45-116a-2f8a-fc6b-90eda624dfc4@redhat.com>
Message-ID: <CADGwLphHOSs5zn9Te2UOm-ztZzeEM5WNvSXMda8+GFwSpzRZBQ@mail.gmail.com>

You could just make it a property too. Maybe something like debug.suspend
that defaults to "y". Either way I think it would make sense.

On Fri, Apr 14, 2017 at 7:56 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> It's really a pain when you are developing a multifaceted change to the
> application server and it hangs.  Sometimes, if you're lucky, you can
> stick jconsole on there and figure out at least a general idea of what
> is going on, or reproduce the problem by running a test, a test class,
> or a test module in isolation with debugging turned on.  Sometimes
> you're not so lucky, or sometimes the hang happens in the manualmode
> test suite where you have to attach a debugger 9,000 times only to find
> out that the hang doesn't happen when you do that.
>
> I think we should introduce a new build profile which activates the
> remote debugging port, but with suspend=n.  This would allow entire full
> test suite runs to be done while allowing debugger to be attached for
> exploratory surgery in the event that something goes wrong.  While it's
> possible that having debugging activated might actually prevent the hang
> you care about, at least there's a chance that something can be done.
>
>
> --
> - DML
> _______________________________________________
> 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/20170417/0b717961/attachment-0001.html 

From ropalka at redhat.com  Tue Apr 18 04:46:36 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Tue, 18 Apr 2017 10:46:36 +0200
Subject: [wildfly-dev] The art, science,
 and torture of debugging test suite hangs
In-Reply-To: <a21cab45-116a-2f8a-fc6b-90eda624dfc4@redhat.com>
References: <a21cab45-116a-2f8a-fc6b-90eda624dfc4@redhat.com>
Message-ID: <327d319e-8522-4e38-0f39-22f6e9cea4e7@redhat.com>

Welcome to the WildFly debugging hell David.

The situation is even more complicated than it seems at first sight.

There are tests (in domain test suite for example) when

there are started multiple host controllers

and servers there, each of them binding

to different port. The 'new build profile' proposal should also

address different debugging ports for

all those 'domain controller', 'host controller' and 'server' processes.


Richard


On 04/14/2017 04:56 PM, David M. Lloyd wrote:
> It's really a pain when you are developing a multifaceted change to the
> application server and it hangs.  Sometimes, if you're lucky, you can
> stick jconsole on there and figure out at least a general idea of what
> is going on, or reproduce the problem by running a test, a test class,
> or a test module in isolation with debugging turned on.  Sometimes
> you're not so lucky, or sometimes the hang happens in the manualmode
> test suite where you have to attach a debugger 9,000 times only to find
> out that the hang doesn't happen when you do that.
>
> I think we should introduce a new build profile which activates the
> remote debugging port, but with suspend=n.  This would allow entire full
> test suite runs to be done while allowing debugger to be attached for
> exploratory surgery in the event that something goes wrong.  While it's
> possible that having debugging activated might actually prevent the hang
> you care about, at least there's a chance that something can be done.
>


From jkalina at redhat.com  Thu Apr 20 12:45:28 2017
From: jkalina at redhat.com (Jan Kalina)
Date: Thu, 20 Apr 2017 18:45:28 +0200
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
Message-ID: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>

Hi,
I am just checking how wildfly controller handle dynamic resources because
issue (WFCORE-2691) where every recursive :read-resource (even with
include-runtime=false) asks parent resource for list of all dynamic
(runtime only)
children.

For example query:
*/subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)*
will cause "server" resource (child of messaging-activemq) is asked for list
of all "core-address" (call *getChildren("core-address")*), even trough
they are not
displayed as part of operation result - only blank placeholder is printed:
*"core-address" => undefined,*

This is problem especially in case of new Elytron resources which allow to
browse
user identities using AS model - every :read-resource on root or every AS
boot
currently causes iterating over all users/identities available in all
concerned realms.

Is this design problem?
Is there some reason why should wildfly controller ask for all resource
children
even when they are ignored and not printed?
What do you think about it? How should be resources with dynamic children
handled?

Thanks,
Honza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170420/99ef314b/attachment.html 

From brian.stansberry at redhat.com  Thu Apr 20 13:22:34 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 20 Apr 2017 12:22:34 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
In-Reply-To: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
Message-ID: <5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>

I know that internally it?s useful in a number of places to know what children a resource has even without knowing their details beyond their address. If it?s useful internally it seems like it could be useful to outside callers too. I don?t know if HAL uses it.

Removing that data would be a breaking change in our responses. Perhaps we could consider it for the :read-resource(include-runtime=false) case since the user has explicitly said they want things excluded, but for non-recursive :read-resource() (i.e. include-runtime=true) that would be a bigger problem with no way for users to get the data without using recursive=true.

Regardless of that, having management resources represent remote objects is problematic for JMX. All management resources, dynamic or not, are available via JMX. MBeanServerConnection.getMBeanCount() and various uses of queryNames and queryMBeans with ObjectName patterns as the param result in needing to access all these resources. I can?t find any JMX API that would make it easy for users to say ?except the runtime-only ones? plus I think some users wouldn?t be interested in that kind of thing anyway. I?ve heard of general purpose agent tools that do this kind of thing.

One thought I had as I wrote this is perhaps marking the resources as remote may help. I don?t believe we expose remote resources via JMX, and if we do that sounds like a bug. Up to now, ?remote? has been used for the resource for other WF processes in a managed domain, but perhaps the use of the concept could be expanded.

So, we should look into ?remote? and maybe all this goes away. :)

If that doesnt? pan out, I question why these things need to be modeled as resources. AFAICT they have no attributes and are just addresses against which operations can be executed. I don?t see much benefit in:

/subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity

vs

/subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)

or

/subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)

vs

/subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)

Modeling these as resources allows you to list the identities etc via things like read-resource, read-children-names, etc but that?s both a feature and a bug. ;) A list-identities op on the realm accomplishes much the same thing.


> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com> wrote:
> 
> Hi,
> I am just checking how wildfly controller handle dynamic resources because
> issue (WFCORE-2691) where every recursive :read-resource (even with
> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
> children.
> 
> For example query:
> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
> will cause "server" resource (child of messaging-activemq) is asked for list
> of all "core-address" (call getChildren("core-address")), even trough they are not
> displayed as part of operation result - only blank placeholder is printed:
> "core-address" => undefined,
> 
> This is problem especially in case of new Elytron resources which allow to browse
> user identities using AS model - every :read-resource on root or every AS boot
> currently causes iterating over all users/identities available in all concerned realms.
> 
> Is this design problem?
> Is there some reason why should wildfly controller ask for all resource children
> even when they are ignored and not printed?
> What do you think about it? How should be resources with dynamic children handled?
> 
> Thanks,
> Honza
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From brian.stansberry at redhat.com  Thu Apr 20 14:50:45 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 20 Apr 2017 13:50:45 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
In-Reply-To: <5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
Message-ID: <67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>


> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> I know that internally it?s useful in a number of places to know what children a resource has even without knowing their details beyond their address. If it?s useful internally it seems like it could be useful to outside callers too. I don?t know if HAL uses it.
> 
> Removing that data would be a breaking change in our responses. Perhaps we could consider it for the :read-resource(include-runtime=false) case since the user has explicitly said they want things excluded, but for non-recursive :read-resource() (i.e. include-runtime=true) that would be a bigger problem with no way for users to get the data without using recursive=true.
> 
> Regardless of that, having management resources represent remote objects is problematic for JMX. All management resources, dynamic or not, are available via JMX. MBeanServerConnection.getMBeanCount() and various uses of queryNames and queryMBeans with ObjectName patterns as the param result in needing to access all these resources. I can?t find any JMX API that would make it easy for users to say ?except the runtime-only ones? plus I think some users wouldn?t be interested in that kind of thing anyway. I?ve heard of general purpose agent tools that do this kind of thing.
> 
> One thought I had as I wrote this is perhaps marking the resources as remote may help. I don?t believe we expose remote resources via JMX, and if we do that sounds like a bug. Up to now, ?remote? has been used for the resource for other WF processes in a managed domain, but perhaps the use of the concept could be expanded.
> 
> So, we should look into ?remote? and maybe all this goes away. :)

I poked a bit and while this may be an interesting thing to explore some day it?s not something practical for WF 11. The handling of ?remote? resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It?s not something applicable to other sorts of usage.

> 
> If that doesnt? pan out, I question why these things need to be modeled as resources. AFAICT they have no attributes and are just addresses against which operations can be executed. I don?t see much benefit in:
> 
> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
> 
> vs
> 
> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
> 
> or
> 
> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
> 
> vs
> 
> /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
> 
> Modeling these as resources allows you to list the identities etc via things like read-resource, read-children-names, etc but that?s both a feature and a bug. ;) A list-identities op on the realm accomplishes much the same thing.
> 
> 
>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com> wrote:
>> 
>> Hi,
>> I am just checking how wildfly controller handle dynamic resources because
>> issue (WFCORE-2691) where every recursive :read-resource (even with
>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>> children.
>> 
>> For example query:
>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>> will cause "server" resource (child of messaging-activemq) is asked for list
>> of all "core-address" (call getChildren("core-address")), even trough they are not
>> displayed as part of operation result - only blank placeholder is printed:
>> "core-address" => undefined,
>> 
>> This is problem especially in case of new Elytron resources which allow to browse
>> user identities using AS model - every :read-resource on root or every AS boot
>> currently causes iterating over all users/identities available in all concerned realms.
>> 
>> Is this design problem?
>> Is there some reason why should wildfly controller ask for all resource children
>> even when they are ignored and not printed?
>> What do you think about it? How should be resources with dynamic children handled?
>> 
>> Thanks,
>> Honza
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
> 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From jkalina at redhat.com  Fri Apr 21 03:22:12 2017
From: jkalina at redhat.com (Jan Kalina)
Date: Fri, 21 Apr 2017 09:22:12 +0200
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
 iterates over dynamic children
In-Reply-To: <67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
Message-ID: <CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>

Not sure if it helps for JMX, but at least for management I see the core of
the problem in obtaining
children of node even through there is placeholder pushed into the
operation result...
It is something for which I dont see any reason - this should be possible
to fix even without management behaviour change.

Not experienced in JMX, but are not the same placeholders used here too?
(if yes, it could be the same problem...)


On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

>
> > On Apr 20, 2017, at 12:22 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > I know that internally it?s useful in a number of places to know what
> children a resource has even without knowing their details beyond their
> address. If it?s useful internally it seems like it could be useful to
> outside callers too. I don?t know if HAL uses it.
> >
> > Removing that data would be a breaking change in our responses. Perhaps
> we could consider it for the :read-resource(include-runtime=false) case
> since the user has explicitly said they want things excluded, but for
> non-recursive :read-resource() (i.e. include-runtime=true) that would be a
> bigger problem with no way for users to get the data without using
> recursive=true.
> >
> > Regardless of that, having management resources represent remote objects
> is problematic for JMX. All management resources, dynamic or not, are
> available via JMX. MBeanServerConnection.getMBeanCount() and various uses
> of queryNames and queryMBeans with ObjectName patterns as the param result
> in needing to access all these resources. I can?t find any JMX API that
> would make it easy for users to say ?except the runtime-only ones? plus I
> think some users wouldn?t be interested in that kind of thing anyway. I?ve
> heard of general purpose agent tools that do this kind of thing.
> >
> > One thought I had as I wrote this is perhaps marking the resources as
> remote may help. I don?t believe we expose remote resources via JMX, and if
> we do that sounds like a bug. Up to now, ?remote? has been used for the
> resource for other WF processes in a managed domain, but perhaps the use of
> the concept could be expanded.
> >
> > So, we should look into ?remote? and maybe all this goes away. :)
>
> I poked a bit and while this may be an interesting thing to explore some
> day it?s not something practical for WF 11. The handling of ?remote?
> resource types is based on their being no Resource instances for them in
> the local resource tree, and then a special ManagementResourceRegistration
> is registered for each individual resource (/host=slave, /server=server-one
> etc) that proxies any operations addressed to that specific resource to a
> remote WildFly process. It?s not something applicable to other sorts of
> usage.
>
> >
> > If that doesnt? pan out, I question why these things need to be modeled
> as resources. AFAICT they have no attributes and are just addresses against
> which operations can be executed. I don?t see much benefit in:
> >
> > /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
> >
> > vs
> >
> > /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
> >
> > or
> >
> > /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:
> add(foo=bar,xyz=true)
> >
> > vs
> >
> > /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=
> ldapUser,foo=bar,xyz=true)
> >
> > Modeling these as resources allows you to list the identities etc via
> things like read-resource, read-children-names, etc but that?s both a
> feature and a bug. ;) A list-identities op on the realm accomplishes much
> the same thing.
> >
> >
> >> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com> wrote:
> >>
> >> Hi,
> >> I am just checking how wildfly controller handle dynamic resources
> because
> >> issue (WFCORE-2691) where every recursive :read-resource (even with
> >> include-runtime=false) asks parent resource for list of all dynamic
> (runtime only)
> >> children.
> >>
> >> For example query:
> >> /subsystem=messaging-activemq:read-resource(include-runtime=
> false,recursive=true)
> >> will cause "server" resource (child of messaging-activemq) is asked for
> list
> >> of all "core-address" (call getChildren("core-address")), even trough
> they are not
> >> displayed as part of operation result - only blank placeholder is
> printed:
> >> "core-address" => undefined,
> >>
> >> This is problem especially in case of new Elytron resources which allow
> to browse
> >> user identities using AS model - every :read-resource on root or every
> AS boot
> >> currently causes iterating over all users/identities available in all
> concerned realms.
> >>
> >> Is this design problem?
> >> Is there some reason why should wildfly controller ask for all resource
> children
> >> even when they are ignored and not printed?
> >> What do you think about it? How should be resources with dynamic
> children handled?
> >>
> >> Thanks,
> >> Honza
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Brian Stansberry
> > Manager, Senior Principal Software Engineer
> > JBoss by Red Hat
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170421/8fcb19be/attachment-0001.html 

From ehugonne at redhat.com  Sat Apr 22 01:19:57 2017
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Sat, 22 Apr 2017 07:19:57 +0200
Subject: [wildfly-dev] Missing Credential Store integration in core
	Management
Message-ID: <ae5bcddb-47ce-9b81-b99c-ebcbc1c39b70@redhat.com>

Hi,
Currently we store passwords for core management in various attributes.
With Elytron we can use a Credential Store to store those attributes values using a CredentialReference, which led to [1].
Investigating we have found the following attributes :
* SecretServerIdentityResourceDefinition.VALUE
* SSLServerIdentityResourceDefinition.KEYSTORE_PASSWORD KEY_PASSWORD
* TruststoreAuthenticationResourceDefinition.KEYSTORE_PASSWORD
* LocalAuthenticationResourceDefinition.DEFAULT_USER ALLOWED_USERS
* UserResourceDefinition.PASSWORD
* LdapConnectionResourceDefinition.SEARCH_CREDENTIAL

Did we miss attributes that could be alternative of CredentialReference ?

KEYSTORE_PASSWORD KEY_PASSWORD (in SSLServerIdentityResourceDefinition and TruststoreAuthenticationResourceDefinition) are using the
attribute definitions of KeystoreAttributes.
We could introduce the alternatives in those definition but that would impact SyslogAuditLogProtocolResourceDefinition.TlsKeyStore.

Cheers,
Emmanuel

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170422/a03533f2/attachment.bin 

From brian.stansberry at redhat.com  Sun Apr 23 08:31:52 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Sun, 23 Apr 2017 07:31:52 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
In-Reply-To: <CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
Message-ID: <75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>

A non-text attachment was scrubbed...
Name: Mail Attachment
Type: application/pgp-encrypted
Size: 12 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170423/7cffa867/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encrypted.asc
Type: application/octet-stream
Size: 4888 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170423/7cffa867/attachment.obj 

From darran.lofthouse at jboss.com  Mon Apr 24 04:17:15 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Apr 2017 09:17:15 +0100
Subject: [wildfly-dev] Missing Credential Store integration in core
 Management
In-Reply-To: <ae5bcddb-47ce-9b81-b99c-ebcbc1c39b70@redhat.com>
References: <ae5bcddb-47ce-9b81-b99c-ebcbc1c39b70@redhat.com>
Message-ID: <ce24b184-5abc-d1e2-beee-d68e789ea866@jboss.com>

Jira issues already exist to address these.

On 22/04/17 06:19, Emmanuel Hugonnet wrote:
> Hi,
> Currently we store passwords for core management in various attributes.
> With Elytron we can use a Credential Store to store those attributes values using a CredentialReference, which led to [1].
> Investigating we have found the following attributes :
> * SecretServerIdentityResourceDefinition.VALUE
> * SSLServerIdentityResourceDefinition.KEYSTORE_PASSWORD KEY_PASSWORD
> * TruststoreAuthenticationResourceDefinition.KEYSTORE_PASSWORD
> * LocalAuthenticationResourceDefinition.DEFAULT_USER ALLOWED_USERS
> * UserResourceDefinition.PASSWORD
> * LdapConnectionResourceDefinition.SEARCH_CREDENTIAL
>
> Did we miss attributes that could be alternative of CredentialReference ?
>
> KEYSTORE_PASSWORD KEY_PASSWORD (in SSLServerIdentityResourceDefinition and TruststoreAuthenticationResourceDefinition) are using the
> attribute definitions of KeystoreAttributes.
> We could introduce the alternatives in those definition but that would impact SyslogAuditLogProtocolResourceDefinition.TlsKeyStore.
>
> Cheers,
> Emmanuel
>
> [1]: https://issues.jboss.org/browse/WFCORE-2483
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From churaev.an at gmail.com  Mon Apr 24 06:59:19 2017
From: churaev.an at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQp9GD0YDQsNC10LI=?=)
Date: Mon, 24 Apr 2017 13:59:19 +0300
Subject: [wildfly-dev] I want to contribute
Message-ID: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>

Hello!

Could you please help me with start contributing.
I want to contribute in WildFly project, but couldnot find any information
about ICLA/CCLA. Is it necessary to fill CLA form for starting contributing
to WildFly?

-- 

Best Regards, Anton Churaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170424/d90209da/attachment.html 

From hpehl at redhat.com  Mon Apr 24 07:53:33 2017
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 24 Apr 2017 13:53:33 +0200
Subject: [wildfly-dev] The future of the management console
Message-ID: <CAPZNLwweudh6uSowofQQUEZS8h109ij5==mZJxF-kiGRZhTiPQ@mail.gmail.com>

We're currently working on the next major version of HAL [1]. HAL.next will
include all features of the current management console plus many new features
such as macro recording, topology overview, better keyboard support and
PatternFly [2] compliance. See [3] for more details.

We're making good progress and have migrated all of the configuration and
half of the runtime screens to HAL.next. What's missing is the support for
patching and the remaining runtime UI. Our goal is to ship HAL.next with
WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
today [4] and give us feedback!

I'd like to use this post to give you the chance to participate in the
future of the management console. We already have some basic ideas what
we would like to add to HAL.next, but we also want you to give us additional
input.

# Runtime Extensions / JavaScript API

As most of you will know both HAL and HAL.next are implemented in GWT.
For the current version there's a way to write extensions as GWT modules [5].
This is based on the concept of having compile time extensions provided as
maven dependencies. While this gives you full access to the HAL API, it's
often hard to get started for none GWT developers.

New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
of your Java code to JavaScript. We've used this feature to provide a basic
JavaScript API. This can be used in the future to write runtime extensions
in JavaScript. A first draft is available at [7].

# Monitoring

The current management console has some limited monitoring capabilities.
We could improve and enhance these capabilities if this is something which
you want to have out of the box. However we don't want to turn HAL into
another monitoring tool. There are plenty of other tools and frameworks
which focus on monitoring.

# Macro Recording

We've built basic support to record macros in HAL.next. Behind the scenes the
DMR operations are collected and made available for replay. We could extend
this feature to be more dynamic if requested (variables, iterations, el al).

# What else?

It's your turn! What else do you want to see in HAL.next?


[1] https://github.com/hal/hal.next
[2] https://www.patternfly.org/
[3] https://github.com/hal/hal.next/#motivation
[4] https://github.com/hal/hal.next/#running
[5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
[6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
[7] https://github.com/hal/hal.next/wiki/JavaScript-API


-- 
Harald Pehl
hpehl at redhat.com

From manovotn at redhat.com  Mon Apr 24 08:32:35 2017
From: manovotn at redhat.com (Matej Novotny)
Date: Mon, 24 Apr 2017 08:32:35 -0400 (EDT)
Subject: [wildfly-dev] Weld 3 & Wildfly 11 integration - help with security
	needed
In-Reply-To: <1297078731.331997.1493036582744.JavaMail.zimbra@redhat.com>
Message-ID: <1852088519.338288.1493037155775.JavaMail.zimbra@redhat.com>

Hello,

recently I decided, that Weld 3 (CDI 2.0, currently nearing Final at high speed) should be running on WildFly 11.
Up until now, we had the integration based on 10.1.0.Final but for several reasons we want to move to 11.

There were some changes and I figured out most of them but I am lost when it comes to security.
I know Elytron was added but I don't know a damn thing about it - could anyone lend a hand here, please?

The code is now located at this branch[1] and the very last commit shows the integration done.
Vast majority is just taken from previous integration with 10.1.0.Final (branch 10.1.0.Final-weld3).
The part I am concerned about is weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java [2]
'getPrincipal'[3] method was earlier adapted to Elytron, and I am thinking the other methods should perhaps be adjusted as well?
But then again, I have no idea how to do that with Elytron... a penny for your thoughts?

Regards
Matej

____________________________________________________________________________________________________________________________________
[1]https://github.com/weld/wildfly/tree/11.0.0.Alpha1-weld3
[2]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-weld3/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java
[3]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-weld3/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java#L69

From david.lloyd at redhat.com  Mon Apr 24 09:05:54 2017
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 24 Apr 2017 08:05:54 -0500
Subject: [wildfly-dev] I want to contribute
In-Reply-To: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>
References: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>
Message-ID: <edf620c7-fbb2-19cd-4379-7dc04c86b9d6@redhat.com>

On 04/24/2017 05:59 AM, ????? ?????? wrote:
> Hello!
>
> Could you please help me with start contributing.
> I want to contribute in WildFly project, but couldnot find any
> information about ICLA/CCLA. Is it necessary to fill CLA form for
> starting contributing to WildFly?

No, however we do require that all changes be submitted under the terms 
of the MIT license.  When you send your first pull request, a committer 
will ask (on the PR) if you agree to the terms; at that point, 
everything should be set.


-- 
- DML

From churaev.an at gmail.com  Mon Apr 24 09:45:44 2017
From: churaev.an at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQp9GD0YDQsNC10LI=?=)
Date: Mon, 24 Apr 2017 16:45:44 +0300
Subject: [wildfly-dev] I want to contribute
In-Reply-To: <edf620c7-fbb2-19cd-4379-7dc04c86b9d6@redhat.com>
References: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>
	<edf620c7-fbb2-19cd-4379-7dc04c86b9d6@redhat.com>
Message-ID: <CAB_oYF_T=wPUAWoSM494iewVS0iNkq9oP+Ew=WjS=QXFR_w_xw@mail.gmail.com>

David, thank you!

What about my employer? Does community need my employer's consent to my
contribution?

2017-04-24 16:05 GMT+03:00 David M. Lloyd <david.lloyd at redhat.com>:

> On 04/24/2017 05:59 AM, ????? ?????? wrote:
> > Hello!
> >
> > Could you please help me with start contributing.
> > I want to contribute in WildFly project, but couldnot find any
> > information about ICLA/CCLA. Is it necessary to fill CLA form for
> > starting contributing to WildFly?
>
> No, however we do require that all changes be submitted under the terms
> of the MIT license.  When you send your first pull request, a committer
> will ask (on the PR) if you agree to the terms; at that point,
> everything should be set.
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 

Best Regards, Anton Churaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170424/465f3651/attachment.html 

From brian.stansberry at redhat.com  Mon Apr 24 10:20:58 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 24 Apr 2017 09:20:58 -0500
Subject: [wildfly-dev] The future of the management console
In-Reply-To: <CAPZNLwweudh6uSowofQQUEZS8h109ij5==mZJxF-kiGRZhTiPQ@mail.gmail.com>
References: <CAPZNLwweudh6uSowofQQUEZS8h109ij5==mZJxF-kiGRZhTiPQ@mail.gmail.com>
Message-ID: <234B355C-313D-4D20-87C8-AF65E794252E@redhat.com>

Hi Harald,

Thanks for the update; it?s great that this keeps moving along!

Re: macro recording, how is the recorded data made useful for the user?

I think this is one where we need to think through the use cases carefully so we make sure we cover all the necessary ones or at least don?t do something that blocks covering them.

One thing I know that?s been requested is taking the output of this kind of recording and being able to execute it from the CLI. But that implies CLI syntax instead of raw DMR. And then if we start getting into variable etc it?s important that it be done in a consistent and compatible way.

Cheers,
Brian

> On Apr 24, 2017, at 6:53 AM, Harald Pehl <hpehl at redhat.com> wrote:
> 
> We're currently working on the next major version of HAL [1]. HAL.next will
> include all features of the current management console plus many new features
> such as macro recording, topology overview, better keyboard support and
> PatternFly [2] compliance. See [3] for more details.
> 
> We're making good progress and have migrated all of the configuration and
> half of the runtime screens to HAL.next. What's missing is the support for
> patching and the remaining runtime UI. Our goal is to ship HAL.next with
> WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
> today [4] and give us feedback!
> 
> I'd like to use this post to give you the chance to participate in the
> future of the management console. We already have some basic ideas what
> we would like to add to HAL.next, but we also want you to give us additional
> input.
> 
> # Runtime Extensions / JavaScript API
> 
> As most of you will know both HAL and HAL.next are implemented in GWT.
> For the current version there's a way to write extensions as GWT modules [5].
> This is based on the concept of having compile time extensions provided as
> maven dependencies. While this gives you full access to the HAL API, it's
> often hard to get started for none GWT developers.
> 
> New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
> of your Java code to JavaScript. We've used this feature to provide a basic
> JavaScript API. This can be used in the future to write runtime extensions
> in JavaScript. A first draft is available at [7].
> 
> # Monitoring
> 
> The current management console has some limited monitoring capabilities.
> We could improve and enhance these capabilities if this is something which
> you want to have out of the box. However we don't want to turn HAL into
> another monitoring tool. There are plenty of other tools and frameworks
> which focus on monitoring.
> 
> # Macro Recording
> 
> We've built basic support to record macros in HAL.next. Behind the scenes the
> DMR operations are collected and made available for replay. We could extend
> this feature to be more dynamic if requested (variables, iterations, el al).
> 
> # What else?
> 
> It's your turn! What else do you want to see in HAL.next?
> 
> 
> [1] https://github.com/hal/hal.next
> [2] https://www.patternfly.org/
> [3] https://github.com/hal/hal.next/#motivation
> [4] https://github.com/hal/hal.next/#running
> [5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
> [6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
> [7] https://github.com/hal/hal.next/wiki/JavaScript-API
> 
> 
> -- 
> Harald Pehl
> hpehl at redhat.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From brian.stansberry at redhat.com  Mon Apr 24 10:29:08 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 24 Apr 2017 09:29:08 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
In-Reply-To: <75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
	<75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
Message-ID: <15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>

Here?s my last post again. For some reason my mail client decide to encrypt it when it resent it.

> On Apr 23, 2017, at 7:31 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com> wrote:
>> 
>> Not sure if it helps for JMX, but at least for management I see the core of the problem in obtaining
>> children of node even through there is placeholder pushed into the operation result...
>> It is something for which I dont see any reason - this should be possible to fix even without management behaviour change.
>> 
> 
> There is a placeholder per address. Even if we made the placeholder objects go away, we have a requirement to list the child addresses that cannot be made to go away. The critical cost here is identifying those addresses, more so than manipulating the placeholder objects. Identifying those addresses means making a remote call to an LDAP server and iterating over possibly thousands of results. 
> 
>> Not experienced in JMX, but are not the same placeholders used here too? (if yes, it could be the same problem?)
>> 
> 
> If we say an identity is a management resource, that means we can produce an mbean for it. And that means JMX ops like MBeanServer.getMBeanCount() need to access all of those resources, at a minimum to know their address.
> 
> Why do these identities need to be represented as management resources?
> 
>> 
>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> I know that internally it?s useful in a number of places to know what children a resource has even without knowing their details beyond their address. If it?s useful internally it seems like it could be useful to outside callers too. I don?t know if HAL uses it.
>>> 
>>> Removing that data would be a breaking change in our responses. Perhaps we could consider it for the :read-resource(include-runtime=false) case since the user has explicitly said they want things excluded, but for non-recursive :read-resource() (i.e. include-runtime=true) that would be a bigger problem with no way for users to get the data without using recursive=true.
>>> 
>>> Regardless of that, having management resources represent remote objects is problematic for JMX. All management resources, dynamic or not, are available via JMX. MBeanServerConnection.getMBeanCount() and various uses of queryNames and queryMBeans with ObjectName patterns as the param result in needing to access all these resources. I can?t find any JMX API that would make it easy for users to say ?except the runtime-only ones? plus I think some users wouldn?t be interested in that kind of thing anyway. I?ve heard of general purpose agent tools that do this kind of thing.
>>> 
>>> One thought I had as I wrote this is perhaps marking the resources as remote may help. I don?t believe we expose remote resources via JMX, and if we do that sounds like a bug. Up to now, ?remote? has been used for the resource for other WF processes in a managed domain, but perhaps the use of the concept could be expanded.
>>> 
>>> So, we should look into ?remote? and maybe all this goes away. :)
>> 
>> I poked a bit and while this may be an interesting thing to explore some day it?s not something practical for WF 11. The handling of ?remote? resource types is based on their being no Resource instances for them in the local resource tree, and then a special ManagementResourceRegistration is registered for each individual resource (/host=slave, /server=server-one etc) that proxies any operations addressed to that specific resource to a remote WildFly process. It?s not something applicable to other sorts of usage.
>> 
>>> 
>>> If that doesnt? pan out, I question why these things need to be modeled as resources. AFAICT they have no attributes and are just addresses against which operations can be executed. I don?t see much benefit in:
>>> 
>>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
>>> 
>>> vs
>>> 
>>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
>>> 
>>> or
>>> 
>>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
>>> 
>>> vs
>>> 
>>> /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
>>> 
>>> Modeling these as resources allows you to list the identities etc via things like read-resource, read-children-names, etc but that?s both a feature and a bug. ;) A list-identities op on the realm accomplishes much the same thing.
>>> 
>>> 
>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com> wrote:
>>>> 
>>>> Hi,
>>>> I am just checking how wildfly controller handle dynamic resources because
>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>> include-runtime=false) asks parent resource for list of all dynamic (runtime only)
>>>> children.
>>>> 
>>>> For example query:
>>>> /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>> will cause "server" resource (child of messaging-activemq) is asked for list
>>>> of all "core-address" (call getChildren("core-address")), even trough they are not
>>>> displayed as part of operation result - only blank placeholder is printed:
>>>> "core-address" => undefined,
>>>> 
>>>> This is problem especially in case of new Elytron resources which allow to browse
>>>> user identities using AS model - every :read-resource on root or every AS boot
>>>> currently causes iterating over all users/identities available in all concerned realms.
>>>> 
>>>> Is this design problem?
>>>> Is there some reason why should wildfly controller ask for all resource children
>>>> even when they are ignored and not printed?
>>>> What do you think about it? How should be resources with dynamic children handled?
>>>> 
>>>> Thanks,
>>>> Honza
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>> 
>> 
>> 
>> 
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From hpehl at redhat.com  Mon Apr 24 10:44:49 2017
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 24 Apr 2017 16:44:49 +0200
Subject: [wildfly-dev] The future of the management console
In-Reply-To: <234B355C-313D-4D20-87C8-AF65E794252E@redhat.com>
References: <CAPZNLwweudh6uSowofQQUEZS8h109ij5==mZJxF-kiGRZhTiPQ@mail.gmail.com>
	<234B355C-313D-4D20-87C8-AF65E794252E@redhat.com>
Message-ID: <CAPZNLwwmL1NfrzYR57rcexwD5M9r+m2mVXV3GkvCY7P8JqKM8w@mail.gmail.com>

On Mon, Apr 24, 2017 at 4:20 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> Hi Harald,
>
> Thanks for the update; it?s great that this keeps moving along!
>
> Re: macro recording, how is the recorded data made useful for the user?

The recorded DMR operations are presented in a read-only editor.
They're already shown in CLI syntax. There's also a
"copy-to-clipboard" button for easy CLI execution.

>
> I think this is one where we need to think through the use cases carefully so we make sure we cover all the necessary ones or at least don?t do something that blocks covering them.
>
> One thing I know that?s been requested is taking the output of this kind of recording and being able to execute it from the CLI. But that implies CLI syntax instead of raw DMR. And then if we start getting into variable etc it?s important that it be done in a consistent and compatible way.
>

Right, adding advanced features like variables and iterations needs
more research and a consistent exchange with the CLI.

> Cheers,
> Brian
>
>> On Apr 24, 2017, at 6:53 AM, Harald Pehl <hpehl at redhat.com> wrote:
>>
>> We're currently working on the next major version of HAL [1]. HAL.next will
>> include all features of the current management console plus many new features
>> such as macro recording, topology overview, better keyboard support and
>> PatternFly [2] compliance. See [3] for more details.
>>
>> We're making good progress and have migrated all of the configuration and
>> half of the runtime screens to HAL.next. What's missing is the support for
>> patching and the remaining runtime UI. Our goal is to ship HAL.next with
>> WildFly asap. If you don't want to wait, I encourage you to try out HAL.next
>> today [4] and give us feedback!
>>
>> I'd like to use this post to give you the chance to participate in the
>> future of the management console. We already have some basic ideas what
>> we would like to add to HAL.next, but we also want you to give us additional
>> input.
>>
>> # Runtime Extensions / JavaScript API
>>
>> As most of you will know both HAL and HAL.next are implemented in GWT.
>> For the current version there's a way to write extensions as GWT modules [5].
>> This is based on the concept of having compile time extensions provided as
>> maven dependencies. While this gives you full access to the HAL API, it's
>> often hard to get started for none GWT developers.
>>
>> New features in GWT 2.8 like JsInterop [6] make it very easy to export parts
>> of your Java code to JavaScript. We've used this feature to provide a basic
>> JavaScript API. This can be used in the future to write runtime extensions
>> in JavaScript. A first draft is available at [7].
>>
>> # Monitoring
>>
>> The current management console has some limited monitoring capabilities.
>> We could improve and enhance these capabilities if this is something which
>> you want to have out of the box. However we don't want to turn HAL into
>> another monitoring tool. There are plenty of other tools and frameworks
>> which focus on monitoring.
>>
>> # Macro Recording
>>
>> We've built basic support to record macros in HAL.next. Behind the scenes the
>> DMR operations are collected and made available for replay. We could extend
>> this feature to be more dynamic if requested (variables, iterations, el al).
>>
>> # What else?
>>
>> It's your turn! What else do you want to see in HAL.next?
>>
>>
>> [1] https://github.com/hal/hal.next
>> [2] https://www.patternfly.org/
>> [3] https://github.com/hal/hal.next/#motivation
>> [4] https://github.com/hal/hal.next/#running
>> [5] https://hal.gitbooks.io/dev/content/building-blocks/extensions.html
>> [6] https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/view
>> [7] https://github.com/hal/hal.next/wiki/JavaScript-API
>>
>>
>> --
>> Harald Pehl
>> hpehl at redhat.com
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>



-- 
Harald Pehl
Senior Software Engineer
Red Hat
hpehl at redhat.com
Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps


From david.lloyd at redhat.com  Mon Apr 24 10:49:01 2017
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 24 Apr 2017 09:49:01 -0500
Subject: [wildfly-dev] I want to contribute
In-Reply-To: <CAB_oYF_T=wPUAWoSM494iewVS0iNkq9oP+Ew=WjS=QXFR_w_xw@mail.gmail.com>
References: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>
	<edf620c7-fbb2-19cd-4379-7dc04c86b9d6@redhat.com>
	<CAB_oYF_T=wPUAWoSM494iewVS0iNkq9oP+Ew=WjS=QXFR_w_xw@mail.gmail.com>
Message-ID: <3b1e6983-e014-7963-3b39-58bc0ca4e82b@redhat.com>

This is something you'll have to ask your employer's legal department or 
other responsible entity.

On 04/24/2017 08:45 AM, ????? ?????? wrote:
> David, thank you!
>
> What about my employer? Does community need my employer's consent to my
> contribution?
>
> 2017-04-24 16:05 GMT+03:00 David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>>:
>
>     On 04/24/2017 05:59 AM, ????? ?????? wrote:
>     > Hello!
>     >
>     > Could you please help me with start contributing.
>     > I want to contribute in WildFly project, but couldnot find any
>     > information about ICLA/CCLA. Is it necessary to fill CLA form for
>     > starting contributing to WildFly?
>
>     No, however we do require that all changes be submitted under the terms
>     of the MIT license.  When you send your first pull request, a committer
>     will ask (on the PR) if you agree to the terms; at that point,
>     everything should be set.
>
>
>     --
>     - DML
>     _______________________________________________
>     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>
>
>
>
>
> --
>
> Best Regards, Anton Churaev
>

-- 
- DML

From churaev.an at gmail.com  Mon Apr 24 11:25:15 2017
From: churaev.an at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQp9GD0YDQsNC10LI=?=)
Date: Mon, 24 Apr 2017 18:25:15 +0300
Subject: [wildfly-dev] I want to contribute
In-Reply-To: <3b1e6983-e014-7963-3b39-58bc0ca4e82b@redhat.com>
References: <CAB_oYF9WXtS8vET8ZyzqMZ9BgGvwbdrz55OVCWre0yfVT063ew@mail.gmail.com>
	<edf620c7-fbb2-19cd-4379-7dc04c86b9d6@redhat.com>
	<CAB_oYF_T=wPUAWoSM494iewVS0iNkq9oP+Ew=WjS=QXFR_w_xw@mail.gmail.com>
	<3b1e6983-e014-7963-3b39-58bc0ca4e82b@redhat.com>
Message-ID: <CAB_oYF-hhDzQmBcqEGGEEws_fWgWv_js4yS_QU-t3b5FNVSK2w@mail.gmail.com>

Ok, I'll solve this with them.

2017-04-24 17:49 GMT+03:00 David M. Lloyd <david.lloyd at redhat.com>:

> This is something you'll have to ask your employer's legal department or
> other responsible entity.
>
> On 04/24/2017 08:45 AM, ????? ?????? wrote:
>
>> David, thank you!
>>
>> What about my employer? Does community need my employer's consent to my
>> contribution?
>>
>> 2017-04-24 16:05 GMT+03:00 David M. Lloyd <david.lloyd at redhat.com
>> <mailto:david.lloyd at redhat.com>>:
>>
>>     On 04/24/2017 05:59 AM, ????? ?????? wrote:
>>     > Hello!
>>     >
>>     > Could you please help me with start contributing.
>>     > I want to contribute in WildFly project, but couldnot find any
>>     > information about ICLA/CCLA. Is it necessary to fill CLA form for
>>     > starting contributing to WildFly?
>>
>>     No, however we do require that all changes be submitted under the
>> terms
>>     of the MIT license.  When you send your first pull request, a
>> committer
>>     will ask (on the PR) if you agree to the terms; at that point,
>>     everything should be set.
>>
>>
>>     --
>>     - DML
>>     _______________________________________________
>>     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>
>>
>>
>>
>>
>> --
>>
>> Best Regards, Anton Churaev
>>
>>
> --
> - DML
>



-- 

Best Regards, Anton Churaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170424/c43faf73/attachment.html 

From jkalina at redhat.com  Mon Apr 24 13:44:59 2017
From: jkalina at redhat.com (Jan Kalina)
Date: Mon, 24 Apr 2017 19:44:59 +0200
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
 iterates over dynamic children
In-Reply-To: <15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
	<75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
	<15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>
Message-ID: <CANvHcN8wi7XV_9fZ16rnWe_=XkzFgkrrVYGJ96ttPtwMhX-oBA@mail.gmail.com>

Darran, when consider mentioned problems (especially getting amount of all
mbeans and other operations
on mbeans, where we cannot filter runtime only things out) do we have same
reason to represent identities as resources?
(Using realm operations instead sounds reasonable.)

On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Here?s my last post again. For some reason my mail client decide to
> encrypt it when it resent it.
>
> > On Apr 23, 2017, at 7:31 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> >> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com> wrote:
> >>
> >> Not sure if it helps for JMX, but at least for management I see the
> core of the problem in obtaining
> >> children of node even through there is placeholder pushed into the
> operation result...
> >> It is something for which I dont see any reason - this should be
> possible to fix even without management behaviour change.
> >>
> >
> > There is a placeholder per address. Even if we made the placeholder
> objects go away, we have a requirement to list the child addresses that
> cannot be made to go away. The critical cost here is identifying those
> addresses, more so than manipulating the placeholder objects. Identifying
> those addresses means making a remote call to an LDAP server and iterating
> over possibly thousands of results.
> >
> >> Not experienced in JMX, but are not the same placeholders used here
> too? (if yes, it could be the same problem?)
> >>
> >
> > If we say an identity is a management resource, that means we can
> produce an mbean for it. And that means JMX ops like
> MBeanServer.getMBeanCount() need to access all of those resources, at a
> minimum to know their address.
> >
> > Why do these identities need to be represented as management resources?
> >
> >>
> >> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>
> >>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>>
> >>> I know that internally it?s useful in a number of places to know what
> children a resource has even without knowing their details beyond their
> address. If it?s useful internally it seems like it could be useful to
> outside callers too. I don?t know if HAL uses it.
> >>>
> >>> Removing that data would be a breaking change in our responses.
> Perhaps we could consider it for the :read-resource(include-runtime=false)
> case since the user has explicitly said they want things excluded, but for
> non-recursive :read-resource() (i.e. include-runtime=true) that would be a
> bigger problem with no way for users to get the data without using
> recursive=true.
> >>>
> >>> Regardless of that, having management resources represent remote
> objects is problematic for JMX. All management resources, dynamic or not,
> are available via JMX. MBeanServerConnection.getMBeanCount() and various
> uses of queryNames and queryMBeans with ObjectName patterns as the param
> result in needing to access all these resources. I can?t find any JMX API
> that would make it easy for users to say ?except the runtime-only ones?
> plus I think some users wouldn?t be interested in that kind of thing
> anyway. I?ve heard of general purpose agent tools that do this kind of
> thing.
> >>>
> >>> One thought I had as I wrote this is perhaps marking the resources as
> remote may help. I don?t believe we expose remote resources via JMX, and if
> we do that sounds like a bug. Up to now, ?remote? has been used for the
> resource for other WF processes in a managed domain, but perhaps the use of
> the concept could be expanded.
> >>>
> >>> So, we should look into ?remote? and maybe all this goes away. :)
> >>
> >> I poked a bit and while this may be an interesting thing to explore
> some day it?s not something practical for WF 11. The handling of ?remote?
> resource types is based on their being no Resource instances for them in
> the local resource tree, and then a special ManagementResourceRegistration
> is registered for each individual resource (/host=slave, /server=server-one
> etc) that proxies any operations addressed to that specific resource to a
> remote WildFly process. It?s not something applicable to other sorts of
> usage.
> >>
> >>>
> >>> If that doesnt? pan out, I question why these things need to be
> modeled as resources. AFAICT they have no attributes and are just addresses
> against which operations can be executed. I don?t see much benefit in:
> >>>
> >>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:
> read-identity
> >>>
> >>> vs
> >>>
> >>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
> >>>
> >>> or
> >>>
> >>> /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:
> add(foo=bar,xyz=true)
> >>>
> >>> vs
> >>>
> >>> /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=
> ldapUser,foo=bar,xyz=true)
> >>>
> >>> Modeling these as resources allows you to list the identities etc via
> things like read-resource, read-children-names, etc but that?s both a
> feature and a bug. ;) A list-identities op on the realm accomplishes much
> the same thing.
> >>>
> >>>
> >>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com> wrote:
> >>>>
> >>>> Hi,
> >>>> I am just checking how wildfly controller handle dynamic resources
> because
> >>>> issue (WFCORE-2691) where every recursive :read-resource (even with
> >>>> include-runtime=false) asks parent resource for list of all dynamic
> (runtime only)
> >>>> children.
> >>>>
> >>>> For example query:
> >>>> /subsystem=messaging-activemq:read-resource(include-runtime=
> false,recursive=true)
> >>>> will cause "server" resource (child of messaging-activemq) is asked
> for list
> >>>> of all "core-address" (call getChildren("core-address")), even trough
> they are not
> >>>> displayed as part of operation result - only blank placeholder is
> printed:
> >>>> "core-address" => undefined,
> >>>>
> >>>> This is problem especially in case of new Elytron resources which
> allow to browse
> >>>> user identities using AS model - every :read-resource on root or
> every AS boot
> >>>> currently causes iterating over all users/identities available in all
> concerned realms.
> >>>>
> >>>> Is this design problem?
> >>>> Is there some reason why should wildfly controller ask for all
> resource children
> >>>> even when they are ignored and not printed?
> >>>> What do you think about it? How should be resources with dynamic
> children handled?
> >>>>
> >>>> Thanks,
> >>>> Honza
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>> --
> >>> Brian Stansberry
> >>> Manager, Senior Principal Software Engineer
> >>> JBoss by Red Hat
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> --
> >> Brian Stansberry
> >> Manager, Senior Principal Software Engineer
> >> JBoss by Red Hat
> >>
> >>
> >>
> >>
> >
> > --
> > Brian Stansberry
> > Manager, Senior Principal Software Engineer
> > JBoss by Red Hat
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170424/9d72b713/attachment.html 

From darran.lofthouse at jboss.com  Mon Apr 24 13:54:02 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Apr 2017 18:54:02 +0100
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
 iterates over dynamic children
In-Reply-To: <CANvHcN8wi7XV_9fZ16rnWe_=XkzFgkrrVYGJ96ttPtwMhX-oBA@mail.gmail.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
	<75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
	<15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>
	<CANvHcN8wi7XV_9fZ16rnWe_=XkzFgkrrVYGJ96ttPtwMhX-oBA@mail.gmail.com>
Message-ID: <b501b725-d2c4-36ef-aa27-aa36fdd000cd@jboss.com>

Moving away from resources to operations may make more sense - 
especially for realms with large a number of identities.

On 24/04/17 18:44, Jan Kalina wrote:
> Darran, when consider mentioned problems (especially getting amount of
> all mbeans and other operations
> on mbeans, where we cannot filter runtime only things out) do we have
> same reason to represent identities as resources?
> (Using realm operations instead sounds reasonable.)
>
> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     Here?s my last post again. For some reason my mail client decide to
>     encrypt it when it resent it.
>
>     > On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>     >
>     >> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com
>     <mailto:jkalina at redhat.com>> wrote:
>     >>
>     >> Not sure if it helps for JMX, but at least for management I see
>     the core of the problem in obtaining
>     >> children of node even through there is placeholder pushed into
>     the operation result...
>     >> It is something for which I dont see any reason - this should be
>     possible to fix even without management behaviour change.
>     >>
>     >
>     > There is a placeholder per address. Even if we made the
>     placeholder objects go away, we have a requirement to list the child
>     addresses that cannot be made to go away. The critical cost here is
>     identifying those addresses, more so than manipulating the
>     placeholder objects. Identifying those addresses means making a
>     remote call to an LDAP server and iterating over possibly thousands
>     of results.
>     >
>     >> Not experienced in JMX, but are not the same placeholders used
>     here too? (if yes, it could be the same problem?)
>     >>
>     >
>     > If we say an identity is a management resource, that means we can
>     produce an mbean for it. And that means JMX ops like
>     MBeanServer.getMBeanCount() need to access all of those resources,
>     at a minimum to know their address.
>     >
>     > Why do these identities need to be represented as management
>     resources?
>     >
>     >>
>     >> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>     >>
>     >>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>     >>>
>     >>> I know that internally it?s useful in a number of places to know
>     what children a resource has even without knowing their details
>     beyond their address. If it?s useful internally it seems like it
>     could be useful to outside callers too. I don?t know if HAL uses it.
>     >>>
>     >>> Removing that data would be a breaking change in our responses.
>     Perhaps we could consider it for the
>     :read-resource(include-runtime=false) case since the user has
>     explicitly said they want things excluded, but for non-recursive
>     :read-resource() (i.e. include-runtime=true) that would be a bigger
>     problem with no way for users to get the data without using
>     recursive=true.
>     >>>
>     >>> Regardless of that, having management resources represent remote
>     objects is problematic for JMX. All management resources, dynamic or
>     not, are available via JMX. MBeanServerConnection.getMBeanCount()
>     and various uses of queryNames and queryMBeans with ObjectName
>     patterns as the param result in needing to access all these
>     resources. I can?t find any JMX API that would make it easy for
>     users to say ?except the runtime-only ones? plus I think some users
>     wouldn?t be interested in that kind of thing anyway. I?ve heard of
>     general purpose agent tools that do this kind of thing.
>     >>>
>     >>> One thought I had as I wrote this is perhaps marking the
>     resources as remote may help. I don?t believe we expose remote
>     resources via JMX, and if we do that sounds like a bug. Up to now,
>     ?remote? has been used for the resource for other WF processes in a
>     managed domain, but perhaps the use of the concept could be expanded.
>     >>>
>     >>> So, we should look into ?remote? and maybe all this goes away. :)
>     >>
>     >> I poked a bit and while this may be an interesting thing to
>     explore some day it?s not something practical for WF 11. The
>     handling of ?remote? resource types is based on their being no
>     Resource instances for them in the local resource tree, and then a
>     special ManagementResourceRegistration is registered for each
>     individual resource (/host=slave, /server=server-one etc) that
>     proxies any operations addressed to that specific resource to a
>     remote WildFly process. It?s not something applicable to other sorts
>     of usage.
>     >>
>     >>>
>     >>> If that doesnt? pan out, I question why these things need to be
>     modeled as resources. AFAICT they have no attributes and are just
>     addresses against which operations can be executed. I don?t see much
>     benefit in:
>     >>>
>     >>>
>     /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
>     >>>
>     >>> vs
>     >>>
>     >>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
>     >>>
>     >>> or
>     >>>
>     >>>
>     /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
>     >>>
>     >>> vs
>     >>>
>     >>>
>     /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
>     >>>
>     >>> Modeling these as resources allows you to list the identities
>     etc via things like read-resource, read-children-names, etc but
>     that?s both a feature and a bug. ;) A list-identities op on the
>     realm accomplishes much the same thing.
>     >>>
>     >>>
>     >>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com
>     <mailto:jkalina at redhat.com>> wrote:
>     >>>>
>     >>>> Hi,
>     >>>> I am just checking how wildfly controller handle dynamic
>     resources because
>     >>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>     >>>> include-runtime=false) asks parent resource for list of all
>     dynamic (runtime only)
>     >>>> children.
>     >>>>
>     >>>> For example query:
>     >>>>
>     /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>     >>>> will cause "server" resource (child of messaging-activemq) is
>     asked for list
>     >>>> of all "core-address" (call getChildren("core-address")), even
>     trough they are not
>     >>>> displayed as part of operation result - only blank placeholder
>     is printed:
>     >>>> "core-address" => undefined,
>     >>>>
>     >>>> This is problem especially in case of new Elytron resources
>     which allow to browse
>     >>>> user identities using AS model - every :read-resource on root
>     or every AS boot
>     >>>> currently causes iterating over all users/identities available
>     in all concerned realms.
>     >>>>
>     >>>> Is this design problem?
>     >>>> Is there some reason why should wildfly controller ask for all
>     resource children
>     >>>> even when they are ignored and not printed?
>     >>>> What do you think about it? How should be resources with
>     dynamic children handled?
>     >>>>
>     >>>> Thanks,
>     >>>> Honza
>     >>>> _______________________________________________
>     >>>> 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
>     >>> 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
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >>
>     >> --
>     >> Brian Stansberry
>     >> Manager, Senior Principal Software Engineer
>     >> JBoss by Red Hat
>     >>
>     >>
>     >>
>     >>
>     >
>     > --
>     > Brian Stansberry
>     > Manager, Senior Principal Software Engineer
>     > JBoss by Red Hat
>
>     --
>     Brian Stansberry
>     Manager, Senior Principal Software Engineer
>     JBoss by Red Hat
>
>
>
>

From david.lloyd at redhat.com  Mon Apr 24 14:20:55 2017
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 24 Apr 2017 13:20:55 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
 iterates over dynamic children
In-Reply-To: <b501b725-d2c4-36ef-aa27-aa36fdd000cd@jboss.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
	<75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
	<15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>
	<CANvHcN8wi7XV_9fZ16rnWe_=XkzFgkrrVYGJ96ttPtwMhX-oBA@mail.gmail.com>
	<b501b725-d2c4-36ef-aa27-aa36fdd000cd@jboss.com>
Message-ID: <733ab0e0-3866-6841-ca2b-29d237b674c2@redhat.com>

+1, in consideration of all the facts this seems like a better approach.

On 04/24/2017 12:54 PM, Darran Lofthouse wrote:
> Moving away from resources to operations may make more sense -
> especially for realms with large a number of identities.
>
> On 24/04/17 18:44, Jan Kalina wrote:
>> Darran, when consider mentioned problems (especially getting amount of
>> all mbeans and other operations
>> on mbeans, where we cannot filter runtime only things out) do we have
>> same reason to represent identities as resources?
>> (Using realm operations instead sounds reasonable.)
>>
>> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>>
>>     Here?s my last post again. For some reason my mail client decide to
>>     encrypt it when it resent it.
>>
>>     > On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>     wrote:
>>     >
>>     >> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com
>>     <mailto:jkalina at redhat.com>> wrote:
>>     >>
>>     >> Not sure if it helps for JMX, but at least for management I see
>>     the core of the problem in obtaining
>>     >> children of node even through there is placeholder pushed into
>>     the operation result...
>>     >> It is something for which I dont see any reason - this should be
>>     possible to fix even without management behaviour change.
>>     >>
>>     >
>>     > There is a placeholder per address. Even if we made the
>>     placeholder objects go away, we have a requirement to list the child
>>     addresses that cannot be made to go away. The critical cost here is
>>     identifying those addresses, more so than manipulating the
>>     placeholder objects. Identifying those addresses means making a
>>     remote call to an LDAP server and iterating over possibly thousands
>>     of results.
>>     >
>>     >> Not experienced in JMX, but are not the same placeholders used
>>     here too? (if yes, it could be the same problem?)
>>     >>
>>     >
>>     > If we say an identity is a management resource, that means we can
>>     produce an mbean for it. And that means JMX ops like
>>     MBeanServer.getMBeanCount() need to access all of those resources,
>>     at a minimum to know their address.
>>     >
>>     > Why do these identities need to be represented as management
>>     resources?
>>     >
>>     >>
>>     >> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>     wrote:
>>     >>
>>     >>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>     wrote:
>>     >>>
>>     >>> I know that internally it?s useful in a number of places to know
>>     what children a resource has even without knowing their details
>>     beyond their address. If it?s useful internally it seems like it
>>     could be useful to outside callers too. I don?t know if HAL uses it.
>>     >>>
>>     >>> Removing that data would be a breaking change in our responses.
>>     Perhaps we could consider it for the
>>     :read-resource(include-runtime=false) case since the user has
>>     explicitly said they want things excluded, but for non-recursive
>>     :read-resource() (i.e. include-runtime=true) that would be a bigger
>>     problem with no way for users to get the data without using
>>     recursive=true.
>>     >>>
>>     >>> Regardless of that, having management resources represent remote
>>     objects is problematic for JMX. All management resources, dynamic or
>>     not, are available via JMX. MBeanServerConnection.getMBeanCount()
>>     and various uses of queryNames and queryMBeans with ObjectName
>>     patterns as the param result in needing to access all these
>>     resources. I can?t find any JMX API that would make it easy for
>>     users to say ?except the runtime-only ones? plus I think some users
>>     wouldn?t be interested in that kind of thing anyway. I?ve heard of
>>     general purpose agent tools that do this kind of thing.
>>     >>>
>>     >>> One thought I had as I wrote this is perhaps marking the
>>     resources as remote may help. I don?t believe we expose remote
>>     resources via JMX, and if we do that sounds like a bug. Up to now,
>>     ?remote? has been used for the resource for other WF processes in a
>>     managed domain, but perhaps the use of the concept could be expanded.
>>     >>>
>>     >>> So, we should look into ?remote? and maybe all this goes away. :)
>>     >>
>>     >> I poked a bit and while this may be an interesting thing to
>>     explore some day it?s not something practical for WF 11. The
>>     handling of ?remote? resource types is based on their being no
>>     Resource instances for them in the local resource tree, and then a
>>     special ManagementResourceRegistration is registered for each
>>     individual resource (/host=slave, /server=server-one etc) that
>>     proxies any operations addressed to that specific resource to a
>>     remote WildFly process. It?s not something applicable to other sorts
>>     of usage.
>>     >>
>>     >>>
>>     >>> If that doesnt? pan out, I question why these things need to be
>>     modeled as resources. AFAICT they have no attributes and are just
>>     addresses against which operations can be executed. I don?t see much
>>     benefit in:
>>     >>>
>>     >>>
>>     /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
>>     >>>
>>     >>> vs
>>     >>>
>>     >>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
>>     >>>
>>     >>> or
>>     >>>
>>     >>>
>>     /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
>>     >>>
>>     >>> vs
>>     >>>
>>     >>>
>>     /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
>>     >>>
>>     >>> Modeling these as resources allows you to list the identities
>>     etc via things like read-resource, read-children-names, etc but
>>     that?s both a feature and a bug. ;) A list-identities op on the
>>     realm accomplishes much the same thing.
>>     >>>
>>     >>>
>>     >>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com
>>     <mailto:jkalina at redhat.com>> wrote:
>>     >>>>
>>     >>>> Hi,
>>     >>>> I am just checking how wildfly controller handle dynamic
>>     resources because
>>     >>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>     >>>> include-runtime=false) asks parent resource for list of all
>>     dynamic (runtime only)
>>     >>>> children.
>>     >>>>
>>     >>>> For example query:
>>     >>>>
>>     /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>     >>>> will cause "server" resource (child of messaging-activemq) is
>>     asked for list
>>     >>>> of all "core-address" (call getChildren("core-address")), even
>>     trough they are not
>>     >>>> displayed as part of operation result - only blank placeholder
>>     is printed:
>>     >>>> "core-address" => undefined,
>>     >>>>
>>     >>>> This is problem especially in case of new Elytron resources
>>     which allow to browse
>>     >>>> user identities using AS model - every :read-resource on root
>>     or every AS boot
>>     >>>> currently causes iterating over all users/identities available
>>     in all concerned realms.
>>     >>>>
>>     >>>> Is this design problem?
>>     >>>> Is there some reason why should wildfly controller ask for all
>>     resource children
>>     >>>> even when they are ignored and not printed?
>>     >>>> What do you think about it? How should be resources with
>>     dynamic children handled?
>>     >>>>
>>     >>>> Thanks,
>>     >>>> Honza
>>     >>>> _______________________________________________
>>     >>>> 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
>>     >>> 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
>>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>     >>
>>     >> --
>>     >> Brian Stansberry
>>     >> Manager, Senior Principal Software Engineer
>>     >> JBoss by Red Hat
>>     >>
>>     >>
>>     >>
>>     >>
>>     >
>>     > --
>>     > Brian Stansberry
>>     > Manager, Senior Principal Software Engineer
>>     > JBoss by Red Hat
>>
>>     --
>>     Brian Stansberry
>>     Manager, Senior Principal Software Engineer
>>     JBoss by Red Hat
>>
>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From brian.stansberry at redhat.com  Mon Apr 24 15:36:48 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 24 Apr 2017 14:36:48 -0500
Subject: [wildfly-dev] read-resource (even with include-runtime=false)
	iterates over dynamic children
In-Reply-To: <733ab0e0-3866-6841-ca2b-29d237b674c2@redhat.com>
References: <CANvHcN-meyWDPWPY+O1naR51-7L5rmMkdSLbZyE-FNaU-b2PYQ@mail.gmail.com>
	<5D2A4884-3BDF-4238-BECA-25A3E51876DD@redhat.com>
	<67E03A6C-EAA0-499D-B008-45F7E8CD21A1@redhat.com>
	<CANvHcN8XNiBz7-erSfSrPN6u29SVV+Mgp8fWhHum6Ga0BeqkTQ@mail.gmail.com>
	<75EF98E9-5453-4E28-A227-81BF35A8990B@redhat.com>
	<15A862C1-1E81-4122-B4EA-3740B5920E7E@redhat.com>
	<CANvHcN8wi7XV_9fZ16rnWe_=XkzFgkrrVYGJ96ttPtwMhX-oBA@mail.gmail.com>
	<b501b725-d2c4-36ef-aa27-aa36fdd000cd@jboss.com>
	<733ab0e0-3866-6841-ca2b-29d237b674c2@redhat.com>
Message-ID: <F6DB869F-AC81-42D6-BA11-FE110E5AD7F8@redhat.com>

I agree.

The kernel can be better about the JMX stuff I think, but some cases like MBeanServer.getMBeanCount() mean there?s no alternative to identifying every resource. But for some less extreme cases we can be better I think by avoiding the unknown-cost runtime-only resources and just dealing with the known-cost ManagementResourceRegistration data. I filed a JIRA for that:

https://issues.jboss.org/browse/WFCORE-2719

> On Apr 24, 2017, at 1:20 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> +1, in consideration of all the facts this seems like a better approach.
> 
> On 04/24/2017 12:54 PM, Darran Lofthouse wrote:
>> Moving away from resources to operations may make more sense -
>> especially for realms with large a number of identities.
>> 
>> On 24/04/17 18:44, Jan Kalina wrote:
>>> Darran, when consider mentioned problems (especially getting amount of
>>> all mbeans and other operations
>>> on mbeans, where we cannot filter runtime only things out) do we have
>>> same reason to represent identities as resources?
>>> (Using realm operations instead sounds reasonable.)
>>> 
>>> On Mon, Apr 24, 2017 at 4:29 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>>> 
>>>    Here?s my last post again. For some reason my mail client decide to
>>>    encrypt it when it resent it.
>>> 
>>>> On Apr 23, 2017, at 7:31 AM, Brian Stansberry
>>>    <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>>    wrote:
>>>> 
>>>>> On Apr 21, 2017, at 2:22 AM, Jan Kalina <jkalina at redhat.com
>>>    <mailto:jkalina at redhat.com>> wrote:
>>>>> 
>>>>> Not sure if it helps for JMX, but at least for management I see
>>>    the core of the problem in obtaining
>>>>> children of node even through there is placeholder pushed into
>>>    the operation result...
>>>>> It is something for which I dont see any reason - this should be
>>>    possible to fix even without management behaviour change.
>>>>> 
>>>> 
>>>> There is a placeholder per address. Even if we made the
>>>    placeholder objects go away, we have a requirement to list the child
>>>    addresses that cannot be made to go away. The critical cost here is
>>>    identifying those addresses, more so than manipulating the
>>>    placeholder objects. Identifying those addresses means making a
>>>    remote call to an LDAP server and iterating over possibly thousands
>>>    of results.
>>>> 
>>>>> Not experienced in JMX, but are not the same placeholders used
>>>    here too? (if yes, it could be the same problem?)
>>>>> 
>>>> 
>>>> If we say an identity is a management resource, that means we can
>>>    produce an mbean for it. And that means JMX ops like
>>>    MBeanServer.getMBeanCount() need to access all of those resources,
>>>    at a minimum to know their address.
>>>> 
>>>> Why do these identities need to be represented as management
>>>    resources?
>>>> 
>>>>> 
>>>>> On Thu, Apr 20, 2017 at 8:50 PM, Brian Stansberry
>>>    <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>>    wrote:
>>>>> 
>>>>>> On Apr 20, 2017, at 12:22 PM, Brian Stansberry
>>>    <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>>>    wrote:
>>>>>> 
>>>>>> I know that internally it?s useful in a number of places to know
>>>    what children a resource has even without knowing their details
>>>    beyond their address. If it?s useful internally it seems like it
>>>    could be useful to outside callers too. I don?t know if HAL uses it.
>>>>>> 
>>>>>> Removing that data would be a breaking change in our responses.
>>>    Perhaps we could consider it for the
>>>    :read-resource(include-runtime=false) case since the user has
>>>    explicitly said they want things excluded, but for non-recursive
>>>    :read-resource() (i.e. include-runtime=true) that would be a bigger
>>>    problem with no way for users to get the data without using
>>>    recursive=true.
>>>>>> 
>>>>>> Regardless of that, having management resources represent remote
>>>    objects is problematic for JMX. All management resources, dynamic or
>>>    not, are available via JMX. MBeanServerConnection.getMBeanCount()
>>>    and various uses of queryNames and queryMBeans with ObjectName
>>>    patterns as the param result in needing to access all these
>>>    resources. I can?t find any JMX API that would make it easy for
>>>    users to say ?except the runtime-only ones? plus I think some users
>>>    wouldn?t be interested in that kind of thing anyway. I?ve heard of
>>>    general purpose agent tools that do this kind of thing.
>>>>>> 
>>>>>> One thought I had as I wrote this is perhaps marking the
>>>    resources as remote may help. I don?t believe we expose remote
>>>    resources via JMX, and if we do that sounds like a bug. Up to now,
>>>    ?remote? has been used for the resource for other WF processes in a
>>>    managed domain, but perhaps the use of the concept could be expanded.
>>>>>> 
>>>>>> So, we should look into ?remote? and maybe all this goes away. :)
>>>>> 
>>>>> I poked a bit and while this may be an interesting thing to
>>>    explore some day it?s not something practical for WF 11. The
>>>    handling of ?remote? resource types is based on their being no
>>>    Resource instances for them in the local resource tree, and then a
>>>    special ManagementResourceRegistration is registered for each
>>>    individual resource (/host=slave, /server=server-one etc) that
>>>    proxies any operations addressed to that specific resource to a
>>>    remote WildFly process. It?s not something applicable to other sorts
>>>    of usage.
>>>>> 
>>>>>> 
>>>>>> If that doesnt? pan out, I question why these things need to be
>>>    modeled as resources. AFAICT they have no attributes and are just
>>>    addresses against which operations can be executed. I don?t see much
>>>    benefit in:
>>>>>> 
>>>>>> 
>>>    /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:read-identity
>>>>>> 
>>>>>> vs
>>>>>> 
>>>>>> /subsystem=elytron/ldap-realm=ldapRealm:read-identity(name=ldapUser)
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> 
>>>    /subsystem=elytron/ldap-realm=ldapRealm/identity=ldapUser:add(foo=bar,xyz=true)
>>>>>> 
>>>>>> vs
>>>>>> 
>>>>>> 
>>>    /subsystem=elytron/ldap-realm=ldapRealm:add-identity(name=ldapUser,foo=bar,xyz=true)
>>>>>> 
>>>>>> Modeling these as resources allows you to list the identities
>>>    etc via things like read-resource, read-children-names, etc but
>>>    that?s both a feature and a bug. ;) A list-identities op on the
>>>    realm accomplishes much the same thing.
>>>>>> 
>>>>>> 
>>>>>>> On Apr 20, 2017, at 11:45 AM, Jan Kalina <jkalina at redhat.com
>>>    <mailto:jkalina at redhat.com>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> I am just checking how wildfly controller handle dynamic
>>>    resources because
>>>>>>> issue (WFCORE-2691) where every recursive :read-resource (even with
>>>>>>> include-runtime=false) asks parent resource for list of all
>>>    dynamic (runtime only)
>>>>>>> children.
>>>>>>> 
>>>>>>> For example query:
>>>>>>> 
>>>    /subsystem=messaging-activemq:read-resource(include-runtime=false,recursive=true)
>>>>>>> will cause "server" resource (child of messaging-activemq) is
>>>    asked for list
>>>>>>> of all "core-address" (call getChildren("core-address")), even
>>>    trough they are not
>>>>>>> displayed as part of operation result - only blank placeholder
>>>    is printed:
>>>>>>> "core-address" => undefined,
>>>>>>> 
>>>>>>> This is problem especially in case of new Elytron resources
>>>    which allow to browse
>>>>>>> user identities using AS model - every :read-resource on root
>>>    or every AS boot
>>>>>>> currently causes iterating over all users/identities available
>>>    in all concerned realms.
>>>>>>> 
>>>>>>> Is this design problem?
>>>>>>> Is there some reason why should wildfly controller ask for all
>>>    resource children
>>>>>>> even when they are ignored and not printed?
>>>>>>> What do you think about it? How should be resources with
>>>    dynamic children handled?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Honza
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> 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
>>>    <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>> 
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>> 
>>>    --
>>>    Brian Stansberry
>>>    Manager, Senior Principal Software Engineer
>>>    JBoss by Red Hat
>>> 
>>> 
>>> 
>>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat





From rory.odonnell at oracle.com  Fri Apr 28 06:01:33 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 28 Apr 2017 11:01:33 +0100
Subject: [wildfly-dev] JDK 9 EA Build 167 and JDK 8u152 build 03 are
 available on jdk.java.net
Message-ID: <4548a322-d5b4-2953-f51d-c228b4af2dbc@oracle.com>


Hi Jason/Tomaz,


*JDK 9 Early Access*  build 167  is available at the new location : - 
jdk.java.net/9/

A summary of all the changes in this build are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+167.html>. One change 
that maybe of interest is :

  *    JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage
    Collector [1]

*
*

*JDK 8u152 Early Access* build 03 is available at the new location : - 
jdk.java.net/8/ <http://jdk.java.net/8/>

More information on the change of location for Early Access builds. [2]

NOTE: - Oracle's JRE and JDK Cryptographic Roadmap has been updated 
since last availability email [3]

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/005766.html
[2] 
http://mail.openjdk.java.net/pipermail/adoption-discuss/2017-April/001610.html
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.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/20170428/d583803a/attachment-0001.html 

From stuart.w.douglas at gmail.com  Sun Apr 30 19:10:16 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 1 May 2017 09:10:16 +1000
Subject: [wildfly-dev] Weld 3 & Wildfly 11 integration - help with
 security needed
In-Reply-To: <1852088519.338288.1493037155775.JavaMail.zimbra@redhat.com>
References: <1297078731.331997.1493036582744.JavaMail.zimbra@redhat.com>
	<1852088519.338288.1493037155775.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c75MNC4O5uqs+8vmPsWMdPktbBrs62tpE+JckADeMNy6Q@mail.gmail.com>

So looking at the code I am not sure if this is possible to adapt to
Elytron without an API change on the Weld side of things.

This issue is in the Weld SecurityContext, which just as associate and
disassociate methods, while elytron uses a more functional approach.

I think this API needs to be change so SecurityContext just has a
run(PrivilidgedExceptionAction action) method, where the implementation
would look something like:

elytronDomain.getCurrentSecurityIdentity().runAs(action)

Not sure how hard to do this will be from the Weld side and I am not sure
how this method is actually used.

Stuart



On Mon, Apr 24, 2017 at 10:32 PM, Matej Novotny <manovotn at redhat.com> wrote:

> Hello,
>
> recently I decided, that Weld 3 (CDI 2.0, currently nearing Final at high
> speed) should be running on WildFly 11.
> Up until now, we had the integration based on 10.1.0.Final but for several
> reasons we want to move to 11.
>
> There were some changes and I figured out most of them but I am lost when
> it comes to security.
> I know Elytron was added but I don't know a damn thing about it - could
> anyone lend a hand here, please?
>
> The code is now located at this branch[1] and the very last commit shows
> the integration done.
> Vast majority is just taken from previous integration with 10.1.0.Final
> (branch 10.1.0.Final-weld3).
> The part I am concerned about is weld/subsystem/src/main/java/
> org/jboss/as/weld/services/bootstrap/WeldSecurityServices.java [2]
> 'getPrincipal'[3] method was earlier adapted to Elytron, and I am thinking
> the other methods should perhaps be adjusted as well?
> But then again, I have no idea how to do that with Elytron... a penny for
> your thoughts?
>
> Regards
> Matej
>
> ____________________________________________________________
> ________________________________________________________________________
> [1]https://github.com/weld/wildfly/tree/11.0.0.Alpha1-weld3
> [2]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-
> weld3/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/
> WeldSecurityServices.java
> [3]https://github.com/weld/wildfly/blob/11.0.0.Alpha1-
> weld3/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/
> WeldSecurityServices.java#L69
> _______________________________________________
> 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/20170501/a40cb1e3/attachment.html