From gunnar at hibernate.org  Tue Nov  1 05:29:52 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 1 Nov 2016 10:29:52 +0100
Subject: [wildfly-dev] Updating components in WildFly
In-Reply-To: <CADGJaX9kZqr-q=piOTda2b9tcu5=0wAzu3ggjSdqcMjv1tO1Cw@mail.gmail.com>
References: <CADGJaX9kZqr-q=piOTda2b9tcu5=0wAzu3ggjSdqcMjv1tO1Cw@mail.gmail.com>
Message-ID: <CADGJaX_zhzLDzXzkQiGvggqoYfxADUiVvp0giyBsFNtr0GQ3+Q@mail.gmail.com>

Hi,

I've sent a pull request which provides a Maven plug-in for patch-gen:
https://github.com/jbossas/patch-gen/pull/8. Tested it successfully by
using it to create a patch file for updating Hibernate Validator.

I hope a release - including deployment to Nexus - of this could be done
some time soon?

Thanks,

--Gunnar




2016-10-31 16:47 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:

> Hi,
>
> Users of the different Hibernate projects often wish to upgrade their
> WildFly installation to the latest releases of Hibernate ORM, Search or
> Validator.
>
> For that purpose we began to provide ZIP files containing the newer JARs
> and module.xml descriptors, to be unzipped into the server's module
> directory. We use separate slot names, so to not overwrite existing modules
> but just add newer versions next to them.
>
> But sometimes redefining the default slot actually is desirable. If an
> update for instance is just a bugfix release, it's sensible to push this to
> the main slot so users can benefit from it without having to explicitly
> specify a slot name, suppress any implicit default module and so on.
>
> But as I said we don't want to mess with any existing modules, so I've
> been looking into alternatives. One thing I found was to provide the
> updated modules in a separate layer, which then overrides the original
> modules from the "base" layer, without physically altering them. The user
> can go back to the original ones just by removing an entry in layers.conf.
>
> That works nicely, but then I also learned about the patch mechanism. So I
> wondered whether that should be the approach for us to follow, e.g. I also
> saw that Weld is providing patches for WF. Is this then the officially
> recommended way (TM) for upstream projects for shipping easy-to-use updates
> of their components for WF?
>
> One thing getting in the way of this is the lack of a Maven plug-in for
> the patch-gen tool. This makes patch creation quite unwieldy in an
> automated build process. Is there any chance for getting a Maven plug-in
> for patch-gen? If there is interest, I'd also be volunteering to provide
> it, it shouldn't take too long.
>
> Thanks for any hints,
>
> --Gunnar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161101/6aa88c9d/attachment-0001.html 

From br.roglusa at gmail.com  Wed Nov  2 18:37:54 2016
From: br.roglusa at gmail.com (=?UTF-8?Q?Rog=C3=A9rio_Luciano_Santos?=)
Date: Wed, 2 Nov 2016 20:37:54 -0200
Subject: [wildfly-dev] WildFly 10 as Service in RHEL7
Message-ID: <CAFCKAGLe1oB2NN0QOuAt7TzHk8wMy7Z4FgAkzCz54110pLiBsA@mail.gmail.com>

How start wildfly 10 as service in redhat linux 7 ?
In the folder ../bin does not has the folder init.d as wildfly 9.
I did not find the files : wildfly.conf and wildfly-init-redhat


tks
Rog?rio L Santos
Brazil - SP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161102/f9ccedc4/attachment.html 

From tomaz.cerar at gmail.com  Wed Nov  2 18:57:09 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 2 Nov 2016 23:57:09 +0100
Subject: [wildfly-dev] WildFly 10 as Service in RHEL7
In-Reply-To: <CAFCKAGLe1oB2NN0QOuAt7TzHk8wMy7Z4FgAkzCz54110pLiBsA@mail.gmail.com>
References: <CAFCKAGLe1oB2NN0QOuAt7TzHk8wMy7Z4FgAkzCz54110pLiBsA@mail.gmail.com>
Message-ID: <CAMquZP5nRmG73Q_ZrtLe0VOphUV60Yyv_WmqqUO6MoLynGbLaA@mail.gmail.com>

they are in docs/contrib/scripts directory.

On Wed, Nov 2, 2016 at 11:37 PM, Rog?rio Luciano Santos <
br.roglusa at gmail.com> wrote:

> How start wildfly 10 as service in redhat linux 7 ?
> In the folder ../bin does not has the folder init.d as wildfly 9.
> I did not find the files : wildfly.conf and wildfly-init-redhat
>
>
> tks
> Rog?rio L Santos
> Brazil - SP
>
> _______________________________________________
> 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/20161102/e71fe939/attachment.html 

From ppalaga at redhat.com  Thu Nov  3 15:06:16 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 3 Nov 2016 20:06:16 +0100
Subject: [wildfly-dev] WFLY/WFCORE PRs
In-Reply-To: <fdf0cdaf-ebf0-0072-0e75-016795fbbb7f@redhat.com>
References: <C71F6A7D-2CCE-457E-9BE1-794622335A53@jboss.com>
	<DCC3A64C-177B-49D1-B0DE-FBCF65BCD4F8@redhat.com>
	<66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com>
	<D4C4BB7C-C984-4F20-BFE4-E248BE5EA8BC@redhat.com>
	<09B834FA-2121-4AD9-8470-34D381C3B8B4@redhat.com>
	<fdf0cdaf-ebf0-0072-0e75-016795fbbb7f@redhat.com>
Message-ID: <0e247655-a459-65df-0d26-1e14cda3afc0@redhat.com>

Knowing that my Chrome extension for linking from GitHub to JBoss Jira 
and Bugzilla has found some audience here, just a notice that the script 
is getting improvements from time to time. I recently added an info to 
the README [2] how to get notified about updates and how to update. -- P

[1] 
https://github.com/ppalaga/jboss-jira-content-script#how-to-get-notified-about-updates

On 2016-09-16 14:53, Peter Palaga wrote:
> Hi Brian, nice to hear that, thanks! If anybody spots a missing Jira/BZ
> pattern, PRs are welcome. -- P
>
> On 2016-09-16 14:21, Brian Stansberry wrote:
>> Peter, I just want to say thanks again for this; it?s working well. I appreciate how it opens the link in a new tab. I mostly use this when I?m working with pull requests, and it?s nice not to have the PR tab change.
>>
>> For anyone on here who reviews pull requests, you should check out this browser extension.
>>
>>> On Sep 6, 2016, at 1:17 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>
>>> Thanks!
>>>
>>> The install process shown on https://developer.chrome.com/extensions/getstarted#unpacked didn?t work for Max?s but it did for yours. :)
>>>
>>> I suspect I could get Max?s to work if I stuck the js I have in its own dir and added a manifest.json that looks like yours. But instead I?ll try yours out now!
>>>
>>>> On Sep 2, 2016, at 3:47 PM, Peter Palaga <ppalaga at redhat.com> wrote:
>>>>
>>>> It is still possible to load a non-Web Store extension in Chrome. I am not 100% sure it works for the one from Max, it works for my [1] Jira linker for sure. -- P
>>>>
>>>> [1] https://github.com/ppalaga/jboss-jira-content-script#jboss-jira-content-script
>>>>
>>>> On 2016-09-01 15:37, Brian Stansberry wrote:
>>>>> I?ll try and be better about that. I used to count on Max Andersen's AutoLink browser extension (which was great!) to generate links from just the issue number text, but now Chrome has been updated to block extensions that aren?t from the Chrome Web Store. Grumble grumble.
>>>>>
>>>>>> On Sep 1, 2016, at 5:07 AM, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>>>
>>>>>> Please try to include a link to the Jira in the pull request when opening them. I want to be a good citizen and resolve them when merging, but it is a PITA to have to manually find the Jira issue in the absence of links.
>>>>>> _______________________________________________
>>>>>> 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
>


From brian.stansberry at redhat.com  Thu Nov  3 16:04:12 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 3 Nov 2016 15:04:12 -0500
Subject: [wildfly-dev] WFLY/WFCORE PRs
In-Reply-To: <0e247655-a459-65df-0d26-1e14cda3afc0@redhat.com>
References: <C71F6A7D-2CCE-457E-9BE1-794622335A53@jboss.com>
	<DCC3A64C-177B-49D1-B0DE-FBCF65BCD4F8@redhat.com>
	<66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com>
	<D4C4BB7C-C984-4F20-BFE4-E248BE5EA8BC@redhat.com>
	<09B834FA-2121-4AD9-8470-34D381C3B8B4@redhat.com>
	<fdf0cdaf-ebf0-0072-0e75-016795fbbb7f@redhat.com>
	<0e247655-a459-65df-0d26-1e14cda3afc0@redhat.com>
Message-ID: <17CD8690-F977-4D33-808A-36CE42816DBB@redhat.com>

I just updated. Thanks. :)

> On Nov 3, 2016, at 2:06 PM, Peter Palaga <ppalaga at redhat.com> wrote:
> 
> Knowing that my Chrome extension for linking from GitHub to JBoss Jira 
> and Bugzilla has found some audience here, just a notice that the script 
> is getting improvements from time to time. I recently added an info to 
> the README [2] how to get notified about updates and how to update. -- P
> 
> [1] 
> https://github.com/ppalaga/jboss-jira-content-script#how-to-get-notified-about-updates
> 
> On 2016-09-16 14:53, Peter Palaga wrote:
>> Hi Brian, nice to hear that, thanks! If anybody spots a missing Jira/BZ
>> pattern, PRs are welcome. -- P
>> 
>> On 2016-09-16 14:21, Brian Stansberry wrote:
>>> Peter, I just want to say thanks again for this; it?s working well. I appreciate how it opens the link in a new tab. I mostly use this when I?m working with pull requests, and it?s nice not to have the PR tab change.
>>> 
>>> For anyone on here who reviews pull requests, you should check out this browser extension.
>>> 
>>>> On Sep 6, 2016, at 1:17 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>> 
>>>> Thanks!
>>>> 
>>>> The install process shown on https://developer.chrome.com/extensions/getstarted#unpacked didn?t work for Max?s but it did for yours. :)
>>>> 
>>>> I suspect I could get Max?s to work if I stuck the js I have in its own dir and added a manifest.json that looks like yours. But instead I?ll try yours out now!
>>>> 
>>>>> On Sep 2, 2016, at 3:47 PM, Peter Palaga <ppalaga at redhat.com> wrote:
>>>>> 
>>>>> It is still possible to load a non-Web Store extension in Chrome. I am not 100% sure it works for the one from Max, it works for my [1] Jira linker for sure. -- P
>>>>> 
>>>>> [1] https://github.com/ppalaga/jboss-jira-content-script#jboss-jira-content-script
>>>>> 
>>>>> On 2016-09-01 15:37, Brian Stansberry wrote:
>>>>>> I?ll try and be better about that. I used to count on Max Andersen's AutoLink browser extension (which was great!) to generate links from just the issue number text, but now Chrome has been updated to block extensions that aren?t from the Chrome Web Store. Grumble grumble.
>>>>>> 
>>>>>>> On Sep 1, 2016, at 5:07 AM, Kabir Khan <kabir.khan at jboss.com> wrote:
>>>>>>> 
>>>>>>> Please try to include a link to the Jira in the pull request when opening them. I want to be a good citizen and resolve them when merging, but it is a PITA to have to manually find the Jira issue in the absence of links.
>>>>>>> _______________________________________________
>>>>>>> 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
>> 
> 
> _______________________________________________
> 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 mstefank at redhat.com  Fri Nov  4 11:09:53 2016
From: mstefank at redhat.com (Martin Stefanko)
Date: Fri, 4 Nov 2016 16:09:53 +0100
Subject: [wildfly-dev] allow-resource-service-restart=true
Message-ID: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>

Hi,

I am looking for help with the usage of the allow-resource-service-restart
header. For the following examples each attribute is a boolean with
"restart-required" set to "no-services".

When I run

/subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}

it works as expected, but

/subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}

for instance, puts the server into the reload-required state.

This is happening on several other places so I want to ask if it is a
desired behavior.


Martin Stefanko

Associate Software Engineer
JBoss Sustaining Engineering Team
Red Hat Czech s.r.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161104/1cffc92e/attachment.html 

From kabir.khan at jboss.com  Fri Nov  4 11:38:27 2016
From: kabir.khan at jboss.com (Kabir Khan)
Date: Fri, 4 Nov 2016 15:38:27 +0000
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
Message-ID: <5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>

Not all operations handle the allow-service-restart header
> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
> 
> 
> Hi,
> 
> I am looking for help with the usage of the allow-resource-service-restart header. For the following examples each attribute is a boolean with "restart-required" set to "no-services".
> 
> When I run
> 
> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
> 
> it works as expected, but
> 
> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
> 
> for instance, puts the server into the reload-required state.
> 
> This is happening on several other places so I want to ask if it is a desired behavior.
> 
> 
> Martin Stefanko
> 
> Associate Software Engineer
> JBoss Sustaining Engineering Team
> Red Hat Czech s.r.o.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From okotek at redhat.com  Mon Nov  7 02:20:58 2016
From: okotek at redhat.com (Ondrej Kotek)
Date: Mon, 7 Nov 2016 02:20:58 -0500 (EST)
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
Message-ID: <813098756.12425387.1478503258007.JavaMail.zimbra@redhat.com>

Is there any way how to recognize whether an operation handles the allow-service-restart header please? (Other way than trying it.)

 Ondra


----- Original Message -----
From: "Kabir Khan" <kabir.khan at jboss.com>
To: "Martin Stefanko" <mstefank at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Friday, November 4, 2016 4:38:27 PM
Subject: Re: [wildfly-dev] allow-resource-service-restart=true

Not all operations handle the allow-service-restart header
> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
> 
> 
> Hi,
> 
> I am looking for help with the usage of the allow-resource-service-restart header. For the following examples each attribute is a boolean with "restart-required" set to "no-services".
> 
> When I run
> 
> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
> 
> it works as expected, but
> 
> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
> 
> for instance, puts the server into the reload-required state.
> 
> This is happening on several other places so I want to ask if it is a desired behavior.
> 
> 
> Martin Stefanko
> 
> Associate Software Engineer
> JBoss Sustaining Engineering Team
> Red Hat Czech s.r.o.
> _______________________________________________
> 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 nathalie.keymeulen at agfa.com  Mon Nov  7 03:08:37 2016
From: nathalie.keymeulen at agfa.com (Nathalie Keymeulen)
Date: Mon, 7 Nov 2016 09:08:37 +0100
Subject: [wildfly-dev] How can I import data exported from hornetq into
	artemis
Message-ID: <OF28B1088F.41B1D8EA-ONC1258064.002C9B51-C1258064.002CBC27@agfa.com>

Hi,

I have exported jms data from hornetq 2.4.7 (using hornetq-tools).
How can I import this generated xml file into wildfly 10 artemis ?

Kind Regards,

Nathalie Keymeulen | Agfa HealthCare
Software Engineer | HE/Orbis Connectivity Core Team Ghent | IT BD, 
Enterprise BU
T  +32 3444 7644 | F  +32 3 444 8401 | M  +32 494 56 02 80

Moutstraat 100, B-9000 Ghent, Belgium
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161107/124bbaf8/attachment.html 

From jmesnil at redhat.com  Mon Nov  7 04:07:30 2016
From: jmesnil at redhat.com (Jeff Mesnil)
Date: Mon, 7 Nov 2016 10:07:30 +0100
Subject: [wildfly-dev] How can I import data exported from hornetq into
 artemis
In-Reply-To: <OF28B1088F.41B1D8EA-ONC1258064.002C9B51-C1258064.002CBC27@agfa.com>
References: <OF28B1088F.41B1D8EA-ONC1258064.002C9B51-C1258064.002CBC27@agfa.com>
Message-ID: <3581193F-6545-4CE9-A08B-F450C44AD73A@redhat.com>

Hi,

> On 7 Nov 2016, at 09:08, Nathalie Keymeulen <nathalie.keymeulen at agfa.com> wrote:
> 
> Hi, 
> 
> I have exported jms data from hornetq 2.4.7 (using hornetq-tools). 
> How can I import this generated xml file into wildfly 10 artemis ? 

This mailing list is for discussing future development of wildfly not users list.
You can use our forum for WildFly https://community.jboss.org/en/wildfly.

Having said that, what you need is to use the :import-journal operation on the messaging-activemq?s server resource[1] with the file path of the xml generated by HornetQ

[1] https://wildscribe.github.io/Wildfly/10.0.0.Final/subsystem/messaging-activemq/server/index.html

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/



From david.lloyd at redhat.com  Mon Nov  7 09:17:02 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 7 Nov 2016 08:17:02 -0600
Subject: [wildfly-dev] Converting things to Java 9
Message-ID: <d0edcbbe-a454-eb05-57a9-d3904f92427b@redhat.com>

I wrote a blog post about making multi-release JARs for projects using 
Maven which build on Java 8 or earlier but also require alternative 
implementations for things under Java 9.

The link is here: http://word-bits.flurg.com/multrelease-jars/
-- 
- DML

From brian.stansberry at redhat.com  Mon Nov  7 09:43:22 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 7 Nov 2016 08:43:22 -0600
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <813098756.12425387.1478503258007.JavaMail.zimbra@redhat.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<813098756.12425387.1478503258007.JavaMail.zimbra@redhat.com>
Message-ID: <C235145E-0CE1-4568-B7C3-86BBA5B80E47@redhat.com>

See ?restart-required? in the ?Description of an Operation? section of https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model

> On Nov 7, 2016, at 1:20 AM, Ondrej Kotek <okotek at redhat.com> wrote:
> 
> Is there any way how to recognize whether an operation handles the allow-service-restart header please? (Other way than trying it.)
> 
> Ondra
> 
> 
> ----- Original Message -----
> From: "Kabir Khan" <kabir.khan at jboss.com>
> To: "Martin Stefanko" <mstefank at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Friday, November 4, 2016 4:38:27 PM
> Subject: Re: [wildfly-dev] allow-resource-service-restart=true
> 
> Not all operations handle the allow-service-restart header
>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>> 
>> 
>> Hi,
>> 
>> I am looking for help with the usage of the allow-resource-service-restart header. For the following examples each attribute is a boolean with "restart-required" set to "no-services".
>> 
>> When I run
>> 
>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>> 
>> it works as expected, but
>> 
>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>> 
>> for instance, puts the server into the reload-required state.
>> 
>> This is happening on several other places so I want to ask if it is a desired behavior.
>> 
>> 
>> Martin Stefanko
>> 
>> Associate Software Engineer
>> JBoss Sustaining Engineering Team
>> Red Hat Czech s.r.o.
>> _______________________________________________
>> 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 okotek at redhat.com  Mon Nov  7 10:28:55 2016
From: okotek at redhat.com (Ondrej Kotek)
Date: Mon, 7 Nov 2016 10:28:55 -0500 (EST)
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <C235145E-0CE1-4568-B7C3-86BBA5B80E47@redhat.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<813098756.12425387.1478503258007.JavaMail.zimbra@redhat.com>
	<C235145E-0CE1-4568-B7C3-86BBA5B80E47@redhat.com>
Message-ID: <2114673830.12633409.1478532535437.JavaMail.zimbra@redhat.com>

Thanks a lot, Brian. I understand the referenced documentation as following:

In case an attribute has "restart-required" => "resource-services" descriptor, when I change/write the attribute using "allow-resource-service-restart" => true request header, then the handler for the operation (write attribute) HAVE TO go ahead and restart the runtime service. In case the handler do not restart the service, it is a bug.

Do I understand it well please?


----- Original Message -----
From: "Brian Stansberry" <brian.stansberry at redhat.com>
To: "Ondrej Kotek" <okotek at redhat.com>
Cc: "Kabir Khan" <kabir.khan at jboss.com>, wildfly-dev at lists.jboss.org
Sent: Monday, November 7, 2016 3:43:22 PM
Subject: Re: [wildfly-dev] allow-resource-service-restart=true

See ?restart-required? in the ?Description of an Operation? section of https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model

> On Nov 7, 2016, at 1:20 AM, Ondrej Kotek <okotek at redhat.com> wrote:
> 
> Is there any way how to recognize whether an operation handles the allow-service-restart header please? (Other way than trying it.)
> 
> Ondra
> 
> 
> ----- Original Message -----
> From: "Kabir Khan" <kabir.khan at jboss.com>
> To: "Martin Stefanko" <mstefank at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Friday, November 4, 2016 4:38:27 PM
> Subject: Re: [wildfly-dev] allow-resource-service-restart=true
> 
> Not all operations handle the allow-service-restart header
>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>> 
>> 
>> Hi,
>> 
>> I am looking for help with the usage of the allow-resource-service-restart header. For the following examples each attribute is a boolean with "restart-required" set to "no-services".
>> 
>> When I run
>> 
>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>> 
>> it works as expected, but
>> 
>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>> 
>> for instance, puts the server into the reload-required state.
>> 
>> This is happening on several other places so I want to ask if it is a desired behavior.
>> 
>> 
>> Martin Stefanko
>> 
>> Associate Software Engineer
>> JBoss Sustaining Engineering Team
>> Red Hat Czech s.r.o.
>> _______________________________________________
>> 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 brian.stansberry at redhat.com  Mon Nov  7 10:42:46 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 7 Nov 2016 09:42:46 -0600
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <2114673830.12633409.1478532535437.JavaMail.zimbra@redhat.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<813098756.12425387.1478503258007.JavaMail.zimbra@redhat.com>
	<C235145E-0CE1-4568-B7C3-86BBA5B80E47@redhat.com>
	<2114673830.12633409.1478532535437.JavaMail.zimbra@redhat.com>
Message-ID: <44EDC33B-6CE0-4113-9B99-9562F3D16F81@redhat.com>

Yes. The exception being when the behavior implemented in https://issues.jboss.org/browse/WFCORE-1106 takes precedence. But if you have a server that isn?t in reload required and then what you described happens, it?s a bug.

> On Nov 7, 2016, at 9:28 AM, Ondrej Kotek <okotek at redhat.com> wrote:
> 
> Thanks a lot, Brian. I understand the referenced documentation as following:
> 
> In case an attribute has "restart-required" => "resource-services" descriptor, when I change/write the attribute using "allow-resource-service-restart" => true request header, then the handler for the operation (write attribute) HAVE TO go ahead and restart the runtime service. In case the handler do not restart the service, it is a bug.
> 
> Do I understand it well please?
> 
> 
> ----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: "Ondrej Kotek" <okotek at redhat.com>
> Cc: "Kabir Khan" <kabir.khan at jboss.com>, wildfly-dev at lists.jboss.org
> Sent: Monday, November 7, 2016 3:43:22 PM
> Subject: Re: [wildfly-dev] allow-resource-service-restart=true
> 
> See ?restart-required? in the ?Description of an Operation? section of https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model
> 
>> On Nov 7, 2016, at 1:20 AM, Ondrej Kotek <okotek at redhat.com> wrote:
>> 
>> Is there any way how to recognize whether an operation handles the allow-service-restart header please? (Other way than trying it.)
>> 
>> Ondra
>> 
>> 
>> ----- Original Message -----
>> From: "Kabir Khan" <kabir.khan at jboss.com>
>> To: "Martin Stefanko" <mstefank at redhat.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Friday, November 4, 2016 4:38:27 PM
>> Subject: Re: [wildfly-dev] allow-resource-service-restart=true
>> 
>> Not all operations handle the allow-service-restart header
>>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I am looking for help with the usage of the allow-resource-service-restart header. For the following examples each attribute is a boolean with "restart-required" set to "no-services".
>>> 
>>> When I run
>>> 
>>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>>> 
>>> it works as expected, but
>>> 
>>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>>> 
>>> for instance, puts the server into the reload-required state.
>>> 
>>> This is happening on several other places so I want to ask if it is a desired behavior.
>>> 
>>> 
>>> Martin Stefanko
>>> 
>>> Associate Software Engineer
>>> JBoss Sustaining Engineering Team
>>> Red Hat Czech s.r.o.
>>> _______________________________________________
>>> 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
> 
> 
> 

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





From smarlow at redhat.com  Mon Nov  7 12:03:00 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 7 Nov 2016 12:03:00 -0500
Subject: [wildfly-dev] Making Jandex annotation index available to
 components
In-Reply-To: <CADGJaX8HtPHAQT3K=sZfR9ZpWwH558du5TwByQJ1ZwQWCxSUiw@mail.gmail.com>
References: <CADGJaX8HtPHAQT3K=sZfR9ZpWwH558du5TwByQJ1ZwQWCxSUiw@mail.gmail.com>
Message-ID: <e5fc7d78-0341-5e2b-92f3-40212b29c366@redhat.com>



On 10/27/2016 08:42 AM, Gunnar Morling wrote:
> Hi,
>
> ---
> TL,DR: Hibernate components would like to receive the Jandex index 
> during deployment. A new method IndexView#close() may help to address 
> concerns about long-living index view references
> ---
>
> Different projects from the Hibernate umbrella (e.g. ORM, Validator 
> and Search) rely heavily on meta-data given via annotations. In order 
> to speed up annotation retrieval, we are looking into using the Jandex 
> index created for deployments by the container.
>
> This would require subsystems like JipiJapa or the one for Bean 
> Validation to pass the IndexView for the deployment to the 
> bootstrapped component. The change itself should be easy, I hope. But 
> Scott expressed concerns about components keeping references to the 
> index after the deployment phase has succeeded. As indexes can be 
> large, this may potentially block a big chunk of memory for as long as 
> the deployment is running.
>
> Of course we can promise that Hibernate components wouldn't keep such 
> references ;) But if that's not enough, could this concern be 
> mitigated by adding a new method IndexView#close()?
>
> This method would free all resources of the index and would be called 
> by the container after the deployment has finished. Any operation on a 
> closed index view would throw an exception indicating that the view 
> has been closed. Then, even if a component accidentally kept a 
> reference to an IndexView, it wouldn't retain much memory (of course 
> the index view wouldn't be of much use to the component in that state).
>
> Would that be an acceptable way forward? If so, I could send a pull 
> request towards Jandex. In a next step WF would have to make use of 
> that new version and invoke close() on a deployment's index at a 
> suitable time during the deployment lifecycle and eventually pass the 
> index to ORM et al.

We have been talking about wanting to pass the "hibernate.jandex_index" 
into Hibernate ORM, from Jipijapa but haven't been able to yet since 
there are no safe guards to ensure the "hibernate.jandex_index" 
reference is cleared after application deployment completes.

If an IndexView could be closed, versus just be garbage collected when 
there are zero references, it would probably be closed by something 
higher up the (deployment) call stack in WildFly, than the JPA container 
(or Jipijapa integration code).

However, if there are references to the Jandex (partially) loaded class 
definitions, those probably also need to be cleared, for us to benefit 
from this idea.  Just clearing the top down IndexView reference is 
probably not enough to reduce memory usage.

>
> In a subsequent step we may consider to address use cases such as 
> dynamic reconfiguration which would require to access the index 
> *after* deployment time. One way for addressing this may be to allow 
> for passing in some kind of executor which would expect e.g. a Lambda 
> doing work on an IndexView passed in by the executor. That way 
> components could access the index at runtime, while not keeping a 
> reference to it themselves and thus allowing the container to manage 
> the index and e.g. close or re-open it upon execution. But I think 
> this could be done as a follow-up.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
>
> PS: As a side note, Hibernate Validator currently reads annotations 
> lazily at runtime (when first validating a specific bean type). When 
> using Jandex, we'd have to change this to eagerly build up all the 
> meta-data for the types listed in the index passed during bootstrap. A 
> bit of work, but as said we hope to gain a nice performance 
> improvement from it.
>
>
>
> _______________________________________________
> 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/20161107/cdcb0263/attachment-0001.html 

From steve at hibernate.org  Mon Nov  7 12:11:06 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 07 Nov 2016 17:11:06 +0000
Subject: [wildfly-dev] Making Jandex annotation index available to
	components
In-Reply-To: <e5fc7d78-0341-5e2b-92f3-40212b29c366@redhat.com>
References: <CADGJaX8HtPHAQT3K=sZfR9ZpWwH558du5TwByQJ1ZwQWCxSUiw@mail.gmail.com>
	<e5fc7d78-0341-5e2b-92f3-40212b29c366@redhat.com>
Message-ID: <CAFdSV9u3gOUPj30WczvrgXdy5ej+EFgD8pwYarW8JYt7iTDh4Q@mail.gmail.com>

ORM 6.0 introduces changes to how we handle bootstrap-only resource like
Jandex to make sure we release hard references to them after we are done
bootstrapping the SessionFactory.  However, any version prior to that (aka
all versions used in any WF releases) do currently hold hard references to
it as part of the SessionFactory.

So having WF close the Jandex Index (or otherwise release the resource it
holds) would be a useful change until WF pulls in 6.0 after it is released.


On Mon, Nov 7, 2016 at 11:03 AM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 10/27/2016 08:42 AM, Gunnar Morling wrote:
>
> Hi,
>
> ---
> TL,DR: Hibernate components would like to receive the Jandex index during
> deployment. A new method IndexView#close() may help to address concerns
> about long-living index view references
> ---
>
> Different projects from the Hibernate umbrella (e.g. ORM, Validator and
> Search) rely heavily on meta-data given via annotations. In order to speed
> up annotation retrieval, we are looking into using the Jandex index created
> for deployments by the container.
>
> This would require subsystems like JipiJapa or the one for Bean Validation
> to pass the IndexView for the deployment to the bootstrapped component. The
> change itself should be easy, I hope. But Scott expressed concerns about
> components keeping references to the index after the deployment phase has
> succeeded. As indexes can be large, this may potentially block a big chunk
> of memory for as long as the deployment is running.
>
> Of course we can promise that Hibernate components wouldn't keep such
> references ;) But if that's not enough, could this concern be mitigated by
> adding a new method IndexView#close()?
>
> This method would free all resources of the index and would be called by
> the container after the deployment has finished. Any operation on a closed
> index view would throw an exception indicating that the view has been
> closed. Then, even if a component accidentally kept a reference to an
> IndexView, it wouldn't retain much memory (of course the index view
> wouldn't be of much use to the component in that state).
>
> Would that be an acceptable way forward? If so, I could send a pull
> request towards Jandex. In a next step WF would have to make use of that
> new version and invoke close() on a deployment's index at a suitable time
> during the deployment lifecycle and eventually pass the index to ORM et al.
>
>
> We have been talking about wanting to pass the "hibernate.jandex_index"
> into Hibernate ORM, from Jipijapa but haven't been able to yet since there
> are no safe guards to ensure the "hibernate.jandex_index" reference is
> cleared after application deployment completes.
>
> If an IndexView could be closed, versus just be garbage collected when
> there are zero references, it would probably be closed by something higher
> up the (deployment) call stack in WildFly, than the JPA container (or
> Jipijapa integration code).
>
> However, if there are references to the Jandex (partially) loaded class
> definitions, those probably also need to be cleared, for us to benefit from
> this idea.  Just clearing the top down IndexView reference is probably not
> enough to reduce memory usage.
>
>
>
> In a subsequent step we may consider to address use cases such as dynamic
> reconfiguration which would require to access the index *after* deployment
> time. One way for addressing this may be to allow for passing in some kind
> of executor which would expect e.g. a Lambda doing work on an IndexView
> passed in by the executor. That way components could access the index at
> runtime, while not keeping a reference to it themselves and thus allowing
> the container to manage the index and e.g. close or re-open it upon
> execution. But I think this could be done as a follow-up.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
>
> PS: As a side note, Hibernate Validator currently reads annotations lazily
> at runtime (when first validating a specific bean type). When using Jandex,
> we'd have to change this to eagerly build up all the meta-data for the
> types listed in the index passed during bootstrap. A bit of work, but as
> said we hope to gain a nice performance improvement from it.
>
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161107/baacd1b4/attachment.html 

From smarlow at redhat.com  Mon Nov  7 21:16:00 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 7 Nov 2016 21:16:00 -0500
Subject: [wildfly-dev] Making Jandex annotation index available to
 components
In-Reply-To: <CADGJaX8HtPHAQT3K=sZfR9ZpWwH558du5TwByQJ1ZwQWCxSUiw@mail.gmail.com>
References: <CADGJaX8HtPHAQT3K=sZfR9ZpWwH558du5TwByQJ1ZwQWCxSUiw@mail.gmail.com>
Message-ID: <79e633b6-bc56-c91d-1542-c918c28407b9@redhat.com>



On 10/27/2016 08:42 AM, Gunnar Morling wrote:
> Hi,
>
> ---
> TL,DR: Hibernate components would like to receive the Jandex index 
> during deployment. A new method IndexView#close() may help to address 
> concerns about long-living index view references
> ---
>
> Different projects from the Hibernate umbrella (e.g. ORM, Validator 
> and Search) rely heavily on meta-data given via annotations. In order 
> to speed up annotation retrieval, we are looking into using the Jandex 
> index created for deployments by the container.
>
> This would require subsystems like JipiJapa or the one for Bean 
> Validation to pass the IndexView for the deployment to the 
> bootstrapped component. The change itself should be easy, I hope. But 
> Scott expressed concerns about components keeping references to the 
> index after the deployment phase has succeeded. As indexes can be 
> large, this may potentially block a big chunk of memory for as long as 
> the deployment is running.
>
> Of course we can promise that Hibernate components wouldn't keep such 
> references ;) But if that's not enough, could this concern be 
> mitigated by adding a new method IndexView#close()?
>
> This method would free all resources of the index and would be called 
> by the container after the deployment has finished. Any operation on a 
> closed index view would throw an exception indicating that the view 
> has been closed. Then, even if a component accidentally kept a 
> reference to an IndexView, it wouldn't retain much memory (of course 
> the index view wouldn't be of much use to the component in that state).
>
> Would that be an acceptable way forward? If so, I could send a pull 
> request towards Jandex. In a next step WF would have to make use of 
> that new version and invoke close() on a deployment's index at a 
> suitable time during the deployment lifecycle and eventually pass the 
> index to ORM et al.
>
> In a subsequent step we may consider to address use cases such as 
> dynamic reconfiguration which would require to access the index 
> *after* deployment time. One way for addressing this may be to allow 
> for passing in some kind of executor which would expect e.g. a Lambda 
> doing work on an IndexView passed in by the executor. That way 
> components could access the index at runtime, while not keeping a 
> reference to it themselves and thus allowing the container to manage 
> the index and e.g. close or re-open it upon execution. But I think 
> this could be done as a follow-up.

A related question might be if creating a Jandex Index after application 
deployment completes, could be backed by the application classloader 
defined classes and whether that would be memory space efficient enough 
for runtime use.

>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
>
> PS: As a side note, Hibernate Validator currently reads annotations 
> lazily at runtime (when first validating a specific bean type). When 
> using Jandex, we'd have to change this to eagerly build up all the 
> meta-data for the types listed in the index passed during bootstrap. A 
> bit of work, but as said we hope to gain a nice performance 
> improvement from it.
>
>
>
> _______________________________________________
> 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/20161107/0c60612e/attachment.html 

From rsvoboda at redhat.com  Tue Nov  8 07:00:58 2016
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Tue, 8 Nov 2016 07:00:58 -0500 (EST)
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
Message-ID: <1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>


> Not all operations handle the allow-service-restart header

Sure, atm it depends a bit on the underlying service.

@statistics-enabled
Shouldn't be the goal to enable & disable stats without reload or restart required at all ?
There are some people/customers which restart or reload their farm of servers only on planned days.
For example for WS subsystem we can enable and disable without reload required, allow-resource-service-restart is to me just helper to avoid full reload.

@Reduce reload-required in general
I think some long-term effort is needed, less reload-required is better for end-user experience.
This probably needs to be more RFE-ish.

Regards.
Rostislav

> > On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
> > 
> > 
> > Hi,
> > 
> > I am looking for help with the usage of the allow-resource-service-restart
> > header. For the following examples each attribute is a boolean with
> > "restart-required" set to "no-services".
> > 
> > When I run
> > 
> > /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
> > 
> > it works as expected, but
> > 
> > /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
> > 
> > for instance, puts the server into the reload-required state.
> > 
> > This is happening on several other places so I want to ask if it is a
> > desired behavior.
> > 
> > 
> > Martin Stefanko
> > 
> > Associate Software Engineer
> > JBoss Sustaining Engineering Team
> > Red Hat Czech s.r.o.
> > _______________________________________________
> > 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 Nov  8 07:10:30 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 8 Nov 2016 12:10:30 +0000
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>
Message-ID: <12716b80-3c96-9e5c-d350-69e7b8639e72@jboss.com>

A problem that you quickly run into however is that supporting the 
allow-resource-service-restart is that in a number of cases restarting a 
service will have the effect of restarting half of the application 
server anyway.

As an example if you restart any new security services the chances are 
high that you either trigger a restart of all management related 
services or all application related services.

So sometimes you may want to go one step further and support real time 
updates to the underlying services - however we don't really have a flag 
an administrator can use to say if real time updates should be applied. 
I would imaging some administrators benefit from being able to apply 
management model only changes and coordinate when they actually take effect.

Regards,
Darran Lofthouse.


On 08/11/16 12:00, Rostislav Svoboda wrote:
>
>> Not all operations handle the allow-service-restart header
>
> Sure, atm it depends a bit on the underlying service.
>
> @statistics-enabled
> Shouldn't be the goal to enable & disable stats without reload or restart required at all ?
> There are some people/customers which restart or reload their farm of servers only on planned days.
> For example for WS subsystem we can enable and disable without reload required, allow-resource-service-restart is to me just helper to avoid full reload.
>
> @Reduce reload-required in general
> I think some long-term effort is needed, less reload-required is better for end-user experience.
> This probably needs to be more RFE-ish.
>
> Regards.
> Rostislav
>
>>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> I am looking for help with the usage of the allow-resource-service-restart
>>> header. For the following examples each attribute is a boolean with
>>> "restart-required" set to "no-services".
>>>
>>> When I run
>>>
>>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>>>
>>> it works as expected, but
>>>
>>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>>>
>>> for instance, puts the server into the reload-required state.
>>>
>>> This is happening on several other places so I want to ask if it is a
>>> desired behavior.
>>>
>>>
>>> Martin Stefanko
>>>
>>> Associate Software Engineer
>>> JBoss Sustaining Engineering Team
>>> Red Hat Czech s.r.o.

From brian.stansberry at redhat.com  Tue Nov  8 08:44:18 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 8 Nov 2016 07:44:18 -0600
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>
Message-ID: <EE794E33-76CE-47E8-95F0-9237697E4989@redhat.com>


> On Nov 8, 2016, at 6:00 AM, Rostislav Svoboda <rsvoboda at redhat.com> wrote:
> 
>> 
>> Not all operations handle the allow-service-restart header
> 
> Sure, atm it depends a bit on the underlying service.
> 
> @statistics-enabled
> Shouldn't be the goal to enable & disable stats without reload or restart required at all ?

Yes, that should be the goal.

Whether it is feasible depends on the underlying library that is being integrated.

> There are some people/customers which restart or reload their farm of servers only on planned days.
> For example for WS subsystem we can enable and disable without reload required, allow-resource-service-restart is to me just helper to avoid full reload.

+10 to allow-resource-service-restart=true just being a helper for power users or special situations. It?s not something we should be pushing users to use.

It?s not widely supported for the reasons Darran mentioned in his response; it can result in app outages and naive users may not understand that.

I?ve gone back and forth over the years on whether I think it is bad that our allow-resource-service-restart support is so limited. Right now I think it?s a small bit bad, as power users might like more of it. But I don?t think it?s a big deal; we have plenty of other bigger concerns.

> 
> @Reduce reload-required in general
> I think some long-term effort is needed, less reload-required is better for end-user experience.
> This probably needs to be more RFE-ish.
> 

It would be a bunch of things, not some single one. Support for this is dependent on what the underlying library can provide, so it needs to be handled one case at a time.

> Regards.
> Rostislav
> 
>>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I am looking for help with the usage of the allow-resource-service-restart
>>> header. For the following examples each attribute is a boolean with
>>> "restart-required" set to "no-services".
>>> 
>>> When I run
>>> 
>>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>>> 
>>> it works as expected, but
>>> 
>>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>>> 
>>> for instance, puts the server into the reload-required state.
>>> 
>>> This is happening on several other places so I want to ask if it is a
>>> desired behavior.
>>> 
>>> 
>>> Martin Stefanko
>>> 
>>> Associate Software Engineer
>>> JBoss Sustaining Engineering Team
>>> Red Hat Czech s.r.o.
>>> _______________________________________________
>>> 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 brian.stansberry at redhat.com  Tue Nov  8 08:50:57 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 8 Nov 2016 07:50:57 -0600
Subject: [wildfly-dev] allow-resource-service-restart=true
In-Reply-To: <12716b80-3c96-9e5c-d350-69e7b8639e72@jboss.com>
References: <CAEEDSKVso4wYnuQUhnJjsoS6pz2LEGCD9XYze1FwBD7wUSBEBg@mail.gmail.com>
	<5A20D6F9-30E1-4EC1-9DAA-B14042886856@jboss.com>
	<1583348797.214764.1478606458023.JavaMail.zimbra@redhat.com>
	<12716b80-3c96-9e5c-d350-69e7b8639e72@jboss.com>
Message-ID: <1B71277B-8981-4937-B505-68C8F2FFDE9D@redhat.com>


> On Nov 8, 2016, at 6:10 AM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
> A problem that you quickly run into however is that supporting the 
> allow-resource-service-restart is that in a number of cases restarting a 
> service will have the effect of restarting half of the application 
> server anyway.
> 
> As an example if you restart any new security services the chances are 
> high that you either trigger a restart of all management related 
> services or all application related services.
> 
> So sometimes you may want to go one step further and support real time 
> updates to the underlying services - however we don't really have a flag 
> an administrator can use to say if real time updates should be applied. 
> I would imaging some administrators benefit from being able to apply 
> management model only changes and coordinate when they actually take effect.
> 

This concern I think would be addressed via a completely separate feature. Get your own snapshot of the config that is not tied to the runtime at all, manipulate it, and publish it when ready.

I also think we are more and more moving to a world where the config is set up offline.

That said, when it comes to reducing reload-required and making more things immediately effective, priority should be given to things where the use case of the admin wanting a live update is more clear. Things related to diagnostics being a good example.

> Regards,
> Darran Lofthouse.
> 
> 
> On 08/11/16 12:00, Rostislav Svoboda wrote:
>> 
>>> Not all operations handle the allow-service-restart header
>> 
>> Sure, atm it depends a bit on the underlying service.
>> 
>> @statistics-enabled
>> Shouldn't be the goal to enable & disable stats without reload or restart required at all ?
>> There are some people/customers which restart or reload their farm of servers only on planned days.
>> For example for WS subsystem we can enable and disable without reload required, allow-resource-service-restart is to me just helper to avoid full reload.
>> 
>> @Reduce reload-required in general
>> I think some long-term effort is needed, less reload-required is better for end-user experience.
>> This probably needs to be more RFE-ish.
>> 
>> Regards.
>> Rostislav
>> 
>>>> On 4 Nov 2016, at 15:09, Martin Stefanko <mstefank at redhat.com> wrote:
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> I am looking for help with the usage of the allow-resource-service-restart
>>>> header. For the following examples each attribute is a boolean with
>>>> "restart-required" set to "no-services".
>>>> 
>>>> When I run
>>>> 
>>>> /subsystem=jmx:write-attribute(name=non-core-mbean-sensitivity,value=true){allow-resource-service-restart=true}
>>>> 
>>>> it works as expected, but
>>>> 
>>>> /subsystem=undertow:write-attribute(name=statistics-enabled,value=true){allow-resource-service-restart=true}
>>>> 
>>>> for instance, puts the server into the reload-required state.
>>>> 
>>>> This is happening on several other places so I want to ask if it is a
>>>> desired behavior.
>>>> 
>>>> 
>>>> Martin Stefanko
>>>> 
>>>> Associate Software Engineer
>>>> JBoss Sustaining Engineering Team
>>>> Red Hat Czech s.r.o.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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





From rory.odonnell at oracle.com  Mon Nov 14 07:32:17 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 14 Nov 2016 12:32:17 +0000
Subject: [wildfly-dev] JDK 9 & JDK 9 with Project Jigsaw b144 are available
	on java.net
Message-ID: <997a2b38-af73-4f24-93a9-f0a6b93fc467@oracle.com>


Hi Jason/Tomaz,

Early Access b144 <https://jdk9.java.net/jigsaw/> (#5709) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here. 
<http://www.java.net/download/java/jigsaw/archive/144/binaries/jdk-9+144.html>

Early Access b144 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/java/jdk9/changes/jdk-9+144.html>.

There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :

  * JDK-8156149 : Blurry rendering on Windows 7 at 125% screen setting
  * JDK-8167431 : tools javac takes too long time to resolve interface
    dependency
  * JDK-8062810 : infrastructure Examine src.zip in JDK image and decide
    if source classes should be organized by module

*Proposal* - latest update

  *    b142 of JDK 9 with project Jigsaw has the initial implementation
    of open modules and open packages as detailed in the recent proposal
    for #ReflectiveAccessToNonExportedTypes [1]

*Tool*

     Adapted from JEP 277 [2]

  * A static analysis tool jdeprscan has been provided that scans a jar
    file (or some other aggregation of class files) for uses of
    deprecated API elements.

*Schedule*

  * The proposed JDK 9 schedule has been adopted and posted on the Open
    JDK 9 Project Page [3]


Rgds,Rory

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
[2] http://openjdk.java.net/jeps/277
[3] http://openjdk.java.net/projects/jdk9/

-- 
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/20161114/a615ee97/attachment.html 

From darran.lofthouse at jboss.com  Tue Nov 15 05:58:36 2016
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 15 Nov 2016 10:58:36 +0000
Subject: [wildfly-dev] Anyone using openjdk version "1.8.0_111" and building
	WildFly Core?
Message-ID: <d2f8a33f-32e1-1031-b2ec-5b8e913e54ca@jboss.com>

Is anyone using the following OpenJDK version and building WildFly Core?

   openjdk version "1.8.0_111"
   OpenJDK Runtime Environment (build 1.8.0_111-b16)
   OpenJDK 64-Bit Server VM (build 25.111-b16, mixed mode)

When I use this version to build core with -DallTests occasionally I am 
getting weird NullPointerExceptions that suggest a JVM issue.

Just wanted to check if anyone else has seen anything similar.

Regards,
Darran Lofthouse.


From jperkins at redhat.com  Tue Nov 15 12:50:52 2016
From: jperkins at redhat.com (James Perkins)
Date: Tue, 15 Nov 2016 09:50:52 -0800
Subject: [wildfly-dev] Anyone using openjdk version "1.8.0_111" and
 building WildFly Core?
In-Reply-To: <d2f8a33f-32e1-1031-b2ec-5b8e913e54ca@jboss.com>
References: <d2f8a33f-32e1-1031-b2ec-5b8e913e54ca@jboss.com>
Message-ID: <CADGwLphr_BuNNB6=GEX8PHGLEEj4zD1Y6Pt8a-m_uJZWxnqV6g@mail.gmail.com>

I've not seen any issues with it. I don't always run the full test suite
locally though. I did a run just now though and it was fine.

On Tue, Nov 15, 2016 at 2:58 AM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> Is anyone using the following OpenJDK version and building WildFly Core?
>
>    openjdk version "1.8.0_111"
>    OpenJDK Runtime Environment (build 1.8.0_111-b16)
>    OpenJDK 64-Bit Server VM (build 25.111-b16, mixed mode)
>
> When I use this version to build core with -DallTests occasionally I am
> getting weird NullPointerExceptions that suggest a JVM issue.
>
> Just wanted to check if anyone else has seen anything similar.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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/20161115/8c2c7833/attachment-0001.html 

From ropalka at redhat.com  Wed Nov 16 02:31:28 2016
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 16 Nov 2016 08:31:28 +0100
Subject: [wildfly-dev] Anyone using openjdk version "1.8.0_111" and
 building WildFly Core?
In-Reply-To: <d2f8a33f-32e1-1031-b2ec-5b8e913e54ca@jboss.com>
References: <d2f8a33f-32e1-1031-b2ec-5b8e913e54ca@jboss.com>
Message-ID: <8edad2fa-fded-9ed4-1ff3-eca1480728da@redhat.com>

Hi Darran,

I'm using it and I'm running whole WildFly-Core test suite on it at 
least 2 times a week.

I didn't notice any such failure indicating JVM bug.

Not saying there isn't a bug. Maybe it's hardware dependent?

Rio


On 11/15/2016 11:58 AM, Darran Lofthouse wrote:
> Is anyone using the following OpenJDK version and building WildFly Core?
>
>     openjdk version "1.8.0_111"
>     OpenJDK Runtime Environment (build 1.8.0_111-b16)
>     OpenJDK 64-Bit Server VM (build 25.111-b16, mixed mode)
>
> When I use this version to build core with -DallTests occasionally I am
> getting weird NullPointerExceptions that suggest a JVM issue.
>
> Just wanted to check if anyone else has seen anything similar.
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka at redhat.com


From david.lloyd at redhat.com  Thu Nov 17 09:47:46 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 17 Nov 2016 08:47:46 -0600
Subject: [wildfly-dev] A note about pull requests and reviews
Message-ID: <cce35ca2-29e6-8221-17eb-a42c13b6d81f@redhat.com>

A quick note about pull requests, particularly those with multiple 
commits - not just on WildFly but on *all* projects.

In order to efficiently review a pull request, especially a complex one, 
it *must* be possible to review it one commit at a time.  This means 
that if there's a review item on your pull request for a mistake or 
problem, don't just add a commit to the PR to fix it.  Rather, please 
amend or remove the faulty commit completely, otherwise some other 
reviewer who is looking one commit at a time is just going to waste time 
reporting the same problem only to have to go back and remove it once 
the later commit found.

Remember: PR *submitters* have a great deal more processing power than 
PR *reviewers*.

Thanks!
-- 
- DML

From david.lloyd at redhat.com  Thu Nov 17 09:53:36 2016
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 17 Nov 2016 08:53:36 -0600
Subject: [wildfly-dev] A note about pull requests and reviews
In-Reply-To: <cce35ca2-29e6-8221-17eb-a42c13b6d81f@redhat.com>
References: <cce35ca2-29e6-8221-17eb-a42c13b6d81f@redhat.com>
Message-ID: <c532098d-e3dd-06ac-bfe1-890d5932ed0e@redhat.com>

On 11/17/2016 08:47 AM, David M. Lloyd wrote:
> A quick note about pull requests, particularly those with multiple
> commits - not just on WildFly but on *all* projects.
>
> In order to efficiently review a pull request, especially a complex one,
> it *must* be possible to review it one commit at a time.  This means
> that if there's a review item on your pull request for a mistake or
> problem, don't just add a commit to the PR to fix it.  Rather, please
> amend or remove the faulty commit completely, otherwise some other
> reviewer who is looking one commit at a time is just going to waste time
> reporting the same problem only to have to go back and remove it once
> the later commit found.
>
> Remember: PR *submitters* have a great deal more processing power than
> PR *reviewers*.

And in addition - very large sweeping changes are best broken down into 
multiple commits whenever possible for this reason!
-- 
- DML

From brian.stansberry at redhat.com  Thu Nov 17 09:56:31 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 17 Nov 2016 08:56:31 -0600
Subject: [wildfly-dev] A note about pull requests and reviews
In-Reply-To: <cce35ca2-29e6-8221-17eb-a42c13b6d81f@redhat.com>
References: <cce35ca2-29e6-8221-17eb-a42c13b6d81f@redhat.com>
Message-ID: <3AE3E06E-A867-4D8B-A3A9-86814ED7F4C4@redhat.com>

+1. Fixing problems in the original commit also makes maintenance easier. Five years from now someone you may never meet is going to want to understand your change and it?s more likely they?ll get it right if incorrect bits in the first attempt are invisible.

> On Nov 17, 2016, at 8:47 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> A quick note about pull requests, particularly those with multiple 
> commits - not just on WildFly but on *all* projects.
> 
> In order to efficiently review a pull request, especially a complex one, 
> it *must* be possible to review it one commit at a time.  This means 
> that if there's a review item on your pull request for a mistake or 
> problem, don't just add a commit to the PR to fix it.  Rather, please 
> amend or remove the faulty commit completely, otherwise some other 
> reviewer who is looking one commit at a time is just going to waste time 
> reporting the same problem only to have to go back and remove it once 
> the later commit found.
> 
> Remember: PR *submitters* have a great deal more processing power than 
> PR *reviewers*.
> 
> Thanks!
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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





From Dominic.Dangerfield at engilitycorp.com  Fri Nov 18 09:26:32 2016
From: Dominic.Dangerfield at engilitycorp.com (Dominic.Dangerfield at engilitycorp.com)
Date: Fri, 18 Nov 2016 14:26:32 +0000
Subject: [wildfly-dev] Email List
Message-ID: <DE543DAA02528746A5DB9DADB2DAB5CAC4296114@DAG21.EGL.ENGILITYCORP.COM>

Hello, I'd like to post to the mailing list. My email is Dominic.dangerfield at engilitycorp.com<mailto:Dominic.dangerfield at engilitycorp.com>


Thanks
Dominic Dangerfield

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

From Dominic.Dangerfield at engilitycorp.com  Fri Nov 18 12:03:34 2016
From: Dominic.Dangerfield at engilitycorp.com (Dominic.Dangerfield at engilitycorp.com)
Date: Fri, 18 Nov 2016 17:03:34 +0000
Subject: [wildfly-dev] Wildfly Service Doesn't Stop Unless Uninstalled
In-Reply-To: <DE543DAA02528746A5DB9DADB2DAB5CAC4296155@DAG21.EGL.ENGILITYCORP.COM>
References: <DE543DAA02528746A5DB9DADB2DAB5CAC4296155@DAG21.EGL.ENGILITYCORP.COM>
Message-ID: <DE543DAA02528746A5DB9DADB2DAB5CAC429619F@DAG21.EGL.ENGILITYCORP.COM>

Currently, I'm trying to use Wildfly but after installing the service, I'm unable to stop it. The only way to stop it is to uninstall it by deleting the Java process and using command prompt to delete the service. This may be stemming from the fact that the Java process is only shown under all users rather than my account even though my username is assigned to it. Reviewing the batch files, I'm unable to find where to fix it.

Has anyone else come into any similar issues?

Thanks!
Dominic Dangerfield

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

From lgao at redhat.com  Tue Nov 22 03:51:18 2016
From: lgao at redhat.com (Lin Gao)
Date: Tue, 22 Nov 2016 03:51:18 -0500 (EST)
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
Message-ID: <1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>

Hi,

  Each management resource has an operation named 'query()' to filter resources according to the condition passed by 'selector' and 'where' parameters, however it does not work for complex attributes.

  2 example of complex attributes:

     - 'query()' operation cannot find which 'possible-capabilities' provides the capability with name 'org.wildfly.data-source'
     - It cannot find which 'rest-resource-paths' provides the REST endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment either.

  Especially for the second case in above examples, it will be helpful for users when doing troubleshooting in case of large deployment.

  Actually, it does not limit to the complex attributes, it would be good to be able to filter resources by condition specified by attribute value of nested child resources(not only by the first level of child resource).

  WDYT?

Best Regards

--
Lin Gao
Software Engineer
JBoss by Red Hat

From jperkins at redhat.com  Tue Nov 22 17:11:21 2016
From: jperkins at redhat.com (James Perkins)
Date: Tue, 22 Nov 2016 14:11:21 -0800
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
Message-ID: <CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>

The second case worked for me without an issue.
[standalone at localhost:9990 /]
/deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"])
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("deployment" => "batch-chunk.war"),
            ("subsystem" => "jaxrs"),
            ("rest-resource" =>
"org.jboss.example.batch.rest.BatchResource")
        ],
        "outcome" => "success",
        "result" => {"rest-resource-paths" => [
            {
                "resource-path" => "batch/jobs",
                "consumes" => undefined,
                "produces" => ["application/json"],
                "java-method" => "javax.ws.rs.core.Response
org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
                "resource-methods" => ["GET /batch-chunk/rest/batch/jobs"]
            },
            {
                "resource-path" => "batch/jobs/{status}",
                "consumes" => undefined,
                "produces" => ["application/json"],
                "java-method" => "javax.ws.rs.core.Response
org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam
java.lang.String status)",
                "resource-methods" => ["GET
/batch-chunk/rest/batch/jobs/{status}"]
            }
        ]}
    }]
}

The read-resource operation really does the same thing though in this case.

On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <lgao at redhat.com> wrote:

> Hi,
>
>   Each management resource has an operation named 'query()' to filter
> resources according to the condition passed by 'selector' and 'where'
> parameters, however it does not work for complex attributes.
>
>   2 example of complex attributes:
>
>      - 'query()' operation cannot find which 'possible-capabilities'
> provides the capability with name 'org.wildfly.data-source'
>      - It cannot find which 'rest-resource-paths' provides the REST
> endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment
> either.
>
>   Especially for the second case in above examples, it will be helpful for
> users when doing troubleshooting in case of large deployment.
>
>   Actually, it does not limit to the complex attributes, it would be good
> to be able to filter resources by condition specified by attribute value of
> nested child resources(not only by the first level of child resource).
>
>   WDYT?
>
> Best Regards
>
> --
> Lin Gao
> Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



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

From brian.stansberry at redhat.com  Tue Nov 22 18:50:44 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 22 Nov 2016 17:50:44 -0600
Subject: [wildfly-dev] Fixing handling of 'required' attributes with
	'alternatives'
In-Reply-To: <BE2CF7D1-273B-45DC-B3B0-2E38ACEE480D@redhat.com>
References: <FCF0DEA4-2F82-4656-8135-56F088ACD7CF@redhat.com>
	<CAPZNLwxEdV-rKPJBoc61kZ5XmomzZaOOQvd58t6nt-z18pY1TQ@mail.gmail.com>
	<CCC71DA0-82A7-4DB0-A632-13249564F7DD@redhat.com>
	<BE2CF7D1-273B-45DC-B3B0-2E38ACEE480D@redhat.com>
Message-ID: <DE1EB466-F348-49B5-9801-945073C5A7E1@redhat.com>

Hi Harald,

This PR is merged so this will be there once this week?s core release is merged into full (probably by Monday).

> On Sep 7, 2016, at 3:59 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> PR for this: https://github.com/wildfly/wildfly-core/pull/1781
> 
>> On Sep 6, 2016, at 1:56 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>>> 
>>> On Sep 6, 2016, at 11:58 AM, Harald Pehl <hpehl at redhat.com> wrote:
>>> 
>>> Thanks Brian for bringing this up. Everything which makes the metadata more consistent helps management client such as HAL. And as more and more forms are based on MBUI (generated based on the r-r-d metadata) this is even more important.
>>> 
>>> Right now we already have some logic behind the 'nillable' and 'alternatives' attributes to decide whether an attribute is required or not:
>>> 
>>> boolean required = attributeDescription.hasDefined("nillable") && !attributeDescription.get("nillable").asBoolean();
>>> if (attributeDescription.hasDefined("alternatives") && !attributeDescription.get("alternatives").asList().isEmpty()) {
>>>   required = false;
>>> }
>>> 
>> 
>> Ah, good. So my proposed change to how nillable is calculated shouldn?t change the final result you get above for your required variable. :) So once I do what I propose on the server side you can adapt to it when convenient.
>> 
>>> In HAL we use attribute descriptions to add new resources and to modify existing resources. For the former we rely on the 'request-properties' node of the add operation description. The latter uses the 'attributes' node of the r-r-d op. If we want to make changes, it's important to be consistent and apply them to both nodes. Right now these two nodes already have slightly different attributes: The 'request-properties' already contain a 'required' attribute whereas the 'attributes' don't. 
>> 
>> Yes, this inconsistency is part of the overall task of WFCORE-1556. The actual metadata we generate doesn?t comply with the spec in [a] and [b] and then the spec itself is inconsistent between those two sections in how it deals with ?required? vs ?nillable?. And there?s no reason for that.
>> 
>> [a] https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-DescriptionofanAttribute
>> [b] https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-DescriptionofanOperationParameterorReturnValue
>> 
>>> 
>>> The proposal makes sense to me and the impact on HAL should be minimal. Some questions I have:
>>> 
>>> 1. Will the metadata contain both 'nillable' and 'required'? With 'required' being the leading attribute and 'nillable' being deprecated but still there for backwards compability?
>>> 
>> 
>> It will contain both. I wouldn?t characterize either as leading or deprecated. Rather they have different functions:
>> 
>> required ? indicates the attribute/parameter represents something that must be configured in some way. But configuring one of the ?alternatives? suffices.
>> nillable ? indicates that attribute/parameter may have an undefined value for some reason
>> 
>> So nillable is useful to a client simply wanting to know whether it needs to deal with ?undefined?. A more sophisticated client would use ?required? plus ?alternatives?.
>> 
>>> 2. Will your proposal also cover the 'request-properties' for the add operation?
>>> 
>> 
>> Yes, they will be made consistent, with all attribute and parameter descriptions exposing the same metadata fields with the same conceptual meaning.
>> 
>> In terms of the server side implementation, for almost all add operations, the same AttributeDefinition instance is used for generating both the attribute description and the add parameter description. And for all parameter descriptions we use the same AttributeDefinition classes that we use for resource attributes, so the behavior we put in the AD class will apply to both.
>> 
>>> 
>>> On Tue, Sep 6, 2016 at 3:10 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>> tl;dr;
>>> 
>>> It?s not an uncommon thing to have a management attribute A that is required; i.e. must be set, but also has an alternative attribute B, where setting B satisfies the requirement for A, making an undefined value for A legal. We?re not handling that correctly and I want to fix it.[1] But fixing it will require some coordination with the HAL console.
>>> 
>>> Right now the way AttributeDefinition building works it?s not practical to declare that an attribute is required but only if no alternative is set. So instead attributes are declared as if they aren?t really required. This leads to less than helpful input validation, e.g. [2] and [3], since the attribute definition is imprecise.
>>> 
>>> The change I?d like to make will alter the read-resource-description output for 4 attributes, changing the value of the ?nillable? description from ?false? to ?true? so I want to coordinate that with the console team.
>>> 
>>> Long version
>>> 
>>> Harald and Claudio you guys are the main audience here. :)
>>> 
>>> For even longer version see description and comments on [1].
>>> 
>>> In a nutshell, if devs set the ?allowNull? property on an AttributeDefinition to ?true?, the r-r-d output for the attribute has ?nillable? => true. But there is no way to say ?allowNull but only if an alternative is set.? So people are setting ?allowNull? to true even if the attribute should be set in the absence of alternatives. And HAL has no metadata available to it to tell users they *must* set one of the alternatives. So I want to:
>>> 
>>> 1) Add a setRequired(boolean) method to the AD builders where the fact that it means ?must be defined if no alternative is defined? is explicitly declared
>>> 2) @Deprecate setAllowNull and point to setRequired
>>> 3) Clarify the meaning of setAllowNull(true) as being the same as setRequired(false)
>>> 4) Change the builder ?allowNull? constructor param name to ?optional? and document its meaning as ?allowing undefined values even in the absence of defined alternatives?.  I could call the param ?notRequired? which is clearer in meaning but odd.
>>> 
>>> Then I will add a new ?required? metadata field to the r-r-d output and change the impl of the existing ?nillable? metadata to a logical ?!required || (alternatives != null && alternatives.length > 0)?
>>> 
>>> This will result in a change in the ?nillable? value for 4 attributes in the WildFly model from ?false? to ?true':
>>> 
>>> /subsystem=transactions PROCESS_ID_SOCKET_BINDING and PROCESS_ID_UUID
>>> /core-service=management/security-realm=*/authenticaton=ldap USERNAME_FILTER and ADVANCED_FILTER
>>> 
>>> The latter two are not exposed in the console so the issue really is the two transaction attributes.
>>> 
>>> I haven?t checked other subsystems in things like Teiid or JDG, but if there are only 4 in all of WildFly I doubt there are many.
>>> 
>>> Also, if people start using the new behavior to correct problems like [2] and [3] people may expect the console to understand and reflect the concept of ?required but only if there is no alternative?.
>>> 
>>> [1] https://issues.jboss.org/browse/WFCORE-1556
>>> [2] https://issues.jboss.org/browse/WFLY-6608
>>> [3] https://issues.jboss.org/browse/WFLY-6607
>>> 
>>> --
>>> 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
>>> 
>>> 
>>> 
>>> -- 
>>> ---
>>> Harald Pehl
>>> JBoss by Red Hat
>>> http://hpehl.info
>> 
>> -- 
>> 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 lgao at redhat.com  Tue Nov 22 20:39:21 2016
From: lgao at redhat.com (Lin Gao)
Date: Tue, 22 Nov 2016 20:39:21 -0500 (EST)
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
	<CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
Message-ID: <191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "James Perkins" <jperkins at redhat.com>
> To: "Lin Gao" <lgao at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Wednesday, November 23, 2016 6:11:21 AM
> Subject: Re: [wildfly-dev] Improve query() operation for complex attributes?
> 
> The second case worked for me without an issue.
> [standalone at localhost:9990 /]
> /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"])
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("deployment" => "batch-chunk.war"),
>             ("subsystem" => "jaxrs"),
>             ("rest-resource" =>
> "org.jboss.example.batch.rest.BatchResource")
>         ],
>         "outcome" => "success",
>         "result" => {"rest-resource-paths" => [
>             {
>                 "resource-path" => "batch/jobs",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
>                 "resource-methods" => ["GET /batch-chunk/rest/batch/jobs"]
>             },
>             {
>                 "resource-path" => "batch/jobs/{status}",
>                 "consumes" => undefined,
>                 "produces" => ["application/json"],
>                 "java-method" => "javax.ws.rs.core.Response
> org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam
> java.lang.String status)",
>                 "resource-methods" => ["GET
> /batch-chunk/rest/batch/jobs/{status}"]
>             }
>         ]}
>     }]
> }

You just listed all 'rest-resource-paths' without any filtering, if you have over 100 REST endpoints in 'batch-chunk.war', it will be difficult to find the one which provides "resource-path" => "batch/jobs". 

Let's assume the following command can do the task:

[standalone at localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})

here the 'rest-resource-paths.resource-path' is the attribute name in enhanced syntax.

> The read-resource operation really does the same thing though in this case.

Yes, it does, but I think the most important feature provided by 'query()' operation is that it can filter resources by conditions specified by 'where' parameter.

It works only on simple attributes, like:

[standalone at localhost:9990 /] /subsystem=datasources/jdbc-driver=*:query(select=[driver-xa-datasource-class-name], where={driver-name=h2})
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("subsystem" => "datasources"),
            ("jdbc-driver" => "h2")
        ],
        "outcome" => "success",
        "result" => {"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"}
    }]
}

It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are inside the complex attribute, so that the following commands can work:

[standalone at localhost:9990 /] /core-service=capability-registry:query(select=[possible-capabilities],where={possible-capabilities.name=org.wildfly.data-source})

[standalone at localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})



Best Regards
--
Lin Gao
Software Engineer
JBoss by Red Hat
 
> On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <lgao at redhat.com> wrote:
> 
> > Hi,
> >
> >   Each management resource has an operation named 'query()' to filter
> > resources according to the condition passed by 'selector' and 'where'
> > parameters, however it does not work for complex attributes.
> >
> >   2 example of complex attributes:
> >
> >      - 'query()' operation cannot find which 'possible-capabilities'
> > provides the capability with name 'org.wildfly.data-source'
> >      - It cannot find which 'rest-resource-paths' provides the REST
> > endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war deployment
> > either.
> >
> >   Especially for the second case in above examples, it will be helpful for
> > users when doing troubleshooting in case of large deployment.
> >
> >   Actually, it does not limit to the complex attributes, it would be good
> > to be able to filter resources by condition specified by attribute value of
> > nested child resources(not only by the first level of child resource).
> >
> >   WDYT?
> >
> > Best Regards
> >
> > --
> > Lin Gao
> > Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 
> 
> 
> --
> James R. Perkins
> JBoss by Red Hat
> 

From hpehl at redhat.com  Wed Nov 23 03:52:49 2016
From: hpehl at redhat.com (Harald Pehl)
Date: Wed, 23 Nov 2016 09:52:49 +0100
Subject: [wildfly-dev] Fixing handling of 'required' attributes with
	'alternatives'
In-Reply-To: <DE1EB466-F348-49B5-9801-945073C5A7E1@redhat.com>
References: <FCF0DEA4-2F82-4656-8135-56F088ACD7CF@redhat.com>
	<CAPZNLwxEdV-rKPJBoc61kZ5XmomzZaOOQvd58t6nt-z18pY1TQ@mail.gmail.com>
	<CCC71DA0-82A7-4DB0-A632-13249564F7DD@redhat.com>
	<BE2CF7D1-273B-45DC-B3B0-2E38ACEE480D@redhat.com>
	<DE1EB466-F348-49B5-9801-945073C5A7E1@redhat.com>
Message-ID: <CAPZNLwyyoao6CdXvgUp0TpQPAste8-i1+B6X3M1Fwns_jebUzg@mail.gmail.com>

Thanks for the info, Brian. I'll check the console with the new server-side
impl (should affect the transaction attributes only, but will also do some
more testing)

On Wed, Nov 23, 2016 at 12:50 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Hi Harald,
>
> This PR is merged so this will be there once this week?s core release is
> merged into full (probably by Monday).
>
> > On Sep 7, 2016, at 3:59 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > PR for this: https://github.com/wildfly/wildfly-core/pull/1781
> >
> >> On Sep 6, 2016, at 1:56 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>
> >>>
> >>> On Sep 6, 2016, at 11:58 AM, Harald Pehl <hpehl at redhat.com> wrote:
> >>>
> >>> Thanks Brian for bringing this up. Everything which makes the metadata
> more consistent helps management client such as HAL. And as more and more
> forms are based on MBUI (generated based on the r-r-d metadata) this is
> even more important.
> >>>
> >>> Right now we already have some logic behind the 'nillable' and
> 'alternatives' attributes to decide whether an attribute is required or not:
> >>>
> >>> boolean required = attributeDescription.hasDefined("nillable") &&
> !attributeDescription.get("nillable").asBoolean();
> >>> if (attributeDescription.hasDefined("alternatives") &&
> !attributeDescription.get("alternatives").asList().isEmpty()) {
> >>>   required = false;
> >>> }
> >>>
> >>
> >> Ah, good. So my proposed change to how nillable is calculated shouldn?t
> change the final result you get above for your required variable. :) So
> once I do what I propose on the server side you can adapt to it when
> convenient.
> >>
> >>> In HAL we use attribute descriptions to add new resources and to
> modify existing resources. For the former we rely on the
> 'request-properties' node of the add operation description. The latter uses
> the 'attributes' node of the r-r-d op. If we want to make changes, it's
> important to be consistent and apply them to both nodes. Right now these
> two nodes already have slightly different attributes: The
> 'request-properties' already contain a 'required' attribute whereas the
> 'attributes' don't.
> >>
> >> Yes, this inconsistency is part of the overall task of WFCORE-1556. The
> actual metadata we generate doesn?t comply with the spec in [a] and [b] and
> then the spec itself is inconsistent between those two sections in how it
> deals with ?required? vs ?nillable?. And there?s no reason for that.
> >>
> >> [a] https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-
> DescriptionofanAttribute
> >> [b] https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-
> DescriptionofanOperationParameterorReturnValue
> >>
> >>>
> >>> The proposal makes sense to me and the impact on HAL should be
> minimal. Some questions I have:
> >>>
> >>> 1. Will the metadata contain both 'nillable' and 'required'? With
> 'required' being the leading attribute and 'nillable' being deprecated but
> still there for backwards compability?
> >>>
> >>
> >> It will contain both. I wouldn?t characterize either as leading or
> deprecated. Rather they have different functions:
> >>
> >> required ? indicates the attribute/parameter represents something that
> must be configured in some way. But configuring one of the ?alternatives?
> suffices.
> >> nillable ? indicates that attribute/parameter may have an undefined
> value for some reason
> >>
> >> So nillable is useful to a client simply wanting to know whether it
> needs to deal with ?undefined?. A more sophisticated client would use
> ?required? plus ?alternatives?.
> >>
> >>> 2. Will your proposal also cover the 'request-properties' for the add
> operation?
> >>>
> >>
> >> Yes, they will be made consistent, with all attribute and parameter
> descriptions exposing the same metadata fields with the same conceptual
> meaning.
> >>
> >> In terms of the server side implementation, for almost all add
> operations, the same AttributeDefinition instance is used for generating
> both the attribute description and the add parameter description. And for
> all parameter descriptions we use the same AttributeDefinition classes that
> we use for resource attributes, so the behavior we put in the AD class will
> apply to both.
> >>
> >>>
> >>> On Tue, Sep 6, 2016 at 3:10 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>> tl;dr;
> >>>
> >>> It?s not an uncommon thing to have a management attribute A that is
> required; i.e. must be set, but also has an alternative attribute B, where
> setting B satisfies the requirement for A, making an undefined value for A
> legal. We?re not handling that correctly and I want to fix it.[1] But
> fixing it will require some coordination with the HAL console.
> >>>
> >>> Right now the way AttributeDefinition building works it?s not
> practical to declare that an attribute is required but only if no
> alternative is set. So instead attributes are declared as if they aren?t
> really required. This leads to less than helpful input validation, e.g. [2]
> and [3], since the attribute definition is imprecise.
> >>>
> >>> The change I?d like to make will alter the read-resource-description
> output for 4 attributes, changing the value of the ?nillable? description
> from ?false? to ?true? so I want to coordinate that with the console team.
> >>>
> >>> Long version
> >>>
> >>> Harald and Claudio you guys are the main audience here. :)
> >>>
> >>> For even longer version see description and comments on [1].
> >>>
> >>> In a nutshell, if devs set the ?allowNull? property on an
> AttributeDefinition to ?true?, the r-r-d output for the attribute has
> ?nillable? => true. But there is no way to say ?allowNull but only if an
> alternative is set.? So people are setting ?allowNull? to true even if the
> attribute should be set in the absence of alternatives. And HAL has no
> metadata available to it to tell users they *must* set one of the
> alternatives. So I want to:
> >>>
> >>> 1) Add a setRequired(boolean) method to the AD builders where the fact
> that it means ?must be defined if no alternative is defined? is explicitly
> declared
> >>> 2) @Deprecate setAllowNull and point to setRequired
> >>> 3) Clarify the meaning of setAllowNull(true) as being the same as
> setRequired(false)
> >>> 4) Change the builder ?allowNull? constructor param name to ?optional?
> and document its meaning as ?allowing undefined values even in the absence
> of defined alternatives?.  I could call the param ?notRequired? which is
> clearer in meaning but odd.
> >>>
> >>> Then I will add a new ?required? metadata field to the r-r-d output
> and change the impl of the existing ?nillable? metadata to a logical
> ?!required || (alternatives != null && alternatives.length > 0)?
> >>>
> >>> This will result in a change in the ?nillable? value for 4 attributes
> in the WildFly model from ?false? to ?true':
> >>>
> >>> /subsystem=transactions PROCESS_ID_SOCKET_BINDING and PROCESS_ID_UUID
> >>> /core-service=management/security-realm=*/authenticaton=ldap
> USERNAME_FILTER and ADVANCED_FILTER
> >>>
> >>> The latter two are not exposed in the console so the issue really is
> the two transaction attributes.
> >>>
> >>> I haven?t checked other subsystems in things like Teiid or JDG, but if
> there are only 4 in all of WildFly I doubt there are many.
> >>>
> >>> Also, if people start using the new behavior to correct problems like
> [2] and [3] people may expect the console to understand and reflect the
> concept of ?required but only if there is no alternative?.
> >>>
> >>> [1] https://issues.jboss.org/browse/WFCORE-1556
> >>> [2] https://issues.jboss.org/browse/WFLY-6608
> >>> [3] https://issues.jboss.org/browse/WFLY-6607
> >>>
> >>> --
> >>> 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
> >>>
> >>>
> >>>
> >>> --
> >>> ---
> >>> Harald Pehl
> >>> JBoss by Red Hat
> >>> http://hpehl.info
> >>
> >> --
> >> 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
>
>
>
>


-- 
Harald Pehl
JBoss by Red Hat
http://hpehl.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161123/7702b9f0/attachment-0001.html 

From jperkins at redhat.com  Wed Nov 23 11:23:51 2016
From: jperkins at redhat.com (James Perkins)
Date: Wed, 23 Nov 2016 08:23:51 -0800
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
	<CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
	<191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>
Message-ID: <CADGwLpjALxp0o8ZYHWhtfxuaJ6vPy2inZcUKKDU_SYCFYkQ22w@mail.gmail.com>

Ah, I see. Sorry for the confusion. It might be possible with that dot
notation. You could file a JIRA and someone can look at it when there is
time. It does seem possible though.

On Tue, Nov 22, 2016 at 5:39 PM, Lin Gao <lgao at redhat.com> wrote:

> ----- Original Message -----
> > From: "James Perkins" <jperkins at redhat.com>
> > To: "Lin Gao" <lgao at redhat.com>
> > Cc: wildfly-dev at lists.jboss.org
> > Sent: Wednesday, November 23, 2016 6:11:21 AM
> > Subject: Re: [wildfly-dev] Improve query() operation for complex
> attributes?
> >
> > The second case worked for me without an issue.
> > [standalone at localhost:9990 /]
> > /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=
> *:query(select=["rest-resource-paths"])
> > {
> >     "outcome" => "success",
> >     "result" => [{
> >         "address" => [
> >             ("deployment" => "batch-chunk.war"),
> >             ("subsystem" => "jaxrs"),
> >             ("rest-resource" =>
> > "org.jboss.example.batch.rest.BatchResource")
> >         ],
> >         "outcome" => "success",
> >         "result" => {"rest-resource-paths" => [
> >             {
> >                 "resource-path" => "batch/jobs",
> >                 "consumes" => undefined,
> >                 "produces" => ["application/json"],
> >                 "java-method" => "javax.ws.rs.core.Response
> > org.jboss.example.batch.rest.BatchResource.listBatchJobs()",
> >                 "resource-methods" => ["GET
> /batch-chunk/rest/batch/jobs"]
> >             },
> >             {
> >                 "resource-path" => "batch/jobs/{status}",
> >                 "consumes" => undefined,
> >                 "produces" => ["application/json"],
> >                 "java-method" => "javax.ws.rs.core.Response
> > org.jboss.example.batch.rest.BatchResource.listBatchJobs(@PathParam
> > java.lang.String status)",
> >                 "resource-methods" => ["GET
> > /batch-chunk/rest/batch/jobs/{status}"]
> >             }
> >         ]}
> >     }]
> > }
>
> You just listed all 'rest-resource-paths' without any filtering, if you
> have over 100 REST endpoints in 'batch-chunk.war', it will be difficult to
> find the one which provides "resource-path" => "batch/jobs".
>
> Let's assume the following command can do the task:
>
> [standalone at localhost:9990 /] /deployment=batch-chunk.war/
> subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"],
> where={"rest-resource-paths.resource-path"=>"batch/jobs"})
>
> here the 'rest-resource-paths.resource-path' is the attribute name in
> enhanced syntax.
>
> > The read-resource operation really does the same thing though in this
> case.
>
> Yes, it does, but I think the most important feature provided by 'query()'
> operation is that it can filter resources by conditions specified by
> 'where' parameter.
>
> It works only on simple attributes, like:
>
> [standalone at localhost:9990 /] /subsystem=datasources/jdbc-
> driver=*:query(select=[driver-xa-datasource-class-name],
> where={driver-name=h2})
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("subsystem" => "datasources"),
>             ("jdbc-driver" => "h2")
>         ],
>         "outcome" => "success",
>         "result" => {"driver-xa-datasource-class-name" =>
> "org.h2.jdbcx.JdbcDataSource"}
>     }]
> }
>
> It would be good if the 'query()' operation can filter the resources by
> specifying value of attributes which are inside the complex attribute, so
> that the following commands can work:
>
> [standalone at localhost:9990 /] /core-service=capability-
> registry:query(select=[possible-capabilities],where={
> possible-capabilities.name=org.wildfly.data-source})
>
> [standalone at localhost:9990 /] /deployment=batch-chunk.war/
> subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"],
> where={"rest-resource-paths.resource-path"=>"batch/jobs"})
>
>
>
> Best Regards
> --
> Lin Gao
> Software Engineer
> JBoss by Red Hat
>
> > On Tue, Nov 22, 2016 at 12:51 AM, Lin Gao <lgao at redhat.com> wrote:
> >
> > > Hi,
> > >
> > >   Each management resource has an operation named 'query()' to filter
> > > resources according to the condition passed by 'selector' and 'where'
> > > parameters, however it does not work for complex attributes.
> > >
> > >   2 example of complex attributes:
> > >
> > >      - 'query()' operation cannot find which 'possible-capabilities'
> > > provides the capability with name 'org.wildfly.data-source'
> > >      - It cannot find which 'rest-resource-paths' provides the REST
> > > endpoint 'resource-path=/helloworld' in jaxrs subsystem of a war
> deployment
> > > either.
> > >
> > >   Especially for the second case in above examples, it will be helpful
> for
> > > users when doing troubleshooting in case of large deployment.
> > >
> > >   Actually, it does not limit to the complex attributes, it would be
> good
> > > to be able to filter resources by condition specified by attribute
> value of
> > > nested child resources(not only by the first level of child resource).
> > >
> > >   WDYT?
> > >
> > > Best Regards
> > >
> > > --
> > > Lin Gao
> > > Software Engineer
> > > JBoss by Red Hat
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >
> >
> >
> >
> > --
> > James R. Perkins
> > JBoss by Red Hat
> >
>



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

From tomaz.cerar at gmail.com  Wed Nov 23 11:33:52 2016
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 23 Nov 2016 17:33:52 +0100
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <CADGwLpjALxp0o8ZYHWhtfxuaJ6vPy2inZcUKKDU_SYCFYkQ22w@mail.gmail.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
	<CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
	<191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>
	<CADGwLpjALxp0o8ZYHWhtfxuaJ6vPy2inZcUKKDU_SYCFYkQ22w@mail.gmail.com>
Message-ID: <CAMquZP4DUge927N35OKPgcCH+i=SYPC85=6OZEx0FPP23A3L9w@mail.gmail.com>

On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <jperkins at redhat.com> wrote:

> Ah, I see. Sorry for the confusion. It might be possible with that dot
> notation. You could file a JIRA and someone can look at it when there is
> time. It does seem possible though.



As long as query op uses :read-attribute / :read-resource for its work than
dot notation should work just fine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161123/51c91d72/attachment.html 

From brian.stansberry at redhat.com  Wed Nov 23 11:50:29 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 23 Nov 2016 10:50:29 -0600
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <CAMquZP4DUge927N35OKPgcCH+i=SYPC85=6OZEx0FPP23A3L9w@mail.gmail.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
	<CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
	<191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>
	<CADGwLpjALxp0o8ZYHWhtfxuaJ6vPy2inZcUKKDU_SYCFYkQ22w@mail.gmail.com>
	<CAMquZP4DUge927N35OKPgcCH+i=SYPC85=6OZEx0FPP23A3L9w@mail.gmail.com>
Message-ID: <C32F77E9-E01C-4551-BF24-9C3CA64EFFFF@redhat.com>


> On Nov 23, 2016, at 10:33 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> 
> On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <jperkins at redhat.com> wrote:
> Ah, I see. Sorry for the confusion. It might be possible with that dot notation. You could file a JIRA and someone can look at it when there is time. It does seem possible though.
> 
> 
> As long as query op uses :read-attribute / :read-resource for its work than dot notation should work just fine
> 

It doesn?t.

WFCORE RFE Jiras for this should probably be split in two, as the request for dealing with child resources is significantly more complex. The dot notation isn?t currently applied to children anywhere.

> _______________________________________________
> 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 lgao at redhat.com  Thu Nov 24 01:07:47 2016
From: lgao at redhat.com (Lin Gao)
Date: Thu, 24 Nov 2016 01:07:47 -0500 (EST)
Subject: [wildfly-dev] Improve query() operation for complex attributes?
In-Reply-To: <C32F77E9-E01C-4551-BF24-9C3CA64EFFFF@redhat.com>
References: <223034469.1074597.1479804558870.JavaMail.zimbra@redhat.com>
	<1081280018.1074717.1479804678413.JavaMail.zimbra@redhat.com>
	<CADGwLphPWfU7YFE_aWGcbb17NP+6uH-KAgc4cu5zjE1TJhPxgw@mail.gmail.com>
	<191261464.1337334.1479865161774.JavaMail.zimbra@redhat.com>
	<CADGwLpjALxp0o8ZYHWhtfxuaJ6vPy2inZcUKKDU_SYCFYkQ22w@mail.gmail.com>
	<CAMquZP4DUge927N35OKPgcCH+i=SYPC85=6OZEx0FPP23A3L9w@mail.gmail.com>
	<C32F77E9-E01C-4551-BF24-9C3CA64EFFFF@redhat.com>
Message-ID: <2079586448.1665194.1479967667881.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry at redhat.com>
> To: "Toma? Cerar" <tomaz.cerar at gmail.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Thursday, November 24, 2016 12:50:29 AM
> Subject: Re: [wildfly-dev] Improve query() operation for complex attributes?
> 
> 
> > On Nov 23, 2016, at 10:33 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> > 
> > 
> > On Wed, Nov 23, 2016 at 5:23 PM, James Perkins <jperkins at redhat.com> wrote:
> > Ah, I see. Sorry for the confusion. It might be possible with that dot
> > notation. You could file a JIRA and someone can look at it when there is
> > time. It does seem possible though.
> > 
> > 
> > As long as query op uses :read-attribute / :read-resource for its work than
> > dot notation should work just fine
> > 
> 
> It doesn?t.
> 
> WFCORE RFE Jiras for this should probably be split in two, as the request for
> dealing with child resources is significantly more complex. The dot notation
> isn?t currently applied to children anywhere.

https://issues.jboss.org/browse/WFCORE-2041 is created for improvement of query in complex attributes
https://issues.jboss.org/browse/WFCORE-2042 is created for improvement of query in nested child resources

The dot notation should apply for attribute names[1], if the dot does not work for resource names,
maybe another parameter like: 'separator' can be added to query() operation to specify one.


[1] https://lists.jboss.org/pipermail/hawkular-dev/2015-June/001158.html

Best Regards
--
Lin Gao
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


From bburke at redhat.com  Wed Nov 30 09:26:20 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Nov 2016 09:26:20 -0500
Subject: [wildfly-dev] deployment phase question
Message-ID: <7d98dd63-bc47-f072-51ea-9195835d54a2@redhat.com>

If you have a bunch of deployments, does each deployment run through the 
deployment phases independently?  Or does a phase like POST_MODULE 
execute for all deployments first, then INSTALL runs for all deployments.

Thanks


From brian.stansberry at redhat.com  Wed Nov 30 09:58:08 2016
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 30 Nov 2016 08:58:08 -0600
Subject: [wildfly-dev] deployment phase question
In-Reply-To: <7d98dd63-bc47-f072-51ea-9195835d54a2@redhat.com>
References: <7d98dd63-bc47-f072-51ea-9195835d54a2@redhat.com>
Message-ID: <A8B78554-228E-4E3C-96A7-2107E6F2236E@redhat.com>


> On Nov 30, 2016, at 8:26 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> If you have a bunch of deployments, does each deployment run through the 
> deployment phases independently?  

Yes. An MSC service is created for each phase for each deployment (or subdeployment in an ear.)

> Or does a phase like POST_MODULE 
> execute for all deployments first, then INSTALL runs for all deployments.
> 
> Thanks
> 
> _______________________________________________
> 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