From gunnar at hibernate.org  Thu Dec  1 03:45:34 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 1 Dec 2016 09:45:34 +0100
Subject: [wildfly-dev] Jandex - Retrieving meta-annotations
Message-ID: <CADGJaX-vx03uwfnCJZzE0G8fgBDMLt1YruaJcbVKMRswjao9kA@mail.gmail.com>

Hi,

Two questions on Jandex usage:

* When having a org.jboss.jandex.AnnotationInstance, how could one obtain
any meta-annotations given for the annotation's *type*?
* Is there any example for obtaining Java 8 type annotations, e.g. from a
FieldInfo?

Thanks for any pointers,

--Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161201/495451f2/attachment.html 

From jcacek at redhat.com  Fri Dec  2 03:11:57 2016
From: jcacek at redhat.com (Josef Cacek)
Date: Fri, 2 Dec 2016 03:11:57 -0500 (EST)
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
Message-ID: <260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>

Hi,

EAP QE and Elytron Dev teams would like to raise a discussion about how the Elytron integration tests will be added to the WildFly/EAP testsuite.
We would like to agree on a unified approach across the testsuite, so we don't end up in situation where each component comes with its own "best-fitting" solution.

We see following requirements:
1. new features which come with Elytron need to be covered by integration tests
2. existing scenarios have to stay working when Elytron is configured as the default security subsystem
3. legacy security subsystem must stay working in parallel

Our teams came to agreement that the safest way would be to copy whole existing testsuite modules into new ones. E.g. 

cp -r testsuite/integration/basic testsuite/integration/basic-legacy-security
# + Reconfigure testsuite/integration/basic to use Elytron
# + Add @Ignore to all tests which fail with Elytron or use directly the old security configuration

The modules would just live side by side - basic would use Elytron configuration, basic-legacy-security would use configuration similar to (or same as) the current server configuration.

In the next step we will go through the Ignored tests (the TODO list) for Elytron and rewrite them or report issues if necessary.

By this way we would keep all the test coverage for legacy security. We would also have all existing scenarios covered (or at least present) for Elytron configuration.

Are there any objections to this suggestion?

Thanks,

-- Josef

From tomaz.cerar at gmail.com  Fri Dec  2 06:03:18 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 2 Dec 2016 12:03:18 +0100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>

On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek <jcacek at redhat.com> wrote:

> The modules would just live side by side - basic would use Elytron
> configuration, basic-legacy-security would use configuration similar to (or
> same as) the current server configuration.



What would this actually mean?
we will have two copies basic tests suites one running with elytron another
with legacy security subsystem?

Do I read that right? Please say I am not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161202/d6f14ae3/attachment.html 

From darran.lofthouse at jboss.com  Fri Dec  2 06:08:18 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 2 Dec 2016 11:08:18 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
Message-ID: <0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>

On 02/12/16 11:03, Toma? Cerar wrote:
>
> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek <jcacek at redhat.com
> <mailto:jcacek at redhat.com>> wrote:
>
>     The modules would just live side by side - basic would use Elytron
>     configuration, basic-legacy-security would use configuration similar
>     to (or same as) the current server configuration.
>
>
>
> What would this actually mean?
> we will have two copies basic tests suites one running with elytron
> another with legacy security subsystem?
>
> Do I read that right? Please say I am not.

That is correct - we have two security implementations they both need 
testing.

One needs testing for backwards compatibility and regressions, the other 
for equivalent behaviour and then new features and bugs.

Needing to test both was discussed previously so this is more about how 
to separate both and also give the Elytron testing a good foundation to 
start from.

>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From darran.lofthouse at jboss.com  Fri Dec  2 06:09:28 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 2 Dec 2016 11:09:28 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
Message-ID: <4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>

Probably should add - any duplication should only be for security tests 
- not everything else in there!

On 02/12/16 11:08, Darran Lofthouse wrote:
> On 02/12/16 11:03, Toma? Cerar wrote:
>>
>> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek <jcacek at redhat.com
>> <mailto:jcacek at redhat.com>> wrote:
>>
>>     The modules would just live side by side - basic would use Elytron
>>     configuration, basic-legacy-security would use configuration similar
>>     to (or same as) the current server configuration.
>>
>>
>>
>> What would this actually mean?
>> we will have two copies basic tests suites one running with elytron
>> another with legacy security subsystem?
>>
>> Do I read that right? Please say I am not.
>
> That is correct - we have two security implementations they both need
> testing.
>
> One needs testing for backwards compatibility and regressions, the other
> for equivalent behaviour and then new features and bugs.
>
> Needing to test both was discussed previously so this is more about how
> to separate both and also give the Elytron testing a good foundation to
> start from.
>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>


From jcacek at redhat.com  Fri Dec  2 06:16:57 2016
From: jcacek at redhat.com (Josef Cacek)
Date: Fri, 2 Dec 2016 06:16:57 -0500 (EST)
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
Message-ID: <1136382203.785044.1480677417157.JavaMail.zimbra@redhat.com>

> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com > wrote:

> > The modules would just live side by side - basic would use Elytron
> > configuration, basic-legacy-security would use configuration similar to (or
> > same as) the current server configuration.
> 
> What would this actually mean?
> we will have two copies basic tests suites one running with elytron another
> with legacy security subsystem?

> Do I read that right? Please say I am not.

Not only the "basic". All testsuite modules in ideal case.

From tomaz.cerar at gmail.com  Fri Dec  2 06:37:22 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 2 Dec 2016 12:37:22 +0100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
Message-ID: <CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>

That is probably fine, but! it should be done differently.

instead of duplicating whole testsuite (and adding extra hour to execution
and extra headaches with intermittent problems and duplication of
maintenance)
I would suggest that all security related tests get extracted to new
"security" testsuite module and than only that part is duplicated.

This way we will have all security related stuff in one place.



On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> Probably should add - any duplication should only be for security tests
> - not everything else in there!
>
> On 02/12/16 11:08, Darran Lofthouse wrote:
> > On 02/12/16 11:03, Toma? Cerar wrote:
> >>
> >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek <jcacek at redhat.com
> >> <mailto:jcacek at redhat.com>> wrote:
> >>
> >>     The modules would just live side by side - basic would use Elytron
> >>     configuration, basic-legacy-security would use configuration similar
> >>     to (or same as) the current server configuration.
> >>
> >>
> >>
> >> What would this actually mean?
> >> we will have two copies basic tests suites one running with elytron
> >> another with legacy security subsystem?
> >>
> >> Do I read that right? Please say I am not.
> >
> > That is correct - we have two security implementations they both need
> > testing.
> >
> > One needs testing for backwards compatibility and regressions, the other
> > for equivalent behaviour and then new features and bugs.
> >
> > Needing to test both was discussed previously so this is more about how
> > to separate both and also give the Elytron testing a good foundation to
> > start from.
> >
> >>
> >>
> >> _______________________________________________
> >> 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/20161202/15d1acd0/attachment-0001.html 

From darran.lofthouse at jboss.com  Fri Dec  2 06:45:42 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 2 Dec 2016 11:45:42 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
Message-ID: <235de8d8-c394-51af-c907-53a14a401430@jboss.com>

Although after my e-mail I hear from Josef they do want to duplicate all ;-)

 From my perspective I think we want to ensure the security tests are 
clearly split in some way so we can identify legacy tests and Elytron 
tests independently.

When it comes to code review the legacy tests are much more about 
backwards compatibility so any changes to those should be given greater 
scrutiny.

Secondly we should hit a point where we can remove the old tests so 
separation will make that easier.

A package split would be fine but maybe a project split would make it 
easier to define which tests are run and when.

Instead maybe we could split it into three: -

basic, basic-legacy-security, basic-security

The two 'security' projects would be the different form of security 
testing, maybe the 'basic' project could have an optional profile to 
switch it to a 100% legacy config mode.


On 02/12/16 11:37, Toma? Cerar wrote:
> That is probably fine, but! it should be done differently.
>
> instead of duplicating whole testsuite (and adding extra hour to
> execution and extra headaches with intermittent problems and duplication
> of maintenance)
> I would suggest that all security related tests get extracted to new
> "security" testsuite module and than only that part is duplicated.
>
> This way we will have all security related stuff in one place.
>
>
>
> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse
> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>
>     Probably should add - any duplication should only be for security tests
>     - not everything else in there!
>
>     On 02/12/16 11:08, Darran Lofthouse wrote:
>     > On 02/12/16 11:03, Toma? Cerar wrote:
>     >>
>     >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek <jcacek at redhat.com
>     <mailto:jcacek at redhat.com>
>     >> <mailto:jcacek at redhat.com <mailto:jcacek at redhat.com>>> wrote:
>     >>
>     >>     The modules would just live side by side - basic would use
>     Elytron
>     >>     configuration, basic-legacy-security would use configuration
>     similar
>     >>     to (or same as) the current server configuration.
>     >>
>     >>
>     >>
>     >> What would this actually mean?
>     >> we will have two copies basic tests suites one running with elytron
>     >> another with legacy security subsystem?
>     >>
>     >> Do I read that right? Please say I am not.
>     >
>     > That is correct - we have two security implementations they both need
>     > testing.
>     >
>     > One needs testing for backwards compatibility and regressions, the
>     other
>     > for equivalent behaviour and then new features and bugs.
>     >
>     > Needing to test both was discussed previously so this is more
>     about how
>     > to separate both and also give the Elytron testing a good
>     foundation to
>     > start from.
>     >
>     >>
>     >>
>     >> _______________________________________________
>     >> 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 <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>

From jcacek at redhat.com  Fri Dec  2 06:58:35 2016
From: jcacek at redhat.com (Josef Cacek)
Date: Fri, 2 Dec 2016 06:58:35 -0500 (EST)
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
Message-ID: <563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>

We prefer duplication of all tests in the testsuite to keep test coverage.

To be sure we don't have regressions with introducing Elytron and at the same time we are able to cover current features with Elytron, we must run all tests with both security subsystems.
Even if a test is not security related on the first glance, the tested component may use a security feature internally. By switching to the new security subsystem the feature may stop work.

Let's keep the current (legacy security based) tests alive until the legacy security subsystem is fully removed. 
Then we'll simply remove the *-legacy-security testsuite modules.

-- Josef

----- Original Message -----
> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Friday, December 2, 2016 12:37:22 PM
> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> 
> That is probably fine, but! it should be done differently.
> 
> instead of duplicating whole testsuite (and adding extra hour to execution
> and extra headaches with intermittent problems and duplication of
> maintenance)
> I would suggest that all security related tests get extracted to new
> "security" testsuite module and than only that part is duplicated.
> 
> This way we will have all security related stuff in one place.
> 
> 
> 
> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
> darran.lofthouse at jboss.com > wrote:
> 
> 
> Probably should add - any duplication should only be for security tests
> - not everything else in there!
> 
> On 02/12/16 11:08, Darran Lofthouse wrote:
> > On 02/12/16 11:03, Toma? Cerar wrote:
> >> 
> >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
> >> <mailto: jcacek at redhat.com >> wrote:
> >> 
> >> The modules would just live side by side - basic would use Elytron
> >> configuration, basic-legacy-security would use configuration similar
> >> to (or same as) the current server configuration.
> >> 
> >> 
> >> 
> >> What would this actually mean?
> >> we will have two copies basic tests suites one running with elytron
> >> another with legacy security subsystem?
> >> 
> >> Do I read that right? Please say I am not.
> > 
> > That is correct - we have two security implementations they both need
> > testing.
> > 
> > One needs testing for backwards compatibility and regressions, the other
> > for equivalent behaviour and then new features and bugs.
> > 
> > Needing to test both was discussed previously so this is more about how
> > to separate both and also give the Elytron testing a good foundation to
> > start from.
> > 
> >> 
> >> 
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> 
> > 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From jkalina at redhat.com  Fri Dec  2 07:13:14 2016
From: jkalina at redhat.com (Jan Kalina)
Date: Fri, 2 Dec 2016 13:13:14 +0100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
Message-ID: <CANvHcN-LjN9Dp5-Q5ivQiGRiAO5vOYtoJqY22oJ0BYUfjs_a_g@mail.gmail.com>

I agree with Josef - it looks like more or less most of integration
tests can be affected by security features.

On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com> wrote:
> We prefer duplication of all tests in the testsuite to keep test coverage.
>
> To be sure we don't have regressions with introducing Elytron and at the same time we are able to cover current features with Elytron, we must run all tests with both security subsystems.
> Even if a test is not security related on the first glance, the tested component may use a security feature internally. By switching to the new security subsystem the feature may stop work.
>
> Let's keep the current (legacy security based) tests alive until the legacy security subsystem is fully removed.
> Then we'll simply remove the *-legacy-security testsuite modules.
>
> -- Josef
>
> ----- Original Message -----
>> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Friday, December 2, 2016 12:37:22 PM
>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
>>
>> That is probably fine, but! it should be done differently.
>>
>> instead of duplicating whole testsuite (and adding extra hour to execution
>> and extra headaches with intermittent problems and duplication of
>> maintenance)
>> I would suggest that all security related tests get extracted to new
>> "security" testsuite module and than only that part is duplicated.
>>
>> This way we will have all security related stuff in one place.
>>
>>
>>
>> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>> darran.lofthouse at jboss.com > wrote:
>>
>>
>> Probably should add - any duplication should only be for security tests
>> - not everything else in there!
>>
>> On 02/12/16 11:08, Darran Lofthouse wrote:
>> > On 02/12/16 11:03, Toma? Cerar wrote:
>> >>
>> >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
>> >> <mailto: jcacek at redhat.com >> wrote:
>> >>
>> >> The modules would just live side by side - basic would use Elytron
>> >> configuration, basic-legacy-security would use configuration similar
>> >> to (or same as) the current server configuration.
>> >>
>> >>
>> >>
>> >> What would this actually mean?
>> >> we will have two copies basic tests suites one running with elytron
>> >> another with legacy security subsystem?
>> >>
>> >> Do I read that right? Please say I am not.
>> >
>> > That is correct - we have two security implementations they both need
>> > testing.
>> >
>> > One needs testing for backwards compatibility and regressions, the other
>> > for equivalent behaviour and then new features and bugs.
>> >
>> > Needing to test both was discussed previously so this is more about how
>> > to separate both and also give the Elytron testing a good foundation to
>> > start from.
>> >
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From tomaz.cerar at gmail.com  Fri Dec  2 09:47:47 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 2 Dec 2016 15:47:47 +0100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>

So if I understood all this correctly,
this mail here was more of a heads up what is happening
than a discussion on how could or should be best done.

I just hope you (the team behind decisions) considered all scenarios how
will that impact everyone involved.

--
tomaz

On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com> wrote:

> We prefer duplication of all tests in the testsuite to keep test coverage.
>
> To be sure we don't have regressions with introducing Elytron and at the
> same time we are able to cover current features with Elytron, we must run
> all tests with both security subsystems.
> Even if a test is not security related on the first glance, the tested
> component may use a security feature internally. By switching to the new
> security subsystem the feature may stop work.
>
> Let's keep the current (legacy security based) tests alive until the
> legacy security subsystem is fully removed.
> Then we'll simply remove the *-legacy-security testsuite modules.
>
> -- Josef
>
> ----- Original Message -----
> > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Friday, December 2, 2016 12:37:22 PM
> > Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> >
> > That is probably fine, but! it should be done differently.
> >
> > instead of duplicating whole testsuite (and adding extra hour to
> execution
> > and extra headaches with intermittent problems and duplication of
> > maintenance)
> > I would suggest that all security related tests get extracted to new
> > "security" testsuite module and than only that part is duplicated.
> >
> > This way we will have all security related stuff in one place.
> >
> >
> >
> > On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
> > darran.lofthouse at jboss.com > wrote:
> >
> >
> > Probably should add - any duplication should only be for security tests
> > - not everything else in there!
> >
> > On 02/12/16 11:08, Darran Lofthouse wrote:
> > > On 02/12/16 11:03, Toma? Cerar wrote:
> > >>
> > >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
> > >> <mailto: jcacek at redhat.com >> wrote:
> > >>
> > >> The modules would just live side by side - basic would use Elytron
> > >> configuration, basic-legacy-security would use configuration similar
> > >> to (or same as) the current server configuration.
> > >>
> > >>
> > >>
> > >> What would this actually mean?
> > >> we will have two copies basic tests suites one running with elytron
> > >> another with legacy security subsystem?
> > >>
> > >> Do I read that right? Please say I am not.
> > >
> > > That is correct - we have two security implementations they both need
> > > testing.
> > >
> > > One needs testing for backwards compatibility and regressions, the
> other
> > > for equivalent behaviour and then new features and bugs.
> > >
> > > Needing to test both was discussed previously so this is more about how
> > > to separate both and also give the Elytron testing a good foundation to
> > > start from.
> > >
> > >>
> > >>
> > >> _______________________________________________
> > >> 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/20161202/27748047/attachment-0001.html 

From darran.lofthouse at jboss.com  Fri Dec  2 09:59:41 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 2 Dec 2016 14:59:41 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
Message-ID: <b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>

No the part we can't avoid is that we have two security implementations 
in the server and we have to have tests for both.  The e-mail from Josef 
is a suggestion as to how this will be achieved.

Other suggestions are welcome ;-)

But we have two security implementations to test.

One of these is deprecated and will hopefully be removed at some point 
so ideally we have something that allows testing to legacy to be removed 
without too much pain.

Writing sufficient test coverage is not a small task so anything that 
gives us more than starting from scratch is a benefit.

But maybe it would be worth summarising these additional scenarios that 
will be affected by changes.

Regards,
Darran Lofthouse.

On 02/12/16 14:47, Toma? Cerar wrote:
> So if I understood all this correctly,
> this mail here was more of a heads up what is happening
> than a discussion on how could or should be best done.
>
> I just hope you (the team behind decisions) considered all scenarios how
> will that impact everyone involved.
>
> --
> tomaz
>
> On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com
> <mailto:jcacek at redhat.com>> wrote:
>
>     We prefer duplication of all tests in the testsuite to keep test
>     coverage.
>
>     To be sure we don't have regressions with introducing Elytron and at
>     the same time we are able to cover current features with Elytron, we
>     must run all tests with both security subsystems.
>     Even if a test is not security related on the first glance, the
>     tested component may use a security feature internally. By switching
>     to the new security subsystem the feature may stop work.
>
>     Let's keep the current (legacy security based) tests alive until the
>     legacy security subsystem is fully removed.
>     Then we'll simply remove the *-legacy-security testsuite modules.
>
>     -- Josef
>
>     ----- Original Message -----
>     > From: "Toma? Cerar" <tomaz.cerar at gmail.com
>     <mailto:tomaz.cerar at gmail.com>>
>     > To: "Darran Lofthouse" <darran.lofthouse at jboss.com
>     <mailto:darran.lofthouse at jboss.com>>
>     > Cc: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     > Sent: Friday, December 2, 2016 12:37:22 PM
>     > Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>     testsuite
>     >
>     > That is probably fine, but! it should be done differently.
>     >
>     > instead of duplicating whole testsuite (and adding extra hour to
>     execution
>     > and extra headaches with intermittent problems and duplication of
>     > maintenance)
>     > I would suggest that all security related tests get extracted to new
>     > "security" testsuite module and than only that part is duplicated.
>     >
>     > This way we will have all security related stuff in one place.
>     >
>     >
>     >
>     > On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>     > darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com> >
>     wrote:
>     >
>     >
>     > Probably should add - any duplication should only be for security
>     tests
>     > - not everything else in there!
>     >
>     > On 02/12/16 11:08, Darran Lofthouse wrote:
>     > > On 02/12/16 11:03, Toma? Cerar wrote:
>     > >>
>     > >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
>     <mailto:jcacek at redhat.com>
>     > >> <mailto: jcacek at redhat.com <mailto:jcacek at redhat.com> >> wrote:
>     > >>
>     > >> The modules would just live side by side - basic would use Elytron
>     > >> configuration, basic-legacy-security would use configuration
>     similar
>     > >> to (or same as) the current server configuration.
>     > >>
>     > >>
>     > >>
>     > >> What would this actually mean?
>     > >> we will have two copies basic tests suites one running with elytron
>     > >> another with legacy security subsystem?
>     > >>
>     > >> Do I read that right? Please say I am not.
>     > >
>     > > That is correct - we have two security implementations they both
>     need
>     > > testing.
>     > >
>     > > One needs testing for backwards compatibility and regressions,
>     the other
>     > > for equivalent behaviour and then new features and bugs.
>     > >
>     > > Needing to test both was discussed previously so this is more
>     about how
>     > > to separate both and also give the Elytron testing a good
>     foundation to
>     > > start from.
>     > >
>     > >>
>     > >>
>     > >> _______________________________________________
>     > >> 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 <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 <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  Fri Dec  2 10:20:12 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 2 Dec 2016 09:20:12 -0600
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
Message-ID: <6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>

Duplicating the whole testsuite is basically a minimal effort way of getting coverage by avoiding the task of test coverage analysis.

Only justification for that is expediency. That may be sufficient justification; I don?t know.

But assuming for the sake of argument it?s sufficient, doubling the amount of time needed to run the testsuite is a massive productivity loss and that means cutting that time down to the necessary minimum and nothing more would need to be a critical extreme high priority task.

So, with this proposal, who would be the people assigned to this critical extreme high priority task? I?d like to see names, lots and lots of names. Darran Lofthouse not among them. ;)


> On Dec 2, 2016, at 8:59 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> No the part we can't avoid is that we have two security implementations 
> in the server and we have to have tests for both.  The e-mail from Josef 
> is a suggestion as to how this will be achieved.
> 
> Other suggestions are welcome ;-)
> 
> But we have two security implementations to test.
> 
> One of these is deprecated and will hopefully be removed at some point 
> so ideally we have something that allows testing to legacy to be removed 
> without too much pain.
> 
> Writing sufficient test coverage is not a small task so anything that 
> gives us more than starting from scratch is a benefit.
> 
> But maybe it would be worth summarising these additional scenarios that 
> will be affected by changes.
> 
> Regards,
> Darran Lofthouse.
> 
> On 02/12/16 14:47, Toma? Cerar wrote:
>> So if I understood all this correctly,
>> this mail here was more of a heads up what is happening
>> than a discussion on how could or should be best done.
>> 
>> I just hope you (the team behind decisions) considered all scenarios how
>> will that impact everyone involved.
>> 
>> --
>> tomaz
>> 
>> On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com
>> <mailto:jcacek at redhat.com>> wrote:
>> 
>>    We prefer duplication of all tests in the testsuite to keep test
>>    coverage.
>> 
>>    To be sure we don't have regressions with introducing Elytron and at
>>    the same time we are able to cover current features with Elytron, we
>>    must run all tests with both security subsystems.
>>    Even if a test is not security related on the first glance, the
>>    tested component may use a security feature internally. By switching
>>    to the new security subsystem the feature may stop work.
>> 
>>    Let's keep the current (legacy security based) tests alive until the
>>    legacy security subsystem is fully removed.
>>    Then we'll simply remove the *-legacy-security testsuite modules.
>> 
>>    -- Josef
>> 
>>    ----- Original Message -----
>>> From: "Toma? Cerar" <tomaz.cerar at gmail.com
>>    <mailto:tomaz.cerar at gmail.com>>
>>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com
>>    <mailto:darran.lofthouse at jboss.com>>
>>> Cc: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> Sent: Friday, December 2, 2016 12:37:22 PM
>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>>    testsuite
>>> 
>>> That is probably fine, but! it should be done differently.
>>> 
>>> instead of duplicating whole testsuite (and adding extra hour to
>>    execution
>>> and extra headaches with intermittent problems and duplication of
>>> maintenance)
>>> I would suggest that all security related tests get extracted to new
>>> "security" testsuite module and than only that part is duplicated.
>>> 
>>> This way we will have all security related stuff in one place.
>>> 
>>> 
>>> 
>>> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>>> darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com> >
>>    wrote:
>>> 
>>> 
>>> Probably should add - any duplication should only be for security
>>    tests
>>> - not everything else in there!
>>> 
>>> On 02/12/16 11:08, Darran Lofthouse wrote:
>>>> On 02/12/16 11:03, Toma? Cerar wrote:
>>>>> 
>>>>> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
>>    <mailto:jcacek at redhat.com>
>>>>> <mailto: jcacek at redhat.com <mailto:jcacek at redhat.com> >> wrote:
>>>>> 
>>>>> The modules would just live side by side - basic would use Elytron
>>>>> configuration, basic-legacy-security would use configuration
>>    similar
>>>>> to (or same as) the current server configuration.
>>>>> 
>>>>> 
>>>>> 
>>>>> What would this actually mean?
>>>>> we will have two copies basic tests suites one running with elytron
>>>>> another with legacy security subsystem?
>>>>> 
>>>>> Do I read that right? Please say I am not.
>>>> 
>>>> That is correct - we have two security implementations they both
>>    need
>>>> testing.
>>>> 
>>>> One needs testing for backwards compatibility and regressions,
>>    the other
>>>> for equivalent behaviour and then new features and bugs.
>>>> 
>>>> Needing to test both was discussed previously so this is more
>>    about how
>>>> to separate both and also give the Elytron testing a good
>>    foundation to
>>>> start from.
>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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 <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 <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

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





From kabir.khan at jboss.com  Fri Dec  2 10:28:07 2016
From: kabir.khan at jboss.com (Kabir Khan)
Date: Fri, 2 Dec 2016 15:28:07 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
Message-ID: <6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>

+1 doubling the testsuite size/time is not practical. Also, there is the issue that if all tests are duplicated, when people come to enhance an existing test they will need to do so in two places.

Could we not do what was suggested earlier and pull out tests which obviously target security into two legacy/elytron modules, and leave the rest where they are? Then if something later turns out to have 'hidden' implications, that test gets pulled out into the two modules. 

Regarding the deprecated legacy stuff, I think we will have to keep that around for many years still due to it being used by the product (and in any case in that branch, although removing it from WF might be possible sooner).


> On 2 Dec 2016, at 15:20, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Duplicating the whole testsuite is basically a minimal effort way of getting coverage by avoiding the task of test coverage analysis.
> 
> Only justification for that is expediency. That may be sufficient justification; I don?t know.
> 
> But assuming for the sake of argument it?s sufficient, doubling the amount of time needed to run the testsuite is a massive productivity loss and that means cutting that time down to the necessary minimum and nothing more would need to be a critical extreme high priority task.
> 
> So, with this proposal, who would be the people assigned to this critical extreme high priority task? I?d like to see names, lots and lots of names. Darran Lofthouse not among them. ;)
> 
> 
>> On Dec 2, 2016, at 8:59 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>> 
>> No the part we can't avoid is that we have two security implementations 
>> in the server and we have to have tests for both.  The e-mail from Josef 
>> is a suggestion as to how this will be achieved.
>> 
>> Other suggestions are welcome ;-)
>> 
>> But we have two security implementations to test.
>> 
>> One of these is deprecated and will hopefully be removed at some point 
>> so ideally we have something that allows testing to legacy to be removed 
>> without too much pain.
>> 
>> Writing sufficient test coverage is not a small task so anything that 
>> gives us more than starting from scratch is a benefit.
>> 
>> But maybe it would be worth summarising these additional scenarios that 
>> will be affected by changes.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> On 02/12/16 14:47, Toma? Cerar wrote:
>>> So if I understood all this correctly,
>>> this mail here was more of a heads up what is happening
>>> than a discussion on how could or should be best done.
>>> 
>>> I just hope you (the team behind decisions) considered all scenarios how
>>> will that impact everyone involved.
>>> 
>>> --
>>> tomaz
>>> 
>>> On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com
>>> <mailto:jcacek at redhat.com>> wrote:
>>> 
>>>   We prefer duplication of all tests in the testsuite to keep test
>>>   coverage.
>>> 
>>>   To be sure we don't have regressions with introducing Elytron and at
>>>   the same time we are able to cover current features with Elytron, we
>>>   must run all tests with both security subsystems.
>>>   Even if a test is not security related on the first glance, the
>>>   tested component may use a security feature internally. By switching
>>>   to the new security subsystem the feature may stop work.
>>> 
>>>   Let's keep the current (legacy security based) tests alive until the
>>>   legacy security subsystem is fully removed.
>>>   Then we'll simply remove the *-legacy-security testsuite modules.
>>> 
>>>   -- Josef
>>> 
>>>   ----- Original Message -----
>>>> From: "Toma? Cerar" <tomaz.cerar at gmail.com
>>>   <mailto:tomaz.cerar at gmail.com>>
>>>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com
>>>   <mailto:darran.lofthouse at jboss.com>>
>>>> Cc: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> Sent: Friday, December 2, 2016 12:37:22 PM
>>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>>>   testsuite
>>>> 
>>>> That is probably fine, but! it should be done differently.
>>>> 
>>>> instead of duplicating whole testsuite (and adding extra hour to
>>>   execution
>>>> and extra headaches with intermittent problems and duplication of
>>>> maintenance)
>>>> I would suggest that all security related tests get extracted to new
>>>> "security" testsuite module and than only that part is duplicated.
>>>> 
>>>> This way we will have all security related stuff in one place.
>>>> 
>>>> 
>>>> 
>>>> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>>>> darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com> >
>>>   wrote:
>>>> 
>>>> 
>>>> Probably should add - any duplication should only be for security
>>>   tests
>>>> - not everything else in there!
>>>> 
>>>> On 02/12/16 11:08, Darran Lofthouse wrote:
>>>>> On 02/12/16 11:03, Toma? Cerar wrote:
>>>>>> 
>>>>>> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
>>>   <mailto:jcacek at redhat.com>
>>>>>> <mailto: jcacek at redhat.com <mailto:jcacek at redhat.com> >> wrote:
>>>>>> 
>>>>>> The modules would just live side by side - basic would use Elytron
>>>>>> configuration, basic-legacy-security would use configuration
>>>   similar
>>>>>> to (or same as) the current server configuration.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> What would this actually mean?
>>>>>> we will have two copies basic tests suites one running with elytron
>>>>>> another with legacy security subsystem?
>>>>>> 
>>>>>> Do I read that right? Please say I am not.
>>>>> 
>>>>> That is correct - we have two security implementations they both
>>>   need
>>>>> testing.
>>>>> 
>>>>> One needs testing for backwards compatibility and regressions,
>>>   the other
>>>>> for equivalent behaviour and then new features and bugs.
>>>>> 
>>>>> Needing to test both was discussed previously so this is more
>>>   about how
>>>>> to separate both and also give the Elytron testing a good
>>>   foundation to
>>>>> start from.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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 <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 <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
> 
> -- 
> 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



From frainone at redhat.com  Fri Dec  2 11:56:14 2016
From: frainone at redhat.com (Flavia Rainone)
Date: Fri, 2 Dec 2016 14:56:14 -0200
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
Message-ID: <7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com>

Hi,

I'm creating this thread to discuss the remaining details of graceful 
shutdown for ejb transactions.

This is more or less what I've done so far:

https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760

While discussing this in the hip chat yesterday, Stuart mentioned that 
maybe we could have the transactions subsystem responsible for keeping 
track of how many active transactions we have, instead of putting that 
code in EjbRemoteTransactionsRepository.

Stuart, does that include having the suspend callback being done at 
transactions subsystem as well? I'm thinking maybe not, because there 
are two points in the ejb subsystem we need to know if transactions 
suspension is over:

- at EjbSuspendInterceptor if it is over, no request is allowed, if it 
is not over, we need to check if current invocation contains a reference 
to an active transaction

- at some point, we need to let control point notify that the ejb module 
is no longer available to ejb client after transaction suspension is 
over, i.e., we need to do that when suspend has been requested and there 
are no remaining active transactions available.

On the other hand, it is hard to draw the line between what should be in 
the transactions subsystem and what shouldn't. If the callback is done 
at transactions subsystem, we need a way of having ejb3 notified that it 
is done. If it is not done at transactions subsystem, ejb3 has to be 
notified of the active transactions going to zero, which seems a lot of 
overhead, so from this point of view maybe the callback should be in the 
transactions system after all.

Stuart and Gytis, any thoughts?

-- 
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466

Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161202/0569f5bf/attachment-0001.html 

From jperkins at redhat.com  Fri Dec  2 12:22:16 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 2 Dec 2016 09:22:16 -0800
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
Message-ID: <CADGwLpji_S3bUAo0pxqvAt046hQa53NAvp=NfmhSS9N4FsMMwA@mail.gmail.com>

Instead of duplicating the entire test suite can we just add a new CI job
that runs the tests with the *-elytron.xml configuration file? Duplicating
the entire testsuite will end in nothing but headaches IMO. Like Kabir
mentioned any bug in a test will need to be fixed in two locations.

On Fri, Dec 2, 2016 at 12:11 AM, Josef Cacek <jcacek at redhat.com> wrote:

> Hi,
>
> EAP QE and Elytron Dev teams would like to raise a discussion about how
> the Elytron integration tests will be added to the WildFly/EAP testsuite.
> We would like to agree on a unified approach across the testsuite, so we
> don't end up in situation where each component comes with its own
> "best-fitting" solution.
>
> We see following requirements:
> 1. new features which come with Elytron need to be covered by integration
> tests
> 2. existing scenarios have to stay working when Elytron is configured as
> the default security subsystem
> 3. legacy security subsystem must stay working in parallel
>
> Our teams came to agreement that the safest way would be to copy whole
> existing testsuite modules into new ones. E.g.
>
> cp -r testsuite/integration/basic testsuite/integration/basic-
> legacy-security
> # + Reconfigure testsuite/integration/basic to use Elytron
> # + Add @Ignore to all tests which fail with Elytron or use directly the
> old security configuration
>
> The modules would just live side by side - basic would use Elytron
> configuration, basic-legacy-security would use configuration similar to (or
> same as) the current server configuration.
>
> In the next step we will go through the Ignored tests (the TODO list) for
> Elytron and rewrite them or report issues if necessary.
>
> By this way we would keep all the test coverage for legacy security. We
> would also have all existing scenarios covered (or at least present) for
> Elytron configuration.
>
> Are there any objections to this suggestion?
>
> Thanks,
>
> -- Josef
> _______________________________________________
> 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/20161202/369d8a6a/attachment.html 

From jason.greene at redhat.com  Fri Dec  2 13:22:33 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 2 Dec 2016 12:22:33 -0600
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CADGwLpji_S3bUAo0pxqvAt046hQa53NAvp=NfmhSS9N4FsMMwA@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CADGwLpji_S3bUAo0pxqvAt046hQa53NAvp=NfmhSS9N4FsMMwA@mail.gmail.com>
Message-ID: <467E89B9-97EC-4C2D-9E79-F2D23A8FC7FB@redhat.com>

While it?s important that we maintain some legacy coverage, I think its important that our testsuite prioritize coverage of the new vs the legacy, and this can be done organically. New tests should use elytron, and old tests that are updated, which aren?t specifically testing legacy compatibility should be converted over gradually, when convenient. 

My main rationale hare is that code which is continually evolved is more likely to break than that which is largely frozen. It?s really the interop pieces that interact with legacy areas that are of most in need of continued coverage.

> On Dec 2, 2016, at 11:22 AM, James Perkins <jperkins at redhat.com> wrote:
> 
> Instead of duplicating the entire test suite can we just add a new CI job that runs the tests with the *-elytron.xml configuration file? Duplicating the entire testsuite will end in nothing but headaches IMO. Like Kabir mentioned any bug in a test will need to be fixed in two locations.
> 
> On Fri, Dec 2, 2016 at 12:11 AM, Josef Cacek <jcacek at redhat.com <mailto:jcacek at redhat.com>> wrote:
> Hi,
> 
> EAP QE and Elytron Dev teams would like to raise a discussion about how the Elytron integration tests will be added to the WildFly/EAP testsuite.
> We would like to agree on a unified approach across the testsuite, so we don't end up in situation where each component comes with its own "best-fitting" solution.
> 
> We see following requirements:
> 1. new features which come with Elytron need to be covered by integration tests
> 2. existing scenarios have to stay working when Elytron is configured as the default security subsystem
> 3. legacy security subsystem must stay working in parallel
> 
> Our teams came to agreement that the safest way would be to copy whole existing testsuite modules into new ones. E.g.
> 
> cp -r testsuite/integration/basic testsuite/integration/basic-legacy-security
> # + Reconfigure testsuite/integration/basic to use Elytron
> # + Add @Ignore to all tests which fail with Elytron or use directly the old security configuration
> 
> The modules would just live side by side - basic would use Elytron configuration, basic-legacy-security would use configuration similar to (or same as) the current server configuration.
> 
> In the next step we will go through the Ignored tests (the TODO list) for Elytron and rewrite them or report issues if necessary.
> 
> By this way we would keep all the test coverage for legacy security. We would also have all existing scenarios covered (or at least present) for Elytron configuration.
> 
> Are there any objections to this suggestion?
> 
> Thanks,
> 
> -- Josef
> _______________________________________________
> 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>
> 
> 
> 
> -- 
> James R. Perkins
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

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

From jason.greene at redhat.com  Fri Dec  2 13:28:52 2016
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 2 Dec 2016 12:28:52 -0600
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
Message-ID: <31AD4613-EEEA-433F-B3DE-4B207168C428@redhat.com>

Right we can?t just double the testsuite. Although I could understand someone doing this as a temporary exercise. Not only is this bad from an overhead standpoint, but its also not guaranteed to be effective, since a large portion of our tests either don?t use security, or only the most basic functions. I think we need targeted testing for the new functionality regardless.

> On Dec 2, 2016, at 9:20 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Duplicating the whole testsuite is basically a minimal effort way of getting coverage by avoiding the task of test coverage analysis.
> 
> Only justification for that is expediency. That may be sufficient justification; I don?t know.
> 
> But assuming for the sake of argument it?s sufficient, doubling the amount of time needed to run the testsuite is a massive productivity loss and that means cutting that time down to the necessary minimum and nothing more would need to be a critical extreme high priority task.
> 
> So, with this proposal, who would be the people assigned to this critical extreme high priority task? I?d like to see names, lots and lots of names. Darran Lofthouse not among them. ;)
> 
> 
>> On Dec 2, 2016, at 8:59 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>> 
>> No the part we can't avoid is that we have two security implementations 
>> in the server and we have to have tests for both.  The e-mail from Josef 
>> is a suggestion as to how this will be achieved.
>> 
>> Other suggestions are welcome ;-)
>> 
>> But we have two security implementations to test.
>> 
>> One of these is deprecated and will hopefully be removed at some point 
>> so ideally we have something that allows testing to legacy to be removed 
>> without too much pain.
>> 
>> Writing sufficient test coverage is not a small task so anything that 
>> gives us more than starting from scratch is a benefit.
>> 
>> But maybe it would be worth summarising these additional scenarios that 
>> will be affected by changes.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> On 02/12/16 14:47, Toma? Cerar wrote:
>>> So if I understood all this correctly,
>>> this mail here was more of a heads up what is happening
>>> than a discussion on how could or should be best done.
>>> 
>>> I just hope you (the team behind decisions) considered all scenarios how
>>> will that impact everyone involved.
>>> 
>>> --
>>> tomaz
>>> 
>>> On Fri, Dec 2, 2016 at 12:58 PM, Josef Cacek <jcacek at redhat.com
>>> <mailto:jcacek at redhat.com>> wrote:
>>> 
>>>   We prefer duplication of all tests in the testsuite to keep test
>>>   coverage.
>>> 
>>>   To be sure we don't have regressions with introducing Elytron and at
>>>   the same time we are able to cover current features with Elytron, we
>>>   must run all tests with both security subsystems.
>>>   Even if a test is not security related on the first glance, the
>>>   tested component may use a security feature internally. By switching
>>>   to the new security subsystem the feature may stop work.
>>> 
>>>   Let's keep the current (legacy security based) tests alive until the
>>>   legacy security subsystem is fully removed.
>>>   Then we'll simply remove the *-legacy-security testsuite modules.
>>> 
>>>   -- Josef
>>> 
>>>   ----- Original Message -----
>>>> From: "Toma? Cerar" <tomaz.cerar at gmail.com
>>>   <mailto:tomaz.cerar at gmail.com>>
>>>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com
>>>   <mailto:darran.lofthouse at jboss.com>>
>>>> Cc: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>> Sent: Friday, December 2, 2016 12:37:22 PM
>>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>>>   testsuite
>>>> 
>>>> That is probably fine, but! it should be done differently.
>>>> 
>>>> instead of duplicating whole testsuite (and adding extra hour to
>>>   execution
>>>> and extra headaches with intermittent problems and duplication of
>>>> maintenance)
>>>> I would suggest that all security related tests get extracted to new
>>>> "security" testsuite module and than only that part is duplicated.
>>>> 
>>>> This way we will have all security related stuff in one place.
>>>> 
>>>> 
>>>> 
>>>> On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>>>> darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com> >
>>>   wrote:
>>>> 
>>>> 
>>>> Probably should add - any duplication should only be for security
>>>   tests
>>>> - not everything else in there!
>>>> 
>>>> On 02/12/16 11:08, Darran Lofthouse wrote:
>>>>> On 02/12/16 11:03, Toma? Cerar wrote:
>>>>>> 
>>>>>> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
>>>   <mailto:jcacek at redhat.com>
>>>>>> <mailto: jcacek at redhat.com <mailto:jcacek at redhat.com> >> wrote:
>>>>>> 
>>>>>> The modules would just live side by side - basic would use Elytron
>>>>>> configuration, basic-legacy-security would use configuration
>>>   similar
>>>>>> to (or same as) the current server configuration.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> What would this actually mean?
>>>>>> we will have two copies basic tests suites one running with elytron
>>>>>> another with legacy security subsystem?
>>>>>> 
>>>>>> Do I read that right? Please say I am not.
>>>>> 
>>>>> That is correct - we have two security implementations they both
>>>   need
>>>>> testing.
>>>>> 
>>>>> One needs testing for backwards compatibility and regressions,
>>>   the other
>>>>> for equivalent behaviour and then new features and bugs.
>>>>> 
>>>>> Needing to test both was discussed previously so this is more
>>>   about how
>>>>> to separate both and also give the Elytron testing a good
>>>   foundation to
>>>>> start from.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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 <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 <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
> 
> -- 
> 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

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From rachmato at redhat.com  Fri Dec  2 13:29:55 2016
From: rachmato at redhat.com (Richard Achmatowicz)
Date: Fri, 2 Dec 2016 13:29:55 -0500
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com>
References: <7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com>
Message-ID: <f0e1121b-de9d-404d-9abb-f1d73998cafd@redhat.com>

Hi Flavia

Is there any overall design for this feature available to browse? For 
example, there has long been a problem (and still is) with remotely 
initiated transactions and the EJB client retry mechanism (both of them) 
which associates an XA resource with one node at the beginning of the 
transaction and then retries on another, completes on the other, then 
tries to commit on the original XA node which has shutdown. This is 
anything but clean.

Richard


On 02/12/16 11:56 AM, Flavia Rainone wrote:
>
> Hi,
>
> I'm creating this thread to discuss the remaining details of graceful 
> shutdown for ejb transactions.
>
> This is more or less what I've done so far:
>
> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>
> While discussing this in the hip chat yesterday, Stuart mentioned that 
> maybe we could have the transactions subsystem responsible for keeping 
> track of how many active transactions we have, instead of putting that 
> code in EjbRemoteTransactionsRepository.
>
> Stuart, does that include having the suspend callback being done at 
> transactions subsystem as well? I'm thinking maybe not, because there 
> are two points in the ejb subsystem we need to know if transactions 
> suspension is over:
>
> - at EjbSuspendInterceptor if it is over, no request is allowed, if it 
> is not over, we need to check if current invocation contains a 
> reference to an active transaction
>
> - at some point, we need to let control point notify that the ejb 
> module is no longer available to ejb client after transaction 
> suspension is over, i.e., we need to do that when suspend has been 
> requested and there are no remaining active transactions available.
>
> On the other hand, it is hard to draw the line between what should be 
> in the transactions subsystem and what shouldn't. If the callback is 
> done at transactions subsystem, we need a way of having ejb3 notified 
> that it is done. If it is not done at transactions subsystem, ejb3 has 
> to be notified of the active transactions going to zero, which seems a 
> lot of overhead, so from this point of view maybe the callback should 
> be in the transactions system after all.
>
> Stuart and Gytis, any thoughts?
> -- 
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team
> M: (+55) 11 981-225-466
>
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration.
>
>
> _______________________________________________
> 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/20161202/a0e6ba02/attachment-0001.html 

From rachmato at redhat.com  Fri Dec  2 14:45:36 2016
From: rachmato at redhat.com (Richard Achmatowicz)
Date: Fri, 2 Dec 2016 14:45:36 -0500
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <f0e1121b-de9d-404d-9abb-f1d73998cafd@redhat.com>
References: <7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com>
	<f0e1121b-de9d-404d-9abb-f1d73998cafd@redhat.com>
Message-ID: <759f6185-ad7b-f900-8cc5-65e6fb023f66@redhat.com>

Another consideration ... but this may be outside the scope of what you 
are working on.

I assume that by "graceful shutdown for ejb transactions" you mean a 
feature to allow ejb transactions, which have been initiated before a 
shutdown, to be given a reasonable chance to complete after shutdown has 
been initiated, and so avoiding aborting a transaction just because a 
shutdown was initiated at an inappropriate time. In other words, the 
feature is specific to the case of when the server is being shutdown 
cleanly/gracefully. It's worht mentioning that in addition to shutdown 
of the server, undeploying a deployment containing ejbs (in the middle 
of a transaction) is going to have a similar negative impact on ejb 
transactions as initiating a shutdown. Also, if the deployment is 
clustered, there are possibilities for retrying on another available 
node; but as I mentioned before, there are issues with that too.

Just to say that "graceful shutdown" has different meanings in different 
deployment contexts.

Richard
On 02/12/16 01:29 PM, Richard Achmatowicz wrote:
>
> Hi Flavia
>
> Is there any overall design for this feature available to browse? For 
> example, there has long been a problem (and still is) with remotely 
> initiated transactions and the EJB client retry mechanism (both of 
> them) which associates an XA resource with one node at the beginning 
> of the transaction and then retries on another, completes on the 
> other, then tries to commit on the original XA node which has 
> shutdown. This is anything but clean.
>
> Richard
>
>
> On 02/12/16 11:56 AM, Flavia Rainone wrote:
>>
>> Hi,
>>
>> I'm creating this thread to discuss the remaining details of graceful 
>> shutdown for ejb transactions.
>>
>> This is more or less what I've done so far:
>>
>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>
>> While discussing this in the hip chat yesterday, Stuart mentioned 
>> that maybe we could have the transactions subsystem responsible for 
>> keeping track of how many active transactions we have, instead of 
>> putting that code in EjbRemoteTransactionsRepository.
>>
>> Stuart, does that include having the suspend callback being done at 
>> transactions subsystem as well? I'm thinking maybe not, because there 
>> are two points in the ejb subsystem we need to know if transactions 
>> suspension is over:
>>
>> - at EjbSuspendInterceptor if it is over, no request is allowed, if 
>> it is not over, we need to check if current invocation contains a 
>> reference to an active transaction
>>
>> - at some point, we need to let control point notify that the ejb 
>> module is no longer available to ejb client after transaction 
>> suspension is over, i.e., we need to do that when suspend has been 
>> requested and there are no remaining active transactions available.
>>
>> On the other hand, it is hard to draw the line between what should be 
>> in the transactions subsystem and what shouldn't. If the callback is 
>> done at transactions subsystem, we need a way of having ejb3 notified 
>> that it is done. If it is not done at transactions subsystem, ejb3 
>> has to be notified of the active transactions going to zero, which 
>> seems a lot of overhead, so from this point of view maybe the 
>> callback should be in the transactions system after all.
>>
>> Stuart and Gytis, any thoughts?
>> -- 
>> Flavia Rainone
>> Principal Software Engineer
>> JBoss EAP/WildFly Team
>> M: (+55) 11 981-225-466
>>
>> Red Hat.
>> Better technology.
>> Faster innovation.
>> Powered by community collaboration.
>>
>>
>> _______________________________________________
>> 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/20161202/fae33814/attachment.html 

From jperkins at redhat.com  Fri Dec  2 20:09:08 2016
From: jperkins at redhat.com (James Perkins)
Date: Fri, 2 Dec 2016 17:09:08 -0800
Subject: [wildfly-dev] Proposal: Batch Job Visibility Restrictions
Message-ID: <CADGwLpihkvgP2TS4wUatCQ-JcBh3hVe=7e6AF-G4-63Y3yaU6Q@mail.gmail.com>

Currently a deployment can view, stop, restart or abandon any batch job
that has been submitted or has been executed that exists in the job
repository. This includes batch jobs from other deployments if the job
repository is shared, which is the default. I cannot however start a batch
job from another deployment.

I'm proposing we limit visibility so that a deployment can only access jobs
which belong to that deployment.

I'd like to get some opinions on this.

There are some, possibly unacceptable, repercussions. For example if a user
has a deployment that displays information about batch jobs for all
deployments this change would break that. However it does seem wrong to
allow any deployment using a shared repository to stop, start or abandon a
job from a different deployment.

One, probably more complicated, option would be to have an attribute on the
job-repository to allow jobs to be visible to any deployment with access to
the job-repository.

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

From david.lloyd at redhat.com  Sat Dec  3 16:22:47 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Sat, 3 Dec 2016 15:22:47 -0600
Subject: [wildfly-dev] Proposal: Batch Job Visibility Restrictions
In-Reply-To: <CADGwLpihkvgP2TS4wUatCQ-JcBh3hVe=7e6AF-G4-63Y3yaU6Q@mail.gmail.com>
References: <CADGwLpihkvgP2TS4wUatCQ-JcBh3hVe=7e6AF-G4-63Y3yaU6Q@mail.gmail.com>
Message-ID: <eb3cac8e-9b6a-df75-e25d-5ea875e5da48@redhat.com>

I think this is a smart idea.  I must ask though, why can I not start a 
batch job from another deployment?  Is it just a design limitation?

Usually we'd want to restrict access to things not by deployment (which 
is a somewhat fluid concept) but by identity and authorization permissions.

On 12/02/2016 07:09 PM, James Perkins wrote:
> Currently a deployment can view, stop, restart or abandon any batch job
> that has been submitted or has been executed that exists in the job
> repository. This includes batch jobs from other deployments if the job
> repository is shared, which is the default. I cannot however start a
> batch job from another deployment.
>
> I'm proposing we limit visibility so that a deployment can only access
> jobs which belong to that deployment.
>
> I'd like to get some opinions on this.
>
> There are some, possibly unacceptable, repercussions. For example if a
> user has a deployment that displays information about batch jobs for all
> deployments this change would break that. However it does seem wrong to
> allow any deployment using a shared repository to stop, start or abandon
> a job from a different deployment.
>
> One, probably more complicated, option would be to have an attribute on
> the job-repository to allow jobs to be visible to any deployment with
> access to the job-repository.
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From stuart.w.douglas at gmail.com  Sat Dec  3 21:35:58 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 4 Dec 2016 13:35:58 +1100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c4dPgTU-bVV=0qCb_bFt7dsYFmRVt1GpNydB2WPOSWbGA@mail.gmail.com>

On 2 Dec 2016 11:00 PM, "Josef Cacek" <jcacek at redhat.com> wrote:
>
> We prefer duplication of all tests in the testsuite to keep test coverage.
>
> To be sure we don't have regressions with introducing Elytron and at the
same time we are able to cover current features with Elytron, we must run
all tests with both security subsystems.
> Even if a test is not security related on the first glance, the tested
component may use a security feature internally. By switching to the new
security subsystem the feature may stop work.
>

I think this is massive overkill, and would severely reduce the quality and
usability of the testsuite (more tests != a better test suite, they need to
be useful test otherwise they just add technical debt for no gain).

I just did a quick search through the code base, and as far as I can tell
there is maybe ~50 test cases that test security related functionality
(i.e. use the SecurityDomainSetup functionality), out of ~950 test cases,
so this would amount to adding around 900 useless test cases.

The argument that Elytron may cause regressions in these cases does really
work either, because these tests are not linked to a security domain
Elytron should never actually be activated, and even if this was a concern
the correct approach would be to write some smoke tests to ensure that non
Elytron deployments still work correctly.

The expediency argument also does not really work, as the tests that
actually use security will need to be modified anyway so they use Elytron
instead of the old security subsystem, so if the whole test suite was
copied the only tests that worked 'out of the box' would be the tests that
don't actually test anything security related.

IMHO a better way to test this would be to move all security related tests
into their own module, and then create subclasses of these tests in Elytron
and legacy modules. Elytron should be added to the default config, so that
even non security related tests run with Elytron present (although we
should still have at least one test module that runs without it, just as a
smoke test to make sure that legacy configs without it will still work).

Stuart


> Let's keep the current (legacy security based) tests alive until the
legacy security subsystem is fully removed.
> Then we'll simply remove the *-legacy-security testsuite modules.
>
> -- Josef
>
> ----- Original Message -----
> > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Friday, December 2, 2016 12:37:22 PM
> > Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
testsuite
> >
> > That is probably fine, but! it should be done differently.
> >
> > instead of duplicating whole testsuite (and adding extra hour to
execution
> > and extra headaches with intermittent problems and duplication of
> > maintenance)
> > I would suggest that all security related tests get extracted to new
> > "security" testsuite module and than only that part is duplicated.
> >
> > This way we will have all security related stuff in one place.
> >
> >
> >
> > On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
> > darran.lofthouse at jboss.com > wrote:
> >
> >
> > Probably should add - any duplication should only be for security tests
> > - not everything else in there!
> >
> > On 02/12/16 11:08, Darran Lofthouse wrote:
> > > On 02/12/16 11:03, Toma? Cerar wrote:
> > >>
> > >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
> > >> <mailto: jcacek at redhat.com >> wrote:
> > >>
> > >> The modules would just live side by side - basic would use Elytron
> > >> configuration, basic-legacy-security would use configuration similar
> > >> to (or same as) the current server configuration.
> > >>
> > >>
> > >>
> > >> What would this actually mean?
> > >> we will have two copies basic tests suites one running with elytron
> > >> another with legacy security subsystem?
> > >>
> > >> Do I read that right? Please say I am not.
> > >
> > > That is correct - we have two security implementations they both need
> > > testing.
> > >
> > > One needs testing for backwards compatibility and regressions, the
other
> > > for equivalent behaviour and then new features and bugs.
> > >
> > > Needing to test both was discussed previously so this is more about
how
> > > to separate both and also give the Elytron testing a good foundation
to
> > > start from.
> > >
> > >>
> > >>
> > >> _______________________________________________
> > >> 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/20161204/d778d30f/attachment-0001.html 

From sdouglas at redhat.com  Sun Dec  4 17:39:09 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 5 Dec 2016 09:39:09 +1100
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
Message-ID: <CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>

On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> wrote:
> Hi,
>
> I'm creating this thread to discuss the remaining details of graceful
> shutdown for ejb transactions.
>
> This is more or less what I've done so far:
>
> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>
> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
> we could have the transactions subsystem responsible for keeping track of
> how many active transactions we have, instead of putting that code in
> EjbRemoteTransactionsRepository.
>
> Stuart, does that include having the suspend callback being done at
> transactions subsystem as well? I'm thinking maybe not, because there are
> two points in the ejb subsystem we need to know if transactions suspension
> is over:
>

No, that still has to be handled at an EJB subsystem level.
Conceptually this is similar to what was done for the XTS subsytem, so
it should probably use a similar design. Ideally while the server is
in the running state the only graceful related code that is run is the
control point request tracking, however this may not be possible.

One other thing that came up on our hipchat discussion yesterday is TX
level graceful shutdown actually has some significant drawbacks, as
you cannot send out the module unavailability message until all the
transactions have been closed. This means that while we are waiting
for transactions to complete the node will still be part of a cluster,
and clients will send it requests that will be immediately rejected.

Stuart

> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
> not over, we need to check if current invocation contains a reference to an
> active transaction
>
> - at some point, we need to let control point notify that the ejb module is
> not longer available to ejb client after transaction suspension is over,
> i.e., we need to do that when suspend has been requested and there are no
> remaining active transactions available.
>
> On the other hand, it is hard to draw the line between what should be in the
> transactions subsystem and what shouldn't. If the callback is done at
> transactions subsystem, we need a way of having ejb3 notified that it is
> done. If it is not done at transactions subsystem, ejb3 has to be notified
> of the active transactions going to zero, which seems a lot of overhead, so
> from this point of view maybe the callback should be in the transactions
> system after all.
>
> Stuart and Gytis, any thoughts?
>
>
> --
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team
> M: (+55) 11 981-225-466
>
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration.

From darran.lofthouse at jboss.com  Mon Dec  5 07:30:35 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 5 Dec 2016 12:30:35 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <CAAoo=c4dPgTU-bVV=0qCb_bFt7dsYFmRVt1GpNydB2WPOSWbGA@mail.gmail.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<260694047.770029.1480666317731.JavaMail.zimbra@redhat.com>
	<CAMquZP5=1fTPaJuwJemmcyvWE31HUUWnyYysvsdVt7Y4hT8-aw@mail.gmail.com>
	<0a311a33-3e39-76ac-588e-a4cea4b0a62f@jboss.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAAoo=c4dPgTU-bVV=0qCb_bFt7dsYFmRVt1GpNydB2WPOSWbGA@mail.gmail.com>
Message-ID: <9f899fd6-7d85-ac98-61e2-a5650e10dac5@jboss.com>

I am not a fan of the subclassing as at some point in the future we do 
need to be able to delete the legacy tests so I would like to keep them 
independent enough so we can do that without another testsuite refactoring.

But I do like the moving the 50 tests out, that fits more closely with 
the three modules I described earlier.

So a new legacy-security module where we move the existing security 
tests to.  Clone this to a new security module and those tests will be 
enhanced to test Elytron specifically, this new module will also be 
where all new tests get added.

So that leaves 900 tests behind - I would suggest that remains by 
default using the default configuration of the server only.

Then if we want I think as a side task the 900 tests could have some 
alternative profiles to be defined so we can ensure the following 
permutations are covered: -

  1 - security extension installed.
  2 - elytron extenstion installed.
  3 - security and elytron extensions installed.
  4 - neither extension installed.

I think the default config will either be #2 or #3 so the testing will 
be more about verifying we don't have hidden dependencies on specific 
extensions.

We probably don't want the overhead of those permutations in either 
local builds or our current CI builds but maybe a separate CI build to 
run those to watch for regressions in those areas.

I expect the *-elytron.xml configurations will be removed entirely from 
the distribution.

Regards,
Darran Lofthouse.


On 04/12/16 02:35, Stuart Douglas wrote:
> On 2 Dec 2016 11:00 PM, "Josef Cacek" <jcacek at redhat.com
> <mailto:jcacek at redhat.com>> wrote:
>>
>> We prefer duplication of all tests in the testsuite to keep test coverage.
>>
>> To be sure we don't have regressions with introducing Elytron and at
> the same time we are able to cover current features with Elytron, we
> must run all tests with both security subsystems.
>> Even if a test is not security related on the first glance, the tested
> component may use a security feature internally. By switching to the new
> security subsystem the feature may stop work.
>>
>
> I think this is massive overkill, and would severely reduce the quality
> and usability of the testsuite (more tests != a better test suite, they
> need to be useful test otherwise they just add technical debt for no gain).
>
> I just did a quick search through the code base, and as far as I can
> tell there is maybe ~50 test cases that test security related
> functionality (i.e. use the SecurityDomainSetup functionality), out of
> ~950 test cases, so this would amount to adding around 900 useless test
> cases.
>
> The argument that Elytron may cause regressions in these cases does
> really work either, because these tests are not linked to a security
> domain Elytron should never actually be activated, and even if this was
> a concern the correct approach would be to write some smoke tests to
> ensure that non Elytron deployments still work correctly.
>
> The expediency argument also does not really work, as the tests that
> actually use security will need to be modified anyway so they use
> Elytron instead of the old security subsystem, so if the whole test
> suite was copied the only tests that worked 'out of the box' would be
> the tests that don't actually test anything security related.
>
> IMHO a better way to test this would be to move all security related
> tests into their own module, and then create subclasses of these tests
> in Elytron and legacy modules. Elytron should be added to the default
> config, so that even non security related tests run with Elytron present
> (although we should still have at least one test module that runs
> without it, just as a smoke test to make sure that legacy configs
> without it will still work).
>
> Stuart
>
>
>> Let's keep the current (legacy security based) tests alive until the
> legacy security subsystem is fully removed.
>> Then we'll simply remove the *-legacy-security testsuite modules.
>>
>> -- Josef
>>
>> ----- Original Message -----
>> > From: "Toma? Cerar" <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>>
>> > To: "Darran Lofthouse" <darran.lofthouse at jboss.com
> <mailto:darran.lofthouse at jboss.com>>
>> > Cc: wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> > Sent: Friday, December 2, 2016 12:37:22 PM
>> > Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
> testsuite
>> >
>> > That is probably fine, but! it should be done differently.
>> >
>> > instead of duplicating whole testsuite (and adding extra hour to
> execution
>> > and extra headaches with intermittent problems and duplication of
>> > maintenance)
>> > I would suggest that all security related tests get extracted to new
>> > "security" testsuite module and than only that part is duplicated.
>> >
>> > This way we will have all security related stuff in one place.
>> >
>> >
>> >
>> > On Fri, Dec 2, 2016 at 12:09 PM, Darran Lofthouse <
>> > darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com> > wrote:
>> >
>> >
>> > Probably should add - any duplication should only be for security tests
>> > - not everything else in there!
>> >
>> > On 02/12/16 11:08, Darran Lofthouse wrote:
>> > > On 02/12/16 11:03, Toma? Cerar wrote:
>> > >>
>> > >> On Fri, Dec 2, 2016 at 9:11 AM, Josef Cacek < jcacek at redhat.com
> <mailto:jcacek at redhat.com>
>> > >> <mailto: jcacek at redhat.com <mailto:jcacek at redhat.com> >> wrote:
>> > >>
>> > >> The modules would just live side by side - basic would use Elytron
>> > >> configuration, basic-legacy-security would use configuration similar
>> > >> to (or same as) the current server configuration.
>> > >>
>> > >>
>> > >>
>> > >> What would this actually mean?
>> > >> we will have two copies basic tests suites one running with elytron
>> > >> another with legacy security subsystem?
>> > >>
>> > >> Do I read that right? Please say I am not.
>> > >
>> > > That is correct - we have two security implementations they both need
>> > > testing.
>> > >
>> > > One needs testing for backwards compatibility and regressions, the
> other
>> > > for equivalent behaviour and then new features and bugs.
>> > >
>> > > Needing to test both was discussed previously so this is more
> about how
>> > > to separate both and also give the Elytron testing a good
> foundation to
>> > > start from.
>> > >
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> 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 <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 <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 <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 jcacek at redhat.com  Mon Dec  5 10:03:47 2016
From: jcacek at redhat.com (Josef Cacek)
Date: Mon, 5 Dec 2016 10:03:47 -0500 (EST)
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
Message-ID: <373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>

Hi,

We still see the copying whole modules as the best way. Let's recap our view.

Tested components may use a security feature internally and without test coverage we would not realize that the feature stopped working. Running all tests will help us to discover regressions before they occur in application server.

Pros:
- we don't lose testcoverage, we can simply detect regressions. It also provides possible early failure detection for dev.
- it would be useful for migration, it shows migration path - user can take a look on tests with legacy solution and compare their configuration with tests which use Elytron configuration
- by each testsuite run we see how many tests are skipped (i.e. TODO list for Elytron integration)
- it should be simple to reconfigure the project (copy module; update metadata in pom.xml; ignore failing tests)
- it's simple to remove legacy testsuite modules once the legacy security subsystem is removed from WildFly

Cons and their solutions:
- double fixing of tests - we don't expect many such cases, the legacy should be handled as frozen (rewriting/adding only on need-to-have basis). Only custormer ticket related tests could be backported, it means only unit of tests per months.
- testsuite execution time - we don't need to run the legacy modules with each PR, it can be resolved by using profiles

As a smoke test we tried to run testsuite/integration-tests/basic module with standalone-elytron.xml and standalone-full-elytron.xml (merged standalone-full.xml and standalone-elytron.xml). There is around 25% test failures/errors. Also some testcases, which seem that are not directly related to security, failed.

Thanks,

-- Josef


----- Original Message -----
> From: "Kabir Khan" <kabir.khan at jboss.com>
> To: "Brian Stansberry" <brian.stansberry at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Friday, December 2, 2016 4:28:07 PM
> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> 
> +1 doubling the testsuite size/time is not practical. Also, there is the
> issue that if all tests are duplicated, when people come to enhance an
> existing test they will need to do so in two places.
> 
> Could we not do what was suggested earlier and pull out tests which obviously
> target security into two legacy/elytron modules, and leave the rest where
> they are? Then if something later turns out to have 'hidden' implications,
> that test gets pulled out into the two modules.
> 
> Regarding the deprecated legacy stuff, I think we will have to keep that
> around for many years still due to it being used by the product (and in any
> case in that branch, although removing it from WF might be possible sooner).

From jperkins at redhat.com  Mon Dec  5 10:33:08 2016
From: jperkins at redhat.com (James Perkins)
Date: Mon, 5 Dec 2016 07:33:08 -0800
Subject: [wildfly-dev] Proposal: Batch Job Visibility Restrictions
In-Reply-To: <eb3cac8e-9b6a-df75-e25d-5ea875e5da48@redhat.com>
References: <CADGwLpihkvgP2TS4wUatCQ-JcBh3hVe=7e6AF-G4-63Y3yaU6Q@mail.gmail.com>
	<eb3cac8e-9b6a-df75-e25d-5ea875e5da48@redhat.com>
Message-ID: <CADGwLpjbN1kL7Ni8XcW2kbT3guBLQSpAKdU8vv3r2esgioX-3A@mail.gmail.com>

On Sat, Dec 3, 2016 at 1:22 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> I think this is a smart idea.  I must ask though, why can I not start a
> batch job from another deployment?  Is it just a design limitation?
>

To start a job you need access to the job XML file and the CDI beans for
the deployment. However there is no limitation on the other operations.


>
> Usually we'd want to restrict access to things not by deployment (which
> is a somewhat fluid concept) but by identity and authorization permissions.
>

I'm going to be adding permissions too for each operation. My plan was to
have a start, stop, restart, abandon and read permission for each
operation. This proposal is more just not allowing A.war to stop a job from
B.war if the two deployments are not setup as dependent on each other.


>
> On 12/02/2016 07:09 PM, James Perkins wrote:
> > Currently a deployment can view, stop, restart or abandon any batch job
> > that has been submitted or has been executed that exists in the job
> > repository. This includes batch jobs from other deployments if the job
> > repository is shared, which is the default. I cannot however start a
> > batch job from another deployment.
> >
> > I'm proposing we limit visibility so that a deployment can only access
> > jobs which belong to that deployment.
> >
> > I'd like to get some opinions on this.
> >
> > There are some, possibly unacceptable, repercussions. For example if a
> > user has a deployment that displays information about batch jobs for all
> > deployments this change would break that. However it does seem wrong to
> > allow any deployment using a shared repository to stop, start or abandon
> > a job from a different deployment.
> >
> > One, probably more complicated, option would be to have an attribute on
> > the job-repository to allow jobs to be visible to any deployment with
> > access to the job-repository.
> >
> > --
> > James R. Perkins
> > JBoss by Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
> --
> - 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/20161205/d9907d08/attachment.html 

From darran.lofthouse at jboss.com  Mon Dec  5 11:28:02 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 5 Dec 2016 16:28:02 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
	<373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
Message-ID: <443b829c-3aa5-0aeb-084e-f29e6d31ecfc@jboss.com>

Regarding that 25% failure - I would expect a lot of that to be picked 
up anyway as we merge the *-elytron.xml configurations into the default 
configurations and then drop the *-elytron configurations.

How about my reply to Stuart's e-mail and a 3-way split, 
legacy-security, security, and basic where basic can have optional 
profiles added to test different extension availability?

We could then do as Kabir suggests and pull out additional tests later 
if we do find a reason to justify duplicating the test and in the 
meantime have the profiles available to run the tests.

Regards,
Darran Lofthouse.

On 05/12/16 15:03, Josef Cacek wrote:
> Hi,
>
> We still see the copying whole modules as the best way. Let's recap our view.
>
> Tested components may use a security feature internally and without test coverage we would not realize that the feature stopped working. Running all tests will help us to discover regressions before they occur in application server.
>
> Pros:
> - we don't lose testcoverage, we can simply detect regressions. It also provides possible early failure detection for dev.
> - it would be useful for migration, it shows migration path - user can take a look on tests with legacy solution and compare their configuration with tests which use Elytron configuration
> - by each testsuite run we see how many tests are skipped (i.e. TODO list for Elytron integration)
> - it should be simple to reconfigure the project (copy module; update metadata in pom.xml; ignore failing tests)
> - it's simple to remove legacy testsuite modules once the legacy security subsystem is removed from WildFly
>
> Cons and their solutions:
> - double fixing of tests - we don't expect many such cases, the legacy should be handled as frozen (rewriting/adding only on need-to-have basis). Only custormer ticket related tests could be backported, it means only unit of tests per months.
> - testsuite execution time - we don't need to run the legacy modules with each PR, it can be resolved by using profiles
>
> As a smoke test we tried to run testsuite/integration-tests/basic module with standalone-elytron.xml and standalone-full-elytron.xml (merged standalone-full.xml and standalone-elytron.xml). There is around 25% test failures/errors. Also some testcases, which seem that are not directly related to security, failed.
>
> Thanks,
>
> -- Josef
>
>
> ----- Original Message -----
>> From: "Kabir Khan" <kabir.khan at jboss.com>
>> To: "Brian Stansberry" <brian.stansberry at redhat.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Friday, December 2, 2016 4:28:07 PM
>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
>>
>> +1 doubling the testsuite size/time is not practical. Also, there is the
>> issue that if all tests are duplicated, when people come to enhance an
>> existing test they will need to do so in two places.
>>
>> Could we not do what was suggested earlier and pull out tests which obviously
>> target security into two legacy/elytron modules, and leave the rest where
>> they are? Then if something later turns out to have 'hidden' implications,
>> that test gets pulled out into the two modules.
>>
>> Regarding the deprecated legacy stuff, I think we will have to keep that
>> around for many years still due to it being used by the product (and in any
>> case in that branch, although removing it from WF might be possible sooner).
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From frainone at redhat.com  Mon Dec  5 13:46:03 2016
From: frainone at redhat.com (Flavia Rainone)
Date: Mon, 5 Dec 2016 16:46:03 -0200
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <759f6185-ad7b-f900-8cc5-65e6fb023f66@redhat.com>
References: <7cfd743c-e1a5-d59a-b33b-f9541cbdc6b1@redhat.com>
	<f0e1121b-de9d-404d-9abb-f1d73998cafd@redhat.com>
	<759f6185-ad7b-f900-8cc5-65e6fb023f66@redhat.com>
Message-ID: <34c39246-9781-d202-b834-42fc2e8d367b@redhat.com>

Hi Richard,

This is the corresponding Jira: https://issues.jboss.org/browse/WFLY-7207

There is a document for transactions graceful shutdown here: 
https://developer.jboss.org/wiki/DevAnalysisForTransactionsGracefulShutdown

In a nutshell, the EJB system will not complete suspension until all 
open transactions are concluded, and that includes XATransactions.

This issue you're mentioning involving EJB client retry plus remote 
transactions is possibly outside the scope of WFLY-7207. Do you have a 
Jira for that one? If I understand correctly, the problem is that the 
client shouldn't retry at the original XA node, because that node has 
shutdown, is that correct? In this case, I find it weird, because the 
ejb client is going to be notified that the client is no longer 
available on shutdown, thus preventing the client from invoking that 
node, as Stuart mentioned in his previous e-mail. We are going to have 
to workaround that mechanism, by delaying the client notification until 
all transactions are complete. As this behavior could be undesired, 
after all it would make invocations to the shutting down node possible 
while there are open transactions in that node, we are going to make it 
configurable, the user might not want graceful ejb transaction at all in 
this case.

Or maybe you mean that all remote invocations belonging to the same 
remote transaction should always be answered by the same cluster node?

Regarding your consideration, yes, you are correct, this feature is to 
give an oportunity for open transactions to complete before shutdown. I 
think Stuart has plans of extending the graceful shutdown feature to 
cover undeployments in the future.

R.

Flavia


On 02-12-2016 17:45, Richard Achmatowicz wrote:
>
> Another consideration ... but this may be outside the scope of what 
> you are working on.
>
> I assume that by "graceful shutdown for ejb transactions" you mean a 
> feature to allow ejb transactions, which have been initiated before a 
> shutdown, to be given a reasonable chance to complete after shutdown 
> has been initiated, and so avoiding aborting a transaction just 
> because a shutdown was initiated at an inappropriate time. In other 
> words, the feature is specific to the case of when the server is being 
> shutdown cleanly/gracefully. It's worht mentioning that in addition to 
> shutdown of the server, undeploying a deployment containing ejbs (in 
> the middle of a transaction) is going to have a similar negative 
> impact on ejb transactions as initiating a shutdown. Also, if the 
> deployment is clustered, there are possibilities for retrying on 
> another available node; but as I mentioned before, there are issues 
> with that too.
>
> Just to say that "graceful shutdown" has different meanings in 
> different deployment contexts.
>
> Richard
> On 02/12/16 01:29 PM, Richard Achmatowicz wrote:
>>
>> Hi Flavia
>>
>> Is there any overall design for this feature available to browse? For 
>> example, there has long been a problem (and still is) with remotely 
>> initiated transactions and the EJB client retry mechanism (both of 
>> them) which associates an XA resource with one node at the beginning 
>> of the transaction and then retries on another, completes on the 
>> other, then tries to commit on the original XA node which has 
>> shutdown. This is anything but clean.
>>
>> Richard
>>
>>
>> On 02/12/16 11:56 AM, Flavia Rainone wrote:
>>>
>>> Hi,
>>>
>>> I'm creating this thread to discuss the remaining details of 
>>> graceful shutdown for ejb transactions.
>>>
>>> This is more or less what I've done so far:
>>>
>>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>
>>> While discussing this in the hip chat yesterday, Stuart mentioned 
>>> that maybe we could have the transactions subsystem responsible for 
>>> keeping track of how many active transactions we have, instead of 
>>> putting that code in EjbRemoteTransactionsRepository.
>>>
>>> Stuart, does that include having the suspend callback being done at 
>>> transactions subsystem as well? I'm thinking maybe not, because 
>>> there are two points in the ejb subsystem we need to know if 
>>> transactions suspension is over:
>>>
>>> - at EjbSuspendInterceptor if it is over, no request is allowed, if 
>>> it is not over, we need to check if current invocation contains a 
>>> reference to an active transaction
>>>
>>> - at some point, we need to let control point notify that the ejb 
>>> module is no longer available to ejb client after transaction 
>>> suspension is over, i.e., we need to do that when suspend has been 
>>> requested and there are no remaining active transactions available.
>>>
>>> On the other hand, it is hard to draw the line between what should 
>>> be in the transactions subsystem and what shouldn't. If the callback 
>>> is done at transactions subsystem, we need a way of having ejb3 
>>> notified that it is done. If it is not done at transactions 
>>> subsystem, ejb3 has to be notified of the active transactions going 
>>> to zero, which seems a lot of overhead, so from this point of view 
>>> maybe the callback should be in the transactions system after all.
>>>
>>> Stuart and Gytis, any thoughts?
>>> -- 
>>> Flavia Rainone
>>> Principal Software Engineer
>>> JBoss EAP/WildFly Team
>>> M: (+55) 11 981-225-466
>>>
>>> Red Hat.
>>> Better technology.
>>> Faster innovation.
>>> Powered by community collaboration.
>>>
>>>
>>> _______________________________________________
>>> 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

-- 
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466

Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161205/2e97d6f7/attachment.html 

From frainone at redhat.com  Mon Dec  5 14:34:07 2016
From: frainone at redhat.com (Flavia Rainone)
Date: Mon, 5 Dec 2016 17:34:07 -0200
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
Message-ID: <7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>

I think we can keep open transaction tracking only inside transactions 
subsystem while we are not shutting down, and then we can enroll for 
notification of open active transactions only on suspend if needed... 
IMHO that's as clean as we can get regarding shutdown code when the 
server is in running state.

I would go with some sort of ActiveTransactionListener, that would be 
notified of no more active transactions only if the listener is set?

Something along the lines below at ejb side:

ServerActivityCallback callback = null;

public void suspend(ServerActivityCallback callback) {
     if ( transactionSubsystem.getActiveTransactions() > 0) {
        transactionSubsystem.setActiveTransactionsListener(this);
     }
     else {
       callback.done(); // done suspending
    }
}

// listener method
public void noMoreActiveTransactions() {
     callback.done(); // done suspending
     // then we let control point notify clients that this node is no 
longer available
     ...
}

At transactions side:
ActiveTransactionListener listener = null;

private void incrementTxnCount() {
     ...
}

private void decrementTxnCount() {
    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
        listener.noMoreActiveTransactions();
}

public int getActiveTransactions() {
    return txnCountUpdater.get();
}







On 04-12-2016 20:39, Stuart Douglas wrote:
> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> wrote:
>> Hi,
>>
>> I'm creating this thread to discuss the remaining details of graceful
>> shutdown for ejb transactions.
>>
>> This is more or less what I've done so far:
>>
>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>
>> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>> we could have the transactions subsystem responsible for keeping track of
>> how many active transactions we have, instead of putting that code in
>> EjbRemoteTransactionsRepository.
>>
>> Stuart, does that include having the suspend callback being done at
>> transactions subsystem as well? I'm thinking maybe not, because there are
>> two points in the ejb subsystem we need to know if transactions suspension
>> is over:
>>
> No, that still has to be handled at an EJB subsystem level.
> Conceptually this is similar to what was done for the XTS subsytem, so
> it should probably use a similar design. Ideally while the server is
> in the running state the only graceful related code that is run is the
> control point request tracking, however this may not be possible.
>
> One other thing that came up on our hipchat discussion yesterday is TX
> level graceful shutdown actually has some significant drawbacks, as
> you cannot send out the module unavailability message until all the
> transactions have been closed. This means that while we are waiting
> for transactions to complete the node will still be part of a cluster,
> and clients will send it requests that will be immediately rejected.
>
> Stuart
>
>> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>> not over, we need to check if current invocation contains a reference to an
>> active transaction
>>
>> - at some point, we need to let control point notify that the ejb module is
>> not longer available to ejb client after transaction suspension is over,
>> i.e., we need to do that when suspend has been requested and there are no
>> remaining active transactions available.
>>
>> On the other hand, it is hard to draw the line between what should be in the
>> transactions subsystem and what shouldn't. If the callback is done at
>> transactions subsystem, we need a way of having ejb3 notified that it is
>> done. If it is not done at transactions subsystem, ejb3 has to be notified
>> of the active transactions going to zero, which seems a lot of overhead, so
>> from this point of view maybe the callback should be in the transactions
>> system after all.
>>
>> Stuart and Gytis, any thoughts?
>>
>>
>> --
>> Flavia Rainone
>> Principal Software Engineer
>> JBoss EAP/WildFly Team
>> M: (+55) 11 981-225-466
>>
>> Red Hat.
>> Better technology.
>> Faster innovation.
>> Powered by community collaboration.

-- 
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466

Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.

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

From anmiller at redhat.com  Mon Dec  5 18:12:44 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Mon, 5 Dec 2016 16:12:44 -0700
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
Message-ID: <CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>

I'm just wondering if we are making this graceful shutdown more complicated
than necessary.

Why wouldn't we just cancel and force a rollback on any active transactions
when shutting down?  Having experienced what a graceful shutdown can look
like with a different architecture (BEA Tuxedo), I can tell you that it can
take a very long time for the server to get to the point of shutting down,
and appear to be hung by the administrator, depending on what was going on
at the time the command was entered.

We used to get administrators killing Tuxedo while it was "gracefully"
shutting down, and messing lots of stuff up.

Andy

On Mon, Dec 5, 2016 at 12:34 PM, Flavia Rainone <frainone at redhat.com> wrote:

> I think we can keep open transaction tracking only inside transactions
> subsystem while we are not shutting down, and then we can enroll for
> notification of open active transactions only on suspend if needed... IMHO
> that's as clean as we can get regarding shutdown code when the server is in
> running state.
>
> I would go with some sort of ActiveTransactionListener, that would be
> notified of no more active transactions only if the listener is set?
>
> Something along the lines below at ejb side:
>
> ServerActivityCallback callback = null;
>
> public void suspend(ServerActivityCallback callback) {
>     if ( transactionSubsystem.getActiveTransactions() > 0) {
>        transactionSubsystem.setActiveTransactionsListener(this);
>     }
>     else {
>       callback.done(); // done suspending
>    }
> }
>
> // listener method
> public void noMoreActiveTransactions() {
>     callback.done(); // done suspending
>     // then we let control point notify clients that this node is no
> longer available
>     ...
> }
>
> At transactions side:
> ActiveTransactionListener listener = null;
>
> private void incrementTxnCount() {
>     ...
> }
>
> private void decrementTxnCount() {
>    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
>        listener.noMoreActiveTransactions();
> }
>
> public int getActiveTransactions() {
>    return txnCountUpdater.get();
>
> }
>
>
>
>
>
>
>
> On 04-12-2016 20:39, Stuart Douglas wrote:
>
> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> <frainone at redhat.com> wrote:
>
> Hi,
>
> I'm creating this thread to discuss the remaining details of graceful
> shutdown for ejb transactions.
>
> This is more or less what I've done so far:
> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>
> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
> we could have the transactions subsystem responsible for keeping track of
> how many active transactions we have, instead of putting that code in
> EjbRemoteTransactionsRepository.
>
> Stuart, does that include having the suspend callback being done at
> transactions subsystem as well? I'm thinking maybe not, because there are
> two points in the ejb subsystem we need to know if transactions suspension
> is over:
>
>
> No, that still has to be handled at an EJB subsystem level.
> Conceptually this is similar to what was done for the XTS subsytem, so
> it should probably use a similar design. Ideally while the server is
> in the running state the only graceful related code that is run is the
> control point request tracking, however this may not be possible.
>
> One other thing that came up on our hipchat discussion yesterday is TX
> level graceful shutdown actually has some significant drawbacks, as
> you cannot send out the module unavailability message until all the
> transactions have been closed. This means that while we are waiting
> for transactions to complete the node will still be part of a cluster,
> and clients will send it requests that will be immediately rejected.
>
> Stuart
>
>
> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
> not over, we need to check if current invocation contains a reference to an
> active transaction
>
> - at some point, we need to let control point notify that the ejb module is
> not longer available to ejb client after transaction suspension is over,
> i.e., we need to do that when suspend has been requested and there are no
> remaining active transactions available.
>
> On the other hand, it is hard to draw the line between what should be in the
> transactions subsystem and what shouldn't. If the callback is done at
> transactions subsystem, we need a way of having ejb3 notified that it is
> done. If it is not done at transactions subsystem, ejb3 has to be notified
> of the active transactions going to zero, which seems a lot of overhead, so
> from this point of view maybe the callback should be in the transactions
> system after all.
>
> Stuart and Gytis, any thoughts?
>
>
> --
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team
> M: (+55) 11 981-225-466
>
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration.
>
>
> --
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team
> M: (+55) 11 981-225-466
>
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration.
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161205/1e5ae0c0/attachment-0001.html 

From stuart.w.douglas at gmail.com  Mon Dec  5 23:53:06 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 6 Dec 2016 15:53:06 +1100
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<4011f9c7-116a-0abb-8e33-107eb8270867@jboss.com>
	<CAMquZP6uVwAV+ZMJBwXdivOLC427eTtvnDV3Bzh098Hook8CyA@mail.gmail.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
	<373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c5OsCvXo_fRAcQawq3q0O_gvyz8Ynj8Dbe-7eO3iA7fEg@mail.gmail.com>

On Tue, Dec 6, 2016 at 2:03 AM, Josef Cacek <jcacek at redhat.com> wrote:

> Hi,
>
> We still see the copying whole modules as the best way. Let's recap our
> view.
>
> Tested components may use a security feature internally and without test
> coverage we would not realize that the feature stopped working. Running all
> tests will help us to discover regressions before they occur in application
> server.
>

They don't though. If the test is not set up to use security then security
won't be applied. The idea of adding an extra 900 test cases 'just in case'
is massive overkill, it adds a massive amount of technical debt and
decreases the overall quality of the test suite for very little gain.


>
> Pros:
> - we don't lose testcoverage, we can simply detect regressions. It also
> provides possible early failure detection for dev.
> - it would be useful for migration, it shows migration path - user can
> take a look on tests with legacy solution and compare their configuration
> with tests which use Elytron configuration
>

This is only applicable for tests that actually use Elytron. Just copying
the relevant tests has the same effect.


> - by each testsuite run we see how many tests are skipped (i.e. TODO list
> for Elytron integration)
>

Once again, also accomplished by just copying Elytron tests.


> - it should be simple to reconfigure the project (copy module; update
> metadata in pom.xml; ignore failing tests)
>

Once again, also accomplished by just copying Elytron tests. Even though it
is convenient at first IMHO the duplication of tests will greatly decrease
test suite maintainability, so overall I think this approach will use a lot
more man hours.


> - it's simple to remove legacy testsuite modules once the legacy security
> subsystem is removed from WildFly
>
> Cons and their solutions:
> - double fixing of tests - we don't expect many such cases, the legacy
> should be handled as frozen (rewriting/adding only on need-to-have basis).
> Only custormer ticket related tests could be backported, it means only unit
> of tests per months.
>

This is a major problem. We should not have to write a new test every time,
whenever possible existing tests should be enhanced (assuming similar tests
for similar functionality already exist). This has many advantages:

- The tests will execute faster, as deployment and set up is only performed
once
- It is very clear exactly what functionality is being tested, as all the
tests are in a single test case
- It reduces the number of classes in the test suite, which makes compile
times faster and increases maintainability

Freezing all these tests is not a practical idea IMHO.


> - testsuite execution time - we don't need to run the legacy modules with
> each PR, it can be resolved by using profiles
>

Yes we do. If a test is not being run with every PR it might as well not be
there, as it means that is can be broken without anyone knowing.


>
> As a smoke test we tried to run testsuite/integration-tests/basic module
> with standalone-elytron.xml and standalone-full-elytron.xml (merged
> standalone-full.xml and standalone-elytron.xml). There is around 25% test
> failures/errors. Also some testcases, which seem that are not directly
> related to security, failed.
>

This does not really mean much at the moment, it is most likely due to
configuration issues. Once the default config contains Elytron all these
tests will be running with the Elytron config anyway.

Stuart


>
> Thanks,
>
> -- Josef
>
>
> ----- Original Message -----
> > From: "Kabir Khan" <kabir.khan at jboss.com>
> > To: "Brian Stansberry" <brian.stansberry at redhat.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Friday, December 2, 2016 4:28:07 PM
> > Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> >
> > +1 doubling the testsuite size/time is not practical. Also, there is the
> > issue that if all tests are duplicated, when people come to enhance an
> > existing test they will need to do so in two places.
> >
> > Could we not do what was suggested earlier and pull out tests which
> obviously
> > target security into two legacy/elytron modules, and leave the rest where
> > they are? Then if something later turns out to have 'hidden'
> implications,
> > that test gets pulled out into the two modules.
> >
> > Regarding the deprecated legacy stuff, I think we will have to keep that
> > around for many years still due to it being used by the product (and in
> any
> > case in that branch, although removing it from WF might be possible
> sooner).
> _______________________________________________
> 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/20161206/bdf2605e/attachment.html 

From stuart.w.douglas at gmail.com  Mon Dec  5 23:54:30 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 6 Dec 2016 15:54:30 +1100
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
Message-ID: <CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>

On Tue, Dec 6, 2016 at 10:12 AM, Andrig Miller <anmiller at redhat.com> wrote:

> I'm just wondering if we are making this graceful shutdown more
> complicated than necessary.
>
> Why wouldn't we just cancel and force a rollback on any active
> transactions when shutting down?  Having experienced what a graceful
> shutdown can look like with a different architecture (BEA Tuxedo), I can
> tell you that it can take a very long time for the server to get to the
> point of shutting down, and appear to be hung by the administrator,
> depending on what was going on at the time the command was entered.
>


I think at the very least this has to be optional, so we can still have the
old non transnational behavior (i.e. wait for requests to finish rather
than transactions).

Stuart


>
> We used to get administrators killing Tuxedo while it was "gracefully"
> shutting down, and messing lots of stuff up.
>
> Andy
>
> On Mon, Dec 5, 2016 at 12:34 PM, Flavia Rainone <frainone at redhat.com>
> wrote:
>
>> I think we can keep open transaction tracking only inside transactions
>> subsystem while we are not shutting down, and then we can enroll for
>> notification of open active transactions only on suspend if needed... IMHO
>> that's as clean as we can get regarding shutdown code when the server is in
>> running state.
>>
>> I would go with some sort of ActiveTransactionListener, that would be
>> notified of no more active transactions only if the listener is set?
>>
>> Something along the lines below at ejb side:
>>
>> ServerActivityCallback callback = null;
>>
>> public void suspend(ServerActivityCallback callback) {
>>     if ( transactionSubsystem.getActiveTransactions() > 0) {
>>        transactionSubsystem.setActiveTransactionsListener(this);
>>     }
>>     else {
>>       callback.done(); // done suspending
>>    }
>> }
>>
>> // listener method
>> public void noMoreActiveTransactions() {
>>     callback.done(); // done suspending
>>     // then we let control point notify clients that this node is no
>> longer available
>>     ...
>> }
>>
>> At transactions side:
>> ActiveTransactionListener listener = null;
>>
>> private void incrementTxnCount() {
>>     ...
>> }
>>
>> private void decrementTxnCount() {
>>    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
>>        listener.noMoreActiveTransactions();
>> }
>>
>> public int getActiveTransactions() {
>>    return txnCountUpdater.get();
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> On 04-12-2016 20:39, Stuart Douglas wrote:
>>
>> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> <frainone at redhat.com> wrote:
>>
>> Hi,
>>
>> I'm creating this thread to discuss the remaining details of graceful
>> shutdown for ejb transactions.
>>
>> This is more or less what I've done so far:
>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>
>> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>> we could have the transactions subsystem responsible for keeping track of
>> how many active transactions we have, instead of putting that code in
>> EjbRemoteTransactionsRepository.
>>
>> Stuart, does that include having the suspend callback being done at
>> transactions subsystem as well? I'm thinking maybe not, because there are
>> two points in the ejb subsystem we need to know if transactions suspension
>> is over:
>>
>>
>> No, that still has to be handled at an EJB subsystem level.
>> Conceptually this is similar to what was done for the XTS subsytem, so
>> it should probably use a similar design. Ideally while the server is
>> in the running state the only graceful related code that is run is the
>> control point request tracking, however this may not be possible.
>>
>> One other thing that came up on our hipchat discussion yesterday is TX
>> level graceful shutdown actually has some significant drawbacks, as
>> you cannot send out the module unavailability message until all the
>> transactions have been closed. This means that while we are waiting
>> for transactions to complete the node will still be part of a cluster,
>> and clients will send it requests that will be immediately rejected.
>>
>> Stuart
>>
>>
>> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>> not over, we need to check if current invocation contains a reference to an
>> active transaction
>>
>> - at some point, we need to let control point notify that the ejb module is
>> not longer available to ejb client after transaction suspension is over,
>> i.e., we need to do that when suspend has been requested and there are no
>> remaining active transactions available.
>>
>> On the other hand, it is hard to draw the line between what should be in the
>> transactions subsystem and what shouldn't. If the callback is done at
>> transactions subsystem, we need a way of having ejb3 notified that it is
>> done. If it is not done at transactions subsystem, ejb3 has to be notified
>> of the active transactions going to zero, which seems a lot of overhead, so
>> from this point of view maybe the callback should be in the transactions
>> system after all.
>>
>> Stuart and Gytis, any thoughts?
>>
>>
>> --
>> Flavia Rainone
>> Principal Software Engineer
>> JBoss EAP/WildFly Team
>> M: (+55) 11 981-225-466
>>
>> Red Hat.
>> Better technology.
>> Faster innovation.
>> Powered by community collaboration.
>>
>>
>> --
>> Flavia Rainone
>> Principal Software Engineer
>> JBoss EAP/WildFly Team
>> M: (+55) 11 981-225-466
>>
>> Red Hat.
>> Better technology.
>> Faster innovation.
>> Powered by community collaboration.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
>
> _______________________________________________
> 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/20161206/732442ef/attachment-0001.html 

From jcacek at redhat.com  Tue Dec  6 02:40:37 2016
From: jcacek at redhat.com (Josef Cacek)
Date: Tue, 6 Dec 2016 02:40:37 -0500 (EST)
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <443b829c-3aa5-0aeb-084e-f29e6d31ecfc@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
	<373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
	<443b829c-3aa5-0aeb-084e-f29e6d31ecfc@jboss.com>
Message-ID: <700821323.1012746.1481010037415.JavaMail.zimbra@redhat.com>

The 3-way split is a good idea, but it would only work if
- we are sure the non-security tests in shared modules stay really independent - i.e. no new Ignores, Assumes, configuration based conditions;
- all shared modules have profiles for running with legacy security.

It's not clear how many new modules would be necessary with the 3 way split. Current TS modules don't share server configuration and they (may) contain several surefire executions with different server profiles.

-- Josef

----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Monday, December 5, 2016 5:28:02 PM
> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> 
> Regarding that 25% failure - I would expect a lot of that to be picked
> up anyway as we merge the *-elytron.xml configurations into the default
> configurations and then drop the *-elytron configurations.
> 
> How about my reply to Stuart's e-mail and a 3-way split,
> legacy-security, security, and basic where basic can have optional
> profiles added to test different extension availability?
> 
> We could then do as Kabir suggests and pull out additional tests later
> if we do find a reason to justify duplicating the test and in the
> meantime have the profiles available to run the tests.
> 
> Regards,
> Darran Lofthouse.
> 
> On 05/12/16 15:03, Josef Cacek wrote:
> > Hi,
> >
> > We still see the copying whole modules as the best way. Let's recap our
> > view.
> >
> > Tested components may use a security feature internally and without test
> > coverage we would not realize that the feature stopped working. Running
> > all tests will help us to discover regressions before they occur in
> > application server.
> >
> > Pros:
> > - we don't lose testcoverage, we can simply detect regressions. It also
> > provides possible early failure detection for dev.
> > - it would be useful for migration, it shows migration path - user can take
> > a look on tests with legacy solution and compare their configuration with
> > tests which use Elytron configuration
> > - by each testsuite run we see how many tests are skipped (i.e. TODO list
> > for Elytron integration)
> > - it should be simple to reconfigure the project (copy module; update
> > metadata in pom.xml; ignore failing tests)
> > - it's simple to remove legacy testsuite modules once the legacy security
> > subsystem is removed from WildFly
> >
> > Cons and their solutions:
> > - double fixing of tests - we don't expect many such cases, the legacy
> > should be handled as frozen (rewriting/adding only on need-to-have basis).
> > Only custormer ticket related tests could be backported, it means only
> > unit of tests per months.
> > - testsuite execution time - we don't need to run the legacy modules with
> > each PR, it can be resolved by using profiles
> >
> > As a smoke test we tried to run testsuite/integration-tests/basic module
> > with standalone-elytron.xml and standalone-full-elytron.xml (merged
> > standalone-full.xml and standalone-elytron.xml). There is around 25% test
> > failures/errors. Also some testcases, which seem that are not directly
> > related to security, failed.
> >
> > Thanks,
> >
> > -- Josef
> >
> >
> > ----- Original Message -----
> >> From: "Kabir Khan" <kabir.khan at jboss.com>
> >> To: "Brian Stansberry" <brian.stansberry at redhat.com>
> >> Cc: wildfly-dev at lists.jboss.org
> >> Sent: Friday, December 2, 2016 4:28:07 PM
> >> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
> >>
> >> +1 doubling the testsuite size/time is not practical. Also, there is the
> >> issue that if all tests are duplicated, when people come to enhance an
> >> existing test they will need to do so in two places.
> >>
> >> Could we not do what was suggested earlier and pull out tests which
> >> obviously
> >> target security into two legacy/elytron modules, and leave the rest where
> >> they are? Then if something later turns out to have 'hidden' implications,
> >> that test gets pulled out into the two modules.
> >>
> >> Regarding the deprecated legacy stuff, I think we will have to keep that
> >> around for many years still due to it being used by the product (and in
> >> any
> >> case in that branch, although removing it from WF might be possible
> >> sooner).
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From darran.lofthouse at jboss.com  Tue Dec  6 07:08:58 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 6 Dec 2016 12:08:58 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <700821323.1012746.1481010037415.JavaMail.zimbra@redhat.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
	<373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
	<443b829c-3aa5-0aeb-084e-f29e6d31ecfc@jboss.com>
	<700821323.1012746.1481010037415.JavaMail.zimbra@redhat.com>
Message-ID: <ce394cfc-3fb8-6182-341f-d232d46bfab8@jboss.com>

As I think about this I am heading back to just a two way split.

If we go for the two way split, lets say the following about the default 
WildFly configuration: -

  - It will be entirely backed by the Elytron subsystem.
  - Legacy security-realms will be removed.
  - The legacy security subsystem will be removed.
  - The legacy security extension will be removed.

Existing users forward porting their configuration are unaffected as 
this only affects default new configuration.

We can offer documentation on how to re-enable those items where really 
needed - anyone doing so hopefully submitting a Jira letting us know why 
they are doing so.

This will mean the 900 "non-security" tests will certainly be verified 
that they run without the legacy security extension being installed.

We then have a new legacy-security module where we add at the very least 
the legacy security extension back in which we copy the 50 or so 
security tests over.

The security specific tests left behind are all cleaned up and ported to 
pure Elytron based testing.

Anything that breaks as we switch the configuration over in the 
remaining 900 tests we will review on a case by case basis, also we will 
keep an eye on other subsystems we have touched as they may want a 
legacy test adding e.g. messaging is one we have been working on this week.

Regards,
Darran Lofthouse.


On 06/12/16 07:40, Josef Cacek wrote:
> The 3-way split is a good idea, but it would only work if
> - we are sure the non-security tests in shared modules stay really independent - i.e. no new Ignores, Assumes, configuration based conditions;
> - all shared modules have profiles for running with legacy security.
>
> It's not clear how many new modules would be necessary with the 3 way split. Current TS modules don't share server configuration and they (may) contain several surefire executions with different server profiles.
>
> -- Josef
>
> ----- Original Message -----
>> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>> To: wildfly-dev at lists.jboss.org
>> Sent: Monday, December 5, 2016 5:28:02 PM
>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
>>
>> Regarding that 25% failure - I would expect a lot of that to be picked
>> up anyway as we merge the *-elytron.xml configurations into the default
>> configurations and then drop the *-elytron configurations.
>>
>> How about my reply to Stuart's e-mail and a 3-way split,
>> legacy-security, security, and basic where basic can have optional
>> profiles added to test different extension availability?
>>
>> We could then do as Kabir suggests and pull out additional tests later
>> if we do find a reason to justify duplicating the test and in the
>> meantime have the profiles available to run the tests.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> On 05/12/16 15:03, Josef Cacek wrote:
>>> Hi,
>>>
>>> We still see the copying whole modules as the best way. Let's recap our
>>> view.
>>>
>>> Tested components may use a security feature internally and without test
>>> coverage we would not realize that the feature stopped working. Running
>>> all tests will help us to discover regressions before they occur in
>>> application server.
>>>
>>> Pros:
>>> - we don't lose testcoverage, we can simply detect regressions. It also
>>> provides possible early failure detection for dev.
>>> - it would be useful for migration, it shows migration path - user can take
>>> a look on tests with legacy solution and compare their configuration with
>>> tests which use Elytron configuration
>>> - by each testsuite run we see how many tests are skipped (i.e. TODO list
>>> for Elytron integration)
>>> - it should be simple to reconfigure the project (copy module; update
>>> metadata in pom.xml; ignore failing tests)
>>> - it's simple to remove legacy testsuite modules once the legacy security
>>> subsystem is removed from WildFly
>>>
>>> Cons and their solutions:
>>> - double fixing of tests - we don't expect many such cases, the legacy
>>> should be handled as frozen (rewriting/adding only on need-to-have basis).
>>> Only custormer ticket related tests could be backported, it means only
>>> unit of tests per months.
>>> - testsuite execution time - we don't need to run the legacy modules with
>>> each PR, it can be resolved by using profiles
>>>
>>> As a smoke test we tried to run testsuite/integration-tests/basic module
>>> with standalone-elytron.xml and standalone-full-elytron.xml (merged
>>> standalone-full.xml and standalone-elytron.xml). There is around 25% test
>>> failures/errors. Also some testcases, which seem that are not directly
>>> related to security, failed.
>>>
>>> Thanks,
>>>
>>> -- Josef
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Kabir Khan" <kabir.khan at jboss.com>
>>>> To: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>> Cc: wildfly-dev at lists.jboss.org
>>>> Sent: Friday, December 2, 2016 4:28:07 PM
>>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly testsuite
>>>>
>>>> +1 doubling the testsuite size/time is not practical. Also, there is the
>>>> issue that if all tests are duplicated, when people come to enhance an
>>>> existing test they will need to do so in two places.
>>>>
>>>> Could we not do what was suggested earlier and pull out tests which
>>>> obviously
>>>> target security into two legacy/elytron modules, and leave the rest where
>>>> they are? Then if something later turns out to have 'hidden' implications,
>>>> that test gets pulled out into the two modules.
>>>>
>>>> Regarding the deprecated legacy stuff, I think we will have to keep that
>>>> around for many years still due to it being used by the product (and in
>>>> any
>>>> case in that branch, although removing it from WF might be possible
>>>> sooner).
>>> _______________________________________________
>>> 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 anmiller at redhat.com  Tue Dec  6 10:50:39 2016
From: anmiller at redhat.com (Andrig Miller)
Date: Tue, 6 Dec 2016 08:50:39 -0700
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
	<CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>
Message-ID: <CAF1-sp4H9OhB+m46LgZg1jrjTMKA=hY1dw9FiJHTnmMMzhNUVw@mail.gmail.com>

On Mon, Dec 5, 2016 at 9:54 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

>
>
> On Tue, Dec 6, 2016 at 10:12 AM, Andrig Miller <anmiller at redhat.com>
> wrote:
>
>> I'm just wondering if we are making this graceful shutdown more
>> complicated than necessary.
>>
>> Why wouldn't we just cancel and force a rollback on any active
>> transactions when shutting down?  Having experienced what a graceful
>> shutdown can look like with a different architecture (BEA Tuxedo), I can
>> tell you that it can take a very long time for the server to get to the
>> point of shutting down, and appear to be hung by the administrator,
>> depending on what was going on at the time the command was entered.
>>
>
>
> I think at the very least this has to be optional, so we can still have
> the old non transnational behavior (i.e. wait for requests to finish rather
> than transactions).
>

?My personal opinion is that it should be the default behavior as well.
Most of the time, when our administrators would try to gracefully shutdown
Tuxedo, then ended up killing it with a kill -9, because it took too long.
Of course, that caused all kinds of consistency problems and transaction
recovery on the next startup.  Generally, it was a mess.

Andy
?


>
> Stuart
>
>
>>
>> We used to get administrators killing Tuxedo while it was "gracefully"
>> shutting down, and messing lots of stuff up.
>>
>> Andy
>>
>> On Mon, Dec 5, 2016 at 12:34 PM, Flavia Rainone <frainone at redhat.com>
>> wrote:
>>
>>> I think we can keep open transaction tracking only inside transactions
>>> subsystem while we are not shutting down, and then we can enroll for
>>> notification of open active transactions only on suspend if needed... IMHO
>>> that's as clean as we can get regarding shutdown code when the server is in
>>> running state.
>>>
>>> I would go with some sort of ActiveTransactionListener, that would be
>>> notified of no more active transactions only if the listener is set?
>>>
>>> Something along the lines below at ejb side:
>>>
>>> ServerActivityCallback callback = null;
>>>
>>> public void suspend(ServerActivityCallback callback) {
>>>     if ( transactionSubsystem.getActiveTransactions() > 0) {
>>>        transactionSubsystem.setActiveTransactionsListener(this);
>>>     }
>>>     else {
>>>       callback.done(); // done suspending
>>>    }
>>> }
>>>
>>> // listener method
>>> public void noMoreActiveTransactions() {
>>>     callback.done(); // done suspending
>>>     // then we let control point notify clients that this node is no
>>> longer available
>>>     ...
>>> }
>>>
>>> At transactions side:
>>> ActiveTransactionListener listener = null;
>>>
>>> private void incrementTxnCount() {
>>>     ...
>>> }
>>>
>>> private void decrementTxnCount() {
>>>    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
>>>        listener.noMoreActiveTransactions();
>>> }
>>>
>>> public int getActiveTransactions() {
>>>    return txnCountUpdater.get();
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 04-12-2016 20:39, Stuart Douglas wrote:
>>>
>>> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> <frainone at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm creating this thread to discuss the remaining details of graceful
>>> shutdown for ejb transactions.
>>>
>>> This is more or less what I've done so far:
>>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>
>>> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>>> we could have the transactions subsystem responsible for keeping track of
>>> how many active transactions we have, instead of putting that code in
>>> EjbRemoteTransactionsRepository.
>>>
>>> Stuart, does that include having the suspend callback being done at
>>> transactions subsystem as well? I'm thinking maybe not, because there are
>>> two points in the ejb subsystem we need to know if transactions suspension
>>> is over:
>>>
>>>
>>> No, that still has to be handled at an EJB subsystem level.
>>> Conceptually this is similar to what was done for the XTS subsytem, so
>>> it should probably use a similar design. Ideally while the server is
>>> in the running state the only graceful related code that is run is the
>>> control point request tracking, however this may not be possible.
>>>
>>> One other thing that came up on our hipchat discussion yesterday is TX
>>> level graceful shutdown actually has some significant drawbacks, as
>>> you cannot send out the module unavailability message until all the
>>> transactions have been closed. This means that while we are waiting
>>> for transactions to complete the node will still be part of a cluster,
>>> and clients will send it requests that will be immediately rejected.
>>>
>>> Stuart
>>>
>>>
>>> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>>> not over, we need to check if current invocation contains a reference to an
>>> active transaction
>>>
>>> - at some point, we need to let control point notify that the ejb module is
>>> not longer available to ejb client after transaction suspension is over,
>>> i.e., we need to do that when suspend has been requested and there are no
>>> remaining active transactions available.
>>>
>>> On the other hand, it is hard to draw the line between what should be in the
>>> transactions subsystem and what shouldn't. If the callback is done at
>>> transactions subsystem, we need a way of having ejb3 notified that it is
>>> done. If it is not done at transactions subsystem, ejb3 has to be notified
>>> of the active transactions going to zero, which seems a lot of overhead, so
>>> from this point of view maybe the callback should be in the transactions
>>> system after all.
>>>
>>> Stuart and Gytis, any thoughts?
>>>
>>>
>>> --
>>> Flavia Rainone
>>> Principal Software Engineer
>>> JBoss EAP/WildFly Team
>>> M: (+55) 11 981-225-466
>>>
>>> Red Hat.
>>> Better technology.
>>> Faster innovation.
>>> Powered by community collaboration.
>>>
>>>
>>> --
>>> Flavia Rainone
>>> Principal Software Engineer
>>> JBoss EAP/WildFly Team
>>> M: (+55) 11 981-225-466
>>>
>>> Red Hat.
>>> Better technology.
>>> Faster innovation.
>>> Powered by community collaboration.
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> Andrig (Andy) T. Miller
>> Global Platform Director, Middleware
>> Red Hat, Inc.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161206/32359650/attachment-0001.html 

From darran.lofthouse at jboss.com  Wed Dec  7 07:59:19 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 7 Dec 2016 12:59:19 +0000
Subject: [wildfly-dev] Elytron integration tests in WildFly testsuite
In-Reply-To: <ce394cfc-3fb8-6182-341f-d232d46bfab8@jboss.com>
References: <1867203190.770028.1480666316459.JavaMail.zimbra@redhat.com>
	<563563631.787428.1480679915152.JavaMail.zimbra@redhat.com>
	<CAMquZP5iw1EKeF3LvVMeViruC3iR=is96pQ=4Z0hUCczDeHBrg@mail.gmail.com>
	<b8dad29d-bd15-de5f-89c7-054f206c3130@jboss.com>
	<6960935B-75B3-4446-9A9A-DA8D3C009324@redhat.com>
	<6B029766-48F2-414F-BCCC-AD522858F344@jboss.com>
	<373439743.938863.1480950227020.JavaMail.zimbra@redhat.com>
	<443b829c-3aa5-0aeb-084e-f29e6d31ecfc@jboss.com>
	<700821323.1012746.1481010037415.JavaMail.zimbra@redhat.com>
	<ce394cfc-3fb8-6182-341f-d232d46bfab8@jboss.com>
Message-ID: <8a6a1f7b-bbdb-a9fd-1d09-c165ef581bc1@jboss.com>

Ok, we will go for this approach.

We will create a new testsuite module 'legacy-security', we will copy 
the 50 or so tests that are easily identifiable as security tests into 
this new module - as these are testing legacy security the only real 
changes they should require will be to re-enable legacy security.

Remaining tests will be executed against configuration that favours 
Elytron over legacy.  Security tests in this area will be cleaned up and 
then we can start adding new security tests.

We will monitor other tests and if security related regressions are 
identified we will review on a case by case basis and if appropriate 
fork into the legacy-security module.

Regards,
Darran Lofthouse.




On 06/12/16 12:08, Darran Lofthouse wrote:
> As I think about this I am heading back to just a two way split.
>
> If we go for the two way split, lets say the following about the default
> WildFly configuration: -
>
>  - It will be entirely backed by the Elytron subsystem.
>  - Legacy security-realms will be removed.
>  - The legacy security subsystem will be removed.
>  - The legacy security extension will be removed.
>
> Existing users forward porting their configuration are unaffected as
> this only affects default new configuration.
>
> We can offer documentation on how to re-enable those items where really
> needed - anyone doing so hopefully submitting a Jira letting us know why
> they are doing so.
>
> This will mean the 900 "non-security" tests will certainly be verified
> that they run without the legacy security extension being installed.
>
> We then have a new legacy-security module where we add at the very least
> the legacy security extension back in which we copy the 50 or so
> security tests over.
>
> The security specific tests left behind are all cleaned up and ported to
> pure Elytron based testing.
>
> Anything that breaks as we switch the configuration over in the
> remaining 900 tests we will review on a case by case basis, also we will
> keep an eye on other subsystems we have touched as they may want a
> legacy test adding e.g. messaging is one we have been working on this week.
>
> Regards,
> Darran Lofthouse.
>
>
> On 06/12/16 07:40, Josef Cacek wrote:
>> The 3-way split is a good idea, but it would only work if
>> - we are sure the non-security tests in shared modules stay really
>> independent - i.e. no new Ignores, Assumes, configuration based
>> conditions;
>> - all shared modules have profiles for running with legacy security.
>>
>> It's not clear how many new modules would be necessary with the 3 way
>> split. Current TS modules don't share server configuration and they
>> (may) contain several surefire executions with different server profiles.
>>
>> -- Josef
>>
>> ----- Original Message -----
>>> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>>> To: wildfly-dev at lists.jboss.org
>>> Sent: Monday, December 5, 2016 5:28:02 PM
>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>>> testsuite
>>>
>>> Regarding that 25% failure - I would expect a lot of that to be picked
>>> up anyway as we merge the *-elytron.xml configurations into the default
>>> configurations and then drop the *-elytron configurations.
>>>
>>> How about my reply to Stuart's e-mail and a 3-way split,
>>> legacy-security, security, and basic where basic can have optional
>>> profiles added to test different extension availability?
>>>
>>> We could then do as Kabir suggests and pull out additional tests later
>>> if we do find a reason to justify duplicating the test and in the
>>> meantime have the profiles available to run the tests.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>> On 05/12/16 15:03, Josef Cacek wrote:
>>>> Hi,
>>>>
>>>> We still see the copying whole modules as the best way. Let's recap our
>>>> view.
>>>>
>>>> Tested components may use a security feature internally and without
>>>> test
>>>> coverage we would not realize that the feature stopped working. Running
>>>> all tests will help us to discover regressions before they occur in
>>>> application server.
>>>>
>>>> Pros:
>>>> - we don't lose testcoverage, we can simply detect regressions. It also
>>>> provides possible early failure detection for dev.
>>>> - it would be useful for migration, it shows migration path - user
>>>> can take
>>>> a look on tests with legacy solution and compare their configuration
>>>> with
>>>> tests which use Elytron configuration
>>>> - by each testsuite run we see how many tests are skipped (i.e. TODO
>>>> list
>>>> for Elytron integration)
>>>> - it should be simple to reconfigure the project (copy module; update
>>>> metadata in pom.xml; ignore failing tests)
>>>> - it's simple to remove legacy testsuite modules once the legacy
>>>> security
>>>> subsystem is removed from WildFly
>>>>
>>>> Cons and their solutions:
>>>> - double fixing of tests - we don't expect many such cases, the legacy
>>>> should be handled as frozen (rewriting/adding only on need-to-have
>>>> basis).
>>>> Only custormer ticket related tests could be backported, it means only
>>>> unit of tests per months.
>>>> - testsuite execution time - we don't need to run the legacy modules
>>>> with
>>>> each PR, it can be resolved by using profiles
>>>>
>>>> As a smoke test we tried to run testsuite/integration-tests/basic
>>>> module
>>>> with standalone-elytron.xml and standalone-full-elytron.xml (merged
>>>> standalone-full.xml and standalone-elytron.xml). There is around 25%
>>>> test
>>>> failures/errors. Also some testcases, which seem that are not directly
>>>> related to security, failed.
>>>>
>>>> Thanks,
>>>>
>>>> -- Josef
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Kabir Khan" <kabir.khan at jboss.com>
>>>>> To: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>>> Cc: wildfly-dev at lists.jboss.org
>>>>> Sent: Friday, December 2, 2016 4:28:07 PM
>>>>> Subject: Re: [wildfly-dev] Elytron integration tests in WildFly
>>>>> testsuite
>>>>>
>>>>> +1 doubling the testsuite size/time is not practical. Also, there
>>>>> is the
>>>>> issue that if all tests are duplicated, when people come to enhance an
>>>>> existing test they will need to do so in two places.
>>>>>
>>>>> Could we not do what was suggested earlier and pull out tests which
>>>>> obviously
>>>>> target security into two legacy/elytron modules, and leave the rest
>>>>> where
>>>>> they are? Then if something later turns out to have 'hidden'
>>>>> implications,
>>>>> that test gets pulled out into the two modules.
>>>>>
>>>>> Regarding the deprecated legacy stuff, I think we will have to keep
>>>>> that
>>>>> around for many years still due to it being used by the product
>>>>> (and in
>>>>> any
>>>>> case in that branch, although removing it from WF might be possible
>>>>> sooner).
>>>> _______________________________________________
>>>> 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 jtyrrell at redhat.com  Wed Dec  7 08:49:20 2016
From: jtyrrell at redhat.com (Jim Tyrrell)
Date: Wed, 7 Dec 2016 06:49:20 -0700
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <CAF1-sp4H9OhB+m46LgZg1jrjTMKA=hY1dw9FiJHTnmMMzhNUVw@mail.gmail.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
	<CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>
	<CAF1-sp4H9OhB+m46LgZg1jrjTMKA=hY1dw9FiJHTnmMMzhNUVw@mail.gmail.com>
Message-ID: <2EFD81C4-EA31-4E65-B50F-0FB30FF3F086@redhat.com>

Team,

How might we process the shutting down with a transaction log message/s saying it is shutting down or saying something like:

Started shutting down
100 pending transactions
10 shut down 90 pending
20 shut down 80 pending

or something like that.

Feedback to the user in this sounds important to ensure people don?t kill -9 the process.

Jim Tyrrell
Principal JBoss Solutions Architect
Public Sector Middleware Advocate
720-839-2251 mobile

> On Dec 6, 2016, at 8:50 AM, Andrig Miller <anmiller at redhat.com> wrote:
> 
> 
> 
> On Mon, Dec 5, 2016 at 9:54 PM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
> 
> 
> On Tue, Dec 6, 2016 at 10:12 AM, Andrig Miller <anmiller at redhat.com <mailto:anmiller at redhat.com>> wrote:
> I'm just wondering if we are making this graceful shutdown more complicated than necessary.
> 
> Why wouldn't we just cancel and force a rollback on any active transactions when shutting down?  Having experienced what a graceful shutdown can look like with a different architecture (BEA Tuxedo), I can tell you that it can take a very long time for the server to get to the point of shutting down, and appear to be hung by the administrator, depending on what was going on at the time the command was entered.
> 
> 
> I think at the very least this has to be optional, so we can still have the old non transnational behavior (i.e. wait for requests to finish rather than transactions). 
> 
> ?My personal opinion is that it should be the default behavior as well.  Most of the time, when our administrators would try to gracefully shutdown Tuxedo, then ended up killing it with a kill -9, because it took too long.  Of course, that caused all kinds of consistency problems and transaction recovery on the next startup.  Generally, it was a mess.
> 
> Andy
> ? 
> 
> Stuart
>  
> 
> We used to get administrators killing Tuxedo while it was "gracefully" shutting down, and messing lots of stuff up.
> 
> Andy
> 
> On Mon, Dec 5, 2016 at 12:34 PM, Flavia Rainone <frainone at redhat.com <mailto:frainone at redhat.com>> wrote:
> I think we can keep open transaction tracking only inside transactions subsystem while we are not shutting down, and then we can enroll for notification of open active transactions only on suspend if needed... IMHO that's as clean as we can get regarding shutdown code when the server is in running state.
> 
> I would go with some sort of ActiveTransactionListener, that would be notified of no more active transactions only if the listener is set?
> 
> Something along the lines below at ejb side:
> 
> ServerActivityCallback callback = null;
> 
> public void suspend(ServerActivityCallback callback) {
>     if ( transactionSubsystem.getActiveTransactions() > 0) {
>        transactionSubsystem.setActiveTransactionsListener(this);
>     }
>     else {
>       callback.done(); // done suspending
>    }
> }
> 
> // listener method
> public void noMoreActiveTransactions() {
>     callback.done(); // done suspending
>     // then we let control point notify clients that this node is no longer available
>     ...
> }
> 
> At transactions side:
> ActiveTransactionListener listener = null;
> 
> private void incrementTxnCount() {
>     ...
> }
> 
> private void decrementTxnCount() {
>    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
>        listener.noMoreActiveTransactions();        
> }
> 
> public int getActiveTransactions() {
>    return txnCountUpdater.get();
> 
> }
> 
> 
> 
> 
> 
> 
> 
> On 04-12-2016 20:39, Stuart Douglas wrote:
>> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone <frainone at redhat.com> <mailto:frainone at redhat.com> wrote:
>>> Hi,
>>> 
>>> I'm creating this thread to discuss the remaining details of graceful
>>> shutdown for ejb transactions.
>>> 
>>> This is more or less what I've done so far:
>>> 
>>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760 <https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760>
>>> 
>>> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>>> we could have the transactions subsystem responsible for keeping track of
>>> how many active transactions we have, instead of putting that code in
>>> EjbRemoteTransactionsRepository.
>>> 
>>> Stuart, does that include having the suspend callback being done at
>>> transactions subsystem as well? I'm thinking maybe not, because there are
>>> two points in the ejb subsystem we need to know if transactions suspension
>>> is over:
>>> 
>> No, that still has to be handled at an EJB subsystem level.
>> Conceptually this is similar to what was done for the XTS subsytem, so
>> it should probably use a similar design. Ideally while the server is
>> in the running state the only graceful related code that is run is the
>> control point request tracking, however this may not be possible.
>> 
>> One other thing that came up on our hipchat discussion yesterday is TX
>> level graceful shutdown actually has some significant drawbacks, as
>> you cannot send out the module unavailability message until all the
>> transactions have been closed. This means that while we are waiting
>> for transactions to complete the node will still be part of a cluster,
>> and clients will send it requests that will be immediately rejected.
>> 
>> Stuart
>> 
>>> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>>> not over, we need to check if current invocation contains a reference to an
>>> active transaction
>>> 
>>> - at some point, we need to let control point notify that the ejb module is
>>> not longer available to ejb client after transaction suspension is over,
>>> i.e., we need to do that when suspend has been requested and there are no
>>> remaining active transactions available.
>>> 
>>> On the other hand, it is hard to draw the line between what should be in the
>>> transactions subsystem and what shouldn't. If the callback is done at
>>> transactions subsystem, we need a way of having ejb3 notified that it is
>>> done. If it is not done at transactions subsystem, ejb3 has to be notified
>>> of the active transactions going to zero, which seems a lot of overhead, so
>>> from this point of view maybe the callback should be in the transactions
>>> system after all.
>>> 
>>> Stuart and Gytis, any thoughts?
>>> 
>>> 
>>> --
>>> Flavia Rainone
>>> Principal Software Engineer
>>> JBoss EAP/WildFly Team
>>> M: (+55) 11 981-225-466
>>> 
>>> Red Hat.
>>> Better technology.
>>> Faster innovation.
>>> Powered by community collaboration.
> 
> -- 
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team 
> M: (+55) 11 981-225-466
> 
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration. 
> 
> _______________________________________________
> 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>
> 
> 
> 
> -- 
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
> 
> _______________________________________________
> 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>
> 
> 
> 
> 
> -- 
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
> _______________________________________________
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161207/ec3f065c/attachment-0001.html 

From rhatlapa at redhat.com  Wed Dec  7 09:16:04 2016
From: rhatlapa at redhat.com (Radim Hatlapatka)
Date: Wed, 7 Dec 2016 15:16:04 +0100
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <2EFD81C4-EA31-4E65-B50F-0FB30FF3F086@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
	<CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>
	<CAF1-sp4H9OhB+m46LgZg1jrjTMKA=hY1dw9FiJHTnmMMzhNUVw@mail.gmail.com>
	<2EFD81C4-EA31-4E65-B50F-0FB30FF3F086@redhat.com>
Message-ID: <0a934185-1228-7f77-3494-783c5316667a@redhat.com>

Definitely +1 for prompting in logs what is being happening and why 
shutdown takes longer period of time.

Also the graceful shutdown adds timeout which can be used to limit 
maximum number of seconds for finishing shutdown gracefully, after that 
time it should stop waiting for remaining transactions/requests to finish.

Note current default behaviour is to stop the server without using the 
graceful shutdown (timeout needs to be specified for actually using the 
graceful shutdown logic), for details see description of shutdown 
command timeout value.

Cheers.

Radim


On 12/07/2016 02:49 PM, Jim Tyrrell wrote:
> Team,
>
> How might we process the shutting down with a transaction log 
> message/s saying it is shutting down or saying something like:
>
> Started shutting down
> 100 pending transactions
> 10 shut down 90 pending
> 20 shut down 80 pending
>
> or something like that.
>
> Feedback to the user in this sounds important to ensure people don?t 
> kill -9 the process.
>
> Jim Tyrrell
> Principal JBoss Solutions Architect
> Public Sector Middleware Advocate
> 720-839-2251 mobile
>
>> On Dec 6, 2016, at 8:50 AM, Andrig Miller <anmiller at redhat.com 
>> <mailto:anmiller at redhat.com>> wrote:
>>
>>
>>
>> On Mon, Dec 5, 2016 at 9:54 PM, Stuart 
>> Douglas<stuart.w.douglas at gmail.com 
>> <mailto:stuart.w.douglas at gmail.com>>wrote:
>>
>>
>>
>>     On Tue, Dec 6, 2016 at 10:12 AM, Andrig
>>     Miller<anmiller at redhat.com <mailto:anmiller at redhat.com>>wrote:
>>
>>         I'm just wondering if we are making this graceful shutdown
>>         more complicated than necessary.
>>
>>         Why wouldn't we just cancel and force a rollback on any
>>         active transactions when shutting down?  Having experienced
>>         what a graceful shutdown can look like with a different
>>         architecture (BEA Tuxedo), I can tell you that it can take a
>>         very long time for the server to get to the point of shutting
>>         down, and appear to be hung by the administrator, depending
>>         on what was going on at the time the command was entered.
>>
>>
>>
>>     I think at the very least this has to be optional, so we can
>>     still have the old non transnational behavior (i.e. wait for
>>     requests to finish rather than transactions).
>>
>>
>> ?My personal opinion is that it should be the default behavior as 
>> well.  Most of the time, when our administrators would try to 
>> gracefully shutdown Tuxedo, then ended up killing it with a kill -9, 
>> because it took too long. Of course, that caused all kinds of 
>> consistency problems and transaction recovery on the next startup.  
>> Generally, it was a mess.
>>
>> Andy
>> ?
>>
>>
>>     Stuart
>>
>>
>>         We used to get administrators killing Tuxedo while it was
>>         "gracefully" shutting down, and messing lots of stuff up.
>>
>>         Andy
>>
>>         On Mon, Dec 5, 2016 at 12:34 PM, Flavia
>>         Rainone<frainone at redhat.com <mailto:frainone at redhat.com>>wrote:
>>
>>             I think we can keep open transaction tracking only inside
>>             transactions subsystem while we are not shutting down,
>>             and then we can enroll for notification of open active
>>             transactions only on suspend if needed... IMHO that's as
>>             clean as we can get regarding shutdown code when the
>>             server is in running state.
>>
>>             I would go with some sort of ActiveTransactionListener,
>>             that would be notified of no more active transactions
>>             only if the listener is set?
>>
>>             Something along the lines below at ejb side:
>>
>>             ServerActivityCallback callback = null;
>>
>>             public void suspend(ServerActivityCallback callback) {
>>             if ( transactionSubsystem.getActiveTransactions() > 0) {
>>             transactionSubsystem.setActiveTransactionsListener(this);
>>             }
>>             else {
>>             callback.done(); // done suspending
>>             }
>>             }
>>
>>             // listener method
>>             public void noMoreActiveTransactions() {
>>             callback.done(); // done suspending
>>             // then we let control point notify clients that this
>>             node is no longer available
>>             ...
>>             }
>>
>>             At transactions side:
>>             ActiveTransactionListener listener = null;
>>
>>             private void incrementTxnCount() {
>>             ...
>>             }
>>
>>             private void decrementTxnCount() {
>>             if (txnCountUpdater.decrementAndGet() == 0 && listener !=
>>             null)
>>             listener.noMoreActiveTransactions();
>>             }
>>
>>             public int getActiveTransactions() {
>>             return txnCountUpdater.get();
>>
>>             }
>>
>>
>>
>>
>>
>>
>>
>>             On 04-12-2016 20:39, Stuart Douglas wrote:
>>>             On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone<frainone at redhat.com> <mailto:frainone at redhat.com>  wrote:
>>>>             Hi,
>>>>
>>>>             I'm creating this thread to discuss the remaining details of graceful
>>>>             shutdown for ejb transactions.
>>>>
>>>>             This is more or less what I've done so far:
>>>>
>>>>             https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>>             <https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760>
>>>>
>>>>             While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>>>>             we could have the transactions subsystem responsible for keeping track of
>>>>             how many active transactions we have, instead of putting that code in
>>>>             EjbRemoteTransactionsRepository.
>>>>
>>>>             Stuart, does that include having the suspend callback being done at
>>>>             transactions subsystem as well? I'm thinking maybe not, because there are
>>>>             two points in the ejb subsystem we need to know if transactions suspension
>>>>             is over:
>>>>
>>>             No, that still has to be handled at an EJB subsystem level.
>>>             Conceptually this is similar to what was done for the XTS subsytem, so
>>>             it should probably use a similar design. Ideally while the server is
>>>             in the running state the only graceful related code that is run is the
>>>             control point request tracking, however this may not be possible.
>>>
>>>             One other thing that came up on our hipchat discussion yesterday is TX
>>>             level graceful shutdown actually has some significant drawbacks, as
>>>             you cannot send out the module unavailability message until all the
>>>             transactions have been closed. This means that while we are waiting
>>>             for transactions to complete the node will still be part of a cluster,
>>>             and clients will send it requests that will be immediately rejected.
>>>
>>>             Stuart
>>>
>>>>             - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>>>>             not over, we need to check if current invocation contains a reference to an
>>>>             active transaction
>>>>
>>>>             - at some point, we need to let control point notify that the ejb module is
>>>>             not longer available to ejb client after transaction suspension is over,
>>>>             i.e., we need to do that when suspend has been requested and there are no
>>>>             remaining active transactions available.
>>>>
>>>>             On the other hand, it is hard to draw the line between what should be in the
>>>>             transactions subsystem and what shouldn't. If the callback is done at
>>>>             transactions subsystem, we need a way of having ejb3 notified that it is
>>>>             done. If it is not done at transactions subsystem, ejb3 has to be notified
>>>>             of the active transactions going to zero, which seems a lot of overhead, so
>>>>             from this point of view maybe the callback should be in the transactions
>>>>             system after all.
>>>>
>>>>             Stuart and Gytis, any thoughts?
>>>>
>>>>
>>>>             --
>>>>             Flavia Rainone
>>>>             Principal Software Engineer
>>>>             JBoss EAP/WildFly Team
>>>>             M: (+55) 11 981-225-466
>>>>
>>>>             Red Hat.
>>>>             Better technology.
>>>>             Faster innovation.
>>>>             Powered by community collaboration.
>>             -- 
>>             Flavia Rainone
>>             Principal Software Engineer
>>             JBoss EAP/WildFly Team
>>             M: (+55) 11 981-225-466
>>
>>             Red Hat.
>>             Better technology.
>>             Faster innovation.
>>             Powered by community collaboration.
>>
>>             _______________________________________________
>>             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> 
>>
>>         --
>>         Andrig (Andy) T. Miller
>>         Global Platform Director, Middleware
>>         Red Hat, Inc.
>>         _______________________________________________ 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> 
>>
>> --
>> Andrig (Andy) T. Miller
>> Global Platform Director, Middleware
>> Red Hat, Inc.
>> _______________________________________________ wildfly-dev mailing 
>> list wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org> 
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161207/2f57af92/attachment-0001.html 

From frainone at redhat.com  Wed Dec  7 13:32:05 2016
From: frainone at redhat.com (Flavia Rainone)
Date: Wed, 7 Dec 2016 16:32:05 -0200
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <0a934185-1228-7f77-3494-783c5316667a@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<CAF1-sp4PojKTU+AoO9WHORyaeeEPvuN0JBx5EFrSFcuGOL7OAA@mail.gmail.com>
	<CAAoo=c6Z7tXueFaG1=Vp55ZmKZKSpVv-risw1pxLcew7-omMwg@mail.gmail.com>
	<CAF1-sp4H9OhB+m46LgZg1jrjTMKA=hY1dw9FiJHTnmMMzhNUVw@mail.gmail.com>
	<2EFD81C4-EA31-4E65-B50F-0FB30FF3F086@redhat.com>
	<0a934185-1228-7f77-3494-783c5316667a@redhat.com>
Message-ID: <43de2edd-9a1d-7595-0874-a1f3dc415b3f@redhat.com>

+1, I like the idea of logging the number of active pending transactions.


On 07-12-2016 12:16, Radim Hatlapatka wrote:
>
> Definitely +1 for prompting in logs what is being happening and why 
> shutdown takes longer period of time.
>
> Also the graceful shutdown adds timeout which can be used to limit 
> maximum number of seconds for finishing shutdown gracefully, after 
> that time it should stop waiting for remaining transactions/requests 
> to finish.
>
> Note current default behaviour is to stop the server without using the 
> graceful shutdown (timeout needs to be specified for actually using 
> the graceful shutdown logic), for details see description of shutdown 
> command timeout value.
>
> Cheers.
>
> Radim
>
>
> On 12/07/2016 02:49 PM, Jim Tyrrell wrote:
>> Team,
>>
>> How might we process the shutting down with a transaction log 
>> message/s saying it is shutting down or saying something like:
>>
>> Started shutting down
>> 100 pending transactions
>> 10 shut down 90 pending
>> 20 shut down 80 pending
>>
>> or something like that.
>>
>> Feedback to the user in this sounds important to ensure people don?t 
>> kill -9 the process.
>>
>> Jim Tyrrell
>> Principal JBoss Solutions Architect
>> Public Sector Middleware Advocate
>> 720-839-2251 mobile
>>
>>> On Dec 6, 2016, at 8:50 AM, Andrig Miller <anmiller at redhat.com 
>>> <mailto:anmiller at redhat.com>> wrote:
>>>
>>>
>>>
>>> On Mon, Dec 5, 2016 at 9:54 PM, Stuart 
>>> Douglas<stuart.w.douglas at gmail.com 
>>> <mailto:stuart.w.douglas at gmail.com>>wrote:
>>>
>>>
>>>
>>>     On Tue, Dec 6, 2016 at 10:12 AM, Andrig
>>>     Miller<anmiller at redhat.com <mailto:anmiller at redhat.com>>wrote:
>>>
>>>         I'm just wondering if we are making this graceful shutdown
>>>         more complicated than necessary.
>>>
>>>         Why wouldn't we just cancel and force a rollback on any
>>>         active transactions when shutting down?  Having experienced
>>>         what a graceful shutdown can look like with a different
>>>         architecture (BEA Tuxedo), I can tell you that it can take a
>>>         very long time for the server to get to the point of
>>>         shutting down, and appear to be hung by the administrator,
>>>         depending on what was going on at the time the command was
>>>         entered.
>>>
>>>
>>>
>>>     I think at the very least this has to be optional, so we can
>>>     still have the old non transnational behavior (i.e. wait for
>>>     requests to finish rather than transactions).
>>>
>>>
>>> ?My personal opinion is that it should be the default behavior as 
>>> well. Most of the time, when our administrators would try to 
>>> gracefully shutdown Tuxedo, then ended up killing it with a kill -9, 
>>> because it took too long.  Of course, that caused all kinds of 
>>> consistency problems and transaction recovery on the next startup. 
>>> Generally, it was a mess.
>>>
>>> Andy
>>> ?
>>>
>>>
>>>     Stuart
>>>
>>>
>>>         We used to get administrators killing Tuxedo while it was
>>>         "gracefully" shutting down, and messing lots of stuff up.
>>>
>>>         Andy
>>>
>>>         On Mon, Dec 5, 2016 at 12:34 PM, Flavia
>>>         Rainone<frainone at redhat.com <mailto:frainone at redhat.com>>wrote:
>>>
>>>             I think we can keep open transaction tracking only
>>>             inside transactions subsystem while we are not shutting
>>>             down, and then we can enroll for notification of open
>>>             active transactions only on suspend if needed... IMHO
>>>             that's as clean as we can get regarding shutdown code
>>>             when the server is in running state.
>>>
>>>             I would go with some sort of ActiveTransactionListener,
>>>             that would be notified of no more active transactions
>>>             only if the listener is set?
>>>
>>>             Something along the lines below at ejb side:
>>>
>>>             ServerActivityCallback callback = null;
>>>
>>>             public void suspend(ServerActivityCallback callback) {
>>>             if ( transactionSubsystem.getActiveTransactions() > 0) {
>>>             transactionSubsystem.setActiveTransactionsListener(this);
>>>             }
>>>             else {
>>>             callback.done(); // done suspending
>>>             }
>>>             }
>>>
>>>             // listener method
>>>             public void noMoreActiveTransactions() {
>>>             callback.done(); // done suspending
>>>             // then we let control point notify clients that this
>>>             node is no longer available
>>>             ...
>>>             }
>>>
>>>             At transactions side:
>>>             ActiveTransactionListener listener = null;
>>>
>>>             private void incrementTxnCount() {
>>>             ...
>>>             }
>>>
>>>             private void decrementTxnCount() {
>>>             if (txnCountUpdater.decrementAndGet() == 0 && listener
>>>             != null)
>>>             listener.noMoreActiveTransactions();
>>>             }
>>>
>>>             public int getActiveTransactions() {
>>>             return txnCountUpdater.get();
>>>
>>>             }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             On 04-12-2016 20:39, Stuart Douglas wrote:
>>>>             On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone<frainone at redhat.com> <mailto:frainone at redhat.com>  wrote:
>>>>>             Hi,
>>>>>
>>>>>             I'm creating this thread to discuss the remaining details of graceful
>>>>>             shutdown for ejb transactions.
>>>>>
>>>>>             This is more or less what I've done so far:
>>>>>
>>>>>             https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>>>             <https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760>
>>>>>
>>>>>             While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>>>>>             we could have the transactions subsystem responsible for keeping track of
>>>>>             how many active transactions we have, instead of putting that code in
>>>>>             EjbRemoteTransactionsRepository.
>>>>>
>>>>>             Stuart, does that include having the suspend callback being done at
>>>>>             transactions subsystem as well? I'm thinking maybe not, because there are
>>>>>             two points in the ejb subsystem we need to know if transactions suspension
>>>>>             is over:
>>>>>
>>>>             No, that still has to be handled at an EJB subsystem level.
>>>>             Conceptually this is similar to what was done for the XTS subsytem, so
>>>>             it should probably use a similar design. Ideally while the server is
>>>>             in the running state the only graceful related code that is run is the
>>>>             control point request tracking, however this may not be possible.
>>>>
>>>>             One other thing that came up on our hipchat discussion yesterday is TX
>>>>             level graceful shutdown actually has some significant drawbacks, as
>>>>             you cannot send out the module unavailability message until all the
>>>>             transactions have been closed. This means that while we are waiting
>>>>             for transactions to complete the node will still be part of a cluster,
>>>>             and clients will send it requests that will be immediately rejected.
>>>>
>>>>             Stuart
>>>>
>>>>>             - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>>>>>             not over, we need to check if current invocation contains a reference to an
>>>>>             active transaction
>>>>>
>>>>>             - at some point, we need to let control point notify that the ejb module is
>>>>>             not longer available to ejb client after transaction suspension is over,
>>>>>             i.e., we need to do that when suspend has been requested and there are no
>>>>>             remaining active transactions available.
>>>>>
>>>>>             On the other hand, it is hard to draw the line between what should be in the
>>>>>             transactions subsystem and what shouldn't. If the callback is done at
>>>>>             transactions subsystem, we need a way of having ejb3 notified that it is
>>>>>             done. If it is not done at transactions subsystem, ejb3 has to be notified
>>>>>             of the active transactions going to zero, which seems a lot of overhead, so
>>>>>             from this point of view maybe the callback should be in the transactions
>>>>>             system after all.
>>>>>
>>>>>             Stuart and Gytis, any thoughts?
>>>>>
>>>>>
>>>>>             --
>>>>>             Flavia Rainone
>>>>>             Principal Software Engineer
>>>>>             JBoss EAP/WildFly Team
>>>>>             M: (+55) 11 981-225-466
>>>>>
>>>>>             Red Hat.
>>>>>             Better technology.
>>>>>             Faster innovation.
>>>>>             Powered by community collaboration.
>>>             -- 
>>>             Flavia Rainone
>>>             Principal Software Engineer
>>>             JBoss EAP/WildFly Team
>>>             M: (+55) 11 981-225-466
>>>
>>>             Red Hat.
>>>             Better technology.
>>>             Faster innovation.
>>>             Powered by community collaboration.
>>>
>>>             _______________________________________________
>>>             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> 
>>>
>>>         --
>>>         Andrig (Andy) T. Miller
>>>         Global Platform Director, Middleware
>>>         Red Hat, Inc.
>>>         _______________________________________________ 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> 
>>>
>>> --
>>> Andrig (Andy) T. Miller
>>> Global Platform Director, Middleware
>>> Red Hat, Inc.
>>> _______________________________________________ wildfly-dev mailing 
>>> list wildfly-dev at lists.jboss.org 
>>> <mailto:wildfly-dev at lists.jboss.org> 
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-- 
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466

Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161207/cbdc4f83/attachment-0001.html 

From jai.forums2013 at gmail.com  Thu Dec  8 06:59:04 2016
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 8 Dec 2016 17:29:04 +0530
Subject: [wildfly-dev] JBoss Modules - "advanced" PathFilter for
	ResourceLoaderSpec?
Message-ID: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>

(Using this list since I couldn't find a place to ask JBoss Modules 
question anywhere else, feel free to direct me there if there's one)

Hello everyone :)

I have been using JBoss Modules for one of the projects I'm involved in. 
The usage there is pretty much similar to how we use it for setting up 
classloaders in WildFly server for deployments. A new module M1 gets 
dynamically created and assigned to a component and this module is added 
with dependencies to some pre-defined static modules A, B, C and such.  
M1 also gets N number of resource roots (backed by ResourceLoaderSpec), 
each pointing to a jar file within some well known directory. So to put 
in some sort of a code, it looks like:

// add each jar as a resource root for the module
for (final File jar : jars) {
     final ResourceLoader jarResourceLoader;
     try {
         jarResourceLoader = 
ResourceLoaders.createJarResourceLoader(jar.getName(), new JarFile(jar));
     } catch (IOException e) {
         // log and continue
         logger.warn("....", e);
         continue;
     }
moduleSpecBuilder.addResourceRoot(ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader));
}



All works fine without any issues and the module M1 has access to the 
resources in these jars. Now there are times where the components for 
which I've created this module M1 and attach these jars, "accidentally" 
ship/package jars which have resources (classes to be precise) which are 
also exposed/present in one of the dependency modules (remember A, B, 
C...). So this then leads to the same old thing where I have go back and 
tell my users not to package such jars.

I want to try and make this a bit more robust and get away with having 
to tell users not to package xyz jars. I had a look at the 
ResourceLoaderSpec interface and it takes a PathFilter 
https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org/jboss/modules/ResourceLoaderSpec.java#L48 
which gets me one step closer to what I want to achieve. So if I know 
that static module A, B, C etc... expose classes belonging to package 
foo.bar.blah, I can setup a PathFilter on these jar resource loader to 
skip/decline the path in the accept() method. I think that should work 
out fine (I need to test it out tonight) and I wouldn't have to worry 
that some jar packaged within that component will introduce these 
classes belonging to the foo.bar.blah package.

However, although it might work, I then have to keep a very close vigil 
or rather keep inspecting what packages (or resources in general) the 
modules A, B and C provide. Instead what I'm thinking of is a "smart" 
PathFilter or anything along those lines whose semantics would be to 
"skip/don't accept/filter out all those resources, from a resource root, 
if the resource is provided by any of the specified modules". So 
something like:

ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader, 
*PathFilters.excludeResourcesExposedByModules("A**:slot", "B:slot", 
"C:slot" ...)*);


Having looked at the JBoss Modules code, I don't think this is possible 
currently. But that's OK. What I really want to check is, is this 
something that would be feasible to implement (doesn't have to be in 
JBoss Modules itself) and is there any obvious issues with the approach? 
Also, is this something that would be useful to have in JBoss Modules 
itself?


-Jaikiran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161208/3d763a58/attachment.html 

From david.lloyd at redhat.com  Thu Dec  8 08:59:24 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 8 Dec 2016 07:59:24 -0600
Subject: [wildfly-dev] JBoss Modules - "advanced" PathFilter for
 ResourceLoaderSpec?
In-Reply-To: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>
References: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>
Message-ID: <1fcb209f-ca43-426f-304b-afe177b68f41@redhat.com>

Hi Jaikiran!

On 12/08/2016 05:59 AM, Jaikiran Pai wrote:
> (Using this list since I couldn't find a place to ask JBoss Modules
> question anywhere else, feel free to direct me there if there's one)
>
> Hello everyone :)
>
> I have been using JBoss Modules for one of the projects I'm involved in.
> The usage there is pretty much similar to how we use it for setting up
> classloaders in WildFly server for deployments. A new module M1 gets
> dynamically created and assigned to a component and this module is added
> with dependencies to some pre-defined static modules A, B, C and such.
> M1 also gets N number of resource roots (backed by ResourceLoaderSpec),
> each pointing to a jar file within some well known directory. So to put
> in some sort of a code, it looks like:
>
> // add each jar as a resource root for the module
> for (final File jar : jars) {
>     final ResourceLoader jarResourceLoader;
>     try {
>         jarResourceLoader =
> ResourceLoaders.createJarResourceLoader(jar.getName(), new JarFile(jar));
>     } catch (IOException e) {
>         // log and continue
>         logger.warn("....", e);
>         continue;
>     }
>
> moduleSpecBuilder.addResourceRoot(ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader));
> }
>
>
>
> All works fine without any issues and the module M1 has access to the
> resources in these jars. Now there are times where the components for
> which I've created this module M1 and attach these jars, "accidentally"
> ship/package jars which have resources (classes to be precise) which are
> also exposed/present in one of the dependency modules (remember A, B,
> C...). So this then leads to the same old thing where I have go back and
> tell my users not to package such jars.
>
> I want to try and make this a bit more robust and get away with having
> to tell users not to package xyz jars. I had a look at the
> ResourceLoaderSpec interface and it takes a PathFilter
> https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org/jboss/modules/ResourceLoaderSpec.java#L48
> which gets me one step closer to what I want to achieve. So if I know
> that static module A, B, C etc... expose classes belonging to package
> foo.bar.blah, I can setup a PathFilter on these jar resource loader to
> skip/decline the path in the accept() method. I think that should work
> out fine (I need to test it out tonight) and I wouldn't have to worry
> that some jar packaged within that component will introduce these
> classes belonging to the foo.bar.blah package.
>
> However, although it might work, I then have to keep a very close vigil
> or rather keep inspecting what packages (or resources in general) the
> modules A, B and C provide. Instead what I'm thinking of is a "smart"
> PathFilter or anything along those lines whose semantics would be to
> "skip/don't accept/filter out all those resources, from a resource root,
> if the resource is provided by any of the specified modules". So
> something like:
>
> ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader,
> *PathFilters.excludeResourcesExposedByModules("A**:slot", "B:slot",
> "C:slot" ...)*);
>
>
> Having looked at the JBoss Modules code, I don't think this is possible
> currently. But that's OK. What I really want to check is, is this
> something that would be feasible to implement (doesn't have to be in
> JBoss Modules itself) and is there any obvious issues with the approach?
> Also, is this something that would be useful to have in JBoss Modules
> itself?

A smart filter is a pretty good idea!  I think that it might make more 
sense as part of a dependency specification though, from a user's 
perspective: if I say "I depend on module org.foo.bar:main" I should 
also be able to say "...and use their packages" which would exclude all 
paths in the source module's resource roots (other than META-INF and the 
root path).

In fact, maybe that ought to be the default setting, with the user 
having to opt in to override packages.  So a user might say:

    <dependencies>
        ...
        <module name="org.foo.bar">
            <override-paths/> <!-- now my paths take precedence -->
        </module>
        ...
    </dependencies>

In the programmatic API it'd be fairly straightforward as well.  We 
could add an overridePaths path filter to the dependency specification 
(which ought to be builder-based at this point, I now realize, what with 
the parameter explosion).  Any dependency paths that are not matched by 
that filter would be subtracted from all resource roots.

As far as XML compatibility goes, the default for 1.5 and earlier can be 
to override all paths, whereas the default for 1.6 and later can be to 
only override META-INF and the root path.

We'd have to have logic to allow for dependency recalculation when a 
module is relinked, but that shouldn't be too hard.

What do you think?
-- 
- DML

From jai.forums2013 at gmail.com  Thu Dec  8 09:41:54 2016
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 8 Dec 2016 20:11:54 +0530
Subject: [wildfly-dev] JBoss Modules - "advanced" PathFilter for
 ResourceLoaderSpec?
In-Reply-To: <1fcb209f-ca43-426f-304b-afe177b68f41@redhat.com>
References: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>
	<1fcb209f-ca43-426f-304b-afe177b68f41@redhat.com>
Message-ID: <6ebc0ed4-a3fa-3c76-9e5e-c8d529b26781@gmail.com>

Hi David,

On Thursday 08 December 2016 07:29 PM, David M. Lloyd wrote:
> Hi Jaikiran!
>
> On 12/08/2016 05:59 AM, Jaikiran Pai wrote:
>> However, although it might work, I then have to keep a very close vigil
>> or rather keep inspecting what packages (or resources in general) the
>> modules A, B and C provide. Instead what I'm thinking of is a "smart"
>> PathFilter or anything along those lines whose semantics would be to
>> "skip/don't accept/filter out all those resources, from a resource root,
>> if the resource is provided by any of the specified modules". So
>> something like:
>>
>> ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader,
>> *PathFilters.excludeResourcesExposedByModules("A**:slot", "B:slot",
>> "C:slot" ...)*);
>>
>>
>> Having looked at the JBoss Modules code, I don't think this is possible
>> currently. But that's OK. What I really want to check is, is this
>> something that would be feasible to implement (doesn't have to be in
>> JBoss Modules itself) and is there any obvious issues with the approach?
>> Also, is this something that would be useful to have in JBoss Modules
>> itself?
> A smart filter is a pretty good idea!  I think that it might make more
> sense as part of a dependency specification though,

Agreed, having it on the dependency spec makes more sense and puts it in 
the right context.


>   from a user's
> perspective: if I say "I depend on module org.foo.bar:main" I should
> also be able to say "...and use their packages" which would exclude all
> paths in the source module's resource roots (other than META-INF and the
> root path).

When you say "would exclude all paths in the source module's resource 
roots...", you mean precedence will be given to the paths of the 
dependency module, right? Not literally exclude all paths of the 
source's resource roots? That way if (one or more) resource roots of the 
source module has a path "hello/world" which isn't part of the 
dependency module's paths, then it will get "accepted" and be available 
to the source module. Did I understand this right or did you intend to 
literally mean excluding all paths of the source module's resource roots?


> In fact, maybe that ought to be the default setting, with the user
> having to opt in to override packages.  So a user might say:
>
>      <dependencies>
>          ...
>          <module name="org.foo.bar">
>              <override-paths/> <!-- now my paths take precedence -->
>          </module>
>          ...
>      </dependencies>

Yes, this looks logical.

> In the programmatic API it'd be fairly straightforward as well.  We
> could add an overridePaths path filter to the dependency specification
> (which ought to be builder-based at this point, I now realize, what with
> the parameter explosion).  Any dependency paths that are not matched by
> that filter would be subtracted from all resource roots.

Yes, this matches with my expectation.


-Jaikiran

From david.lloyd at redhat.com  Thu Dec  8 09:58:56 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 8 Dec 2016 08:58:56 -0600
Subject: [wildfly-dev] JBoss Modules - "advanced" PathFilter for
 ResourceLoaderSpec?
In-Reply-To: <6ebc0ed4-a3fa-3c76-9e5e-c8d529b26781@gmail.com>
References: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>
	<1fcb209f-ca43-426f-304b-afe177b68f41@redhat.com>
	<6ebc0ed4-a3fa-3c76-9e5e-c8d529b26781@gmail.com>
Message-ID: <f4f354b6-947f-23eb-4c42-92c8f4ac30a7@redhat.com>

On 12/08/2016 08:41 AM, Jaikiran Pai wrote:
> Hi David,
>
> On Thursday 08 December 2016 07:29 PM, David M. Lloyd wrote:
>> Hi Jaikiran!
>>
>> On 12/08/2016 05:59 AM, Jaikiran Pai wrote:
>>> However, although it might work, I then have to keep a very close vigil
>>> or rather keep inspecting what packages (or resources in general) the
>>> modules A, B and C provide. Instead what I'm thinking of is a "smart"
>>> PathFilter or anything along those lines whose semantics would be to
>>> "skip/don't accept/filter out all those resources, from a resource root,
>>> if the resource is provided by any of the specified modules". So
>>> something like:
>>>
>>> ResourceLoaderSpec.createResourceLoaderSpec(jarResourceLoader,
>>> *PathFilters.excludeResourcesExposedByModules("A**:slot", "B:slot",
>>> "C:slot" ...)*);
>>>
>>>
>>> Having looked at the JBoss Modules code, I don't think this is possible
>>> currently. But that's OK. What I really want to check is, is this
>>> something that would be feasible to implement (doesn't have to be in
>>> JBoss Modules itself) and is there any obvious issues with the approach?
>>> Also, is this something that would be useful to have in JBoss Modules
>>> itself?
>> A smart filter is a pretty good idea!  I think that it might make more
>> sense as part of a dependency specification though,
>
> Agreed, having it on the dependency spec makes more sense and puts it in
> the right context.
>
>
>>   from a user's
>> perspective: if I say "I depend on module org.foo.bar:main" I should
>> also be able to say "...and use their packages" which would exclude all
>> paths in the source module's resource roots (other than META-INF and the
>> root path).
>
> When you say "would exclude all paths in the source module's resource
> roots...", you mean precedence will be given to the paths of the
> dependency module, right? Not literally exclude all paths of the
> source's resource roots? That way if (one or more) resource roots of the
> source module has a path "hello/world" which isn't part of the
> dependency module's paths, then it will get "accepted" and be available
> to the source module. Did I understand this right or did you intend to
> literally mean excluding all paths of the source module's resource roots?

I mean literally excluding.  Dependency-first (aka "parent-first") 
loading is fundamentally flawed in any non-tree graph.  To boil it down 
to the degenerate case, if I have two modules A and B which have a 
mutual interdependency and a common resource or class, using 
parent-first loading, A gets B's resource, while B gets A's resource, 
which is just plain weird.

Using local-first (aka "child-first") loading (as we do) and excluding 
local resource paths that are found in dependencies, A always gets A's 
resource, and B always gets B's resource.  If you want both, then you 
simply don't override, and A gets A's and then B's, and B gets B's and 
then A's.

Does that make sense?

>> In fact, maybe that ought to be the default setting, with the user
>> having to opt in to override packages.  So a user might say:
>>
>>      <dependencies>
>>          ...
>>          <module name="org.foo.bar">
>>              <override-paths/> <!-- now my paths take precedence -->
>>          </module>
>>          ...
>>      </dependencies>
>
> Yes, this looks logical.
>
>> In the programmatic API it'd be fairly straightforward as well.  We
>> could add an overridePaths path filter to the dependency specification
>> (which ought to be builder-based at this point, I now realize, what with
>> the parameter explosion).  Any dependency paths that are not matched by
>> that filter would be subtracted from all resource roots.
>
> Yes, this matches with my expectation.

Great!  I'll open up a JIRA for this enhancement.
-- 
- DML

From jai.forums2013 at gmail.com  Thu Dec  8 10:22:58 2016
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 8 Dec 2016 20:52:58 +0530
Subject: [wildfly-dev] JBoss Modules - "advanced" PathFilter for
 ResourceLoaderSpec?
In-Reply-To: <f4f354b6-947f-23eb-4c42-92c8f4ac30a7@redhat.com>
References: <9b6edcb1-737a-4fee-9a67-47cb8e5853fb@gmail.com>
	<1fcb209f-ca43-426f-304b-afe177b68f41@redhat.com>
	<6ebc0ed4-a3fa-3c76-9e5e-c8d529b26781@gmail.com>
	<f4f354b6-947f-23eb-4c42-92c8f4ac30a7@redhat.com>
Message-ID: <82a71204-2cd6-acb5-4585-a0cfcdec305f@gmail.com>



On Thursday 08 December 2016 08:28 PM, David M. Lloyd wrote:
> On 12/08/2016 08:41 AM, Jaikiran Pai wrote:
>>
>>>    from a user's
>>> perspective: if I say "I depend on module org.foo.bar:main" I should
>>> also be able to say "...and use their packages" which would exclude all
>>> paths in the source module's resource roots (other than META-INF and the
>>> root path).
>> When you say "would exclude all paths in the source module's resource
>> roots...", you mean precedence will be given to the paths of the
>> dependency module, right? Not literally exclude all paths of the
>> source's resource roots? That way if (one or more) resource roots of the
>> source module has a path "hello/world" which isn't part of the
>> dependency module's paths, then it will get "accepted" and be available
>> to the source module. Did I understand this right or did you intend to
>> literally mean excluding all paths of the source module's resource roots?
> I mean literally excluding.  Dependency-first (aka "parent-first")
> loading is fundamentally flawed in any non-tree graph.  To boil it down
> to the degenerate case, if I have two modules A and B which have a
> mutual interdependency and a common resource or class, using
> parent-first loading, A gets B's resource, while B gets A's resource,
> which is just plain weird.
>
> Using local-first (aka "child-first") loading (as we do) and excluding
> local resource paths that are found in dependencies, A always gets A's
> resource, and B always gets B's resource.  If you want both, then you
> simply don't override, and A gets A's and then B's, and B gets B's and
> then A's.
>
> Does that make sense?

Yes, it does now. Thanks for explaining that part.



> Great!  I'll open up a JIRA for this enhancement.

Thanks, I'll keep a watch and test it out whenever it's available.


-Jaikiran

From rory.odonnell at oracle.com  Fri Dec  9 05:29:37 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 9 Dec 2016 10:29:37 +0000
Subject: [wildfly-dev] JDK 9 b148 including a refresh of the module system
 is available on java.net
Message-ID: <8c3708a9-9de7-9799-323e-d93123e2b8f5@oracle.com>


Hi Jason/Tomaz,


JDK 9 build b148 <https://jdk9.java.net/download/> includes an important 
Refresh of the module system [1] , summary of changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+148.html>.

*This refresh includes a disruptive change that is important to understand.

*For those that have been trying out modules with regular JDK 9 builds 
then be aware that `requires public` changes to `requires transitive`. 
In addition, the binary representation of the module declaration 
(module-info.class) has changed so that you need to recompile any 
modules that were compiled with previous JDK 9 builds.

As things stand today in JDK 9 then you use setAccessible to break into 
non-public elements of any type in exported packages. However, it cannot 
be used to break into any type in non-exported package. The current 
specified behavior was a compromise for the initial integration of the 
module system. It is of course not very satisfactory, hence the 
#AwkwardStrongEncapsulation issue [2] on the JSR 376 issues list. With 
the updated proposal in the JSR, this refresh changes setAccessible 
further so that it cannot be used to break into non-public types, or 
non-public elements of public types, in exported packages. Code that 
uses setAccessible to hack into the private constructor of 
java.lang.invoke.MethodHandles.Lookup will be disappointed for example.

This change will expose hacks in many existing libraries and tools. As a 
workaround then a new command line option `--add-opens` can be used to 
open specific packages for "deep reflection". For example, a really 
popular build tool fails with this refresh because it uses setAccessible 
+ core reflection to hack into a private field of an unmodifiable 
collection so that it can mutate it, facepalm! This code will continue 
to work as before when run with `--add-opens 
java.base/java.util=ALL-UNNAMED` to open the package java.util in module 
java.base to "all unnamed modules" (think class path).

*Any help reporting issues to popular tools and libraries would be 
appreciated. *

A debugging aid that is useful to identify issues is to run with 
-Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when 
setAccessible fails, this is particularly useful when code swallows 
exceptions without any logging.


Rgds,Rory


[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html 
<http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html>
[2] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation

-- 
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/20161209/d6937b59/attachment.html 

From darran.lofthouse at jboss.com  Fri Dec  9 06:27:16 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 9 Dec 2016 11:27:16 +0000
Subject: [wildfly-dev] Time to remove *-elytron.xml Configurations
Message-ID: <a8be17cc-6bcc-9fd5-e3df-ccfee9ab0d1f@jboss.com>

I think it is now time to start removing the *-elytron.xml 
configurations from the feature packs, these were added so we could 
start to get Elytron enabled in isolation.  As more and more is 
integrated it makes less sense to keep the isolation, and if anything it 
is starting to make things harder such as testing.

The default configuration I have planned is for components to be updated 
to reference Elytron and for the Elytron configuration to be closely 
aligned with the existing default configuration, i.e. Digest 
authentication, backed by properties file and local authentication.

We did think if we should enable stronger authentication immediately but 
that will break the existing clients already out there, if we do this in 
stages the clients should have had a chance to be updated to Elytron so 
when we do switch to stronger authentication by default the clients will 
be ready.

So step 1, I will move the Elytron extension and subsystem definition(s) 
into the existing configurations we ship and remove the *-elytron.xml 
definitions.

We will then incrementally update resources that reference security 
services to reference Elytron capabilities.

Regards,
Darran Lofthouse.


From ppalaga at redhat.com  Fri Dec  9 10:28:59 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 9 Dec 2016 16:28:59 +0100
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
Message-ID: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>

Hi *,

as discussed with some of you on Brno F2F, both wildfly and wildfly-core 
are ready for Maven 3.3.1+ now. I am in the process of preparing PRs 
that will:

* Enforce Maven version 3.3.1+
* Introduce mvnw (a.k.a.) Maven Wrapper [1] - a script that
   downloads and installs (if necessary) the required Maven version to
    ~/.m2/wrapper and runs it from there.
* Use of mvnw will be optional
* build.sh/bat in wildfly will be removed
* MAVEN_OPTS will live in .mvn/jvm.config and .mvn/maven.config

A PR for core [2] was sent already.

[1] https://github.com/takari/maven-wrapper#maven-wrapper
[2] https://github.com/wildfly/wildfly-core/pull/2017

Thanks,

Peter

From smarlow at redhat.com  Fri Dec  9 11:34:46 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 9 Dec 2016 11:34:46 -0500
Subject: [wildfly-dev] Time to remove *-elytron.xml Configurations
In-Reply-To: <a8be17cc-6bcc-9fd5-e3df-ccfee9ab0d1f@jboss.com>
References: <a8be17cc-6bcc-9fd5-e3df-ccfee9ab0d1f@jboss.com>
Message-ID: <CAJtdNN4=uc+41UfBYF5q-upOBm759yof7CTTbDweA1T2wyB0Ng@mail.gmail.com>

After we have completely switched to Elytron, will there be
*-legacy.xml files for switching back to Picketbox?

On Fri, Dec 9, 2016 at 6:27 AM, Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> I think it is now time to start removing the *-elytron.xml
> configurations from the feature packs, these were added so we could
> start to get Elytron enabled in isolation.  As more and more is
> integrated it makes less sense to keep the isolation, and if anything it
> is starting to make things harder such as testing.
>
> The default configuration I have planned is for components to be updated
> to reference Elytron and for the Elytron configuration to be closely
> aligned with the existing default configuration, i.e. Digest
> authentication, backed by properties file and local authentication.
>
> We did think if we should enable stronger authentication immediately but
> that will break the existing clients already out there, if we do this in
> stages the clients should have had a chance to be updated to Elytron so
> when we do switch to stronger authentication by default the clients will
> be ready.
>
> So step 1, I will move the Elytron extension and subsystem definition(s)
> into the existing configurations we ship and remove the *-elytron.xml
> definitions.
>
> We will then incrementally update resources that reference security
> services to reference Elytron capabilities.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From darran.lofthouse at jboss.com  Sun Dec 11 10:00:09 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Sun, 11 Dec 2016 15:00:09 +0000
Subject: [wildfly-dev] Time to remove *-elytron.xml Configurations
In-Reply-To: <CAJtdNN4=uc+41UfBYF5q-upOBm759yof7CTTbDweA1T2wyB0Ng@mail.gmail.com>
References: <a8be17cc-6bcc-9fd5-e3df-ccfee9ab0d1f@jboss.com>
	<CAJtdNN4=uc+41UfBYF5q-upOBm759yof7CTTbDweA1T2wyB0Ng@mail.gmail.com>
Message-ID: <0e92bf6e-2c65-1ae7-b0ab-f47d160a49aa@jboss.com>

On 09/12/16 16:34, Scott Marlow wrote:
> After we have completely switched to Elytron, will there be
> *-legacy.xml files for switching back to Picketbox?

I do not expect so.

For anyone who identifies a need to use the PicketBox based security I 
think our best option is to provide the management ops to add it back. 
For anyone else already using PicketBox I would expect them to bring 
their old configuration to WildFly 11 and so will be unaffected by this 
discussion.

> On Fri, Dec 9, 2016 at 6:27 AM, Darran Lofthouse
> <darran.lofthouse at jboss.com> wrote:
>> I think it is now time to start removing the *-elytron.xml
>> configurations from the feature packs, these were added so we could
>> start to get Elytron enabled in isolation.  As more and more is
>> integrated it makes less sense to keep the isolation, and if anything it
>> is starting to make things harder such as testing.
>>
>> The default configuration I have planned is for components to be updated
>> to reference Elytron and for the Elytron configuration to be closely
>> aligned with the existing default configuration, i.e. Digest
>> authentication, backed by properties file and local authentication.
>>
>> We did think if we should enable stronger authentication immediately but
>> that will break the existing clients already out there, if we do this in
>> stages the clients should have had a chance to be updated to Elytron so
>> when we do switch to stronger authentication by default the clients will
>> be ready.
>>
>> So step 1, I will move the Elytron extension and subsystem definition(s)
>> into the existing configurations we ship and remove the *-elytron.xml
>> definitions.
>>
>> We will then incrementally update resources that reference security
>> services to reference Elytron capabilities.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From tom.jenkinson at redhat.com  Mon Dec 12 13:00:51 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Mon, 12 Dec 2016 18:00:51 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
Message-ID: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>

Hi,

I have a subsystem that configures itself from system properties.

For example:
<system-properties>
  <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>

In earlier revisions of WFLY this worked fine. However I am now seeing that
the system property is not set until after my subsystem has started. I can
tell this as I have breakpoints on where I process the property. I can see
"MSC service thread 1-4" attempting to process the property (which is not
set). I do later see messages that suggest the system property is set but
at that the later point:

2016-12-12 17:57:48,042 TRACE
[org.jboss.as.controller.management-operation] (Controller Boot Thread)
Final response for step handler
org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling
add in address [("system-property" =>
"RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
"success"}
2016-12-12 17:57:48,093 TRACE
[org.jboss.as.controller.management-operation] (Controller Boot Thread)
Final response for step handler
org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
internal-model-validation in address [("system-property" =>
"RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
"success"}

Does my subsystem need to depend on something to get the old behaviour of
being started after system properties are processed?

My subsystem is the transaction one and the service is the recovery manager.

Thanks!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161212/165e1385/attachment-0001.html 

From kabir.khan at jboss.com  Mon Dec 12 13:10:29 2016
From: kabir.khan at jboss.com (Kabir Khan)
Date: Mon, 12 Dec 2016 18:10:29 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
Message-ID: <EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>

Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> 
> Hi,
> 
> I have a subsystem that configures itself from system properties.
> 
> For example:
> <system-properties>
>   <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> 
> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
> 
> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 
> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
> 
> My subsystem is the transaction one and the service is the recovery manager.
> 
> Thanks!
> Tom
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From gtrikler at redhat.com  Mon Dec 12 14:25:01 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Mon, 12 Dec 2016 20:25:01 +0100
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
Message-ID: <9eafe20c-3281-7071-4578-9a76ae325048@redhat.com>

Flavia,

it seems that it might be better for EJB subsystem to keep track of its 
own transaction. The reason being that all transactions are kept in the 
same map no matter what created them (EJB, CDI, or UserTransaction).

We could expose an API to get that map (or just a number of transactions 
in it) as well as a way to register callback. However, that will also 
include transactions created by other ways mentioned above.

Gytis


On 05/12/2016 20:34, Flavia Rainone wrote:
> I think we can keep open transaction tracking only inside transactions 
> subsystem while we are not shutting down, and then we can enroll for 
> notification of open active transactions only on suspend if needed... 
> IMHO that's as clean as we can get regarding shutdown code when the 
> server is in running state.
>
> I would go with some sort of ActiveTransactionListener, that would be 
> notified of no more active transactions only if the listener is set?
>
> Something along the lines below at ejb side:
>
> ServerActivityCallback callback = null;
>
> public void suspend(ServerActivityCallback callback) {
>     if ( transactionSubsystem.getActiveTransactions() > 0) {
>        transactionSubsystem.setActiveTransactionsListener(this);
>     }
>     else {
>       callback.done(); // done suspending
>    }
> }
>
> // listener method
> public void noMoreActiveTransactions() {
>     callback.done(); // done suspending
>     // then we let control point notify clients that this node is no 
> longer available
>     ...
> }
>
> At transactions side:
> ActiveTransactionListener listener = null;
>
> private void incrementTxnCount() {
>     ...
> }
>
> private void decrementTxnCount() {
>    if (txnCountUpdater.decrementAndGet() == 0 && listener != null)
>        listener.noMoreActiveTransactions();
> }
>
> public int getActiveTransactions() {
>    return txnCountUpdater.get();
> }
>
>
>
>
>
>
>
> On 04-12-2016 20:39, Stuart Douglas wrote:
>> On Sat, Dec 3, 2016 at 3:40 AM, Flavia Rainone<frainone at redhat.com>  wrote:
>>> Hi,
>>>
>>> I'm creating this thread to discuss the remaining details of graceful
>>> shutdown for ejb transactions.
>>>
>>> This is more or less what I've done so far:
>>>
>>> https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a5fb18760
>>>
>>> While discussing this in the hip chat yesterday, Stuart mentioned that maybe
>>> we could have the transactions subsystem responsible for keeping track of
>>> how many active transactions we have, instead of putting that code in
>>> EjbRemoteTransactionsRepository.
>>>
>>> Stuart, does that include having the suspend callback being done at
>>> transactions subsystem as well? I'm thinking maybe not, because there are
>>> two points in the ejb subsystem we need to know if transactions suspension
>>> is over:
>>>
>> No, that still has to be handled at an EJB subsystem level.
>> Conceptually this is similar to what was done for the XTS subsytem, so
>> it should probably use a similar design. Ideally while the server is
>> in the running state the only graceful related code that is run is the
>> control point request tracking, however this may not be possible.
>>
>> One other thing that came up on our hipchat discussion yesterday is TX
>> level graceful shutdown actually has some significant drawbacks, as
>> you cannot send out the module unavailability message until all the
>> transactions have been closed. This means that while we are waiting
>> for transactions to complete the node will still be part of a cluster,
>> and clients will send it requests that will be immediately rejected.
>>
>> Stuart
>>
>>> - at EjbSuspendInterceptor if it is over, no request is allowed, if it is
>>> not over, we need to check if current invocation contains a reference to an
>>> active transaction
>>>
>>> - at some point, we need to let control point notify that the ejb module is
>>> not longer available to ejb client after transaction suspension is over,
>>> i.e., we need to do that when suspend has been requested and there are no
>>> remaining active transactions available.
>>>
>>> On the other hand, it is hard to draw the line between what should be in the
>>> transactions subsystem and what shouldn't. If the callback is done at
>>> transactions subsystem, we need a way of having ejb3 notified that it is
>>> done. If it is not done at transactions subsystem, ejb3 has to be notified
>>> of the active transactions going to zero, which seems a lot of overhead, so
>>> from this point of view maybe the callback should be in the transactions
>>> system after all.
>>>
>>> Stuart and Gytis, any thoughts?
>>>
>>>
>>> --
>>> Flavia Rainone
>>> Principal Software Engineer
>>> JBoss EAP/WildFly Team
>>> M: (+55) 11 981-225-466
>>>
>>> Red Hat.
>>> Better technology.
>>> Faster innovation.
>>> Powered by community collaboration.
>
> -- 
> Flavia Rainone
> Principal Software Engineer
> JBoss EAP/WildFly Team
> M: (+55) 11 981-225-466
>
> Red Hat.
> Better technology.
> Faster innovation.
> Powered by community collaboration.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161212/0ac3f602/attachment.html 

From brian.stansberry at redhat.com  Mon Dec 12 14:55:58 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 12 Dec 2016 13:55:58 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
Message-ID: <3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>

I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.

> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> 
> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
>> 
>> Hi,
>> 
>> I have a subsystem that configures itself from system properties.
>> 
>> For example:
>> <system-properties>
>>  <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>> </system-properties>
>> 
>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
>> 
>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>> 
>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
>> 
>> My subsystem is the transaction one and the service is the recovery manager.
>> 
>> Thanks!
>> Tom
>> _______________________________________________
>> 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 brian.stansberry at redhat.com  Mon Dec 12 15:15:59 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 12 Dec 2016 14:15:59 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
Message-ID: <3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>

This works fine for me. Adding that xml snippet to standalone.xml after the <extensions> element I see the property being set during boot before any processing of subsystem operations begins.

> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.
> 
>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>> 
>> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I have a subsystem that configures itself from system properties.
>>> 
>>> For example:
>>> <system-properties>
>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>>> </system-properties>
>>> 
>>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
>>> 
>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>>> 
>>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
>>> 
>>> My subsystem is the transaction one and the service is the recovery manager.
>>> 
>>> Thanks!
>>> Tom
>>> _______________________________________________
>>> 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
> 
> 
> 
> 
> _______________________________________________
> 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 tom.jenkinson at redhat.com  Mon Dec 12 15:50:17 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Mon, 12 Dec 2016 20:50:17 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
Message-ID: <CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>

Thanks for the input/

This is the point I do not think the property has been set by:

"MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at
com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
 - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean)
 at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
 at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:170)
 at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
 at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
 at
com.arjuna.ats.arjuna.common.recoveryPropertyManager.getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
 at
org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:96)
 - locked <0x1bd2> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService)
 at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
 at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)

(that is output from the debugger)

Once releasing that thread and letting the container continue startup I see
this execute:
2016-12-12 20:46:49,731 TRACE
[org.jboss.as.controller.management-operation] (Controller Boot Thread)
Final response for step handler
org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling
add in address [("system-property" =>
"RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
"success"}
2016-12-12 20:46:49,787 TRACE
[org.jboss.as.controller.management-operation] (Controller Boot Thread)
Final response for step handler
org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
internal-model-validation in address [("system-property" =>
"RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
"success"}

I believe this is different to previous behaviour as I have had a defect
raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's
possible that there is a regression in Narayana (somehow) if nothing
changed in this area in the core itself.

Thanks for your input,
Tom




On 12 December 2016 at 20:15, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> This works fine for me. Adding that xml snippet to standalone.xml after
> the <extensions> element I see the property being set during boot before
> any processing of subsystem operations begins.
>
> > On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > I don?t see anything in the organization of boot ops that would have
> changed the ordering, and the add op for that system property should be
> executing prior to the subsystem ops. I?ll see if I can reproduce.
> >
> >> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >>
> >> Where are you trying to use the system property from? They should only
> be attempted resolved during the RUNTIME stage, not MODEL.
> >>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have a subsystem that configures itself from system properties.
> >>>
> >>> For example:
> >>> <system-properties>
> >>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
> value="com.arjuna.ats.internal.arjuna.recovery.
> ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.
> arjuna.recovery.AtomicActionExpiryScanner"/>
> >>> </system-properties>
> >>>
> >>> In earlier revisions of WFLY this worked fine. However I am now seeing
> that the system property is not set until after my subsystem has started. I
> can tell this as I have breakpoints on where I process the property. I can
> see "MSC service thread 1-4" attempting to process the property (which is
> not set). I do later see messages that suggest the system property is set
> but at that the later point:
> >>>
> >>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> >>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> >>>
> >>> Does my subsystem need to depend on something to get the old behaviour
> of being started after system properties are processed?
> >>>
> >>> My subsystem is the transaction one and the service is the recovery
> manager.
> >>>
> >>> Thanks!
> >>> Tom
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161212/0e7f0f2a/attachment-0001.html 

From tomaz.cerar at gmail.com  Mon Dec 12 16:03:02 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 12 Dec 2016 22:03:02 +0100
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
Message-ID: <CAMquZP6te+Spf_mmdQE0Fw-J95rOQRi1zKAbKdXXUQfoeAyPQQ@mail.gmail.com>

You are adding and starting this service in performBoottime which is
causing you this issues.
As you service can get started before stage MODEL can complete

I would change initial state of the service to ON_DEMAND instead of active.
https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemAdd.java#L432

which should solve your problem. I would do the same also for
JTAEnvironmentBeanService.

so they get started only when needed not up front without any requirement.

--
tomaz

On Mon, Dec 12, 2016 at 9:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> Thanks for the input/
>
> This is the point I do not think the property has been set by:
>
> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.
> getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
>  - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.
> RecoveryEnvironmentBean)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(
> NativeMethodAccessorImpl.java:-1)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.
> handleGroupProperty(BeanPopulator.java:263)
>  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.
> configureFromProperties(BeanPopulator.java:170)
>  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.
> getNamedInstance(BeanPopulator.java:87)
>  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.
> getDefaultInstance(BeanPopulator.java:53)
>  at com.arjuna.ats.arjuna.common.recoveryPropertyManager.
> getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(
> ArjunaRecoveryManagerService.java:96)
>  - locked <0x1bd2> (a org.jboss.as.txn.service.
> ArjunaRecoveryManagerService)
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(
> ServiceControllerImpl.java:1963)
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> ServiceControllerImpl.java:1896)
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
>  at java.lang.Thread.run(Thread.java:745)
>
> (that is output from the debugger)
>
> Once releasing that thread and letting the container continue startup I
> see this execute:
> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
>
> I believe this is different to previous behaviour as I have had a defect
> raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's
> possible that there is a regression in Narayana (somehow) if nothing
> changed in this area in the core itself.
>
> Thanks for your input,
> Tom
>
>
>
>
> On 12 December 2016 at 20:15, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> This works fine for me. Adding that xml snippet to standalone.xml after
>> the <extensions> element I see the property being set during boot before
>> any processing of subsystem operations begins.
>>
>> > On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >
>> > I don?t see anything in the organization of boot ops that would have
>> changed the ordering, and the add op for that system property should be
>> executing prior to the subsystem ops. I?ll see if I can reproduce.
>> >
>> >> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>> >>
>> >> Where are you trying to use the system property from? They should only
>> be attempted resolved during the RUNTIME stage, not MODEL.
>> >>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I have a subsystem that configures itself from system properties.
>> >>>
>> >>> For example:
>> >>> <system-properties>
>> >>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
>> value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
>> com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>> >>> </system-properties>
>> >>>
>> >>> In earlier revisions of WFLY this worked fine. However I am now
>> seeing that the system property is not set until after my subsystem has
>> started. I can tell this as I have breakpoints on where I process the
>> property. I can see "MSC service thread 1-4" attempting to process the
>> property (which is not set). I do later see messages that suggest the
>> system property is set but at that the later point:
>> >>>
>> >>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f
>> handling add in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
>> internal-model-validation in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>>
>> >>> Does my subsystem need to depend on something to get the old
>> behaviour of being started after system properties are processed?
>> >>>
>> >>> My subsystem is the transaction one and the service is the recovery
>> manager.
>> >>>
>> >>> Thanks!
>> >>> Tom
>> >>> _______________________________________________
>> >>> 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
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> 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/20161212/a5a85557/attachment.html 

From brian.stansberry at redhat.com  Mon Dec 12 16:19:35 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 12 Dec 2016 15:19:35 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CAMquZP6te+Spf_mmdQE0Fw-J95rOQRi1zKAbKdXXUQfoeAyPQQ@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<CAMquZP6te+Spf_mmdQE0Fw-J95rOQRi1zKAbKdXXUQfoeAyPQQ@mail.gmail.com>
Message-ID: <BF08201D-90EF-4444-AB0C-EB76186FDDE8@redhat.com>


> On Dec 12, 2016, at 3:03 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> You are adding and starting this service in performBoottime which is causing you this issues.
> As you service can get started before stage MODEL can complete

performBoottime executes in Stage.RUNTIME, so it?s after MODEL.

It?s just the equivalent to performRuntime for add handlers that can only do runtime stuff during boot.

> 
> I would change initial state of the service to ON_DEMAND instead of active.
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemAdd.java#L432
> 
> which should solve your problem. I would do the same also for JTAEnvironmentBeanService.
> 
> so they get started only when needed not up front without any requirement.
> 
> --
> tomaz
> 
> On Mon, Dec 12, 2016 at 9:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> Thanks for the input/
> 
> This is the point I do not think the property has been set by:
> 
> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
> 	  at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> 	  - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:498)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> 	  at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> 	  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:96)
> 	  - locked <0x1bd2> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService)
> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 	  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	  at java.lang.Thread.run(Thread.java:745)
> 
> (that is output from the debugger)
> 
> Once releasing that thread and letting the container continue startup I see this execute:
> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 
> I believe this is different to previous behaviour as I have had a defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's possible that there is a regression in Narayana (somehow) if nothing changed in this area in the core itself.
> 
> Thanks for your input,
> Tom
> 
> 
> 
> 
> On 12 December 2016 at 20:15, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> This works fine for me. Adding that xml snippet to standalone.xml after the <extensions> element I see the property being set during boot before any processing of subsystem operations begins.
> 
> > On Dec 12, 2016, at 1:55 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> >
> > I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.
> >
> >> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >>
> >> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
> >>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have a subsystem that configures itself from system properties.
> >>>
> >>> For example:
> >>> <system-properties>
> >>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> >>> </system-properties>
> >>>
> >>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
> >>>
> >>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>>
> >>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
> >>>
> >>> My subsystem is the transaction one and the service is the recovery manager.
> >>>
> >>> Thanks!
> >>> Tom
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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 Dec 12 16:21:26 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 12 Dec 2016 15:21:26 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
Message-ID: <A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>

This is the problem: the TransactionExtension initialize method of touching classes that result in doing static initialization stuff that reads the system props at that point, which is too early:

"ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
	  at com.arjuna.common.util.propertyservice.PropertiesFactory.initPropertiesFactory(PropertiesFactory.java:53)
	  - locked <0x1389> (a java.lang.Class)
	  at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:36)
	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:86)
	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
	  at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
	  at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.<init>(TransactionSubsystemRootResourceDefinition.java:518)
	  at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition.registerAttributes(TransactionSubsystemRootResourceDefinition.java:314)
	  at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:104)
	  at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225)
	  at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
	  at org.jboss.as.txn.subsystem.TransactionExtension.initialize(TransactionExtension.java:104)
	  at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
	  at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
	  at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
	  at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
	  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	  at java.lang.Thread.run(Thread.java:745)
	  at org.jboss.threads.JBossThread.run(JBossThread.java:320)


> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> 
> Thanks for the input/
> 
> This is the point I do not think the property has been set by:
> 
> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
> 	  at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> 	  - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:498)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> 	  at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> 	  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:96)
> 	  - locked <0x1bd2> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService)
> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 	  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	  at java.lang.Thread.run(Thread.java:745)
> 
> (that is output from the debugger)
> 
> Once releasing that thread and letting the container continue startup I see this execute:
> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> 
> I believe this is different to previous behaviour as I have had a defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's possible that there is a regression in Narayana (somehow) if nothing changed in this area in the core itself.
> 
> Thanks for your input,
> Tom
> 
> 
> 
> 
> On 12 December 2016 at 20:15, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> This works fine for me. Adding that xml snippet to standalone.xml after the <extensions> element I see the property being set during boot before any processing of subsystem operations begins.
> 
> > On Dec 12, 2016, at 1:55 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> >
> > I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.
> >
> >> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >>
> >> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
> >>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have a subsystem that configures itself from system properties.
> >>>
> >>> For example:
> >>> <system-properties>
> >>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> >>> </system-properties>
> >>>
> >>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
> >>>
> >>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>>
> >>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
> >>>
> >>> My subsystem is the transaction one and the service is the recovery manager.
> >>>
> >>> Thanks!
> >>> Tom
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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 brian.stansberry at redhat.com  Mon Dec 12 16:33:07 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 12 Dec 2016 15:33:07 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
Message-ID: <99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>


> On Dec 12, 2016, at 3:21 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> This is the problem: the TransactionExtension initialize method of touching classes that result in doing static initialization stuff that reads the system props at that point, which is too early:
> 

s/of touching/is touching/g

A likely fix is to just not store a ref to coordinatorEnvironmentBean in TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just find it and use it in applyUpdateToRuntime/revertUpdateToRuntime neither of which will get called before system properties are set. They don?t get called at all if the user doesn?t do a write-attribute op to change that attribute.

> "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
>  java.lang.Thread.State: RUNNABLE
> 	  at com.arjuna.common.util.propertyservice.PropertiesFactory.initPropertiesFactory(PropertiesFactory.java:53)
> 	  - locked <0x1389> (a java.lang.Class)
> 	  at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:36)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:86)
> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> 	  at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
> 	  at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.<init>(TransactionSubsystemRootResourceDefinition.java:518)
> 	  at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition.registerAttributes(TransactionSubsystemRootResourceDefinition.java:314)
> 	  at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:104)
> 	  at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225)
> 	  at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
> 	  at org.jboss.as.txn.subsystem.TransactionExtension.initialize(TransactionExtension.java:104)
> 	  at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> 	  at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
> 	  at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
> 	  at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
> 	  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	  at java.lang.Thread.run(Thread.java:745)
> 	  at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 
> 
>> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
>> 
>> Thanks for the input/
>> 
>> This is the point I do not think the property has been set by:
>> 
>> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>>  java.lang.Thread.State: RUNNABLE
>> 	  at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
>> 	  - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean)
>> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
>> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	  at java.lang.reflect.Method.invoke(Method.java:498)
>> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
>> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:170)
>> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
>> 	  at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
>> 	  at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
>> 	  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:96)
>> 	  - locked <0x1bd2> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService)
>> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
>> 	  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
>> 	  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	  at java.lang.Thread.run(Thread.java:745)
>> 
>> (that is output from the debugger)
>> 
>> Once releasing that thread and letting the container continue startup I see this execute:
>> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>> 
>> I believe this is different to previous behaviour as I have had a defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's possible that there is a regression in Narayana (somehow) if nothing changed in this area in the core itself.
>> 
>> Thanks for your input,
>> Tom
>> 
>> 
>> 
>> 
>> On 12 December 2016 at 20:15, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> This works fine for me. Adding that xml snippet to standalone.xml after the <extensions> element I see the property being set during boot before any processing of subsystem operations begins.
>> 
>>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> 
>>> I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.
>>> 
>>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>> 
>>>> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
>>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I have a subsystem that configures itself from system properties.
>>>>> 
>>>>> For example:
>>>>> <system-properties>
>>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>>>>> </system-properties>
>>>>> 
>>>>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
>>>>> 
>>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
>>>>> 
>>>>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
>>>>> 
>>>>> My subsystem is the transaction one and the service is the recovery manager.
>>>>> 
>>>>> Thanks!
>>>>> Tom
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> 
> 
> _______________________________________________
> 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 tom.jenkinson at redhat.com  Tue Dec 13 05:54:29 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 13 Dec 2016 10:54:29 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
	<99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>
Message-ID: <CALaezvWDSNOjL0GbhF1RqN3_ipZATL9q-o1BkfgjrV3WBh8OBg@mail.gmail.com>

Thanks, I will take a look. Did this change recently? If not I am at a loss
why it is starting to fail an existing test.

On 12 December 2016 at 21:33, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

>
> > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > This is the problem: the TransactionExtension initialize method of
> touching classes that result in doing static initialization stuff that
> reads the system props at that point, which is too early:
> >
>
> s/of touching/is touching/g
>
> A likely fix is to just not store a ref to coordinatorEnvironmentBean in
> TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just
> find it and use it in applyUpdateToRuntime/revertUpdateToRuntime neither
> of which will get called before system properties are set. They don?t get
> called at all if the user doesn?t do a write-attribute op to change that
> attribute.
>
> > "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
> >  java.lang.Thread.State: RUNNABLE
> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.
> initPropertiesFactory(PropertiesFactory.java:53)
> >         - locked <0x1389> (a java.lang.Class)
> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.
> getDefaultProperties(PropertiesFactory.java:36)
> >         at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getNamedInstance(BeanPopulator.java:86)
> >         at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> >         at com.arjuna.ats.arjuna.common.arjPropertyManager.
> getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResour
> ceDefinition$StatisticsEnabledHandler.<init>(
> TransactionSubsystemRootResourceDefinition.java:518)
> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResour
> ceDefinition.registerAttributes(TransactionSubsystemRootResour
> ceDefinition.java:314)
> >         at org.jboss.as.controller.registry.NodeSubregistry.
> registerChild(NodeSubregistry.java:104)
> >         at org.jboss.as.controller.registry.
> ConcreteResourceRegistration.registerSubModel(
> ConcreteResourceRegistration.java:225)
> >         at org.jboss.as.controller.extension.ExtensionRegistry$
> SubsystemRegistrationImpl.registerSubsystemModel(
> ExtensionRegistry.java:706)
> >         at org.jboss.as.txn.subsystem.TransactionExtension.initialize(
> TransactionExtension.java:104)
> >         at org.jboss.as.controller.extension.ExtensionAddHandler.
> initializeExtension(ExtensionAddHandler.java:131)
> >         at org.jboss.as.controller.extension.ExtensionAddHandler.
> initializeExtension(ExtensionAddHandler.java:104)
> >         at org.jboss.as.controller.extension.
> ParallelExtensionAddHandler$ExtensionInitializeTask.call(
> ParallelExtensionAddHandler.java:144)
> >         at org.jboss.as.controller.extension.
> ParallelExtensionAddHandler$ExtensionInitializeTask.call(
> ParallelExtensionAddHandler.java:127)
> >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >         at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> >         at java.lang.Thread.run(Thread.java:745)
> >         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> >
> >
> >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> >>
> >> Thanks for the input/
> >>
> >> This is the point I do not think the property has been set by:
> >>
> >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
> >>  java.lang.Thread.State: RUNNABLE
> >>        at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.
> getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> >>        - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.
> RecoveryEnvironmentBean)
> >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(
> NativeMethodAccessorImpl.java:-1)
> >>        at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> >>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> >>        at java.lang.reflect.Method.invoke(Method.java:498)
> >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> >>        at com.arjuna.ats.arjuna.common.recoveryPropertyManager.
> getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> >>        at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(
> ArjunaRecoveryManagerService.java:96)
> >>        - locked <0x1bd2> (a org.jboss.as.txn.service.
> ArjunaRecoveryManagerService)
> >>        at org.jboss.msc.service.ServiceControllerImpl$
> StartTask.startService(ServiceControllerImpl.java:1963)
> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> ServiceControllerImpl.java:1896)
> >>        at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> >>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> >>        at java.lang.Thread.run(Thread.java:745)
> >>
> >> (that is output from the debugger)
> >>
> >> Once releasing that thread and letting the container continue startup I
> see this execute:
> >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> >>
> >> I believe this is different to previous behaviour as I have had a
> defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820.
> It's possible that there is a regression in Narayana (somehow) if nothing
> changed in this area in the core itself.
> >>
> >> Thanks for your input,
> >> Tom
> >>
> >>
> >>
> >>
> >> On 12 December 2016 at 20:15, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >> This works fine for me. Adding that xml snippet to standalone.xml after
> the <extensions> element I see the property being set during boot before
> any processing of subsystem operations begins.
> >>
> >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>>
> >>> I don?t see anything in the organization of boot ops that would have
> changed the ordering, and the add op for that system property should be
> executing prior to the subsystem ops. I?ll see if I can reproduce.
> >>>
> >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com>
> wrote:
> >>>>
> >>>> Where are you trying to use the system property from? They should
> only be attempted resolved during the RUNTIME stage, not MODEL.
> >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have a subsystem that configures itself from system properties.
> >>>>>
> >>>>> For example:
> >>>>> <system-properties>
> >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
> value="com.arjuna.ats.internal.arjuna.recovery.
> ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.
> arjuna.recovery.AtomicActionExpiryScanner"/>
> >>>>> </system-properties>
> >>>>>
> >>>>> In earlier revisions of WFLY this worked fine. However I am now
> seeing that the system property is not set until after my subsystem has
> started. I can tell this as I have breakpoints on where I process the
> property. I can see "MSC service thread 1-4" attempting to process the
> property (which is not set). I do later see messages that suggest the
> system property is set but at that the later point:
> >>>>>
> >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> >>>>>
> >>>>> Does my subsystem need to depend on something to get the old
> behaviour of being started after system properties are processed?
> >>>>>
> >>>>> My subsystem is the transaction one and the service is the recovery
> manager.
> >>>>>
> >>>>> Thanks!
> >>>>> Tom
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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/20161213/ecb4ecac/attachment-0001.html 

From tom.jenkinson at redhat.com  Tue Dec 13 06:55:59 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 13 Dec 2016 11:55:59 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CALaezvWDSNOjL0GbhF1RqN3_ipZATL9q-o1BkfgjrV3WBh8OBg@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
	<99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>
	<CALaezvWDSNOjL0GbhF1RqN3_ipZATL9q-o1BkfgjrV3WBh8OBg@mail.gmail.com>
Message-ID: <CALaezvXysNd06eQ=cf5GL3UxGdnbzg6JaHBy8oHAPHPTSZV9ZA@mail.gmail.com>

Yeah, moving the lookup to the area you mentioned worked - thanks again!

On 13 December 2016 at 10:54, Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> Thanks, I will take a look. Did this change recently? If not I am at a
> loss why it is starting to fail an existing test.
>
> On 12 December 2016 at 21:33, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>> > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >
>> > This is the problem: the TransactionExtension initialize method of
>> touching classes that result in doing static initialization stuff that
>> reads the system props at that point, which is too early:
>> >
>>
>> s/of touching/is touching/g
>>
>> A likely fix is to just not store a ref to coordinatorEnvironmentBean in
>> TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.
>> Just find it and use it in applyUpdateToRuntime/revertUpdateToRuntime
>> neither of which will get called before system properties are set. They
>> don?t get called at all if the user doesn?t do a write-attribute op to
>> change that attribute.
>>
>> > "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
>> >  java.lang.Thread.State: RUNNABLE
>> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.ini
>> tPropertiesFactory(PropertiesFactory.java:53)
>> >         - locked <0x1389> (a java.lang.Class)
>> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.get
>> DefaultProperties(PropertiesFactory.java:36)
>> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getNamedInstance(BeanPopulator.java:86)
>> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getDefaultInstance(BeanPopulator.java:53)
>> >         at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinat
>> orEnvironmentBean(arjPropertyManager.java:51)
>> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceD
>> efinition$StatisticsEnabledHandler.<init>(TransactionSubsyst
>> emRootResourceDefinition.java:518)
>> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceD
>> efinition.registerAttributes(TransactionSubsystemRootResourc
>> eDefinition.java:314)
>> >         at org.jboss.as.controller.registry.NodeSubregistry.registerChi
>> ld(NodeSubregistry.java:104)
>> >         at org.jboss.as.controller.registry.ConcreteResourceRegistratio
>> n.registerSubModel(ConcreteResourceRegistration.java:225)
>> >         at org.jboss.as.controller.extension.ExtensionRegistry$Subsyste
>> mRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
>> >         at org.jboss.as.txn.subsystem.TransactionExtension.initialize(T
>> ransactionExtension.java:104)
>> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initia
>> lizeExtension(ExtensionAddHandler.java:131)
>> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initia
>> lizeExtension(ExtensionAddHandler.java:104)
>> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandle
>> r$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
>> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandle
>> r$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
>> >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> >         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> >         at java.lang.Thread.run(Thread.java:745)
>> >         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>> >
>> >
>> >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>> >>
>> >> Thanks for the input/
>> >>
>> >> This is the point I do not think the property has been set by:
>> >>
>> >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
>> >>  java.lang.Thread.State: RUNNABLE
>> >>        at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpi
>> ryScannerClassNames(RecoveryEnvironmentBean.java:336)
>> >>        - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.R
>> ecoveryEnvironmentBean)
>> >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAcc
>> essorImpl.java:-1)
>> >>        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> >>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> >>        at java.lang.reflect.Method.invoke(Method.java:498)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.handleGroupProperty(BeanPopulator.java:263)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.configureFromProperties(BeanPopulator.java:170)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getNamedInstance(BeanPopulator.java:87)
>> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulato
>> r.getDefaultInstance(BeanPopulator.java:53)
>> >>        at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getReco
>> veryEnvironmentBean(recoveryPropertyManager.java:34)
>> >>        at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(
>> ArjunaRecoveryManagerService.java:96)
>> >>        - locked <0x1bd2> (a org.jboss.as.txn.service.Arjun
>> aRecoveryManagerService)
>> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.
>> startService(ServiceControllerImpl.java:1963)
>> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(Se
>> rviceControllerImpl.java:1896)
>> >>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)
>> >>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.java:617)
>> >>        at java.lang.Thread.run(Thread.java:745)
>> >>
>> >> (that is output from the debugger)
>> >>
>> >> Once releasing that thread and letting the container continue startup
>> I see this execute:
>> >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735
>> handling add in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
>> internal-model-validation in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>
>> >> I believe this is different to previous behaviour as I have had a
>> defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820.
>> It's possible that there is a regression in Narayana (somehow) if nothing
>> changed in this area in the core itself.
>> >>
>> >> Thanks for your input,
>> >> Tom
>> >>
>> >>
>> >>
>> >>
>> >> On 12 December 2016 at 20:15, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >> This works fine for me. Adding that xml snippet to standalone.xml
>> after the <extensions> element I see the property being set during boot
>> before any processing of subsystem operations begins.
>> >>
>> >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>> >>>
>> >>> I don?t see anything in the organization of boot ops that would have
>> changed the ordering, and the add op for that system property should be
>> executing prior to the subsystem ops. I?ll see if I can reproduce.
>> >>>
>> >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com>
>> wrote:
>> >>>>
>> >>>> Where are you trying to use the system property from? They should
>> only be attempted resolved during the RUNTIME stage, not MODEL.
>> >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I have a subsystem that configures itself from system properties.
>> >>>>>
>> >>>>> For example:
>> >>>>> <system-properties>
>> >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
>> value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
>> com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
>> >>>>> </system-properties>
>> >>>>>
>> >>>>> In earlier revisions of WFLY this worked fine. However I am now
>> seeing that the system property is not set until after my subsystem has
>> started. I can tell this as I have breakpoints on where I process the
>> property. I can see "MSC service thread 1-4" attempting to process the
>> property (which is not set). I do later see messages that suggest the
>> system property is set but at that the later point:
>> >>>>>
>> >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f
>> handling add in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
>> (Controller Boot Thread) Final response for step handler
>> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
>> internal-model-validation in address [("system-property" =>
>> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
>> "success"}
>> >>>>>
>> >>>>> Does my subsystem need to depend on something to get the old
>> behaviour of being started after system properties are processed?
>> >>>>>
>> >>>>> My subsystem is the transaction one and the service is the recovery
>> manager.
>> >>>>>
>> >>>>> Thanks!
>> >>>>> Tom
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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/20161213/7f8276d6/attachment-0001.html 

From fgavrilo at redhat.com  Tue Dec 13 06:58:41 2016
From: fgavrilo at redhat.com (Fedor Gavrilov)
Date: Tue, 13 Dec 2016 06:58:41 -0500 (EST)
Subject: [wildfly-dev] 4 y.o. transactions hack calls wildfly his home now:
 should we depart it?
In-Reply-To: <1325528944.7311308.1481629444462.JavaMail.zimbra@redhat.com>
Message-ID: <1806300870.7314259.1481630321332.JavaMail.zimbra@redhat.com>

Hi,

Lately there was a need to fix a peculiar issue related to handling non-exiting tx: no matter what results xa_commit would bring, it was ignored: https://issues.jboss.org/browse/WFLY-7196
What I realised while working on it was this behaviour is kinda intentional. To be exact:
https://github.com/jbosstm/jboss-as/commit/87ea78a26a53b71411dd52753bb08ef06a8e5969
https://github.com/jbosstm/jboss-as/commit/de5fbd309cad0767eaf8cf9a8b55f89a7092fdf4

Making XidTransaction*Tasks more strict by throwing exceptions when there is no way to find a transaction causes some test failures because the whole thing currently relies on that.
We have sort of conflicting requirements here. I think we need to figure out how do we distinguish between these two possibile situations when no tx is found: the one where we call alarm and the one which we want to ignore.
Maybe that hack should be placed somewhere else. What do you think?

Fedor

From brian.stansberry at redhat.com  Tue Dec 13 08:46:07 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 13 Dec 2016 07:46:07 -0600
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <CALaezvXysNd06eQ=cf5GL3UxGdnbzg6JaHBy8oHAPHPTSZV9ZA@mail.gmail.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
	<99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>
	<CALaezvWDSNOjL0GbhF1RqN3_ipZATL9q-o1BkfgjrV3WBh8OBg@mail.gmail.com>
	<CALaezvXysNd06eQ=cf5GL3UxGdnbzg6JaHBy8oHAPHPTSZV9ZA@mail.gmail.com>
Message-ID: <1B7A3A85-7D7F-43C4-8032-AC1D72D64FEC@redhat.com>

Great. :)

It looks like the TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler logic came in about a month ago. The issue may have surfaced more recently than that if the test that revealed it was not part of CI, but was something extended that Red Hat QE runs against periodic internal builds. Those happen every few weeks.

> On Dec 13, 2016, at 5:55 AM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> 
> Yeah, moving the lookup to the area you mentioned worked - thanks again!
> 
> On 13 December 2016 at 10:54, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> Thanks, I will take a look. Did this change recently? If not I am at a loss why it is starting to fail an existing test.
> 
> On 12 December 2016 at 21:33, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> >
> > This is the problem: the TransactionExtension initialize method of touching classes that result in doing static initialization stuff that reads the system props at that point, which is too early:
> >
> 
> s/of touching/is touching/g
> 
> A likely fix is to just not store a ref to coordinatorEnvironmentBean in TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just find it and use it in applyUpdateToRuntime/revertUpdateToRuntime neither of which will get called before system properties are set. They don?t get called at all if the user doesn?t do a write-attribute op to change that attribute.
> 
> > "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
> >  java.lang.Thread.State: RUNNABLE
> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.initPropertiesFactory(PropertiesFactory.java:53)
> >         - locked <0x1389> (a java.lang.Class)
> >         at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:36)
> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:86)
> >         at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> >         at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.<init>(TransactionSubsystemRootResourceDefinition.java:518)
> >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition.registerAttributes(TransactionSubsystemRootResourceDefinition.java:314)
> >         at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:104)
> >         at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225)
> >         at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
> >         at org.jboss.as.txn.subsystem.TransactionExtension.initialize(TransactionExtension.java:104)
> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> >         at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
> >         at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
> >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >         at java.lang.Thread.run(Thread.java:745)
> >         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> >
> >
> >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> >>
> >> Thanks for the input/
> >>
> >> This is the point I do not think the property has been set by:
> >>
> >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
> >>  java.lang.Thread.State: RUNNABLE
> >>        at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> >>        - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean)
> >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> >>        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>        at java.lang.reflect.Method.invoke(Method.java:498)
> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> >>        at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> >>        at com.arjuna.ats.arjuna.common.recoveryPropertyManager.getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> >>        at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:96)
> >>        - locked <0x1bd2> (a org.jboss.as.txn.service.ArjunaRecoveryManagerService)
> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> >>        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >>        at java.lang.Thread.run(Thread.java:745)
> >>
> >> (that is output from the debugger)
> >>
> >> Once releasing that thread and letting the container continue startup I see this execute:
> >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>
> >> I believe this is different to previous behaviour as I have had a defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820. It's possible that there is a regression in Narayana (somehow) if nothing changed in this area in the core itself.
> >>
> >> Thanks for your input,
> >> Tom
> >>
> >>
> >>
> >>
> >> On 12 December 2016 at 20:15, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> >> This works fine for me. Adding that xml snippet to standalone.xml after the <extensions> element I see the property being set during boot before any processing of subsystem operations begins.
> >>
> >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> >>>
> >>> I don?t see anything in the organization of boot ops that would have changed the ordering, and the add op for that system property should be executing prior to the subsystem ops. I?ll see if I can reproduce.
> >>>
> >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com> wrote:
> >>>>
> >>>> Where are you trying to use the system property from? They should only be attempted resolved during the RUNTIME stage, not MODEL.
> >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have a subsystem that configures itself from system properties.
> >>>>>
> >>>>> For example:
> >>>>> <system-properties>
> >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> >>>>> </system-properties>
> >>>>>
> >>>>> In earlier revisions of WFLY this worked fine. However I am now seeing that the system property is not set until after my subsystem has started. I can tell this as I have breakpoints on where I process the property. I can see "MSC service thread 1-4" attempting to process the property (which is not set). I do later see messages that suggest the system property is set but at that the later point:
> >>>>>
> >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation] (Controller Boot Thread) Final response for step handler org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling internal-model-validation in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" => "success"}
> >>>>>
> >>>>> Does my subsystem need to depend on something to get the old behaviour of being started after system properties are processed?
> >>>>>
> >>>>> My subsystem is the transaction one and the service is the recovery manager.
> >>>>>
> >>>>> Thanks!
> >>>>> Tom
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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





From david.lloyd at redhat.com  Tue Dec 13 09:14:22 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 13 Dec 2016 08:14:22 -0600
Subject: [wildfly-dev] 4 y.o. transactions hack calls wildfly his home
 now: should we depart it?
In-Reply-To: <1806300870.7314259.1481630321332.JavaMail.zimbra@redhat.com>
References: <1806300870.7314259.1481630321332.JavaMail.zimbra@redhat.com>
Message-ID: <7663cc21-4df8-b088-64dd-8dc26437e846@redhat.com>

On 12/13/2016 05:58 AM, Fedor Gavrilov wrote:
> Hi,
>
> Lately there was a need to fix a peculiar issue related to handling non-exiting tx: no matter what results xa_commit would bring, it was ignored: https://issues.jboss.org/browse/WFLY-7196
> What I realised while working on it was this behaviour is kinda intentional. To be exact:
> https://github.com/jbosstm/jboss-as/commit/87ea78a26a53b71411dd52753bb08ef06a8e5969
> https://github.com/jbosstm/jboss-as/commit/de5fbd309cad0767eaf8cf9a8b55f89a7092fdf4
>
> Making XidTransaction*Tasks more strict by throwing exceptions when there is no way to find a transaction causes some test failures because the whole thing currently relies on that.
> We have sort of conflicting requirements here. I think we need to figure out how do we distinguish between these two possibile situations when no tx is found: the one where we call alarm and the one which we want to ignore.
> Maybe that hack should be placed somewhere else. What do you think?

You are right, this needs to be examined.

In the UserTransaction case, the client clearly knows when no 
invocations have taken place (as it will never have outflowed the 
transaction) so it could just drop it.  So this *should* be done on the 
client side.  Unfortunately we need the server side to remain for as 
long as we have clients without this behavior.

In the XA case, it's a little more complex because the server might have 
hosted invocations that it doesn't remember (due to new connections or 
whatever).  I don't think we can just ignore the transaction in *this* 
case, but not doing so might cause other problems in this old code.

In EAP 7.1 I'm reworking some of this stuff (almost done in fact), but I 
still have a couple of cases I have to figure out.

-- 
- DML

From tom.jenkinson at redhat.com  Tue Dec 13 09:19:04 2016
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 13 Dec 2016 14:19:04 +0000
Subject: [wildfly-dev] Accessing system properties in a subsystem
In-Reply-To: <1B7A3A85-7D7F-43C4-8032-AC1D72D64FEC@redhat.com>
References: <CALaezvXZUzE6gZ=gRn7-m_0Jzu5bC8kXTKzqQDVzijzR_Crx5A@mail.gmail.com>
	<EAF72B92-E5AD-4B66-A08D-CC138488C3E5@jboss.com>
	<3AD9DD9F-E5A0-4CF8-A723-7DA4F945B747@redhat.com>
	<3EA9770C-8ECB-44B0-8882-6EE22056F099@redhat.com>
	<CALaezvV62+RqHqtnyP6N8vU2bF8u+94-6+ptnXBq9bRaDEYytg@mail.gmail.com>
	<A4DE6630-20B2-4BB2-9A23-1A2CEDEA85B5@redhat.com>
	<99B02AB0-4151-49F8-AAE5-13FFB59A84D6@redhat.com>
	<CALaezvWDSNOjL0GbhF1RqN3_ipZATL9q-o1BkfgjrV3WBh8OBg@mail.gmail.com>
	<CALaezvXysNd06eQ=cf5GL3UxGdnbzg6JaHBy8oHAPHPTSZV9ZA@mail.gmail.com>
	<1B7A3A85-7D7F-43C4-8032-AC1D72D64FEC@redhat.com>
Message-ID: <CALaezvWcQ7MjrQ5b3907z4Y28s2PL0RjM6Pyq_7qZdXHY6OFsg@mail.gmail.com>

Yeah - that must be it thanks!

On 13 December 2016 at 13:46, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> Great. :)
>
> It looks like the TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler
> logic came in about a month ago. The issue may have surfaced more recently
> than that if the test that revealed it was not part of CI, but was
> something extended that Red Hat QE runs against periodic internal builds.
> Those happen every few weeks.
>
> > On Dec 13, 2016, at 5:55 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> >
> > Yeah, moving the lookup to the area you mentioned worked - thanks again!
> >
> > On 13 December 2016 at 10:54, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > Thanks, I will take a look. Did this change recently? If not I am at a
> loss why it is starting to fail an existing test.
> >
> > On 12 December 2016 at 21:33, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >
> > > This is the problem: the TransactionExtension initialize method of
> touching classes that result in doing static initialization stuff that
> reads the system props at that point, which is too early:
> > >
> >
> > s/of touching/is touching/g
> >
> > A likely fix is to just not store a ref to coordinatorEnvironmentBean in
> TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just
> find it and use it in applyUpdateToRuntime/revertUpdateToRuntime neither
> of which will get called before system properties are set. They don?t get
> called at all if the user doesn?t do a write-attribute op to change that
> attribute.
> >
> > > "ServerService Thread Pool -- 21 at 3635" prio=5 tid=0x30 nid=NA runnable
> > >  java.lang.Thread.State: RUNNABLE
> > >         at com.arjuna.common.util.propertyservice.PropertiesFactory.
> initPropertiesFactory(PropertiesFactory.java:53)
> > >         - locked <0x1389> (a java.lang.Class)
> > >         at com.arjuna.common.util.propertyservice.PropertiesFactory.
> getDefaultProperties(PropertiesFactory.java:36)
> > >         at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getNamedInstance(BeanPopulator.java:86)
> > >         at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> > >         at com.arjuna.ats.arjuna.common.arjPropertyManager.
> getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
> > >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResour
> ceDefinition$StatisticsEnabledHandler.<init>(
> TransactionSubsystemRootResourceDefinition.java:518)
> > >         at org.jboss.as.txn.subsystem.TransactionSubsystemRootResour
> ceDefinition.registerAttributes(TransactionSubsystemRootResour
> ceDefinition.java:314)
> > >         at org.jboss.as.controller.registry.NodeSubregistry.
> registerChild(NodeSubregistry.java:104)
> > >         at org.jboss.as.controller.registry.
> ConcreteResourceRegistration.registerSubModel(
> ConcreteResourceRegistration.java:225)
> > >         at org.jboss.as.controller.extension.ExtensionRegistry$
> SubsystemRegistrationImpl.registerSubsystemModel(
> ExtensionRegistry.java:706)
> > >         at org.jboss.as.txn.subsystem.TransactionExtension.initialize(
> TransactionExtension.java:104)
> > >         at org.jboss.as.controller.extension.ExtensionAddHandler.
> initializeExtension(ExtensionAddHandler.java:131)
> > >         at org.jboss.as.controller.extension.ExtensionAddHandler.
> initializeExtension(ExtensionAddHandler.java:104)
> > >         at org.jboss.as.controller.extension.
> ParallelExtensionAddHandler$ExtensionInitializeTask.call(
> ParallelExtensionAddHandler.java:144)
> > >         at org.jboss.as.controller.extension.
> ParallelExtensionAddHandler$ExtensionInitializeTask.call(
> ParallelExtensionAddHandler.java:127)
> > >         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > >         at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> > >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> > >         at java.lang.Thread.run(Thread.java:745)
> > >         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> > >
> > >
> > >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > >>
> > >> Thanks for the input/
> > >>
> > >> This is the point I do not think the property has been set by:
> > >>
> > >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
> > >>  java.lang.Thread.State: RUNNABLE
> > >>        at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.
> getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> > >>        - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.
> RecoveryEnvironmentBean)
> > >>        at sun.reflect.NativeMethodAccessorImpl.invoke0(
> NativeMethodAccessorImpl.java:-1)
> > >>        at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> > >>        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> > >>        at java.lang.reflect.Method.invoke(Method.java:498)
> > >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> > >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> > >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> > >>        at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> > >>        at com.arjuna.ats.arjuna.common.recoveryPropertyManager.
> getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> > >>        at org.jboss.as.txn.service.ArjunaRecoveryManagerService.
> start(ArjunaRecoveryManagerService.java:96)
> > >>        - locked <0x1bd2> (a org.jboss.as.txn.service.
> ArjunaRecoveryManagerService)
> > >>        at org.jboss.msc.service.ServiceControllerImpl$
> StartTask.startService(ServiceControllerImpl.java:1963)
> > >>        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> ServiceControllerImpl.java:1896)
> > >>        at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> > >>        at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> > >>        at java.lang.Thread.run(Thread.java:745)
> > >>
> > >> (that is output from the debugger)
> > >>
> > >> Once releasing that thread and letting the container continue startup
> I see this execute:
> > >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> > >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> > >>
> > >> I believe this is different to previous behaviour as I have had a
> defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820.
> It's possible that there is a regression in Narayana (somehow) if nothing
> changed in this area in the core itself.
> > >>
> > >> Thanks for your input,
> > >> Tom
> > >>
> > >>
> > >>
> > >>
> > >> On 12 December 2016 at 20:15, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >> This works fine for me. Adding that xml snippet to standalone.xml
> after the <extensions> element I see the property being set during boot
> before any processing of subsystem operations begins.
> > >>
> > >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >>>
> > >>> I don?t see anything in the organization of boot ops that would have
> changed the ordering, and the add op for that system property should be
> executing prior to the subsystem ops. I?ll see if I can reproduce.
> > >>>
> > >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com>
> wrote:
> > >>>>
> > >>>> Where are you trying to use the system property from? They should
> only be attempted resolved during the RUNTIME stage, not MODEL.
> > >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I have a subsystem that configures itself from system properties.
> > >>>>>
> > >>>>> For example:
> > >>>>> <system-properties>
> > >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
> value="com.arjuna.ats.internal.arjuna.recovery.
> ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.
> arjuna.recovery.AtomicActionExpiryScanner"/>
> > >>>>> </system-properties>
> > >>>>>
> > >>>>> In earlier revisions of WFLY this worked fine. However I am now
> seeing that the system property is not set until after my subsystem has
> started. I can tell this as I have breakpoints on where I process the
> property. I can see "MSC service thread 1-4" attempting to process the
> property (which is not set). I do later see messages that suggest the
> system property is set but at that the later point:
> > >>>>>
> > >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> > >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> > >>>>>
> > >>>>> Does my subsystem need to depend on something to get the old
> behaviour of being started after system properties are processed?
> > >>>>>
> > >>>>> My subsystem is the transaction one and the service is the
> recovery manager.
> > >>>>>
> > >>>>> Thanks!
> > >>>>> Tom
> > >>>>> _______________________________________________
> > >>>>> 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161213/aca70a31/attachment-0001.html 

From gtrikler at redhat.com  Tue Dec 13 16:26:07 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Tue, 13 Dec 2016 22:26:07 +0100
Subject: [wildfly-dev] WildFly status listener
Message-ID: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>

Hello,

I'm wondering if there is a way to register a listener which would be 
invoked when server status has changed. More specifically when 
application server completed start-up.

The reason for that is that after [1] commit was introduced our rest 
transaction tests started to fail. The cause seems to be rest service 
call during the start of one of our services. That call doesn't 
necessarily have to be executed during the service start. However, the 
sooner it's done the better and if it would be possible to register some 
sort of callback to be invoked once start-up was done, that would be great.

Thanks,

Gytis


[1] 
https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e


From brian.stansberry at redhat.com  Tue Dec 13 16:34:45 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 13 Dec 2016 15:34:45 -0600
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
Message-ID: <3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>

That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)

But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.

> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
> 
> Hello,
> 
> I'm wondering if there is a way to register a listener which would be 
> invoked when server status has changed. More specifically when 
> application server completed start-up.
> 
> The reason for that is that after [1] commit was introduced our rest 
> transaction tests started to fail. The cause seems to be rest service 
> call during the start of one of our services. That call doesn't 
> necessarily have to be executed during the service start. However, the 
> sooner it's done the better and if it would be possible to register some 
> sort of callback to be invoked once start-up was done, that would be great.
> 
> Thanks,
> 
> Gytis
> 
> 
> [1] 
> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
> 
> _______________________________________________
> 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 jperkins at redhat.com  Tue Dec 13 16:51:29 2016
From: jperkins at redhat.com (James Perkins)
Date: Tue, 13 Dec 2016 13:51:29 -0800
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
In-Reply-To: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
References: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
Message-ID: <CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>

Hi Peter,
It may not be a big deal because it's just for builds, but instead of
deleting the build.(sh|bat) maybe we just make those invoke the appropriate
mvnw command instead.

On Fri, Dec 9, 2016 at 7:28 AM, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi *,
>
> as discussed with some of you on Brno F2F, both wildfly and wildfly-core
> are ready for Maven 3.3.1+ now. I am in the process of preparing PRs
> that will:
>
> * Enforce Maven version 3.3.1+
> * Introduce mvnw (a.k.a.) Maven Wrapper [1] - a script that
>    downloads and installs (if necessary) the required Maven version to
>     ~/.m2/wrapper and runs it from there.
> * Use of mvnw will be optional
> * build.sh/bat in wildfly will be removed
> * MAVEN_OPTS will live in .mvn/jvm.config and .mvn/maven.config
>
> A PR for core [2] was sent already.
>
> [1] https://github.com/takari/maven-wrapper#maven-wrapper
> [2] https://github.com/wildfly/wildfly-core/pull/2017
>
> Thanks,
>
> Peter
> _______________________________________________
> 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/20161213/21ace8a1/attachment.html 

From gtrikler at redhat.com  Tue Dec 13 17:22:44 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Tue, 13 Dec 2016 23:22:44 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
Message-ID: <de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>

Is there a way to make sure I'm making the service call not too early?

Also, ControlledProcessStateService methods which are used in that 
commit are deprecated. That's why I wasn't sure if it's OK for me to use 
them.


On 13/12/2016 22:34, Brian Stansberry wrote:
> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>
> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>
>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>
>> Hello,
>>
>> I'm wondering if there is a way to register a listener which would be
>> invoked when server status has changed. More specifically when
>> application server completed start-up.
>>
>> The reason for that is that after [1] commit was introduced our rest
>> transaction tests started to fail. The cause seems to be rest service
>> call during the start of one of our services. That call doesn't
>> necessarily have to be executed during the service start. However, the
>> sooner it's done the better and if it would be possible to register some
>> sort of callback to be invoked once start-up was done, that would be great.
>>
>> Thanks,
>>
>> Gytis
>>
>>
>> [1]
>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From ppalaga at redhat.com  Tue Dec 13 17:26:40 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Tue, 13 Dec 2016 23:26:40 +0100
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
In-Reply-To: <CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>
References: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
	<CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>
Message-ID: <f55703ff-7a5b-4bf9-79bf-54936efb253b@redhat.com>

Hi James,

On 2016-12-13 22:51, James Perkins wrote:
> Hi Peter,
> It may not be a big deal because it's just for builds, but instead of
> deleting the build.(sh|bat) maybe we just make those invoke the
> appropriate mvnw command instead.

That would be easy to do, but can you name a situation where it would 
actually matter?

-- P


> On Fri, Dec 9, 2016 at 7:28 AM, Peter Palaga <ppalaga at redhat.com
> <mailto:ppalaga at redhat.com>> wrote:
>
>     Hi *,
>
>     as discussed with some of you on Brno F2F, both wildfly and wildfly-core
>     are ready for Maven 3.3.1+ now. I am in the process of preparing PRs
>     that will:
>
>     * Enforce Maven version 3.3.1+
>     * Introduce mvnw (a.k.a.) Maven Wrapper [1] - a script that
>        downloads and installs (if necessary) the required Maven version to
>         ~/.m2/wrapper and runs it from there.
>     * Use of mvnw will be optional
>     * build.sh/bat <http://build.sh/bat> in wildfly will be removed
>     * MAVEN_OPTS will live in .mvn/jvm.config and .mvn/maven.config
>
>     A PR for core [2] was sent already.
>
>     [1] https://github.com/takari/maven-wrapper#maven-wrapper
>     <https://github.com/takari/maven-wrapper#maven-wrapper>
>     [2] https://github.com/wildfly/wildfly-core/pull/2017
>     <https://github.com/wildfly/wildfly-core/pull/2017>
>
>     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>
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat


From stuart.w.douglas at gmail.com  Tue Dec 13 17:45:45 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 14 Dec 2016 09:45:45 +1100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
Message-ID: <CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>

Why do you need to make a rest call while startup is taking place?

Stuart

On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com>
wrote:

> Is there a way to make sure I'm making the service call not too early?
>
> Also, ControlledProcessStateService methods which are used in that
> commit are deprecated. That's why I wasn't sure if it's OK for me to use
> them.
>
>
> On 13/12/2016 22:34, Brian Stansberry wrote:
> > That commit you linked shows the mechanism for getting a notification of
> process state changes (inject ControlledProcessStateService and register a
> property change listener.)
> >
> > But, that commit is opening up the listener when it gets the
> notification, so if you listen for the same notification and make a call
> it?s going to be racy.
> >
> >> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com>
> wrote:
> >>
> >> Hello,
> >>
> >> I'm wondering if there is a way to register a listener which would be
> >> invoked when server status has changed. More specifically when
> >> application server completed start-up.
> >>
> >> The reason for that is that after [1] commit was introduced our rest
> >> transaction tests started to fail. The cause seems to be rest service
> >> call during the start of one of our services. That call doesn't
> >> necessarily have to be executed during the service start. However, the
> >> sooner it's done the better and if it would be possible to register some
> >> sort of callback to be invoked once start-up was done, that would be
> great.
> >>
> >> Thanks,
> >>
> >> Gytis
> >>
> >>
> >> [1]
> >> https://github.com/wildfly/wildfly/commit/
> d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
> >>
> >> _______________________________________________
> >> 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/20161214/31ca0e10/attachment.html 

From brian.stansberry at redhat.com  Tue Dec 13 18:01:05 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 13 Dec 2016 17:01:05 -0600
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
Message-ID: <4D282CF9-F4BD-4D0B-ADED-49F732718CD3@redhat.com>


> On Dec 13, 2016, at 4:22 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
> 
> Is there a way to make sure I'm making the service call not too early?
> 
> Also, ControlledProcessStateService methods which are used in that commit are deprecated. That's why I wasn't sure if it's OK for me to use them.
> 

I deprecated that code when wrote with a meaning more like ?@Experimental?. But it?s still valid years later so https://github.com/wildfly/wildfly-core/pull/2030 will take care of that.

> On 13/12/2016 22:34, Brian Stansberry wrote:
>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>> 
>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>> 
>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I'm wondering if there is a way to register a listener which would be
>>> invoked when server status has changed. More specifically when
>>> application server completed start-up.
>>> 
>>> The reason for that is that after [1] commit was introduced our rest
>>> transaction tests started to fail. The cause seems to be rest service
>>> call during the start of one of our services. That call doesn't
>>> necessarily have to be executed during the service start. However, the
>>> sooner it's done the better and if it would be possible to register some
>>> sort of callback to be invoked once start-up was done, that would be great.
>>> 
>>> Thanks,
>>> 
>>> Gytis
>>> 
>>> 
>>> [1]
>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>> 
>>> _______________________________________________
>>> 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 smarlow at redhat.com  Tue Dec 13 19:04:59 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 13 Dec 2016 19:04:59 -0500
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
In-Reply-To: <f55703ff-7a5b-4bf9-79bf-54936efb253b@redhat.com>
References: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
	<CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>
	<f55703ff-7a5b-4bf9-79bf-54936efb253b@redhat.com>
Message-ID: <CAJtdNN6wgL7xzGOEB+xmBpzj2x85KEQJ_M+ojxU6HNL3JqQGOQ@mail.gmail.com>

Hi Peter,

On Tue, Dec 13, 2016 at 5:26 PM, Peter Palaga <ppalaga at redhat.com> wrote:
> Hi James,
>
> On 2016-12-13 22:51, James Perkins wrote:
>> Hi Peter,
>> It may not be a big deal because it's just for builds, but instead of
>> deleting the build.(sh|bat) maybe we just make those invoke the
>> appropriate mvnw command instead.
>
> That would be easy to do, but can you name a situation where it would
> actually matter?

We have a few (compliance) test scripts that invoke build.sh to build
the app server from source.  I'm not sure how widespread use of
build.sh is in other test environments but we probably could ask that
question via a separate topic.

Scott

From frainone at redhat.com  Wed Dec 14 01:42:17 2016
From: frainone at redhat.com (Flavia Rainone)
Date: Wed, 14 Dec 2016 04:42:17 -0200
Subject: [wildfly-dev] EJB Transactions Graceful Shutdown
In-Reply-To: <9eafe20c-3281-7071-4578-9a76ae325048@redhat.com>
References: <57737168-7d55-1161-60f3-725c5b6f0b98@redhat.com>
	<CAD+L2cyQWnZrLK_o-OQZkmaBWfEDtJZYpzz-mLcubqmiUfQ03g@mail.gmail.com>
	<7e17bec3-ebe9-a420-1e2d-cd32d714f7af@redhat.com>
	<9eafe20c-3281-7071-4578-9a76ae325048@redhat.com>
Message-ID: <161bb1b1-d566-6d9e-03d6-1bc3d0d29485@redhat.com>

I see, I'll keep the count in EJB system, then.

I'll complete my commit and make a PR, I'll let you know if I have any 
remaining questions in this thread.


On 12-12-2016 17:25, Gytis Trikleris wrote:
> (EJB, CDI, or UserTransaction

-- 
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466

Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.

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

From pkremens at redhat.com  Wed Dec 14 03:29:15 2016
From: pkremens at redhat.com (Petr Kremensky)
Date: Wed, 14 Dec 2016 03:29:15 -0500 (EST)
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
In-Reply-To: <CAJtdNN6wgL7xzGOEB+xmBpzj2x85KEQJ_M+ojxU6HNL3JqQGOQ@mail.gmail.com>
References: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
	<CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>
	<f55703ff-7a5b-4bf9-79bf-54936efb253b@redhat.com>
	<CAJtdNN6wgL7xzGOEB+xmBpzj2x85KEQJ_M+ojxU6HNL3JqQGOQ@mail.gmail.com>
Message-ID: <1922818807.11518908.1481704155430.JavaMail.zimbra@redhat.com>

Hi Peter,

also our automation rely on these (in case this should bubble into EAP codebase as well).

Petr

----- Original Message -----
From: "Scott Marlow" <smarlow at redhat.com>
To: "Peter Palaga" <ppalaga at redhat.com>
Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
Sent: Wednesday, 14 December, 2016 1:04:59 AM
Subject: Re: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core

Hi Peter,

On Tue, Dec 13, 2016 at 5:26 PM, Peter Palaga <ppalaga at redhat.com> wrote:
> Hi James,
>
> On 2016-12-13 22:51, James Perkins wrote:
>> Hi Peter,
>> It may not be a big deal because it's just for builds, but instead of
>> deleting the build.(sh|bat) maybe we just make those invoke the
>> appropriate mvnw command instead.
>
> That would be easy to do, but can you name a situation where it would
> actually matter?

We have a few (compliance) test scripts that invoke build.sh to build
the app server from source.  I'm not sure how widespread use of
build.sh is in other test environments but we probably could ask that
question via a separate topic.

Scott
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

From ppalaga at redhat.com  Wed Dec 14 03:36:44 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 14 Dec 2016 09:36:44 +0100
Subject: [wildfly-dev] Maven 3.3.1+ coming to wildfly and wildfly-core
In-Reply-To: <CAJtdNN6wgL7xzGOEB+xmBpzj2x85KEQJ_M+ojxU6HNL3JqQGOQ@mail.gmail.com>
References: <6d206f5a-a45a-6bcb-1deb-2f4feee34ba2@redhat.com>
	<CADGwLpi_rGjn9rCSLMVy6YtD2Z1zs2jcjd8LpAoXE=FFY59nMg@mail.gmail.com>
	<f55703ff-7a5b-4bf9-79bf-54936efb253b@redhat.com>
	<CAJtdNN6wgL7xzGOEB+xmBpzj2x85KEQJ_M+ojxU6HNL3JqQGOQ@mail.gmail.com>
Message-ID: <b10e0573-d1bc-e631-a48e-1318bf7dcb60@redhat.com>

Hi Scott, OK, let's keep the build.(sh|bat) scripts for now. I'll change 
them (1) to wrap mvnw and (2) to print a warning that they are 
deprecated in favor of mvnw. -- P

On 2016-12-14 01:04, Scott Marlow wrote:
> Hi Peter,
>
> On Tue, Dec 13, 2016 at 5:26 PM, Peter Palaga <ppalaga at redhat.com> wrote:
>> Hi James,
>>
>> On 2016-12-13 22:51, James Perkins wrote:
>>> Hi Peter,
>>> It may not be a big deal because it's just for builds, but instead of
>>> deleting the build.(sh|bat) maybe we just make those invoke the
>>> appropriate mvnw command instead.
>>
>> That would be easy to do, but can you name a situation where it would
>> actually matter?
>
> We have a few (compliance) test scripts that invoke build.sh to build
> the app server from source.  I'm not sure how widespread use of
> build.sh is in other test environments but we probably could ask that
> question via a separate topic.
>
> Scott
>


From gtrikler at redhat.com  Wed Dec 14 03:58:08 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Wed, 14 Dec 2016 09:58:08 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
Message-ID: <932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>

I need to load REST-AT participants from the crash recovery store and 
notify REST-AT coordinator (via REST API) of their URLs. This doesn't 
have to be done on the server start, but until it's done REST-AT 
coordinator recovery will be printing warnings because it won't be able 
to contact participants. So the sooner it's done the better, hence my 
question about a listener which could be invoked once the server 
completed boot-up.

Gytis


On 13/12/2016 23:45, Stuart Douglas wrote:
> Why do you need to make a rest call while startup is taking place?
>
> Stuart
>
> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com 
> <mailto:gtrikler at redhat.com>> wrote:
>
>     Is there a way to make sure I'm making the service call not too early?
>
>     Also, ControlledProcessStateService methods which are used in that
>     commit are deprecated. That's why I wasn't sure if it's OK for me
>     to use
>     them.
>
>
>     On 13/12/2016 22:34, Brian Stansberry wrote:
>     > That commit you linked shows the mechanism for getting a
>     notification of process state changes (inject
>     ControlledProcessStateService and register a property change
>     listener.)
>     >
>     > But, that commit is opening up the listener when it gets the
>     notification, so if you listen for the same notification and make
>     a call it?s going to be racy.
>     >
>     >> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris
>     <gtrikler at redhat.com <mailto:gtrikler at redhat.com>> wrote:
>     >>
>     >> Hello,
>     >>
>     >> I'm wondering if there is a way to register a listener which
>     would be
>     >> invoked when server status has changed. More specifically when
>     >> application server completed start-up.
>     >>
>     >> The reason for that is that after [1] commit was introduced our
>     rest
>     >> transaction tests started to fail. The cause seems to be rest
>     service
>     >> call during the start of one of our services. That call doesn't
>     >> necessarily have to be executed during the service start.
>     However, the
>     >> sooner it's done the better and if it would be possible to
>     register some
>     >> sort of callback to be invoked once start-up was done, that
>     would be great.
>     >>
>     >> Thanks,
>     >>
>     >> Gytis
>     >>
>     >>
>     >> [1]
>     >>
>     https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>     <https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e>
>     >>
>     >> _______________________________________________
>     >> 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 <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161214/3ae3a91a/attachment.html 

From ppalaga at redhat.com  Wed Dec 14 10:50:11 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 14 Dec 2016 16:50:11 +0100
Subject: [wildfly-dev] An integration test adding JBoss Module and running
 management commands?
Message-ID: <89bd23f7-e8da-3a43-d490-f85cdbe6b869@redhat.com>

Hi *,

I wonder if we already have an integration test that requires to add 
some custom JBoss Module and to run some Management commands?

I'd like to add an integration test for 
https://issues.jboss.org/browse/WFLY-7412 . I was able to do everything 
I need using various Maven plugins (most notably WF Plugin and some 
resource copying) in this test project: https://github.com/ppalaga/WFLY-7412

However, I am kinda hesitant to send my solution to WF code base, 
because it looks too different from the usual Arquillian way of writing 
itests.

Therefore, I am asking if anybody could perhaps point me to an 
Arquillian (or any other existing) test in WF code base that runs 
management commands, installs custom JBoss modules, deploys a simple 
test app and then sends some HTTP requests against the container?

Thanks,

Peter

From kabir.khan at jboss.com  Wed Dec 14 11:50:27 2016
From: kabir.khan at jboss.com (Kabir Khan)
Date: Wed, 14 Dec 2016 16:50:27 +0000
Subject: [wildfly-dev] An integration test adding JBoss Module and
 running management commands?
In-Reply-To: <89bd23f7-e8da-3a43-d490-f85cdbe6b869@redhat.com>
References: <89bd23f7-e8da-3a43-d490-f85cdbe6b869@redhat.com>
Message-ID: <EDA148D7-7DE6-444C-89E3-3270AD1962B9@jboss.com>

For adding the module, look for usage of org.jboss.as.test.module.util.TestModule
> On 14 Dec 2016, at 15:50, Peter Palaga <ppalaga at redhat.com> wrote:
> 
> Hi *,
> 
> I wonder if we already have an integration test that requires to add 
> some custom JBoss Module and to run some Management commands?
> 
> I'd like to add an integration test for 
> https://issues.jboss.org/browse/WFLY-7412 . I was able to do everything 
> I need using various Maven plugins (most notably WF Plugin and some 
> resource copying) in this test project: https://github.com/ppalaga/WFLY-7412
> 
> However, I am kinda hesitant to send my solution to WF code base, 
> because it looks too different from the usual Arquillian way of writing 
> itests.
> 
> Therefore, I am asking if anybody could perhaps point me to an 
> Arquillian (or any other existing) test in WF code base that runs 
> management commands, installs custom JBoss modules, deploys a simple 
> test app and then sends some HTTP requests against the container?
> 
> Thanks,
> 
> Peter
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From brian.stansberry at redhat.com  Wed Dec 14 12:19:40 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 14 Dec 2016 11:19:40 -0600
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
Message-ID: <D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>

This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.

> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
> 
> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
> 
> Gytis
> 
> On 13/12/2016 23:45, Stuart Douglas wrote:
>> Why do you need to make a rest call while startup is taking place?
>> 
>> Stuart
>> 
>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> Is there a way to make sure I'm making the service call not too early?
>> 
>> Also, ControlledProcessStateService methods which are used in that
>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>> them.
>> 
>> 
>> On 13/12/2016 22:34, Brian Stansberry wrote:
>> > That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>> >
>> > But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>> >
>> >> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm wondering if there is a way to register a listener which would be
>> >> invoked when server status has changed. More specifically when
>> >> application server completed start-up.
>> >>
>> >> The reason for that is that after [1] commit was introduced our rest
>> >> transaction tests started to fail. The cause seems to be rest service
>> >> call during the start of one of our services. That call doesn't
>> >> necessarily have to be executed during the service start. However, the
>> >> sooner it's done the better and if it would be possible to register some
>> >> sort of callback to be invoked once start-up was done, that would be great.
>> >>
>> >> Thanks,
>> >>
>> >> Gytis
>> >>
>> >>
>> >> [1]
>> >> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>> >>
>> >> _______________________________________________
>> >> 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 gtrikler at redhat.com  Wed Dec 14 14:33:15 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Wed, 14 Dec 2016 20:33:15 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
Message-ID: <abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>

In this particular test case both coordinator and participants are on 
the same server. But they can also be running on different servers. 
Participant just contacts coordinator via URL provided wherever it is 
located.


On 14/12/2016 18:19, Brian Stansberry wrote:
> This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.
>
>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>
>> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
>>
>> Gytis
>>
>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>> Why do you need to make a rest call while startup is taking place?
>>>
>>> Stuart
>>>
>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>> Is there a way to make sure I'm making the service call not too early?
>>>
>>> Also, ControlledProcessStateService methods which are used in that
>>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>>> them.
>>>
>>>
>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>>>>
>>>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>>>>
>>>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I'm wondering if there is a way to register a listener which would be
>>>>> invoked when server status has changed. More specifically when
>>>>> application server completed start-up.
>>>>>
>>>>> The reason for that is that after [1] commit was introduced our rest
>>>>> transaction tests started to fail. The cause seems to be rest service
>>>>> call during the start of one of our services. That call doesn't
>>>>> necessarily have to be executed during the service start. However, the
>>>>> sooner it's done the better and if it would be possible to register some
>>>>> sort of callback to be invoked once start-up was done, that would be great.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gytis
>>>>>
>>>>>
>>>>> [1]
>>>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>


From brian.stansberry at redhat.com  Wed Dec 14 14:49:24 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 14 Dec 2016 13:49:24 -0600
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
Message-ID: <6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>

OK. I should probably shut up and defer to Stuart anyway. :)

I say that because looking at his commit you linked, it looks like what it does is it starts queuing up requests during boot and then when it gets the ControlledProcessStateService RUNNING notification it opens the gate and the queued requests get handled (as do new ones of course.)

So that means you shouldn?t have a problematic race if you also use the ControlledProcessStateService RUNNING notification. Your request will either get there before the gate opens and be queued momentarily before being processed, or it will get there after the gate opens and be processed. Either way it gets processed and the client is none the wiser. 

> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
> 
> In this particular test case both coordinator and participants are on the same server. But they can also be running on different servers. Participant just contacts coordinator via URL provided wherever it is located.
> 
> 
> On 14/12/2016 18:19, Brian Stansberry wrote:
>> This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.
>> 
>>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>> 
>>> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
>>> 
>>> Gytis
>>> 
>>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>>> Why do you need to make a rest call while startup is taking place?
>>>> 
>>>> Stuart
>>>> 
>>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>> Is there a way to make sure I'm making the service call not too early?
>>>> 
>>>> Also, ControlledProcessStateService methods which are used in that
>>>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>>>> them.
>>>> 
>>>> 
>>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>>>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>>>>> 
>>>>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>>>>> 
>>>>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I'm wondering if there is a way to register a listener which would be
>>>>>> invoked when server status has changed. More specifically when
>>>>>> application server completed start-up.
>>>>>> 
>>>>>> The reason for that is that after [1] commit was introduced our rest
>>>>>> transaction tests started to fail. The cause seems to be rest service
>>>>>> call during the start of one of our services. That call doesn't
>>>>>> necessarily have to be executed during the service start. However, the
>>>>>> sooner it's done the better and if it would be possible to register some
>>>>>> sort of callback to be invoked once start-up was done, that would be great.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Gytis
>>>>>> 
>>>>>> 
>>>>>> [1]
>>>>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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 gtrikler at redhat.com  Wed Dec 14 15:10:45 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Wed, 14 Dec 2016 21:10:45 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
Message-ID: <e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>

Yes it does get processed. But because at the moment call is made from 
service's start method, the service isn't started until the request is 
processed. As a result Arquillian test fails because app server doesn't 
start fast enough.


On 14/12/2016 20:49, Brian Stansberry wrote:
> OK. I should probably shut up and defer to Stuart anyway. :)
>
> I say that because looking at his commit you linked, it looks like what it does is it starts queuing up requests during boot and then when it gets the ControlledProcessStateService RUNNING notification it opens the gate and the queued requests get handled (as do new ones of course.)
>
> So that means you shouldn?t have a problematic race if you also use the ControlledProcessStateService RUNNING notification. Your request will either get there before the gate opens and be queued momentarily before being processed, or it will get there after the gate opens and be processed. Either way it gets processed and the client is none the wiser.
>
>> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>
>> In this particular test case both coordinator and participants are on the same server. But they can also be running on different servers. Participant just contacts coordinator via URL provided wherever it is located.
>>
>>
>> On 14/12/2016 18:19, Brian Stansberry wrote:
>>> This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.
>>>
>>>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>>
>>>> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
>>>>
>>>> Gytis
>>>>
>>>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>>>> Why do you need to make a rest call while startup is taking place?
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>>> Is there a way to make sure I'm making the service call not too early?
>>>>>
>>>>> Also, ControlledProcessStateService methods which are used in that
>>>>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>>>>> them.
>>>>>
>>>>>
>>>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>>>>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>>>>>>
>>>>>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>>>>>>
>>>>>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm wondering if there is a way to register a listener which would be
>>>>>>> invoked when server status has changed. More specifically when
>>>>>>> application server completed start-up.
>>>>>>>
>>>>>>> The reason for that is that after [1] commit was introduced our rest
>>>>>>> transaction tests started to fail. The cause seems to be rest service
>>>>>>> call during the start of one of our services. That call doesn't
>>>>>>> necessarily have to be executed during the service start. However, the
>>>>>>> sooner it's done the better and if it would be possible to register some
>>>>>>> sort of callback to be invoked once start-up was done, that would be great.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Gytis
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>


From stuart.w.douglas at gmail.com  Wed Dec 14 17:21:40 2016
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 15 Dec 2016 09:21:40 +1100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
	<e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
Message-ID: <CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>

In that case you should probably move the rest call out of the service
start, and have it processed by a separate thread.

Its probably not great having server start dependent on an external service
being up anyway.

Stuart

On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com>
wrote:

> Yes it does get processed. But because at the moment call is made from
> service's start method, the service isn't started until the request is
> processed. As a result Arquillian test fails because app server doesn't
> start fast enough.
>
>
>
> On 14/12/2016 20:49, Brian Stansberry wrote:
>
>> OK. I should probably shut up and defer to Stuart anyway. :)
>>
>> I say that because looking at his commit you linked, it looks like what
>> it does is it starts queuing up requests during boot and then when it gets
>> the ControlledProcessStateService RUNNING notification it opens the gate
>> and the queued requests get handled (as do new ones of course.)
>>
>> So that means you shouldn?t have a problematic race if you also use the
>> ControlledProcessStateService RUNNING notification. Your request will
>> either get there before the gate opens and be queued momentarily before
>> being processed, or it will get there after the gate opens and be
>> processed. Either way it gets processed and the client is none the wiser.
>>
>> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>
>>> In this particular test case both coordinator and participants are on
>>> the same server. But they can also be running on different servers.
>>> Participant just contacts coordinator via URL provided wherever it is
>>> located.
>>>
>>>
>>> On 14/12/2016 18:19, Brian Stansberry wrote:
>>>
>>>> This can?t be done internally? Using an HTTP to communicate between
>>>> aspects of the server seems yuck.
>>>>
>>>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com>
>>>>> wrote:
>>>>>
>>>>> I need to load REST-AT participants from the crash recovery store and
>>>>> notify REST-AT coordinator (via REST API) of their URLs. This doesn't have
>>>>> to be done on the server start, but until it's done REST-AT coordinator
>>>>> recovery will be printing warnings because it won't be able to contact
>>>>> participants. So the sooner it's done the better, hence my question about a
>>>>> listener which could be invoked once the server completed boot-up.
>>>>>
>>>>> Gytis
>>>>>
>>>>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>>>>
>>>>>> Why do you need to make a rest call while startup is taking place?
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com>
>>>>>> wrote:
>>>>>> Is there a way to make sure I'm making the service call not too early?
>>>>>>
>>>>>> Also, ControlledProcessStateService methods which are used in that
>>>>>> commit are deprecated. That's why I wasn't sure if it's OK for me to
>>>>>> use
>>>>>> them.
>>>>>>
>>>>>>
>>>>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>>>>>
>>>>>>> That commit you linked shows the mechanism for getting a
>>>>>>> notification of process state changes (inject ControlledProcessStateService
>>>>>>> and register a property change listener.)
>>>>>>>
>>>>>>> But, that commit is opening up the listener when it gets the
>>>>>>> notification, so if you listen for the same notification and make a call
>>>>>>> it?s going to be racy.
>>>>>>>
>>>>>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm wondering if there is a way to register a listener which would
>>>>>>>> be
>>>>>>>> invoked when server status has changed. More specifically when
>>>>>>>> application server completed start-up.
>>>>>>>>
>>>>>>>> The reason for that is that after [1] commit was introduced our rest
>>>>>>>> transaction tests started to fail. The cause seems to be rest
>>>>>>>> service
>>>>>>>> call during the start of one of our services. That call doesn't
>>>>>>>> necessarily have to be executed during the service start. However,
>>>>>>>> the
>>>>>>>> sooner it's done the better and if it would be possible to register
>>>>>>>> some
>>>>>>>> sort of callback to be invoked once start-up was done, that would
>>>>>>>> be great.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Gytis
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5
>>>>>>>> 027744d5ce57f3ebc46d8e
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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/20161215/84094571/attachment-0001.html 

From gtrikler at redhat.com  Wed Dec 14 17:39:18 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Wed, 14 Dec 2016 23:39:18 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
	<e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
	<CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
Message-ID: <91c35750-825b-9158-b520-e2d611dd936d@redhat.com>

I agree, and my intention when starting this thread was to find the best 
place to move that call to. I'll try registering similar listener as in 
your commit. That should free-up a service boot-up thread.

Gytis


On 14/12/2016 23:21, Stuart Douglas wrote:
> In that case you should probably move the rest call out of the service 
> start, and have it processed by a separate thread.
>
> Its probably not great having server start dependent on an external 
> service being up anyway.
>
> Stuart
>
> On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com 
> <mailto:gtrikler at redhat.com>> wrote:
>
>     Yes it does get processed. But because at the moment call is made
>     from service's start method, the service isn't started until the
>     request is processed. As a result Arquillian test fails because
>     app server doesn't start fast enough.
>
>
>
>     On 14/12/2016 20:49, Brian Stansberry wrote:
>
>         OK. I should probably shut up and defer to Stuart anyway. :)
>
>         I say that because looking at his commit you linked, it looks
>         like what it does is it starts queuing up requests during boot
>         and then when it gets the ControlledProcessStateService
>         RUNNING notification it opens the gate and the queued requests
>         get handled (as do new ones of course.)
>
>         So that means you shouldn?t have a problematic race if you
>         also use the ControlledProcessStateService RUNNING
>         notification. Your request will either get there before the
>         gate opens and be queued momentarily before being processed,
>         or it will get there after the gate opens and be processed.
>         Either way it gets processed and the client is none the wiser.
>
>             On Dec 14, 2016, at 1:33 PM, Gytis Trikleris
>             <gtrikler at redhat.com <mailto:gtrikler at redhat.com>> wrote:
>
>             In this particular test case both coordinator and
>             participants are on the same server. But they can also be
>             running on different servers. Participant just contacts
>             coordinator via URL provided wherever it is located.
>
>
>             On 14/12/2016 18:19, Brian Stansberry wrote:
>
>                 This can?t be done internally? Using an HTTP to
>                 communicate between aspects of the server seems yuck.
>
>                     On Dec 14, 2016, at 2:58 AM, Gytis Trikleris
>                     <gtrikler at redhat.com <mailto:gtrikler at redhat.com>>
>                     wrote:
>
>                     I need to load REST-AT participants from the crash
>                     recovery store and notify REST-AT coordinator (via
>                     REST API) of their URLs. This doesn't have to be
>                     done on the server start, but until it's done
>                     REST-AT coordinator recovery will be printing
>                     warnings because it won't be able to contact
>                     participants. So the sooner it's done the better,
>                     hence my question about a listener which could be
>                     invoked once the server completed boot-up.
>
>                     Gytis
>
>                     On 13/12/2016 23:45, Stuart Douglas wrote:
>
>                         Why do you need to make a rest call while
>                         startup is taking place?
>
>                         Stuart
>
>                         On Wed, Dec 14, 2016 at 9:22 AM, Gytis
>                         Trikleris <gtrikler at redhat.com
>                         <mailto:gtrikler at redhat.com>> wrote:
>                         Is there a way to make sure I'm making the
>                         service call not too early?
>
>                         Also, ControlledProcessStateService methods
>                         which are used in that
>                         commit are deprecated. That's why I wasn't
>                         sure if it's OK for me to use
>                         them.
>
>
>                         On 13/12/2016 22:34, Brian Stansberry wrote:
>
>                             That commit you linked shows the mechanism
>                             for getting a notification of process
>                             state changes (inject
>                             ControlledProcessStateService and register
>                             a property change listener.)
>
>                             But, that commit is opening up the
>                             listener when it gets the notification, so
>                             if you listen for the same notification
>                             and make a call it?s going to be racy.
>
>                                 On Dec 13, 2016, at 3:26 PM, Gytis
>                                 Trikleris <gtrikler at redhat.com
>                                 <mailto:gtrikler at redhat.com>> wrote:
>
>                                 Hello,
>
>                                 I'm wondering if there is a way to
>                                 register a listener which would be
>                                 invoked when server status has
>                                 changed. More specifically when
>                                 application server completed start-up.
>
>                                 The reason for that is that after [1]
>                                 commit was introduced our rest
>                                 transaction tests started to fail. The
>                                 cause seems to be rest service
>                                 call during the start of one of our
>                                 services. That call doesn't
>                                 necessarily have to be executed during
>                                 the service start. However, the
>                                 sooner it's done the better and if it
>                                 would be possible to register some
>                                 sort of callback to be invoked once
>                                 start-up was done, that would be great.
>
>                                 Thanks,
>
>                                 Gytis
>
>
>                                 [1]
>                                 https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>                                 <https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e>
>
>                                 _______________________________________________
>                                 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
>                         <mailto:wildfly-dev at lists.jboss.org>
>                         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>                         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161214/9c9d9cf1/attachment.html 

From brian.stansberry at redhat.com  Wed Dec 14 18:07:34 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 14 Dec 2016 17:07:34 -0600
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <91c35750-825b-9158-b520-e2d611dd936d@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
	<e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
	<CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
	<91c35750-825b-9158-b520-e2d611dd936d@redhat.com>
Message-ID: <51B1FB3A-C880-4EBC-8F47-CC24D3AFD262@redhat.com>

Don?t do it in the property change callback thread itself.

> On Dec 14, 2016, at 4:39 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
> 
> I agree, and my intention when starting this thread was to find the best place to move that call to. I'll try registering similar listener as in your commit. That should free-up a service boot-up thread.
> 
> Gytis
> 
> On 14/12/2016 23:21, Stuart Douglas wrote:
>> In that case you should probably move the rest call out of the service start, and have it processed by a separate thread.
>> 
>> Its probably not great having server start dependent on an external service being up anyway. 
>> 
>> Stuart
>> 
>> On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> Yes it does get processed. But because at the moment call is made from service's start method, the service isn't started until the request is processed. As a result Arquillian test fails because app server doesn't start fast enough.
>> 
>> 
>> 
>> On 14/12/2016 20:49, Brian Stansberry wrote:
>> OK. I should probably shut up and defer to Stuart anyway. :)
>> 
>> I say that because looking at his commit you linked, it looks like what it does is it starts queuing up requests during boot and then when it gets the ControlledProcessStateService RUNNING notification it opens the gate and the queued requests get handled (as do new ones of course.)
>> 
>> So that means you shouldn?t have a problematic race if you also use the ControlledProcessStateService RUNNING notification. Your request will either get there before the gate opens and be queued momentarily before being processed, or it will get there after the gate opens and be processed. Either way it gets processed and the client is none the wiser.
>> 
>> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> 
>> In this particular test case both coordinator and participants are on the same server. But they can also be running on different servers. Participant just contacts coordinator via URL provided wherever it is located.
>> 
>> 
>> On 14/12/2016 18:19, Brian Stansberry wrote:
>> This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.
>> 
>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> 
>> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
>> 
>> Gytis
>> 
>> On 13/12/2016 23:45, Stuart Douglas wrote:
>> Why do you need to make a rest call while startup is taking place?
>> 
>> Stuart
>> 
>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> Is there a way to make sure I'm making the service call not too early?
>> 
>> Also, ControlledProcessStateService methods which are used in that
>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>> them.
>> 
>> 
>> On 13/12/2016 22:34, Brian Stansberry wrote:
>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>> 
>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>> 
>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>> 
>> Hello,
>> 
>> I'm wondering if there is a way to register a listener which would be
>> invoked when server status has changed. More specifically when
>> application server completed start-up.
>> 
>> The reason for that is that after [1] commit was introduced our rest
>> transaction tests started to fail. The cause seems to be rest service
>> call during the start of one of our services. That call doesn't
>> necessarily have to be executed during the service start. However, the
>> sooner it's done the better and if it would be possible to register some
>> sort of callback to be invoked once start-up was done, that would be great.
>> 
>> Thanks,
>> 
>> Gytis
>> 
>> 
>> [1]
>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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





From bmcwhirt at redhat.com  Wed Dec 14 19:38:04 2016
From: bmcwhirt at redhat.com (Bob McWhirter)
Date: Thu, 15 Dec 2016 00:38:04 +0000
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
	<e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
	<CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
Message-ID: <CA+45JvFibSgbs01C8XMY=fQ14FKv-j3BLt=7v=kfbxD7mnBMfg@mail.gmail.com>

Service start should be quick and non-blocking or call async and run in a
different thread and signal completion when done. Generally speaking.


On Wed, Dec 14, 2016 at 5:30 PM Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> In that case you should probably move the rest call out of the service
> start, and have it processed by a separate thread.
>
> Its probably not great having server start dependent on an external
> service being up anyway.
>
> Stuart
>
> On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com>
> wrote:
>
> Yes it does get processed. But because at the moment call is made from
> service's start method, the service isn't started until the request is
> processed. As a result Arquillian test fails because app server doesn't
> start fast enough.
>
>
>
>
>
>
>
>
>
> On 14/12/2016 20:49, Brian Stansberry wrote:
>
>
>
>
> OK. I should probably shut up and defer to Stuart anyway. :)
>
>
>
>
>
> I say that because looking at his commit you linked, it looks like what it
> does is it starts queuing up requests during boot and then when it gets the
> ControlledProcessStateService RUNNING notification it opens the gate and
> the queued requests get handled (as do new ones of course.)
>
>
>
>
>
> So that means you shouldn?t have a problematic race if you also use the
> ControlledProcessStateService RUNNING notification. Your request will
> either get there before the gate opens and be queued momentarily before
> being processed, or it will get there after the gate opens and be
> processed. Either way it gets processed and the client is none the wiser.
>
>
>
>
>
>
>
> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>
>
>
>
>
> In this particular test case both coordinator and participants are on the
> same server. But they can also be running on different servers. Participant
> just contacts coordinator via URL provided wherever it is located.
>
>
>
>
>
>
>
>
> On 14/12/2016 18:19, Brian Stansberry wrote:
>
>
>
>
> This can?t be done internally? Using an HTTP to communicate between
> aspects of the server seems yuck.
>
>
>
>
>
>
>
> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>
>
>
>
>
> I need to load REST-AT participants from the crash recovery store and
> notify REST-AT coordinator (via REST API) of their URLs. This doesn't have
> to be done on the server start, but until it's done REST-AT coordinator
> recovery will be printing warnings because it won't be able to contact
> participants. So the sooner it's done the better, hence my question about a
> listener which could be invoked once the server completed boot-up.
>
>
>
>
>
> Gytis
>
>
>
>
>
> On 13/12/2016 23:45, Stuart Douglas wrote:
>
>
>
>
> Why do you need to make a rest call while startup is taking place?
>
>
>
>
>
> Stuart
>
>
>
>
>
> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com>
> wrote:
>
>
> Is there a way to make sure I'm making the service call not too early?
>
>
>
>
>
> Also, ControlledProcessStateService methods which are used in that
>
>
> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>
>
> them.
>
>
>
>
>
>
>
>
> On 13/12/2016 22:34, Brian Stansberry wrote:
>
>
>
>
> That commit you linked shows the mechanism for getting a notification of
> process state changes (inject ControlledProcessStateService and register a
> property change listener.)
>
>
>
>
>
> But, that commit is opening up the listener when it gets the notification,
> so if you listen for the same notification and make a call it?s going to be
> racy.
>
>
>
>
>
>
>
> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>
>
>
>
>
> Hello,
>
>
>
>
>
> I'm wondering if there is a way to register a listener which would be
>
>
> invoked when server status has changed. More specifically when
>
>
> application server completed start-up.
>
>
>
>
>
> The reason for that is that after [1] commit was introduced our rest
>
>
> transaction tests started to fail. The cause seems to be rest service
>
>
> call during the start of one of our services. That call doesn't
>
>
> necessarily have to be executed during the service start. However, the
>
>
> sooner it's done the better and if it would be possible to register some
>
>
> sort of callback to be invoked once start-up was done, that would be great.
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Gytis
>
>
>
>
>
>
>
>
> [1]
>
>
>
> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>
>
>
>
>
> _______________________________________________
>
>
> 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/20161215/1b0e30db/attachment-0001.html 

From gtrikler at redhat.com  Thu Dec 15 05:33:15 2016
From: gtrikler at redhat.com (Gytis Trikleris)
Date: Thu, 15 Dec 2016 11:33:15 +0100
Subject: [wildfly-dev] WildFly status listener
In-Reply-To: <51B1FB3A-C880-4EBC-8F47-CC24D3AFD262@redhat.com>
References: <e3f343f0-750e-f31c-c14a-ae19978e2bb0@redhat.com>
	<3DF34081-DDB5-4B59-BED4-0C15E099BC0D@redhat.com>
	<de527d44-d136-5020-a5b1-a35f675e2899@redhat.com>
	<CAAoo=c7k=dTLoQAofe_NqzTWUYbJxWNHT4mhxgSgvfdsnJjajg@mail.gmail.com>
	<932bb6de-a6ab-59c0-d498-aa9ea0996bb2@redhat.com>
	<D1DB7424-21DE-4FD8-8088-42C19A22EFCB@redhat.com>
	<abae0c94-9572-2479-92b0-cf4eb82490d4@redhat.com>
	<6F219DFA-2661-43E4-945D-0F524018A476@redhat.com>
	<e0fc3e9c-6357-84b3-8265-1da41636b457@redhat.com>
	<CAAoo=c6cMcj2cnTLRCnYfkRdq=4uoeq2wKmbxX6AF0QeaYoaDQ@mail.gmail.com>
	<91c35750-825b-9158-b520-e2d611dd936d@redhat.com>
	<51B1FB3A-C880-4EBC-8F47-CC24D3AFD262@redhat.com>
Message-ID: <037633ed-c3a1-0c95-b71e-d7f0632bde93@redhat.com>

Thanks for the explanations. I'll move the http call to the recovery 
module, so it will be executed in the recovery thread.

Gytis


On 15/12/2016 00:07, Brian Stansberry wrote:
> Don?t do it in the property change callback thread itself.
>
>> On Dec 14, 2016, at 4:39 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>
>> I agree, and my intention when starting this thread was to find the best place to move that call to. I'll try registering similar listener as in your commit. That should free-up a service boot-up thread.
>>
>> Gytis
>>
>> On 14/12/2016 23:21, Stuart Douglas wrote:
>>> In that case you should probably move the rest call out of the service start, and have it processed by a separate thread.
>>>
>>> Its probably not great having server start dependent on an external service being up anyway.
>>>
>>> Stuart
>>>
>>> On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>> Yes it does get processed. But because at the moment call is made from service's start method, the service isn't started until the request is processed. As a result Arquillian test fails because app server doesn't start fast enough.
>>>
>>>
>>>
>>> On 14/12/2016 20:49, Brian Stansberry wrote:
>>> OK. I should probably shut up and defer to Stuart anyway. :)
>>>
>>> I say that because looking at his commit you linked, it looks like what it does is it starts queuing up requests during boot and then when it gets the ControlledProcessStateService RUNNING notification it opens the gate and the queued requests get handled (as do new ones of course.)
>>>
>>> So that means you shouldn?t have a problematic race if you also use the ControlledProcessStateService RUNNING notification. Your request will either get there before the gate opens and be queued momentarily before being processed, or it will get there after the gate opens and be processed. Either way it gets processed and the client is none the wiser.
>>>
>>> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>
>>> In this particular test case both coordinator and participants are on the same server. But they can also be running on different servers. Participant just contacts coordinator via URL provided wherever it is located.
>>>
>>>
>>> On 14/12/2016 18:19, Brian Stansberry wrote:
>>> This can?t be done internally? Using an HTTP to communicate between aspects of the server seems yuck.
>>>
>>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>
>>> I need to load REST-AT participants from the crash recovery store and notify REST-AT coordinator (via REST API) of their URLs. This doesn't have to be done on the server start, but until it's done REST-AT coordinator recovery will be printing warnings because it won't be able to contact participants. So the sooner it's done the better, hence my question about a listener which could be invoked once the server completed boot-up.
>>>
>>> Gytis
>>>
>>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>> Why do you need to make a rest call while startup is taking place?
>>>
>>> Stuart
>>>
>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>> Is there a way to make sure I'm making the service call not too early?
>>>
>>> Also, ControlledProcessStateService methods which are used in that
>>> commit are deprecated. That's why I wasn't sure if it's OK for me to use
>>> them.
>>>
>>>
>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>> That commit you linked shows the mechanism for getting a notification of process state changes (inject ControlledProcessStateService and register a property change listener.)
>>>
>>> But, that commit is opening up the listener when it gets the notification, so if you listen for the same notification and make a call it?s going to be racy.
>>>
>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>
>>> Hello,
>>>
>>> I'm wondering if there is a way to register a listener which would be
>>> invoked when server status has changed. More specifically when
>>> application server completed start-up.
>>>
>>> The reason for that is that after [1] commit was introduced our rest
>>> transaction tests started to fail. The cause seems to be rest service
>>> call during the start of one of our services. That call doesn't
>>> necessarily have to be executed during the service start. However, the
>>> sooner it's done the better and if it would be possible to register some
>>> sort of callback to be invoked once start-up was done, that would be great.
>>>
>>> Thanks,
>>>
>>> Gytis
>>>
>>>
>>> [1]
>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From tomaz.cerar at gmail.com  Thu Dec 15 06:22:54 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 15 Dec 2016 12:22:54 +0100
Subject: [wildfly-dev] An integration test adding JBoss Module and
 running management commands?
In-Reply-To: <EDA148D7-7DE6-444C-89E3-3270AD1962B9@jboss.com>
References: <89bd23f7-e8da-3a43-d490-f85cdbe6b869@redhat.com>
	<EDA148D7-7DE6-444C-89E3-3270AD1962B9@jboss.com>
Message-ID: <CAMquZP5O7gvxa6w_-E_qKhVN4e0wkRvySmbjBuWQh1ei3=UZ8Q@mail.gmail.com>

There are many tests that do that.

for examples see ExtensionTestCase, WeldModuleDeploymentTestCase

and many others.

just look for string "module.xml" in whole testsuite...

--
tomaz

On Wed, Dec 14, 2016 at 5:50 PM, Kabir Khan <kabir.khan at jboss.com> wrote:

> For adding the module, look for usage of org.jboss.as.test.module.util.
> TestModule
> > On 14 Dec 2016, at 15:50, Peter Palaga <ppalaga at redhat.com> wrote:
> >
> > Hi *,
> >
> > I wonder if we already have an integration test that requires to add
> > some custom JBoss Module and to run some Management commands?
> >
> > I'd like to add an integration test for
> > https://issues.jboss.org/browse/WFLY-7412 . I was able to do everything
> > I need using various Maven plugins (most notably WF Plugin and some
> > resource copying) in this test project: https://github.com/ppalaga/
> WFLY-7412
> >
> > However, I am kinda hesitant to send my solution to WF code base,
> > because it looks too different from the usual Arquillian way of writing
> > itests.
> >
> > Therefore, I am asking if anybody could perhaps point me to an
> > Arquillian (or any other existing) test in WF code base that runs
> > management commands, installs custom JBoss modules, deploys a simple
> > test app and then sends some HTTP requests against the container?
> >
> > Thanks,
> >
> > Peter
> > _______________________________________________
> > 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/20161215/7af25012/attachment.html 

From ppalaga at redhat.com  Thu Dec 22 11:03:02 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 22 Dec 2016 17:03:02 +0100
Subject: [wildfly-dev] An integration test adding JBoss Module and
 running management commands?
In-Reply-To: <CAMquZP5O7gvxa6w_-E_qKhVN4e0wkRvySmbjBuWQh1ei3=UZ8Q@mail.gmail.com>
References: <89bd23f7-e8da-3a43-d490-f85cdbe6b869@redhat.com>
	<EDA148D7-7DE6-444C-89E3-3270AD1962B9@jboss.com>
	<CAMquZP5O7gvxa6w_-E_qKhVN4e0wkRvySmbjBuWQh1ei3=UZ8Q@mail.gmail.com>
Message-ID: <9968cbea-b0eb-d8bf-21dc-d6266e68c19b@redhat.com>

Thanks a lot, Kabir and Toma?! PR sent 
https://github.com/wildfly/wildfly/pull/9508 -- P

On 2016-12-15 12:22, Toma? Cerar wrote:
> There are many tests that do that.
>
> for examples see ExtensionTestCase, WeldModuleDeploymentTestCase
>
> and many others.
>
> just look for string "module.xml" in whole testsuite...
>
> --
> tomaz
>
> On Wed, Dec 14, 2016 at 5:50 PM, Kabir Khan <kabir.khan at jboss.com
> <mailto:kabir.khan at jboss.com>> wrote:
>
>     For adding the module, look for usage of
>     org.jboss.as.test.module.util.TestModule
>     > On 14 Dec 2016, at 15:50, Peter Palaga <ppalaga at redhat.com
>     <mailto:ppalaga at redhat.com>> wrote:
>     >
>     > Hi *,
>     >
>     > I wonder if we already have an integration test that requires to add
>     > some custom JBoss Module and to run some Management commands?
>     >
>     > I'd like to add an integration test for
>     > https://issues.jboss.org/browse/WFLY-7412
>     <https://issues.jboss.org/browse/WFLY-7412> . I was able to do
>     everything
>     > I need using various Maven plugins (most notably WF Plugin and some
>     > resource copying) in this test project:
>     https://github.com/ppalaga/WFLY-7412
>     <https://github.com/ppalaga/WFLY-7412>
>     >
>     > However, I am kinda hesitant to send my solution to WF code base,
>     > because it looks too different from the usual Arquillian way of
>     writing
>     > itests.
>     >
>     > Therefore, I am asking if anybody could perhaps point me to an
>     > Arquillian (or any other existing) test in WF code base that runs
>     > management commands, installs custom JBoss modules, deploys a simple
>     > test app and then sends some HTTP requests against the container?
>     >
>     > 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>
>
>
>     _______________________________________________
>     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>
>
>