From asoldano at redhat.com Thu Sep 1 03:40:52 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 1 Sep 2016 09:40:52 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com> <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> Message-ID: <74437173-5791-08d1-f3ed-6094c8d6e1b4@redhat.com> Il 01/09/2016 01:12, Jason T. Greene ha scritto: > On the other hand i suspect this relies on CXF to generate the client > side messages, so perhaps it would be a complex transition. CXF is needed to generate the SOAP message on "client" side. But that could still run on the server. What needs to be on the actual client (browser) is the generation of the graphical representation of the message. IOW, the user is not presented with a static page, but with something that 1) depends on the previously selected service endpoint 2) depends on how the user interacts with it (for example, say you have arrays of complex types in the schema, the user can add and remove items in the array and the page has to show the proper structure). The core of the application generates a generic tree view of the request message, which is modifiable according to the schema constraints (allowed types, optional items, complex structures, collections, etc.); the GUI allows the user to fill in data into that tree and modify it before eventually pressing the invoke button and hence telling the core to convert the tree back into actual arguments to make the ws invocation. Not sure this fits with your concept of serving just static files, but I'll let Rebecca comment here as she's worked on the GUI. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From kabir.khan at jboss.com Thu Sep 1 06:07:45 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 1 Sep 2016 12:07:45 +0200 Subject: [wildfly-dev] WFLY/WFCORE PRs Message-ID: 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. From darran.lofthouse at jboss.com Thu Sep 1 09:26:41 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 1 Sep 2016 14:26:41 +0100 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <077E4783-07B9-45BB-A2AA-B40EC889DD9E@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com> <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> <077E4783-07B9-45BB-A2AA-B40EC889DD9E@redhat.com> Message-ID: <3956932a-4fbb-670f-9041-74f8329e94f6@jboss.com> On 01/09/16 01:23, Brian Stansberry wrote: > >> On Aug 31, 2016, at 6:12 PM, Jason T. Greene wrote: >> >> >> >>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry wrote: >>> >>> >>>> For example the GWT app could be mostly client side, with no GWT-RPC >>> >>> That part is still involves a deployment though, right? Even if it?s just like HAL and just static files, making it downloadable means either a deployment or some custom integration into the undertow subsystem. The alternative is to make it a special context on the management http interace like we do for the HAL console. Or one way or the other make it part of HAL. But my impression of this app is despite the bit of integration into HAL, it?s not really a ?management? app and is meant to be usable outside of HAL. A "dev-ops" admin may use it, hence the integration with HAL, or a ?dev" may use it, but a classic ?ops? admin is not going to use it and we don?t want to force the ?dev? user to be given admin permissions in order to use it. >>> >>> If the downloadable part is a deployment but also an patchable official part of the software we for sure don?t want it deployed via the deployments/ folder. >> >> By deployment I was referring to going through the deployment process, and registered as a deployment node, in order to start. With client side JS it's just static files and trivial to install wherever is desired. For example, the subsystem could register a handler as part of the server, or the web services subsystem could register a handler as part of a *user* deployment (a special opt in sub URL) or it could be a direct HAL plugin, or yet another app on 9990 and thus usable on a DC. >> > Yes. I went to dinner before getting a chance to reply to myself saying I didn?t want to distract from your main point about how to integrate, since I realized that if all the ?deployment? part was was serving static files, having the subsystem integrate a simple handler into the webserver is a perfectly good approach. > >> As to roles, sure I doubt a standard admin would do much with this. I could maybe see an operator perhaps verifying service functionality, or perhaps troubleshooting. It definitely seems more of a development use case. In a pure client side solution you aren't really introducing the need for a permission per se because it runs straight from the client browser, with no management API interaction other than discovering the port. >> > > True. We?d need to restructure how the ?9090? interface is set up though. Now it?s the ?http management? interface with a single security realm. If it became something more general purpose with different security policies for different contexts that would require a different config style I wouldn't worry too much about security realms as they are deprecated and TBH will make everyone's life easier if no new resource make use of them. The replacement security architecture is however better suited to having different authentication policies for different entry points to the server and even if those entry points end up calling a common back end we have formal support for security domain to security domain identity propagation / transformation. Add to that using the same security architecture for applications and management makes it much easier to mix and match as well. > >> On the other hand i suspect this relies on CXF to generate the client side messages, so perhaps it would be a complex transition. >> >> -Jason >> > From brian.stansberry at redhat.com Thu Sep 1 09:37:37 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 1 Sep 2016 08:37:37 -0500 Subject: [wildfly-dev] WFLY/WFCORE PRs In-Reply-To: References: Message-ID: 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 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 From rsvoboda at redhat.com Thu Sep 1 09:47:54 2016 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Thu, 1 Sep 2016 09:47:54 -0400 (EDT) Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <3956932a-4fbb-670f-9041-74f8329e94f6@jboss.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com> <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> <077E4783-07B9-45BB-A2AA-B40EC889DD9E@redhat.com> <3956932a-4fbb-670f-9041-74f8329e94f6@jboss.com> Message-ID: <2130315979.997833.1472737674528.JavaMail.zimbra@redhat.com> Hi. Can be WISE pulled back in, but do not include the subsystem definition into standard standalone*.xml ? WISE would be made available via cli - subsystem add+enable Future / wish: "Enable WISE" button in webconsole to have even better experience than just CLI - e.g. WISE button near ws subsystem configuration + runtime information Future (probably/maybe far far away): Redesign of integration based on conclusions from the discussion about integration approaches for cases like this. Rostislav ----- Original Message ----- > > > On 01/09/16 01:23, Brian Stansberry wrote: > > > >> On Aug 31, 2016, at 6:12 PM, Jason T. Greene > >> wrote: > >> > >> > >> > >>> On Aug 31, 2016, at 4:51 PM, Brian Stansberry > >>> wrote: > >>> > >>> > >>>> For example the GWT app could be mostly client side, with no GWT-RPC > >>> > >>> That part is still involves a deployment though, right? Even if it?s just > >>> like HAL and just static files, making it downloadable means either a > >>> deployment or some custom integration into the undertow subsystem. The > >>> alternative is to make it a special context on the management http > >>> interace like we do for the HAL console. Or one way or the other make it > >>> part of HAL. But my impression of this app is despite the bit of > >>> integration into HAL, it?s not really a ?management? app and is meant to > >>> be usable outside of HAL. A "dev-ops" admin may use it, hence the > >>> integration with HAL, or a ?dev" may use it, but a classic ?ops? admin > >>> is not going to use it and we don?t want to force the ?dev? user to be > >>> given admin permissions in order to use it. > >>> > >>> If the downloadable part is a deployment but also an patchable official > >>> part of the software we for sure don?t want it deployed via the > >>> deployments/ folder. > >> > >> By deployment I was referring to going through the deployment process, and > >> registered as a deployment node, in order to start. With client side JS > >> it's just static files and trivial to install wherever is desired. For > >> example, the subsystem could register a handler as part of the server, or > >> the web services subsystem could register a handler as part of a *user* > >> deployment (a special opt in sub URL) or it could be a direct HAL plugin, > >> or yet another app on 9990 and thus usable on a DC. > >> > > Yes. I went to dinner before getting a chance to reply to myself saying I > > didn?t want to distract from your main point about how to integrate, since > > I realized that if all the ?deployment? part was was serving static files, > > having the subsystem integrate a simple handler into the webserver is a > > perfectly good approach. > > > >> As to roles, sure I doubt a standard admin would do much with this. I > >> could maybe see an operator perhaps verifying service functionality, or > >> perhaps troubleshooting. It definitely seems more of a development use > >> case. In a pure client side solution you aren't really introducing the > >> need for a permission per se because it runs straight from the client > >> browser, with no management API interaction other than discovering the > >> port. > >> > > > > True. We?d need to restructure how the ?9090? interface is set up though. > > Now it?s the ?http management? interface with a single security realm. If > > it became something more general purpose with different security policies > > for different contexts that would require a different config style > > I wouldn't worry too much about security realms as they are deprecated > and TBH will make everyone's life easier if no new resource make use of > them. > > The replacement security architecture is however better suited to having > different authentication policies for different entry points to the > server and even if those entry points end up calling a common back end > we have formal support for security domain to security domain identity > propagation / transformation. > > Add to that using the same security architecture for applications and > management makes it much easier to mix and match as well. > > > > >> On the other hand i suspect this relies on CXF to generate the client side > >> messages, so perhaps it would be a complex transition. > >> > >> -Jason > >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rsearls at redhat.com Thu Sep 1 11:36:14 2016 From: rsearls at redhat.com (Rebecca Searls) Date: Thu, 1 Sep 2016 11:36:14 -0400 (EDT) Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <74437173-5791-08d1-f3ed-6094c8d6e1b4@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com> <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> <74437173-5791-08d1-f3ed-6094c8d6e1b4@redhat.com> Message-ID: <2128156290.8200529.1472744174473.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Alessio Soldano" > To: wildfly-dev at lists.jboss.org > Sent: Thursday, September 1, 2016 3:40:52 AM > Subject: Re: [wildfly-dev] question 2 sec boot time of WISE > > Il 01/09/2016 01:12, Jason T. Greene ha scritto: > > On the other hand i suspect this relies on CXF to generate the client > > side messages, so perhaps it would be a complex transition. > > CXF is needed to generate the SOAP message on "client" side. But that > could still run on the server. What needs to be on the actual client > (browser) is the generation of the graphical representation of the > message. IOW, the user is not presented with a static page, but with > something that 1) depends on the previously selected service endpoint 2) > depends on how the user interacts with it (for example, say you have > arrays of complex types in the schema, the user can add and remove items > in the array and the page has to show the proper structure). The core of > the application generates a generic tree view of the request message, > which is modifiable according to the schema constraints (allowed types, > optional items, complex structures, collections, etc.); the GUI allows > the user to fill in data into that tree and modify it before eventually > pressing the invoke button and hence telling the core to convert the > tree back into actual arguments to make the ws invocation. > Not sure this fits with your concept of serving just static files, but > I'll let Rebecca comment here as she's worked on the GUI. > I'm assuming its the gwt-servlet that is taking most the bootup time. I don't see that Wise can have a lot of static code. I'm investigating using the restyGWT api to see if that can resolve some of these issues. > Cheers > Alessio > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rsearls at redhat.com Thu Sep 1 16:43:38 2016 From: rsearls at redhat.com (Rebecca Searls) Date: Thu, 1 Sep 2016 16:43:38 -0400 (EDT) Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <2128156290.8200529.1472744174473.JavaMail.zimbra@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <95646C88-7FAF-4AF4-8A2A-023ABAE2E421@redhat.com> <7379543D-09EE-40DD-A5F3-0E052F88A89B@redhat.com> <74437173-5791-08d1-f3ed-6094c8d6e1b4@redhat.com> <2128156290.8200529.1472744174473.JavaMail.zimbra@redhat.com> Message-ID: <912876830.8274192.1472762618219.JavaMail.zimbra@redhat.com> Are there any details about what elements from the Wise war are taking the longest during bootup? Or is there a specific logging setting or package name I should add to my local wfly to see more detail? ----- Original Message ----- > From: "Rebecca Searls" > To: "Alessio Soldano" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, September 1, 2016 11:36:14 AM > Subject: Re: [wildfly-dev] question 2 sec boot time of WISE > > > > ----- Original Message ----- > > From: "Alessio Soldano" > > To: wildfly-dev at lists.jboss.org > > Sent: Thursday, September 1, 2016 3:40:52 AM > > Subject: Re: [wildfly-dev] question 2 sec boot time of WISE > > > > Il 01/09/2016 01:12, Jason T. Greene ha scritto: > > > On the other hand i suspect this relies on CXF to generate the client > > > side messages, so perhaps it would be a complex transition. > > > > CXF is needed to generate the SOAP message on "client" side. But that > > could still run on the server. What needs to be on the actual client > > (browser) is the generation of the graphical representation of the > > message. IOW, the user is not presented with a static page, but with > > something that 1) depends on the previously selected service endpoint 2) > > depends on how the user interacts with it (for example, say you have > > arrays of complex types in the schema, the user can add and remove items > > in the array and the page has to show the proper structure). The core of > > the application generates a generic tree view of the request message, > > which is modifiable according to the schema constraints (allowed types, > > optional items, complex structures, collections, etc.); the GUI allows > > the user to fill in data into that tree and modify it before eventually > > pressing the invoke button and hence telling the core to convert the > > tree back into actual arguments to make the ws invocation. > > Not sure this fits with your concept of serving just static files, but > > I'll let Rebecca comment here as she's worked on the GUI. > > > > I'm assuming its the gwt-servlet that is taking most the bootup time. > I don't see that Wise can have a lot of static code. I'm investigating > using the restyGWT api to see if that can resolve some of these issues. > > > > Cheers > > Alessio > > > > -- > > Alessio Soldano > > Web Service Lead, JBoss > > > > _______________________________________________ > > 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 ppalaga at redhat.com Fri Sep 2 16:47:49 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 2 Sep 2016 22:47:49 +0200 Subject: [wildfly-dev] WFLY/WFCORE PRs In-Reply-To: References: Message-ID: <66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com> 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 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 > From asoldano at redhat.com Sun Sep 4 18:20:54 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 5 Sep 2016 00:20:54 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> Message-ID: <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> Il 31/08/2016 20:51, Jason Greene ha scritto: >> 1. lazy deployment of the utility > What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. I've thought about this a bit tonight...yes, the wise.war could be exploded, its classes moved into the subsystem and the gtw and wise core jars left as external libs in their own modules. As for the lazy start, how about a service in the new wise subsystem that uses the WebHost service to start the servlet app (would need to provide it with a classloader including the required external libs mentioned before)? That could be triggered (on/off) by operations in the subsystem. Then the user would basically have to enable the gui using management (hal, cli). Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss From rory.odonnell at oracle.com Mon Sep 5 13:42:04 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 5 Sep 2016 18:42:04 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net Message-ID: Hi Jason/Tomaz, Early Access b134 for JDK 9 is available on java.net, summary of changes are listed here . There have been a number of fixes , since the last availability email , to bugs reported by Open Source projects : * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a strong reference to the context class loader * 8146961 Fix PermGen memory leaks caused by static final Exceptions * 8163353 NPE in ConcurrentHashMap.removeAll() * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.xr.XRSurfaceData after xrandr change output Secondly, there are a number of interesting items to bring to our attention * JDK 9 Rampdown Phase 1: Process proposal [1] * The Java team has published the ?Oracle JRE and JDK Cryptographic Roadmap? [2] java.com/cryptoroadmap * The Quality Report for September 2016 is now available [3], thank you for your continued support! Highlights from the Quality Report for September : * 21 new Open Source projects have joined the Outreach program * Projects filed 35 new issues in the JDK Bug System, this is almost double the number of bugs in the previous six months! * Continuing to provide excellent feedback via the OpenJDK dev mailing lists Thank you! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html [2] java.com/cryptoroadmap [3] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 -- 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/20160905/9350cd1f/attachment.html From rory.odonnell at oracle.com Tue Sep 6 06:04:08 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 6 Sep 2016 11:04:08 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: References: Message-ID: Hi Tomaz, Can you confirm fix for : 8163353 NPE in ConcurrentHashMap.removeAll() Rgds,Rory On 05/09/2016 18:42, Rory O'Donnell wrote: > > > Hi Jason/Tomaz, > > Early Access b134 for JDK 9 is > available on java.net, summary of changes are listed here > . > > There have been a number of fixes , since the last availability email > , to bugs reported by Open Source projects : > > * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a > strong reference to the context class loader > * 8146961 Fix PermGen memory leaks caused by static final Exceptions > * 8163353 NPE in ConcurrentHashMap.removeAll() > * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData > cannot be cast to sun.java2d.xr.XRSurfaceData after xrandr change > output > > Secondly, there are a number of interesting items to bring to our > attention > > * JDK 9 Rampdown Phase 1: Process proposal [1] > * The Java team has published the ?Oracle JRE and JDK Cryptographic > Roadmap? [2] java.com/cryptoroadmap > * The Quality Report for September 2016 is now available [3], thank > you for your continued support! > > > Highlights from the Quality Report for September : > > * 21 new Open Source projects have joined the Outreach program > * Projects filed 35 new issues in the JDK Bug System, this is almost > double the number of bugs in the previous six months! > * Continuing to provide excellent feedback via the OpenJDK dev > mailing lists > > Thank you! > > Rgds,Rory > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html > [2] java.com/cryptoroadmap > [3] > https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland -- 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/20160906/016a8f69/attachment.html From brian.stansberry at redhat.com Tue Sep 6 09:10:03 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 6 Sep 2016 08:10:03 -0500 Subject: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives' Message-ID: 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 From hpehl at redhat.com Tue Sep 6 12:58:01 2016 From: hpehl at redhat.com (Harald Pehl) Date: Tue, 6 Sep 2016 18:58:01 +0200 Subject: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives' In-Reply-To: References: Message-ID: 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; } 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. 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? 2. Will your proposal also cover the 'request-properties' for the add operation? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160906/5a92afc9/attachment-0001.html From brian.stansberry at redhat.com Tue Sep 6 14:17:17 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 6 Sep 2016 13:17:17 -0500 Subject: [wildfly-dev] WFLY/WFCORE PRs In-Reply-To: <66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com> References: <66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com> Message-ID: 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 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 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 From brian.stansberry at redhat.com Tue Sep 6 14:56:58 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 6 Sep 2016 13:56:58 -0500 Subject: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives' In-Reply-To: References: Message-ID: > On Sep 6, 2016, at 11:58 AM, Harald Pehl 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 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 From tomaz.cerar at gmail.com Wed Sep 7 09:46:01 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 7 Sep 2016 15:46:01 +0200 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: References: Message-ID: Hey Rory, I can confirm that b134 fixes the said problem. thank you for heads up -- tomaz On Tue, Sep 6, 2016 at 12:04 PM, Rory O'Donnell wrote: > Hi Tomaz, > > Can you confirm fix for : > > 8163353 NPE in ConcurrentHashMap.removeAll() > Rgds,Rory > > On 05/09/2016 18:42, Rory O'Donnell wrote: > > > Hi Jason/Tomaz, > Early Access b134 for JDK 9 is > available on java.net, summary of changes are listed here > . > > There have been a number of fixes , since the last availability email , > to bugs reported by Open Source projects : > > - 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a > strong reference to the context class loader > - 8146961 Fix PermGen memory leaks caused by static final Exceptions > - 8163353 NPE in ConcurrentHashMap.removeAll() > - 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot > be cast to sun.java2d.xr.XRSurfaceData after xrandr change output > > Secondly, there are a number of interesting items to bring to our attention > > - JDK 9 Rampdown Phase 1: Process proposal [1] > - The Java team has published the ?Oracle JRE and JDK Cryptographic > Roadmap? [2] java.com/cryptoroadmap > - The Quality Report for September 2016 is now available [3], thank > you for your continued support! > > > Highlights from the Quality Report for September : > > - 21 new Open Source projects have joined the Outreach program > - Projects filed 35 new issues in the JDK Bug System, this is almost > double the number of bugs in the previous six months! > - Continuing to provide excellent feedback via the OpenJDK dev mailing > lists > > Thank you! > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016- > August/004777.html > [2] java.com/cryptoroadmap > [3] https://wiki.openjdk.java.net/display/quality/Quality+ > Outreach+Report+September+2016 > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > -- > 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/20160907/7e567f04/attachment.html From rory.odonnell at oracle.com Wed Sep 7 09:59:46 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 7 Sep 2016 14:59:46 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: References: Message-ID: Thanks Tomaz! On 07/09/2016 14:46, Toma? Cerar wrote: > Hey Rory, > > I can confirm that b134 fixes the said problem. > > thank you for heads up > -- > tomaz > > On Tue, Sep 6, 2016 at 12:04 PM, Rory O'Donnell > > wrote: > > Hi Tomaz, > > Can you confirm fix for : > > 8163353 NPE in ConcurrentHashMap.removeAll() > > Rgds,Rory > > On 05/09/2016 18:42, Rory O'Donnell wrote: >> >> >> Hi Jason/Tomaz, >> >> Early Access b134 for JDK 9 is >> available on java.net , summary of changes are >> listed here >> . >> >> There have been a number of fixes , since the last availability >> email , to bugs reported by Open Source projects : >> >> * 8156841 sun.security.pkcs11.SunPKCS11 poller thread >> retains a strong reference to the context class loader >> * 8146961 Fix PermGen memory leaks caused by static final >> Exceptions >> * 8163353 NPE in ConcurrentHashMap.removeAll() >> * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData >> cannot be cast to sun.java2d.xr.XRSurfaceData after xrandr >> change output >> >> Secondly, there are a number of interesting items to bring to our >> attention >> >> * JDK 9 Rampdown Phase 1: Process proposal [1] >> * The Java team has published the ?Oracle JRE and JDK >> Cryptographic Roadmap? [2] java.com/cryptoroadmap >> >> * The Quality Report for September 2016 is now available [3], >> thank you for your continued support! >> >> >> Highlights from the Quality Report for September : >> >> * 21 new Open Source projects have joined the Outreach program >> * Projects filed 35 new issues in the JDK Bug System, this is >> almost double the number of bugs in the previous six months! >> * Continuing to provide excellent feedback via the OpenJDK dev >> mailing lists >> >> Thank you! >> >> Rgds,Rory >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >> >> [2] java.com/cryptoroadmap >> [3] >> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- 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/20160907/6e62984e/attachment-0001.html From manovotn at redhat.com Wed Sep 7 10:00:39 2016 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 7 Sep 2016 10:00:39 -0400 (EDT) Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: References: Message-ID: <1070939803.5001468.1473256839560.JavaMail.zimbra@redhat.com> Hello Weld team here - we have been seeing this error before. I can confirm it is FIXED with JDK 9 b134 - thanks for that! Also I would like to thank Tomaz, who reported this as I didn't quite get to it :-) Regards Matej ----- Original Message ----- > From: "Rory O'Donnell" > To: "jason greene" > Cc: "Balchandra Vaidya" , "rory odonnell" , "Muneer > Kolarkunnu" , "Dalibor Topic" , wildfly-dev at lists.jboss.org > Sent: Tuesday, September 6, 2016 12:04:08 PM > Subject: Re: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net > > > > Hi Tomaz, > > Can you confirm fix for : > > 8163353 NPE in ConcurrentHashMap.removeAll() Rgds,Rory > On 05/09/2016 18:42, Rory O'Donnell wrote: > > > > > > > > Hi Jason/Tomaz, Early Access b134 for JDK 9 is available on java.net, summary > of changes are listed here . > > There have been a number of fixes , since the last availability email , to > bugs reported by Open Source projects : > > > * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a strong > reference to the context class loader > * 8146961 Fix PermGen memory leaks caused by static final Exceptions > * 8163353 NPE in ConcurrentHashMap.removeAll() > * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot be > cast to sun.java2d.xr.XRSurfaceData after xrandr change output > > > Secondly, there are a number of interesting items to bring to our attention > > > * JDK 9 Rampdown Phase 1: Process proposal [1] > * The Java team has published the ?Oracle JRE and JDK Cryptographic > Roadmap? [2] java.com/cryptoroadmap > * The Quality Report for September 2016 is now available [3], thank you > for your continued support! > > Highlights from the Quality Report for September : > > > * 21 new Open Source projects have joined the Outreach program > * Projects filed 35 new issues in the JDK Bug System, this is almost > double the number of bugs in the previous six months! > * Continuing to provide excellent feedback via the OpenJDK dev mailing > lists > > > Thank you! > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html > [2] java.com/cryptoroadmap > [3] > https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Wed Sep 7 10:06:25 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 7 Sep 2016 15:06:25 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: <1070939803.5001468.1473256839560.JavaMail.zimbra@redhat.com> References: <1070939803.5001468.1473256839560.JavaMail.zimbra@redhat.com> Message-ID: <20bf154d-75d3-4d07-727e-07603feb9a16@oracle.com> Glad we could help! Rgds,Rory On 07/09/2016 15:00, Matej Novotny wrote: > Hello > > Weld team here - we have been seeing this error before. > > I can confirm it is FIXED with JDK 9 b134 - thanks for that! > > Also I would like to thank Tomaz, who reported this as I didn't quite get to it :-) > > Regards > Matej > > ----- Original Message ----- >> From: "Rory O'Donnell" >> To: "jason greene" >> Cc: "Balchandra Vaidya" , "rory odonnell" , "Muneer >> Kolarkunnu" , "Dalibor Topic" , wildfly-dev at lists.jboss.org >> Sent: Tuesday, September 6, 2016 12:04:08 PM >> Subject: Re: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net >> >> >> >> Hi Tomaz, >> >> Can you confirm fix for : >> >> 8163353 NPE in ConcurrentHashMap.removeAll() Rgds,Rory >> On 05/09/2016 18:42, Rory O'Donnell wrote: >> >> >> >> >> >> >> >> Hi Jason/Tomaz, Early Access b134 for JDK 9 is available on java.net, summary >> of changes are listed here . >> >> There have been a number of fixes , since the last availability email , to >> bugs reported by Open Source projects : >> >> >> * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a strong >> reference to the context class loader >> * 8146961 Fix PermGen memory leaks caused by static final Exceptions >> * 8163353 NPE in ConcurrentHashMap.removeAll() >> * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot be >> cast to sun.java2d.xr.XRSurfaceData after xrandr change output >> >> >> Secondly, there are a number of interesting items to bring to our attention >> >> >> * JDK 9 Rampdown Phase 1: Process proposal [1] >> * The Java team has published the ?Oracle JRE and JDK Cryptographic >> Roadmap? [2] java.com/cryptoroadmap >> * The Quality Report for September 2016 is now available [3], thank you >> for your continued support! >> >> Highlights from the Quality Report for September : >> >> >> * 21 new Open Source projects have joined the Outreach program >> * Projects filed 35 new issues in the JDK Bug System, this is almost >> double the number of bugs in the previous six months! >> * Continuing to provide excellent feedback via the OpenJDK dev mailing >> lists >> >> >> Thank you! >> Rgds,Rory >> >> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >> [2] java.com/cryptoroadmap >> [3] >> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From brian.stansberry at redhat.com Wed Sep 7 16:59:37 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 7 Sep 2016 15:59:37 -0500 Subject: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives' In-Reply-To: References: Message-ID: PR for this: https://github.com/wildfly/wildfly-core/pull/1781 > On Sep 6, 2016, at 1:56 PM, Brian Stansberry wrote: > >> >> On Sep 6, 2016, at 11:58 AM, Harald Pehl 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 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 From rory.odonnell at oracle.com Thu Sep 8 05:46:00 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 8 Sep 2016 10:46:00 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b134 are available on java.net In-Reply-To: <20bf154d-75d3-4d07-727e-07603feb9a16@oracle.com> References: <1070939803.5001468.1473256839560.JavaMail.zimbra@redhat.com> <20bf154d-75d3-4d07-727e-07603feb9a16@oracle.com> Message-ID: <20b802a6-e61e-9d86-f4ca-2f2628f04c0e@oracle.com> Hi Matej, Do you want us to list your project on the Quality Outreach wiki here Rgds,Rory On 07/09/2016 15:06, Rory O'Donnell wrote: > Glad we could help! > > Rgds,Rory > > > On 07/09/2016 15:00, Matej Novotny wrote: >> Hello >> >> Weld team here - we have been seeing this error before. >> >> I can confirm it is FIXED with JDK 9 b134 - thanks for that! >> >> Also I would like to thank Tomaz, who reported this as I didn't quite >> get to it :-) >> >> Regards >> Matej >> >> ----- Original Message ----- >>> From: "Rory O'Donnell" >>> To: "jason greene" >>> Cc: "Balchandra Vaidya" , "rory >>> odonnell" , "Muneer >>> Kolarkunnu" , "Dalibor Topic" >>> , wildfly-dev at lists.jboss.org >>> Sent: Tuesday, September 6, 2016 12:04:08 PM >>> Subject: Re: [wildfly-dev] Early Access builds of JDK 9 b134 are >>> available on java.net >>> >>> >>> >>> Hi Tomaz, >>> >>> Can you confirm fix for : >>> >>> 8163353 NPE in ConcurrentHashMap.removeAll() Rgds,Rory >>> On 05/09/2016 18:42, Rory O'Donnell wrote: >>> >>> >>> >>> >>> >>> >>> >>> Hi Jason/Tomaz, Early Access b134 for JDK 9 is available on >>> java.net, summary >>> of changes are listed here . >>> >>> There have been a number of fixes , since the last availability >>> email , to >>> bugs reported by Open Source projects : >>> >>> >>> * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a >>> strong >>> reference to the context class loader >>> * 8146961 Fix PermGen memory leaks caused by static final >>> Exceptions >>> * 8163353 NPE in ConcurrentHashMap.removeAll() >>> * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData >>> cannot be >>> cast to sun.java2d.xr.XRSurfaceData after xrandr change output >>> >>> >>> Secondly, there are a number of interesting items to bring to our >>> attention >>> >>> >>> * JDK 9 Rampdown Phase 1: Process proposal [1] >>> * The Java team has published the ?Oracle JRE and JDK >>> Cryptographic >>> Roadmap? [2] java.com/cryptoroadmap >>> * The Quality Report for September 2016 is now available [3], >>> thank you >>> for your continued support! >>> >>> Highlights from the Quality Report for September : >>> >>> >>> * 21 new Open Source projects have joined the Outreach program >>> * Projects filed 35 new issues in the JDK Bug System, this is >>> almost >>> double the number of bugs in the previous six months! >>> * Continuing to provide excellent feedback via the OpenJDK dev >>> mailing >>> lists >>> >>> >>> Thank you! >>> Rgds,Rory >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >>> [2] java.com/cryptoroadmap >>> [3] >>> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- 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/20160908/ddc2c0db/attachment-0001.html From asoldano at redhat.com Mon Sep 12 08:59:43 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 12 Sep 2016 14:59:43 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> Message-ID: <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> I've invested some hours of Sunday on hacking a prototype doing more or less what I explained below; see [1] . It builds using latest wise snapshots, which are on nexus, anyway the changes I applied to wise-gui are [2] In particular, there's a service [3] that starts the webapp programmatically; there's no more war deployment, the app is split into 3 modules plus few plain contents (html, js, css) in /wise. I see no sensible change in boot time compared to when there's no wise susbystem. Any comments? shall we spend a bit of time cleaning up the prototype and sending a PR with this new approach? Thanks Alessio [1] https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox [2] https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 [3] https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 Il 05/09/2016 00:20, Alessio Soldano ha scritto: > Il 31/08/2016 20:51, Jason Greene ha scritto: >>> 1. lazy deployment of the utility >> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. > I've thought about this a bit tonight...yes, the wise.war could be > exploded, its classes moved into the subsystem and the gtw and wise core > jars left as external libs in their own modules. As for the lazy start, > how about a service in the new wise subsystem that uses the WebHost > service to start the servlet app (would need to provide it with a > classloader including the required external libs mentioned before)? That > could be triggered (on/off) by operations in the subsystem. Then the > user would basically have to enable the gui using management (hal, cli). > > Cheers > Alessio > > -- Alessio Soldano Web Service Lead, JBoss From brian.stansberry at redhat.com Mon Sep 12 09:04:58 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Sep 2016 08:04:58 -0500 Subject: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives' In-Reply-To: <25AE2808-E2D0-4D7F-BFD6-C8F2710C43EF@redhat.com> References: <25AE2808-E2D0-4D7F-BFD6-C8F2710C43EF@redhat.com> Message-ID: <21A411FD-846B-4F8D-8C7C-E27428ABD7ED@redhat.com> > On Sep 12, 2016, at 7:44 AM, Heiko W.Rupp wrote: > > On 6 Sep 2016, at 15:10, Brian Stansberry wrote: > >> 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. > > Would this also include cases where e.g. a logger has an > attribute 'mode' which could be one of file, console, rsyslog > and then dependent attributes that are only usable with > one of the modes. Something like filename for 'file', > none for 'console' and 'remote-socket-binding' for 'rsyslog' ? > Both 'filename' and 'remote-socket-binding' would be > required only for their mode (and even forbidden otherwise). No, that kind of thing is not covered by this work. We have ?requires? metadata for an attribute that names other attributes that must be set if the given attribute is set, but that?s just a relationship based on defined vs undefined, not on any particular defined value. There would need to be some sort of new metadata added to cover what you describe. Perhaps something like ?requires-if => [ { ?value? => true, ?attributes? => [?another?, ?athird?] }, { ?value? => false, ?attributes? => [?afourth?, ?afifth?] }, ] Note that for something like that we couldn?t support it for attributes that allow expressions, as the validation of the constraint would need to happen before we?re able to accurately resolve expressions. But for enum attributes like your example I don?t think that would be an issue. I don?t imagine using an expression to control an enum would be a typical thing. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From smarlow at redhat.com Mon Sep 12 10:31:55 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 12 Sep 2016 10:31:55 -0400 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... Message-ID: Hi, I'm thinking that the NoSQL unit tests should be optional, since most WildFly developers won't have access to a local NoSQL database server. Currently, to run the unit tests, you have to define "nosql-tests" (e.g. ./integration-tests.sh -Dnosql-tests). As we work towards our first (NoSQL integration) pull requests for WildFly master (and some small wildfly-core changes to the Phase class), does anything else need to be optional? Currently we are building WildFly to include the NoSQL driver artifacts, for the specific versions of the drivers that we support. We also allow other versions of the NoSQL drivers to be brought into WildFly, as long as they are (API) compatible with the version that we (loosely) integrate with. Thanks for the feedback! Scott From darran.lofthouse at jboss.com Mon Sep 12 10:50:58 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 12 Sep 2016 15:50:58 +0100 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> Message-ID: <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> Once a subsystem is adding it's own web app programatcially does make me think we can't be far off being able to dynamically register it on the HTTP management interface (Standalone Mode), so rather than updating the configuration model for the management interface the additional context is defined in the subsystem that added it. On 12/09/16 13:59, Alessio Soldano wrote: > I've invested some hours of Sunday on hacking a prototype doing more or > less what I explained below; see [1] . It builds using latest wise > snapshots, which are on nexus, anyway the changes I applied to wise-gui > are [2] > In particular, there's a service [3] that starts the webapp > programmatically; there's no more war deployment, the app is split into > 3 modules plus few plain contents (html, js, css) in /wise. > I see no sensible change in boot time compared to when there's no wise > susbystem. > Any comments? shall we spend a bit of time cleaning up the prototype and > sending a PR with this new approach? > > Thanks > Alessio > > [1] > https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox > [2] > https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 > [3] > https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 > > Il 05/09/2016 00:20, Alessio Soldano ha scritto: >> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>> 1. lazy deployment of the utility >>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >> I've thought about this a bit tonight...yes, the wise.war could be >> exploded, its classes moved into the subsystem and the gtw and wise core >> jars left as external libs in their own modules. As for the lazy start, >> how about a service in the new wise subsystem that uses the WebHost >> service to start the servlet app (would need to provide it with a >> classloader including the required external libs mentioned before)? That >> could be triggered (on/off) by operations in the subsystem. Then the >> user would basically have to enable the gui using management (hal, cli). >> >> Cheers >> Alessio >> >> > > From brian.stansberry at redhat.com Mon Sep 12 11:00:11 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Sep 2016 10:00:11 -0500 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: References: Message-ID: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> > On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: > > Hi, > > I'm thinking that the NoSQL unit tests should be optional, since most > WildFly developers won't have access to a local NoSQL database server. > Currently, to run the unit tests, you have to define "nosql-tests" (e.g. > ./integration-tests.sh -Dnosql-tests). > The standard pattern for this kind of switch is something like -Dts.nosql So please stick with that pattern. How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. > As we work towards our first (NoSQL integration) pull requests for > WildFly master (and some small wildfly-core changes to the Phase class), > does anything else need to be optional? > > Currently we are building WildFly to include the NoSQL driver artifacts, > for the specific versions of the drivers that we support. We also allow > other versions of the NoSQL drivers to be brought into WildFly, as long > as they are (API) compatible with the version that we (loosely) > integrate with. > > Thanks for the feedback! > > Scott > _______________________________________________ > 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 asoldano at redhat.com Mon Sep 12 11:12:44 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 12 Sep 2016 17:12:44 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> Message-ID: Hi Darran, thanks for the feedback, but I'm not sure I really understand what you mean, can you give us few more details / explanations? Thanks Alessio Il 12/09/2016 16:50, Darran Lofthouse ha scritto: > Once a subsystem is adding it's own web app programatcially does make me > think we can't be far off being able to dynamically register it on the > HTTP management interface (Standalone Mode), so rather than updating the > configuration model for the management interface the additional context > is defined in the subsystem that added it. > > On 12/09/16 13:59, Alessio Soldano wrote: >> I've invested some hours of Sunday on hacking a prototype doing more or >> less what I explained below; see [1] . It builds using latest wise >> snapshots, which are on nexus, anyway the changes I applied to wise-gui >> are [2] >> In particular, there's a service [3] that starts the webapp >> programmatically; there's no more war deployment, the app is split into >> 3 modules plus few plain contents (html, js, css) in /wise. >> I see no sensible change in boot time compared to when there's no wise >> susbystem. >> Any comments? shall we spend a bit of time cleaning up the prototype and >> sending a PR with this new approach? >> >> Thanks >> Alessio >> >> [1] >> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >> [2] >> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 >> [3] >> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >> >> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >>> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>>> 1. lazy deployment of the utility >>>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >>> I've thought about this a bit tonight...yes, the wise.war could be >>> exploded, its classes moved into the subsystem and the gtw and wise core >>> jars left as external libs in their own modules. As for the lazy start, >>> how about a service in the new wise subsystem that uses the WebHost >>> service to start the servlet app (would need to provide it with a >>> classloader including the required external libs mentioned before)? That >>> could be triggered (on/off) by operations in the subsystem. Then the >>> user would basically have to enable the gui using management (hal, cli). >>> >>> Cheers >>> Alessio >>> >>> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Alessio Soldano Web Service Lead, JBoss From darran.lofthouse at jboss.com Mon Sep 12 11:26:48 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 12 Sep 2016 16:26:48 +0100 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> Message-ID: It was more a general comment for domain management rather than a direct comment on your PR. But say the subsystem could obtain a reference to the HTTP management interface, after creating the app it could register it as a new context on the management interface and be accessible on port 9990. Not saying this is something you should go ahead and do ;-) But it does open up options for adding custom management endpoints to that interface. Subsystems can also be defined on host controllers now so may even be options for domain mode. Darran. On 12/09/16 16:12, Alessio Soldano wrote: > Hi Darran, > thanks for the feedback, but I'm not sure I really understand what you > mean, can you give us few more details / explanations? > > Thanks > Alessio > > Il 12/09/2016 16:50, Darran Lofthouse ha scritto: >> Once a subsystem is adding it's own web app programatcially does make me >> think we can't be far off being able to dynamically register it on the >> HTTP management interface (Standalone Mode), so rather than updating the >> configuration model for the management interface the additional context >> is defined in the subsystem that added it. >> >> On 12/09/16 13:59, Alessio Soldano wrote: >>> I've invested some hours of Sunday on hacking a prototype doing more or >>> less what I explained below; see [1] . It builds using latest wise >>> snapshots, which are on nexus, anyway the changes I applied to wise-gui >>> are [2] >>> In particular, there's a service [3] that starts the webapp >>> programmatically; there's no more war deployment, the app is split into >>> 3 modules plus few plain contents (html, js, css) in /wise. >>> I see no sensible change in boot time compared to when there's no wise >>> susbystem. >>> Any comments? shall we spend a bit of time cleaning up the prototype and >>> sending a PR with this new approach? >>> >>> Thanks >>> Alessio >>> >>> [1] >>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >>> [2] >>> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 >>> [3] >>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >>> >>> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >>>> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>>>> 1. lazy deployment of the utility >>>>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >>>> I've thought about this a bit tonight...yes, the wise.war could be >>>> exploded, its classes moved into the subsystem and the gtw and wise core >>>> jars left as external libs in their own modules. As for the lazy start, >>>> how about a service in the new wise subsystem that uses the WebHost >>>> service to start the servlet app (would need to provide it with a >>>> classloader including the required external libs mentioned before)? That >>>> could be triggered (on/off) by operations in the subsystem. Then the >>>> user would basically have to enable the gui using management (hal, cli). >>>> >>>> Cheers >>>> Alessio >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From brian.stansberry at redhat.com Mon Sep 12 11:43:37 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Sep 2016 10:43:37 -0500 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> Message-ID: <6AF967CC-5F5E-46DF-8D6C-089F84B0FCEF@redhat.com> What you are doing in wise-sandbox is different from what would be involved with adding a context to the management interface. It?s integrating using the WebHost concept, which then brings in EE related APIs (servlets etc.) For what you?re doing to be proper, undertow would need to agree to expose WebHost as a proper capability and agree to support the entire API as a reliable contract. To integrate with the management interface we?d need to develop a different contract. > On Sep 12, 2016, at 10:12 AM, Alessio Soldano wrote: > > Hi Darran, > thanks for the feedback, but I'm not sure I really understand what you > mean, can you give us few more details / explanations? > > Thanks > Alessio > > Il 12/09/2016 16:50, Darran Lofthouse ha scritto: >> Once a subsystem is adding it's own web app programatcially does make me >> think we can't be far off being able to dynamically register it on the >> HTTP management interface (Standalone Mode), so rather than updating the >> configuration model for the management interface the additional context >> is defined in the subsystem that added it. >> >> On 12/09/16 13:59, Alessio Soldano wrote: >>> I've invested some hours of Sunday on hacking a prototype doing more or >>> less what I explained below; see [1] . It builds using latest wise >>> snapshots, which are on nexus, anyway the changes I applied to wise-gui >>> are [2] >>> In particular, there's a service [3] that starts the webapp >>> programmatically; there's no more war deployment, the app is split into >>> 3 modules plus few plain contents (html, js, css) in /wise. >>> I see no sensible change in boot time compared to when there's no wise >>> susbystem. >>> Any comments? shall we spend a bit of time cleaning up the prototype and >>> sending a PR with this new approach? >>> >>> Thanks >>> Alessio >>> >>> [1] >>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >>> [2] >>> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 >>> [3] >>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >>> >>> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >>>> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>>>> 1. lazy deployment of the utility >>>>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >>>> I've thought about this a bit tonight...yes, the wise.war could be >>>> exploded, its classes moved into the subsystem and the gtw and wise core >>>> jars left as external libs in their own modules. As for the lazy start, >>>> how about a service in the new wise subsystem that uses the WebHost >>>> service to start the servlet app (would need to provide it with a >>>> classloader including the required external libs mentioned before)? That >>>> could be triggered (on/off) by operations in the subsystem. Then the >>>> user would basically have to enable the gui using management (hal, cli). >>>> >>>> Cheers >>>> Alessio >>>> >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > 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 asoldano at redhat.com Mon Sep 12 11:48:58 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Mon, 12 Sep 2016 17:48:58 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <6AF967CC-5F5E-46DF-8D6C-089F84B0FCEF@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> <6AF967CC-5F5E-46DF-8D6C-089F84B0FCEF@redhat.com> Message-ID: <32860e0a-842b-d7e2-ca82-9f34f07a192a@redhat.com> Il 12/09/2016 17:43, Brian Stansberry ha scritto: > What you are doing in wise-sandbox is different from what would be involved with adding a context to the management interface. It?s integrating using the WebHost concept, which then brings in EE related APIs (servlets etc.) :) > > For what you?re doing to be proper, undertow would need to agree to expose WebHost as a proper capability and agree to support the entire API as a reliable contract. OK, just note that webservices subsystem already relies on WebHost almost the same way to support JAX-WS Endpoint.publish() API and XTS integration ;-) > To integrate with the management interface we?d need to develop a different contract Is this option anything we are going to actually explore? Cheers Alessio > > >> On Sep 12, 2016, at 10:12 AM, Alessio Soldano wrote: >> >> Hi Darran, >> thanks for the feedback, but I'm not sure I really understand what you >> mean, can you give us few more details / explanations? >> >> Thanks >> Alessio >> >> Il 12/09/2016 16:50, Darran Lofthouse ha scritto: >>> Once a subsystem is adding it's own web app programatcially does make me >>> think we can't be far off being able to dynamically register it on the >>> HTTP management interface (Standalone Mode), so rather than updating the >>> configuration model for the management interface the additional context >>> is defined in the subsystem that added it. >>> >>> On 12/09/16 13:59, Alessio Soldano wrote: >>>> I've invested some hours of Sunday on hacking a prototype doing more or >>>> less what I explained below; see [1] . It builds using latest wise >>>> snapshots, which are on nexus, anyway the changes I applied to wise-gui >>>> are [2] >>>> In particular, there's a service [3] that starts the webapp >>>> programmatically; there's no more war deployment, the app is split into >>>> 3 modules plus few plain contents (html, js, css) in /wise. >>>> I see no sensible change in boot time compared to when there's no wise >>>> susbystem. >>>> Any comments? shall we spend a bit of time cleaning up the prototype and >>>> sending a PR with this new approach? >>>> >>>> Thanks >>>> Alessio >>>> >>>> [1] >>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >>>> [2] >>>> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 >>>> [3] >>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >>>> >>>> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >>>>> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>>>>> 1. lazy deployment of the utility >>>>>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >>>>> I've thought about this a bit tonight...yes, the wise.war could be >>>>> exploded, its classes moved into the subsystem and the gtw and wise core >>>>> jars left as external libs in their own modules. As for the lazy start, >>>>> how about a service in the new wise subsystem that uses the WebHost >>>>> service to start the servlet app (would need to provide it with a >>>>> classloader including the required external libs mentioned before)? That >>>>> could be triggered (on/off) by operations in the subsystem. Then the >>>>> user would basically have to enable the gui using management (hal, cli). >>>>> >>>>> Cheers >>>>> Alessio >>>>> >>>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Alessio Soldano >> Web Service Lead, JBoss >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Alessio Soldano Web Service Lead, JBoss From brian.stansberry at redhat.com Mon Sep 12 11:59:43 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Sep 2016 10:59:43 -0500 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <32860e0a-842b-d7e2-ca82-9f34f07a192a@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> <6AF967CC-5F5E-46DF-8D6C-089F84B0FCEF@redhat.com> <32860e0a-842b-d7e2-ca82-9f34f07a192a@redhat.com> Message-ID: <5FF895A2-F365-4CD6-8B20-B458B6125B0E@redhat.com> > On Sep 12, 2016, at 10:48 AM, Alessio Soldano wrote: > > Il 12/09/2016 17:43, Brian Stansberry ha scritto: >> What you are doing in wise-sandbox is different from what would be involved with adding a context to the management interface. It?s integrating using the WebHost concept, which then brings in EE related APIs (servlets etc.) > :) >> >> For what you?re doing to be proper, undertow would need to agree to expose WebHost as a proper capability and agree to support the entire API as a reliable contract. > OK, just note that webservices subsystem already relies on WebHost almost the same way to support JAX-WS Endpoint.publish() API and XTS integration ;-) > That?s good. My comment above is kind of a general one. Where we have custom integrations between parts of the server those should be turned into proper capability-defined contracts. For sure we should do that before adding new ones. At a glance this WebHost stuff looks quite amenable to that since it?s a separate SPI from undertow. It may just be a matter of documenting the capability in https://github.com/wildfly/wildfly-capabilities and adding a small bit to undertow to expose it properly as a capability. >> To integrate with the management interface we?d need to develop a different contract > Is this option anything we are going to actually explore? Not any time in the next few months, no. > > Cheers > Alessio > > >> >> >>> On Sep 12, 2016, at 10:12 AM, Alessio Soldano wrote: >>> >>> Hi Darran, >>> thanks for the feedback, but I'm not sure I really understand what you >>> mean, can you give us few more details / explanations? >>> >>> Thanks >>> Alessio >>> >>> Il 12/09/2016 16:50, Darran Lofthouse ha scritto: >>>> Once a subsystem is adding it's own web app programatcially does make me >>>> think we can't be far off being able to dynamically register it on the >>>> HTTP management interface (Standalone Mode), so rather than updating the >>>> configuration model for the management interface the additional context >>>> is defined in the subsystem that added it. >>>> >>>> On 12/09/16 13:59, Alessio Soldano wrote: >>>>> I've invested some hours of Sunday on hacking a prototype doing more or >>>>> less what I explained below; see [1] . It builds using latest wise >>>>> snapshots, which are on nexus, anyway the changes I applied to wise-gui >>>>> are [2] >>>>> In particular, there's a service [3] that starts the webapp >>>>> programmatically; there's no more war deployment, the app is split into >>>>> 3 modules plus few plain contents (html, js, css) in /wise. >>>>> I see no sensible change in boot time compared to when there's no wise >>>>> susbystem. >>>>> Any comments? shall we spend a bit of time cleaning up the prototype and >>>>> sending a PR with this new approach? >>>>> >>>>> Thanks >>>>> Alessio >>>>> >>>>> [1] >>>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >>>>> [2] >>>>> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 >>>>> [3] >>>>> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >>>>> >>>>> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >>>>>> Il 31/08/2016 20:51, Jason Greene ha scritto: >>>>>>>> 1. lazy deployment of the utility >>>>>>> What did you have in mind? This sounds tricky. You could perhaps have the subsystem register an http handler that dynamically installs the server, but if you are going that far it?s best to just register the components directly as part of the subsystem than in a deployment. >>>>>> I've thought about this a bit tonight...yes, the wise.war could be >>>>>> exploded, its classes moved into the subsystem and the gtw and wise core >>>>>> jars left as external libs in their own modules. As for the lazy start, >>>>>> how about a service in the new wise subsystem that uses the WebHost >>>>>> service to start the servlet app (would need to provide it with a >>>>>> classloader including the required external libs mentioned before)? That >>>>>> could be triggered (on/off) by operations in the subsystem. Then the >>>>>> user would basically have to enable the gui using management (hal, cli). >>>>>> >>>>>> Cheers >>>>>> Alessio >>>>>> >>>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Alessio Soldano >>> Web Service Lead, JBoss >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Alessio Soldano > Web Service Lead, JBoss -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From smarlow at redhat.com Mon Sep 12 12:42:57 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 12 Sep 2016 12:42:57 -0400 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> References: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> Message-ID: On 09/12/2016 11:00 AM, Brian Stansberry wrote: > >> On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: >> >> Hi, >> >> I'm thinking that the NoSQL unit tests should be optional, since most >> WildFly developers won't have access to a local NoSQL database server. >> Currently, to run the unit tests, you have to define "nosql-tests" (e.g. >> ./integration-tests.sh -Dnosql-tests). >> > > The standard pattern for this kind of switch is something like > > -Dts.nosql Thanks, we will switch over to -Dts.nosql > > So please stick with that pattern. > > How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases. I did a -DallTests run and the NoSQL tests were included. > > That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. > >> As we work towards our first (NoSQL integration) pull requests for >> WildFly master (and some small wildfly-core changes to the Phase class), >> does anything else need to be optional? >> >> Currently we are building WildFly to include the NoSQL driver artifacts, >> for the specific versions of the drivers that we support. We also allow >> other versions of the NoSQL drivers to be brought into WildFly, as long >> as they are (API) compatible with the version that we (loosely) >> integrate with. >> >> Thanks for the feedback! >> >> Scott >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Mon Sep 12 12:52:17 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Sep 2016 11:52:17 -0500 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: References: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> Message-ID: > On Sep 12, 2016, at 11:42 AM, Scott Marlow wrote: > > > > On 09/12/2016 11:00 AM, Brian Stansberry wrote: >> >>> On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: >>> >>> Hi, >>> >>> I'm thinking that the NoSQL unit tests should be optional, since most >>> WildFly developers won't have access to a local NoSQL database server. >>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g. >>> ./integration-tests.sh -Dnosql-tests). >>> >> >> The standard pattern for this kind of switch is something like >> >> -Dts.nosql > > Thanks, we will switch over to -Dts.nosql > >> >> So please stick with that pattern. >> >> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. > > I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases. > > I did a -DallTests run and the NoSQL tests were included. Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn?t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;) Is there any property that defines how to have "(local) access to all of the NoSQL databases?? I ask because in the case of testsuite/mixed domain, there is ? a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There?s no -Dts.mixed-domain involved as that would just have been an extra thing to set. > >> >> That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. >> >>> As we work towards our first (NoSQL integration) pull requests for >>> WildFly master (and some small wildfly-core changes to the Phase class), >>> does anything else need to be optional? >>> >>> Currently we are building WildFly to include the NoSQL driver artifacts, >>> for the specific versions of the drivers that we support. We also allow >>> other versions of the NoSQL drivers to be brought into WildFly, as long >>> as they are (API) compatible with the version that we (loosely) >>> integrate with. >>> >>> Thanks for the feedback! >>> >>> Scott >>> _______________________________________________ >>> 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 stuart.w.douglas at gmail.com Mon Sep 12 18:27:30 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 13 Sep 2016 08:27:30 +1000 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> Message-ID: How are you going to handle security? At the moment WebHost does not really allow you to set security domains etc. Are you planning on expanding it's functionality to cover this? BTW in many ways WebHost is a bit of a legacy artifact. It was introduced back when we supported both JBoss Web and Undertow. It may end up being better to just use Undertow API's directly, as I don't know if we really need the abstraction any more. Stuart On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano wrote: > I've invested some hours of Sunday on hacking a prototype doing more or > less what I explained below; see [1] . It builds using latest wise > snapshots, which are on nexus, anyway the changes I applied to wise-gui > are [2] > In particular, there's a service [3] that starts the webapp > programmatically; there's no more war deployment, the app is split into > 3 modules plus few plain contents (html, js, css) in /wise. > I see no sensible change in boot time compared to when there's no wise > susbystem. > Any comments? shall we spend a bit of time cleaning up the prototype and > sending a PR with this new approach? > > Thanks > Alessio > > [1] > https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox > [2] > https://github.com/asoldano/wise-gwt-gui/commit/ > 679fad6e3f9244f1c1caf7507434dff0fbfe5701 > [3] > https://github.com/wildfly/wildfly/compare/master... > asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 > > Il 05/09/2016 00:20, Alessio Soldano ha scritto: > > Il 31/08/2016 20:51, Jason Greene ha scritto: > >>> 1. lazy deployment of the utility > >> What did you have in mind? This sounds tricky. You could perhaps have > the subsystem register an http handler that dynamically installs the > server, but if you are going that far it?s best to just register the > components directly as part of the subsystem than in a deployment. > > I've thought about this a bit tonight...yes, the wise.war could be > > exploded, its classes moved into the subsystem and the gtw and wise core > > jars left as external libs in their own modules. As for the lazy start, > > how about a service in the new wise subsystem that uses the WebHost > > service to start the servlet app (would need to provide it with a > > classloader including the required external libs mentioned before)? That > > could be triggered (on/off) by operations in the subsystem. Then the > > user would basically have to enable the gui using management (hal, cli). > > > > Cheers > > Alessio > > > > > > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > 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/20160913/1574cf88/attachment-0001.html From asoldano at redhat.com Mon Sep 12 18:44:08 2016 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 13 Sep 2016 00:44:08 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> Message-ID: Il 13/09/2016 00:27, Stuart Douglas ha scritto: > How are you going to handle security? At the moment WebHost does not > really allow you to set security domains etc. Are you planning on > expanding it's functionality to cover this? oh, didn't notice that, I expected to setup security providing the same conf options that were in web.xml/jboss-web.xml in the war deployment. This said, I see that io.undertow.servlet.api.DeploymentInfo has that stuff, so I assume it should be possible to expand WebHostService and WebDeploymentBuilder a bit, similarly to what I did for supporting welcome pages. > > BTW in many ways WebHost is a bit of a legacy artifact. It was > introduced back when we supported both JBoss Web and Undertow. It may > end up being better to just use Undertow API's directly, as I don't > know if we really need the abstraction any more. What do you mean, directly doing the same that WebHostService does with the Undertow api in a service of mine? Thanks Alessio > > Stuart > > On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano > wrote: > > I've invested some hours of Sunday on hacking a prototype doing > more or > less what I explained below; see [1] . It builds using latest wise > snapshots, which are on nexus, anyway the changes I applied to > wise-gui > are [2] > In particular, there's a service [3] that starts the webapp > programmatically; there's no more war deployment, the app is split > into > 3 modules plus few plain contents (html, js, css) in /wise. > I see no sensible change in boot time compared to when there's no wise > susbystem. > Any comments? shall we spend a bit of time cleaning up the > prototype and > sending a PR with this new approach? > > Thanks > Alessio > > [1] > https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox > > [2] > https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f9244f1c1caf7507434dff0fbfe5701 > > [3] > https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 > > > Il 05/09/2016 00:20, Alessio Soldano ha scritto: > > Il 31/08/2016 20:51, Jason Greene ha scritto: > >>> 1. lazy deployment of the utility > >> What did you have in mind? This sounds tricky. You could > perhaps have the subsystem register an http handler that > dynamically installs the server, but if you are going that far > it?s best to just register the components directly as part of the > subsystem than in a deployment. > > I've thought about this a bit tonight...yes, the wise.war could be > > exploded, its classes moved into the subsystem and the gtw and > wise core > > jars left as external libs in their own modules. As for the lazy > start, > > how about a service in the new wise subsystem that uses the WebHost > > service to start the servlet app (would need to provide it with a > > classloader including the required external libs mentioned > before)? That > > could be triggered (on/off) by operations in the subsystem. Then the > > user would basically have to enable the gui using management > (hal, cli). > > > > Cheers > > Alessio > > > > > > > -- > Alessio Soldano > Web Service Lead, JBoss > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- Alessio Soldano Web Service Lead, JBoss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160913/f7028d95/attachment.html From stuart.w.douglas at gmail.com Mon Sep 12 19:01:53 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 13 Sep 2016 09:01:53 +1000 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> Message-ID: On Tue, Sep 13, 2016 at 8:44 AM, Alessio Soldano wrote: > Il 13/09/2016 00:27, Stuart Douglas ha scritto: > > How are you going to handle security? At the moment WebHost does not > really allow you to set security domains etc. Are you planning on expanding > it's functionality to cover this? > > oh, didn't notice that, I expected to setup security providing the same > conf options that were in web.xml/jboss-web.xml in the war deployment. This > said, I see that io.undertow.servlet.api.DeploymentInfo has that stuff, > so I assume it should be possible to expand WebHostService and > WebDeploymentBuilder a bit, similarly to what I did for supporting welcome > pages. > > > BTW in many ways WebHost is a bit of a legacy artifact. It was introduced > back when we supported both JBoss Web and Undertow. It may end up being > better to just use Undertow API's directly, as I don't know if we really > need the abstraction any more. > > What do you mean, directly doing the same that WebHostService does with > the Undertow api in a service of mine? > I am more thinking about exposing the Undertow DeploymentInfo API directly, although I guess you would still need something similar to the WebHost service to provide integration with security domain etc (as that is provided by the Undertow subsystem, not Undertow itself). Basically to add support for security we are going to need some way of specifying the constraints etc, which the DeploymentInfo API already does. It seems kind of silly to duplicate this. Stuart > > Thanks > Alessio > > > > Stuart > > On Mon, Sep 12, 2016 at 10:59 PM, Alessio Soldano > wrote: > >> I've invested some hours of Sunday on hacking a prototype doing more or >> less what I explained below; see [1] . It builds using latest wise >> snapshots, which are on nexus, anyway the changes I applied to wise-gui >> are [2] >> In particular, there's a service [3] that starts the webapp >> programmatically; there's no more war deployment, the app is split into >> 3 modules plus few plain contents (html, js, css) in /wise. >> I see no sensible change in boot time compared to when there's no wise >> susbystem. >> Any comments? shall we spend a bit of time cleaning up the prototype and >> sending a PR with this new approach? >> >> Thanks >> Alessio >> >> [1] >> https://github.com/wildfly/wildfly/compare/master...asoldano:wise-sandbox >> [2] >> https://github.com/asoldano/wise-gwt-gui/commit/679fad6e3f92 >> 44f1c1caf7507434dff0fbfe5701 >> [3] >> https://github.com/wildfly/wildfly/compare/master...asoldano >> :wise-sandbox#diff-0623bdf83c3d80b3ba52d0b82f89efc7R77 >> >> Il 05/09/2016 00:20, Alessio Soldano ha scritto: >> > Il 31/08/2016 20:51, Jason Greene ha scritto: >> >>> 1. lazy deployment of the utility >> >> What did you have in mind? This sounds tricky. You could perhaps have >> the subsystem register an http handler that dynamically installs the >> server, but if you are going that far it?s best to just register the >> components directly as part of the subsystem than in a deployment. >> > I've thought about this a bit tonight...yes, the wise.war could be >> > exploded, its classes moved into the subsystem and the gtw and wise core >> > jars left as external libs in their own modules. As for the lazy start, >> > how about a service in the new wise subsystem that uses the WebHost >> > service to start the servlet app (would need to provide it with a >> > classloader including the required external libs mentioned before)? That >> > could be triggered (on/off) by operations in the subsystem. Then the >> > user would basically have to enable the gui using management (hal, cli). >> > >> > Cheers >> > Alessio >> > >> > >> >> >> -- >> Alessio Soldano >> Web Service Lead, JBoss >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Alessio Soldano > Web Service Lead, JBoss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160913/443a1d23/attachment.html From ttarrant at redhat.com Tue Sep 13 03:08:24 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 13 Sep 2016 09:08:24 +0200 Subject: [wildfly-dev] WildFly's transaction subsystem needs a diet (too much Artemis!) Message-ID: Hi all, ever since wildfly-core was conceived I've wanted to deliver an Infinispan Server distribution based on it using a feature-pack. Unfortunately this has not been possible because we depend on two subsystems which are not part of core: datasource and transactions. Our current approach, therefore, implements a feature pack based on the full wildfly. We then use some scripts to build a tree of module dependencies, we identify unused modules and we trim them from the final distribution. Unfortunately this trimming is not effective as it could be because of the org.jboss.as.transactions module which pulls in a ton of nono-optional dependencies. You can find the dependency tree at the end of this e-mail. In particular the culprit seems to be org.jboss.jts which depends on org.apache.activemq.artemis which in turn is a kitchen-sink of artemis-* dependencies. [1] I guess Narayana is only really interested in Artemis' journal, so the laziness of the artemis module is particularly painful. Can the artemis-journal/artemis-native jars be split out into their own independent module ? This might be harder than it seems as the journal classes seem to depend on artemis-server, so deeper surgery is needed. Tristan [1] https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/jts/main/module.xml#L44 org.jboss.as.transactions org.jboss.jboss-transaction-spi javax.resource.api org.jboss.jts org.omg.api javax.orb.api org.wildfly.iiop-openjdk org.jboss.metadata.ejb org.jboss.jts.integration org.jboss.iiop-client javax.ejb.api javax.xml.rpc.api javax.xml.soap.api javax.rmi.api org.apache.activemq.artemis com.google.guava javax.jms.api org.apache.commons.beanutils org.wildfly.extension.messaging-activemq org.apache.activemq.artemis.ra org.jboss.as.cli org.jboss.aesh org.fusesource.jansi org.wildfly.embedded org.jboss.as.weld ch.qos.cal10n javax.persistence.api org.hibernate.validator.cdi org.hibernate.validator com.fasterxml.classmate org.jboss.weld.core org.jboss.weld.api org.jboss.weld.spi org.jsoup org.wildfly.extension.bean-validation org.jboss.as.ejb3 org.hibernate org.wildfly.clustering.api org.wildfly.clustering.ee.spi org.wildfly.clustering.ejb.spi org.jboss.ejb-client org.wildfly.clustering.service org.wildfly.clustering.marshalling.api org.wildfly.clustering.marshalling.jboss org.wildfly.clustering.spi org.wildfly.clustering.ejb.infinispan org.wildfly.clustering.ee.infinispan org.wildfly.clustering.infinispan.spi org.wildfly.clustering.server org.wildfly.clustering.jgroups.spi org.wildfly.clustering.jgroups.api org.wildfly.clustering.singleton org.wildfly.clustering.web.infinispan net.jcip org.wildfly.clustering.web.api org.wildfly.clustering.web.spi org.jboss.as.connector org.jboss.ironjacamar.api org.jboss.ironjacamar.impl org.jboss.ironjacamar.jdbcadapters org.jboss.ejb3 org.jboss.as.webservices.server.integration asm.asm javax.jws.api javax.wsdl4j.api javax.xml.ws.api org.jboss.as.webservices com.sun.xml.messaging.saaj org.apache.ws.security org.apache.neethi org.opensaml org.bouncycastle org.jboss.xts org.jboss.narayana.compensations org.jboss.narayana.txframework org.slf4j.ext org.hornetq.client -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From kabir.khan at jboss.com Tue Sep 13 05:35:44 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 13 Sep 2016 10:35:44 +0100 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: References: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> Message-ID: > On 12 Sep 2016, at 17:52, Brian Stansberry wrote: > > >> On Sep 12, 2016, at 11:42 AM, Scott Marlow wrote: >> >> >> >> On 09/12/2016 11:00 AM, Brian Stansberry wrote: >>> >>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: >>>> >>>> Hi, >>>> >>>> I'm thinking that the NoSQL unit tests should be optional, since most >>>> WildFly developers won't have access to a local NoSQL database server. >>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g. >>>> ./integration-tests.sh -Dnosql-tests). >>>> >>> >>> The standard pattern for this kind of switch is something like >>> >>> -Dts.nosql >> >> Thanks, we will switch over to -Dts.nosql >> >>> >>> So please stick with that pattern. >>> >>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. >> >> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases. >> >> I did a -DallTests run and the NoSQL tests were included. > > Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn?t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;) To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder The jboss.test.mixed.domain.dir property servers two purposes: - tells testsuite/mixed-domain where to find the directory containing the zips - in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml: mixed-domain.module.profile jboss.test.mixed.domain.dir mixed-domain > > Is there any property that defines how to have "(local) access to all of the NoSQL databases?? > > I ask because in the case of testsuite/mixed domain, there is ? a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There?s no -Dts.mixed-domain involved as that would just have been an extra thing to set. > >> >>> >>> That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. >>> >>>> As we work towards our first (NoSQL integration) pull requests for >>>> WildFly master (and some small wildfly-core changes to the Phase class), >>>> does anything else need to be optional? >>>> >>>> Currently we are building WildFly to include the NoSQL driver artifacts, >>>> for the specific versions of the drivers that we support. We also allow >>>> other versions of the NoSQL drivers to be brought into WildFly, as long >>>> as they are (API) compatible with the version that we (loosely) >>>> integrate with. >>>> >>>> Thanks for the feedback! >>>> >>>> Scott >>>> _______________________________________________ >>>> 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 ttarrant at redhat.com Tue Sep 13 06:46:08 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 13 Sep 2016 12:46:08 +0200 Subject: [wildfly-dev] Subsystems changing their own configuration model Message-ID: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> We would like to allow a subsystem to modify its configuration model by itself at runtime. The use case for this is that we would like to let a remote Hot Rod client create a cache on an Infinispan server and making that configuration persistent across restarts. I understand this is creating management ops which are orthogonal to the server's. I guess that in standalone mode this wouldn't be too much of an issue, with two caveats: - all nodes in a cluster should apply the changes to their own configuration, leveraging the model rollback mechanism to handle failures on other nodes - new nodes joining the cluster (and therefore with a possibly outdated configuration) would receive the configuration of caches already running in the cluster and applying them locally The real tricky bit is obviously domain mode. The server receiving the cache creation request would need to delegate it to the DC who would then apply it across the profile. However this clashes with the fact that, as far as I know, there is no way for a server to communicate with its DC. Is this type of functionality planned ? I have created a document which describes what we'd like to do at [1] Tristan [1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From anilsaldhana at gmail.com Tue Sep 13 07:17:32 2016 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Tue, 13 Sep 2016 06:17:32 -0500 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: References: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> Message-ID: Kabir - hi. Should this info be put on a wiki page for Wildfly community for test instructions? :-) > On Sep 13, 2016, at 4:35 AM, Kabir Khan wrote: > > >> On 12 Sep 2016, at 17:52, Brian Stansberry wrote: >> >> >>> On Sep 12, 2016, at 11:42 AM, Scott Marlow wrote: >>> >>> >>> >>>> On 09/12/2016 11:00 AM, Brian Stansberry wrote: >>>> >>>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm thinking that the NoSQL unit tests should be optional, since most >>>>> WildFly developers won't have access to a local NoSQL database server. >>>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g. >>>>> ./integration-tests.sh -Dnosql-tests). >>>> >>>> The standard pattern for this kind of switch is something like >>>> >>>> -Dts.nosql >>> >>> Thanks, we will switch over to -Dts.nosql >>> >>>> >>>> So please stick with that pattern. >>>> >>>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. >>> >>> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases. >>> >>> I did a -DallTests run and the NoSQL tests were included. >> >> Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn?t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;) > > > To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder > > The jboss.test.mixed.domain.dir property servers two purposes: > - tells testsuite/mixed-domain where to find the directory containing the zips > - in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml: > > > mixed-domain.module.profile > jboss.test.mixed.domain.dir > > mixed-domain > > > > >> >> Is there any property that defines how to have "(local) access to all of the NoSQL databases?? >> >> I ask because in the case of testsuite/mixed domain, there is ? a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There?s no -Dts.mixed-domain involved as that would just have been an extra thing to set. >> >>> >>>> >>>> That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. >>>> >>>>> As we work towards our first (NoSQL integration) pull requests for >>>>> WildFly master (and some small wildfly-core changes to the Phase class), >>>>> does anything else need to be optional? >>>>> >>>>> Currently we are building WildFly to include the NoSQL driver artifacts, >>>>> for the specific versions of the drivers that we support. We also allow >>>>> other versions of the NoSQL drivers to be brought into WildFly, as long >>>>> as they are (API) compatible with the version that we (loosely) >>>>> integrate with. >>>>> >>>>> Thanks for the feedback! >>>>> >>>>> Scott >>>>> _______________________________________________ >>>>> 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 ttarrant at redhat.com Tue Sep 13 09:12:29 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 13 Sep 2016 15:12:29 +0200 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> Message-ID: <477ec87d-98a4-79f4-2c93-58b0801960fe@redhat.com> On 12/09/16 17:26, Darran Lofthouse wrote: > But say the subsystem could obtain a reference to the HTTP management > interface, after creating the app it could register it as a new context > on the management interface and be accessible on port 9990. Having the ability to register custom handlers on the management interface is something we need. Is there a tracking Jira ? Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From brian.stansberry at redhat.com Tue Sep 13 09:17:51 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 13 Sep 2016 08:17:51 -0500 Subject: [wildfly-dev] question 2 sec boot time of WISE In-Reply-To: <477ec87d-98a4-79f4-2c93-58b0801960fe@redhat.com> References: <392730097.7474774.1472573705630.JavaMail.zimbra@redhat.com> <55BA9ADA-21C3-4B6B-98E6-3E349AB59B2F@redhat.com> <2a513219-a665-c767-1d45-a94efe6d6b64@redhat.com> <27987600-8a67-9601-a97a-1acc3e83c09c@redhat.com> <8e1809fe-b482-f533-dbf1-f3b028c8046e@jboss.com> <477ec87d-98a4-79f4-2c93-58b0801960fe@redhat.com> Message-ID: <5775F018-D921-4863-B883-2701AE9397CD@redhat.com> > On Sep 13, 2016, at 8:12 AM, Tristan Tarrant wrote: > > On 12/09/16 17:26, Darran Lofthouse wrote: >> But say the subsystem could obtain a reference to the HTTP management >> interface, after creating the app it could register it as a new context >> on the management interface and be accessible on port 9990. > > Having the ability to register custom handlers on the management > interface is something we need. Is there a tracking Jira ? > https://issues.jboss.org/browse/WFCORE-1742 > Tristan > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Sep 13 16:40:58 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 13 Sep 2016 15:40:58 -0500 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: > On Sep 13, 2016, at 5:46 AM, Tristan Tarrant wrote: > > We would like to allow a subsystem to modify its configuration model by > itself at runtime. The use case for this is that we would like to let a > remote Hot Rod client create a cache on an Infinispan server and making > that configuration persistent across restarts. I understand this is > creating management ops which are orthogonal to the server?s. > There is nothing fundamental that says you can?t do this so long as you?re not trying to execute these ops as part of the start/stop of an MSC service. It doesn?t sound like that?s the case. It does sound though like you want to expose management over the non-management interface. That?s a significant security hole. > I guess that in standalone mode this wouldn't be too much of an issue, > with two caveats: > - all nodes in a cluster should apply the changes to their own > configuration, leveraging the model rollback mechanism to handle > failures on other nodes There is no multi-process model rollback mechanism with standalone servers. > - new nodes joining the cluster (and therefore with a possibly outdated > configuration) would receive the configuration of caches already running > in the cluster and applying them locally > How does this happen? > The real tricky bit is obviously domain mode. The server receiving the > cache creation request would need to delegate it to the DC who would > then apply it across the profile. However this clashes with the fact > that, as far as I know, there is no way for a server to communicate with > its DC. Is this type of functionality planned ? > Not actively. We looked into it a bit in the context of DOMAIN_PING but for that use case it became apparent that invoking a bunch of management ops against the DC was a non-scalable solution. This sounds different; a server would need to figure out what profile stores the infinispan subsystem config (it may not be the final one associated with the server group since profile x can include profile y) and then make a change to that profile. That?s scalable. If we set up this kind of connection we?d need to ensure the caller?s security context propagates. Having an external request come in to a server and then get treated by the DC as if it were from a trusted caller like a slave HC or server would be bad. > I have created a document which describes what we'd like to do at [1] > > Tristan > > > [1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of 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 ttarrant at redhat.com Wed Sep 14 04:54:55 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 14 Sep 2016 10:54:55 +0200 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: On 13/09/16 22:40, Brian Stansberry wrote: >> > > There is nothing fundamental that says you can?t do this so long as you?re not trying to execute these ops as part of the start/stop of an MSC service. It doesn?t sound like that?s the case. Indeed. > It does sound though like you want to expose management over the non-management interface. That?s a significant security hole. Well, it is a protocol operation which has a management side-effect. The way we have approached that in other similar situations is to either require access through a loopback interface or require authentication and authorization be enabled on the endpoint and an Admin permission on the subject requesting the operation. Note however that the Hot Rod endpoint would be using a different security realm compared to the management one. >> I guess that in standalone mode this wouldn't be too much of an issue, >> with two caveats: >> - all nodes in a cluster should apply the changes to their own >> configuration, leveraging the model rollback mechanism to handle >> failures on other nodes > > There is no multi-process model rollback mechanism with standalone servers. I know: this would have to be implemented by the subsystem using the cluster transport. >> - new nodes joining the cluster (and therefore with a possibly outdated >> configuration) would receive the configuration of caches already running >> in the cluster and applying them locally >> > > How does this happen? Again, via the cluster transport. >> The real tricky bit is obviously domain mode. The server receiving the >> cache creation request would need to delegate it to the DC who would >> then apply it across the profile. However this clashes with the fact >> that, as far as I know, there is no way for a server to communicate with >> its DC. Is this type of functionality planned ? >> > > Not actively. We looked into it a bit in the context of DOMAIN_PING but for that use case it became apparent that invoking a bunch of management ops against the DC was a non-scalable solution. This sounds different; a server would need to figure out what profile stores the infinispan subsystem config (it may not be the final one associated with the server group since profile x can include profile y) and then make a change to that profile. That?s scalable. > > If we set up this kind of connection we?d need to ensure the caller?s security context propagates. Having an external request come in to a server and then get treated by the DC as if it were from a trusted caller like a slave HC or server would be bad. As described above, the caller might not be in the same security realm as the management stuff. >> I have created a document which describes what we'd like to do at [1] >> >> Tristan >> >> >> [1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod >> >> -- >> Tristan Tarrant >> Infinispan Lead >> JBoss, a division of Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From tomaz.cerar at gmail.com Wed Sep 14 05:19:53 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 14 Sep 2016 11:19:53 +0200 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: On Wed, Sep 14, 2016 at 10:54 AM, Tristan Tarrant wrote: > >> - new nodes joining the cluster (and therefore with a possibly outdated > >> configuration) would receive the configuration of caches already running > >> in the cluster and applying them locally > >> > > > > How does this happen? > > Again, via the cluster transport. > How can his be? Isn't the cache configuration managed by mgmt configuration. so as such would always be "latest" or does cache change its own configuration independently? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160914/f4b650df/attachment.html From darran.lofthouse at jboss.com Wed Sep 14 05:24:05 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 14 Sep 2016 10:24:05 +0100 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: On 14/09/16 09:54, Tristan Tarrant wrote: > On 13/09/16 22:40, Brian Stansberry wrote: >>> >> >> There is nothing fundamental that says you can?t do this so long as you?re not trying to execute these ops as part of the start/stop of an MSC service. It doesn?t sound like that?s the case. > > Indeed. > >> It does sound though like you want to expose management over the non-management interface. That?s a significant security hole. > > Well, it is a protocol operation which has a management side-effect. The > way we have approached that in other similar situations is to either > require access through a loopback interface or require authentication > and authorization be enabled on the endpoint and an Admin permission on > the subject requesting the operation. Note however that the Hot Rod > endpoint would be using a different security realm compared to the > management one. FYI for WildFly 11 if a call remains in-VM and goes from the application to the management tier we will have a mechanism for the identity to be inflowed to the security domain used for management which will allow management access control to be used. >>> I guess that in standalone mode this wouldn't be too much of an issue, >>> with two caveats: >>> - all nodes in a cluster should apply the changes to their own >>> configuration, leveraging the model rollback mechanism to handle >>> failures on other nodes >> >> There is no multi-process model rollback mechanism with standalone servers. > > I know: this would have to be implemented by the subsystem using the > cluster transport. > >>> - new nodes joining the cluster (and therefore with a possibly outdated >>> configuration) would receive the configuration of caches already running >>> in the cluster and applying them locally >>> >> >> How does this happen? > > Again, via the cluster transport. > >>> The real tricky bit is obviously domain mode. The server receiving the >>> cache creation request would need to delegate it to the DC who would >>> then apply it across the profile. However this clashes with the fact >>> that, as far as I know, there is no way for a server to communicate with >>> its DC. Is this type of functionality planned ? >>> >> >> Not actively. We looked into it a bit in the context of DOMAIN_PING but for that use case it became apparent that invoking a bunch of management ops against the DC was a non-scalable solution. This sounds different; a server would need to figure out what profile stores the infinispan subsystem config (it may not be the final one associated with the server group since profile x can include profile y) and then make a change to that profile. That?s scalable. >> >> If we set up this kind of connection we?d need to ensure the caller?s security context propagates. Having an external request come in to a server and then get treated by the DC as if it were from a trusted caller like a slave HC or server would be bad. > > As described above, the caller might not be in the same security realm > as the management stuff. > > >>> I have created a document which describes what we'd like to do at [1] >>> >>> Tristan >>> >>> >>> [1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod >>> >>> -- >>> Tristan Tarrant >>> Infinispan Lead >>> JBoss, a division of Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > From ttarrant at redhat.com Wed Sep 14 05:34:17 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 14 Sep 2016 11:34:17 +0200 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: <3500fea4-f7a8-e653-f44a-ac94e8e0852d@redhat.com> On 14/09/16 11:19, Toma? Cerar wrote: > > On Wed, Sep 14, 2016 at 10:54 AM, Tristan Tarrant > wrote: > > >> - new nodes joining the cluster (and therefore with a possibly outdated > >> configuration) would receive the configuration of caches already running > >> in the cluster and applying them locally > >> > > > > How does this happen? > > Again, via the cluster transport. > > > > How can his be? Isn't the cache configuration managed by mgmt configuration. > so as such would always be "latest" or does cache change its own > configuration independently? This would be limited to creating or removing a cache using an existing configuration template. Example: I have a cluster of two standalone nodes A and B with a cache X running. A client requests the creation of a cache Y and both A and B add that. Node C which joins the cluster later will also need to start cache X. You are probably going to tell me that this is something Domain management should do, or some external configuration provisioning system (e.g. Ansible). I'm exploring the various possibilities here to see what can be done. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Wed Sep 14 05:37:42 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 14 Sep 2016 11:37:42 +0200 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> Message-ID: <4b37eba3-3578-e68a-466f-45c0a0eee06c@redhat.com> On 14/09/16 11:24, Darran Lofthouse wrote: > On 14/09/16 09:54, Tristan Tarrant wrote: >> Well, it is a protocol operation which has a management side-effect. The >> way we have approached that in other similar situations is to either >> require access through a loopback interface or require authentication >> and authorization be enabled on the endpoint and an Admin permission on >> the subject requesting the operation. Note however that the Hot Rod >> endpoint would be using a different security realm compared to the >> management one. > FYI for WildFly 11 if a call remains in-VM and goes from the application > to the management tier we will have a mechanism for the identity to be > inflowed to the security domain used for management which will allow > management access control to be used. That would require the identity to be present in both "security realms" (or whatever their equivalent is in WF11) ? Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From darran.lofthouse at jboss.com Wed Sep 14 05:44:40 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 14 Sep 2016 10:44:40 +0100 Subject: [wildfly-dev] Subsystems changing their own configuration model In-Reply-To: <4b37eba3-3578-e68a-466f-45c0a0eee06c@redhat.com> References: <32bf9757-f699-d3da-fede-9684bd642917@redhat.com> <4b37eba3-3578-e68a-466f-45c0a0eee06c@redhat.com> Message-ID: On 14/09/16 10:37, Tristan Tarrant wrote: > On 14/09/16 11:24, Darran Lofthouse wrote: >> On 14/09/16 09:54, Tristan Tarrant wrote: >>> Well, it is a protocol operation which has a management side-effect. The >>> way we have approached that in other similar situations is to either >>> require access through a loopback interface or require authentication >>> and authorization be enabled on the endpoint and an Admin permission on >>> the subject requesting the operation. Note however that the Hot Rod >>> endpoint would be using a different security realm compared to the >>> management one. >> FYI for WildFly 11 if a call remains in-VM and goes from the application >> to the management tier we will have a mechanism for the identity to be >> inflowed to the security domain used for management which will allow >> management access control to be used. > That would require the identity to be present in both "security realms" > (or whatever their equivalent is in WF11) ? Generally yes - but there is quite a bit more to it. A security domain can reference multiple security realms, in addition to this there are ways to structure the new configuration so that identity does not have direct access to the management tier. Also the identity will look very different depending on which tier it is in as each tier will have it's own security domain with it's own configuration for role and permission mapping. > Tristan > From brian.stansberry at redhat.com Thu Sep 15 08:21:08 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 15 Sep 2016 07:21:08 -0500 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> Message-ID: <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> I?m adding wildfly-dev in cc. Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: ?attribute? ? required=true, alternatives=[parameter] ?parameter - required=true, alternatives=[attribute], requires=[operation] ?operation? - required=false An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) { ?outcome? => ?success?, ?result? => [ ?http?, ?https? ] } When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: :write-attribute(name=complex.nested[2].field,value=http) For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. > On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: > > The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. > I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. > JF > > On 15/09/16 12:41, Harald Pehl wrote: >> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? >> >> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: >> Hi, >> >> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). >> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. >> >> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: >> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, >> attribute=socket-binding) >> { >> ?outcome? => ?success?, >> ?result? => [ >> ?http?, >> ?https? >> ] >> } >> >> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? >> >> Thanks. >> >> JF >> >> >> On 13/09/16 21:50, Harald Pehl wrote: >>> See my answers inline. >>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: >>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. >>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? >>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. >>> >>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java >>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? >>> Yes we read everything from /core-service=capability-registry >>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png >>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? >>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" >>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? >>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. >>> >>> Thank-you. >>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java >>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java >>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 >>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 >>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >> -- >> --- Harald Pehl JBoss by Red Hat http://hpehl.info -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From hpehl at redhat.com Thu Sep 15 15:05:05 2016 From: hpehl at redhat.com (Harald Pehl) Date: Thu, 15 Sep 2016 21:05:05 +0200 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> Message-ID: On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > I?m adding wildfly-dev in cc. > > Yes, the names of the parameters are ambiguous. And it?s not necessary for > them to be ambiguous, as the ?alternatives?, ?required? and ?requires" > stuff lets us use clearly named params for different cases: > > ?attribute? ? required=true, alternatives=[parameter] > ?parameter - required=true, alternatives=[attribute], requires=[operation] > ?operation? - required=false > > An alternative is we could just drop all of those. The operation and > attribute params are not necessary if the client has already done a > read-resource-description or read-operation-description and already knows > the value of the ?capability-reference? descriptor. Then it could simply be > > /core-service=capability-registry:suggest-capabilities( > address=[(subsystem=foo),(child=bar)],static-name=org. > wildfly.network.socket-binding) > { > ?outcome? => ?success?, > ?result? => [ > ?http?, > ?https? > ] > } > >From the console's perspective that version would work best for us. However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: standard-sockets / http ha-sockets / http full-sockets / http ... > > When thinking about this we should remember the dot/bracket syntax we > allow for updating details of complex attributes via write-attribute: > > :write-attribute(name=complex.nested[2].field,value=http) > > For the CLI, just passing through ?attribute?=>"complex.nested[2].field? > is easier as there is no need for it to unpack the ?.? and ?[]' syntax and > find the description of ?field? and get the capabiity-reference. > > For the console, it may be easier to get the capability-reference and pass > it instead. Easier than going from some code backing a gui widget and > synthesizing "complex.nested[2].field? to pass to the server. > > > > On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise > wrote: > > > > The operation argument is an optional argument that contains the > resource operation name. In case the operation is present, the attribute > argument means operation argument. Otherwise the attribute contains the > name of an attribute. This is a draft of operation, the operation naming > could be reviewed. > > I don't think that this operation updates the capabilities registry, > this is a readonly operation to retrieve capabilities. > > JF > > > > On 15/09/16 12:41, Harald Pehl wrote: > >> That looks very promising. Having such an operation would also cover > the requirements of HAL. What's behind the "operation" parameter? Does it > allow add / modify? > >> > >> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise < > jdenise at redhat.com> wrote: > >> Hi, > >> > >> I have spent some time looking at the semantic of the capability scopes > (thanks to Brian help). > >> A client "could" try to base its capability resolution by looking at > capabilities present in the capabilities registry. Scope can be very > complex, are possibly not fully modeled yet, and semantic could evolve in > the future. So difficult for a client to rely on scopes to > resolve the accessible capabilities. > >> > >> The server side has the logic to check the capabilities and could > expose part of its engine logic to clients for capabilities resolution. > Brian is proposing that the capabilities registry would expose a new > operation: > >> /core-service=capability-registry:suggest-capabilities( > address=[(subsystem=foo),(child=bar)],operation=add, > >> attribute=socket-binding) > >> { > >> ?outcome? => ?success?, > >> ?result? => [ > >> ?http?, > >> ?https? > >> ] > >> } > >> > >> It seems that the CLI "completion requirements" would be covered by > this addition. I am wandering if it would also cover the HAL ones? > >> > >> Thanks. > >> > >> JF > >> > >> > >> On 13/09/16 21:50, Harald Pehl wrote: > >>> See my answers inline. > >>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise < > jdenise at redhat.com> wrote: > >>> Hi Claudio and Harald, thank you for your reply. Some questions > in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 > 19:47, Claudio Miranda wrote: > >>> Your suggested approach looks similar to the way HAL does, however > there are some differences. 1) There are many attributes that doesn't > declare the capability-reference, (example: subsystem=transactions, > attribute jdbc-store-datasource), then we emulate it. > >>> How do you emulate this? You are hard coding the list of attributes > that are reference to capabilities? You can point me to some code? Harald, > what is the technical difficulty there? Are they real capabilities? If the > referenced resource can't register capabilities, are they actual > capabilities? > >>> We have an internal registry [1] which is basically a map with the > capability name as key and a class holding information about the capability > as value [2]. Most entries in our registry are taken from > /core-service=capability-registry, but to provide the capabilities also > for WildFly < 11, we need to manually add entries to our registry during > startup [3]. > >>> > >>> 2) The capabilities and addresses are associated at bootstrap, this > way HAL associates all capability-reference names to the target address it > should lookup on at runtime. https://github.com/hal/core/blob/ > 26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/ > org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java > >>> This is the information that the capabilities registry contains? > Right? I should be able to retrieve all that from the registry? > >>> Yes we read everything from /core-service=capability-registry > >>> 3) For domain mode, the attributes that declares capabilities > resources out of profile, as socket-bindings, there is a small > inconvenient, we need to display the full resource address, as there is no > way to associate the profile to the socket-binding, we need to show all > socket-binding of all socket-binding-groups, see > http://i.imgur.com/86VP1F9.png > >>> The //subsystem=transactions/process-id-socket-binding > should be tagged with "capability-reference". Right? And it doesn't seem to > be. Do you now the rational? > >>> Right, the r-r-d result for //subsystem=transactions does > not contain a "capabilities-reference" for the attribute > "process-id-socket-binding". This seems to be a bug in the transactions > subsystem. But actually it's a good example how we can still provide > typeahead support for attributes which do not have a "capability-reference" > info [4]. This does not involve the capabilities registry. It's just about > adding typeahead support for attributes which reference some other > resources, but do not yet have a "capabilities-reference" > >>> Once the user has chosen a value, what are you setting as the value > for the process-id-socket-binding attribute? Harald, you are saying that > the resource name is taken as form input. So it means that only the last > part of the resource address is stored? For example only "ajp"? Is it > enough to fully identify the actual resource? Don't you need (full > capabilities name + scope)? > >>> Yes that's right, only the resource name is stored. Let's take the > server-group resource as an example. It has the attribute "profile" which > declares the "capability-reference" "org.wildfly.domain.profile". When > adding the resource, only the profile name is stored. AIUI to identify / > verify the profile the attribute value and the information from the > capabilities-regisrty are used. > >>> > >>> Thank-you. > >>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/ > main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java > >>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/ > main/java/org/jboss/hal/meta/capabilitiy/Capability.java > >>> [3] https://github.com/hal/hal.next/blob/develop/app/src/ > main/java/org/jboss/hal/client/bootstrap/functions/ > ReadCapabilities.java#L65 > >>> [4] https://github.com/hal/hal.next/blob/develop/app/src/ > main/resources/org/jboss/hal/client/configuration/subsystem/transactions/ > TransactionView.mbui.xml#L47 > >>> --- Harald Pehl JBoss by Red Hat http://hpehl.info > >> -- > >> --- Harald Pehl JBoss by Red Hat http://hpehl.info > > -- > 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/20160915/b68773de/attachment.html From brian.stansberry at redhat.com Thu Sep 15 15:15:52 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 15 Sep 2016 14:15:52 -0500 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> Message-ID: > On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: > > > > On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry wrote: > I?m adding wildfly-dev in cc. > > Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: > > ?attribute? ? required=true, alternatives=[parameter] > ?parameter - required=true, alternatives=[attribute], requires=[operation] > ?operation? - required=false > > An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be > > /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) > { > ?outcome? => ?success?, > ?result? => [ > ?http?, > ?https? > ] > } > > From the console's perspective that version would work best for us. > Ok thanks. And both variants are possible if Jeff wants the other one for the CLI. The 'static-name' param could just be an alternative to ?attribute? and ?parameter?+?operation'. > However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). > > Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. > > Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: > > standard-sockets / http > ha-sockets / http > full-sockets / http > ? To account for this instead of returning a simple list we can return an object node equivalent to a Map>. > > > When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: > > :write-attribute(name=complex.nested[2].field,value=http) > > For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. > > For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. > > > > On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: > > > > The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. > > I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. > > JF > > > > On 15/09/16 12:41, Harald Pehl wrote: > >> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? > >> > >> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: > >> Hi, > >> > >> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). > >> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. > >> > >> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: > >> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, > >> attribute=socket-binding) > >> { > >> ?outcome? => ?success?, > >> ?result? => [ > >> ?http?, > >> ?https? > >> ] > >> } > >> > >> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? > >> > >> Thanks. > >> > >> JF > >> > >> > >> On 13/09/16 21:50, Harald Pehl wrote: > >>> See my answers inline. > >>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: > >>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: > >>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. > >>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? > >>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. > >>> > >>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java > >>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? > >>> Yes we read everything from /core-service=capability-registry > >>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png > >>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? > >>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" > >>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? > >>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. > >>> > >>> Thank-you. > >>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java > >>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java > >>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 > >>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 > >>> --- Harald Pehl JBoss by Red Hat http://hpehl.info > >> -- > >> --- Harald Pehl JBoss by Red Hat http://hpehl.info > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > > > -- > --- > Harald Pehl > JBoss by Red Hat > http://hpehl.info -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From jdenise at redhat.com Fri Sep 16 04:50:51 2016 From: jdenise at redhat.com (Jean-Francois Denise) Date: Fri, 16 Sep 2016 10:50:51 +0200 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> Message-ID: <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> My reply inlined. On 15/09/16 21:15, Brian Stansberry wrote: >> On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: >> >> >> >> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry wrote: >> I?m adding wildfly-dev in cc. >> >> Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: >> >> ?attribute? ? required=true, alternatives=[parameter] >> ?parameter - required=true, alternatives=[attribute], requires=[operation] >> ?operation? - required=false >> >> An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be >> >> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) >> { >> ?outcome? => ?success?, >> ?result? => [ >> ?http?, >> ?https? >> ] >> } >> >> From the console's perspective that version would work best for us. >> > Ok thanks. > > And both variants are possible if Jeff wants the other one for the CLI. The 'static-name' param could just be an alternative to ?attribute? and ?parameter?+?operation'. I am not sure about the right syntax, We are possibly in the same case as HAL. If we offer a proper completion for the :write-attribute name (there is a start for this), we will have already accessed to the value-type and metadata for the deepest property. So we should have the capability-reference and call the operation with the couple Resource Address,Reference. > >> However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). >> >> Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. >> >> Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: >> >> standard-sockets / http >> ha-sockets / http >> full-sockets / http >> ? > To account for this instead of returning a simple list we can return an object node equivalent to a Map>. What is the advantage to expose all possible http capabilities? At the end the attribute value will only contain 'http' right? So do we really need to expose all the possibilities although whatever the user choice, 'http' will be stored in the value? For a given resource attribute value (eg: 'http') the server should be able to compute scopes and identify the right path (one of the 3 possible paths to 'http'). > >> >> >> When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: >> >> :write-attribute(name=complex.nested[2].field,value=http) >> >> For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. >> >> For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. >> >> >>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: >>> >>> The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. >>> I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. >>> JF >>> >>> On 15/09/16 12:41, Harald Pehl wrote: >>>> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? >>>> >>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>> Hi, >>>> >>>> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). >>>> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. >>>> >>>> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: >>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, >>>> attribute=socket-binding) >>>> { >>>> ?outcome? => ?success?, >>>> ?result? => [ >>>> ?http?, >>>> ?https? >>>> ] >>>> } >>>> >>>> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? >>>> >>>> Thanks. >>>> >>>> JF >>>> >>>> >>>> On 13/09/16 21:50, Harald Pehl wrote: >>>>> See my answers inline. >>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: >>>>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. >>>>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? >>>>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. >>>>> >>>>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java >>>>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? >>>>> Yes we read everything from /core-service=capability-registry >>>>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png >>>>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? >>>>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" >>>>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? >>>>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. >>>>> >>>>> Thank-you. >>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java >>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java >>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 >>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 >>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>> -- >>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> JBoss by Red Hat >> >> >> >> >> >> >> -- >> --- >> Harald Pehl >> JBoss by Red Hat >> http://hpehl.info From brian.stansberry at redhat.com Fri Sep 16 08:21:34 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 16 Sep 2016 07:21:34 -0500 Subject: [wildfly-dev] WFLY/WFCORE PRs In-Reply-To: References: <66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com> Message-ID: <09B834FA-2121-4AD9-8470-34D381C3B8B4@redhat.com> 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 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 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 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 -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From ppalaga at redhat.com Fri Sep 16 08:53:36 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Fri, 16 Sep 2016 14:53:36 +0200 Subject: [wildfly-dev] WFLY/WFCORE PRs In-Reply-To: <09B834FA-2121-4AD9-8470-34D381C3B8B4@redhat.com> References: <66247c5a-91aa-c559-86c2-f59b0dc9517a@redhat.com> <09B834FA-2121-4AD9-8470-34D381C3B8B4@redhat.com> Message-ID: 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 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 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 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 > From brian.stansberry at redhat.com Fri Sep 16 08:53:42 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 16 Sep 2016 07:53:42 -0500 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> Message-ID: <6F64437C-2F18-4148-BC8C-26D5F4CD65E6@redhat.com> > On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise wrote: > > My reply inlined. > > On 15/09/16 21:15, Brian Stansberry wrote: >>> On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: >>> >>> >>> >>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry wrote: >>> I?m adding wildfly-dev in cc. >>> >>> Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: >>> >>> ?attribute? ? required=true, alternatives=[parameter] >>> ?parameter - required=true, alternatives=[attribute], requires=[operation] >>> ?operation? - required=false >>> >>> An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be >>> >>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) >>> { >>> ?outcome? => ?success?, >>> ?result? => [ >>> ?http?, >>> ?https? >>> ] >>> } >>> >>> From the console's perspective that version would work best for us. >>> >> Ok thanks. >> >> And both variants are possible if Jeff wants the other one for the CLI. The 'static-name' param could just be an alternative to ?attribute? and ?parameter?+?operation'. > > I am not sure about the right syntax, We are possibly in the same case as HAL. If we offer a proper completion for the :write-attribute name (there is a start for this), we will have already accessed to the value-type and metadata for the deepest property. So we should have the capability-reference and call the operation with the couple Resource Address,Reference. How about other operations? The nice thing is if we just need static-name we can do that, and then if later we find we need more it can be added in a compatible way. > >> >>> However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). >>> >>> Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. >>> >>> Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: >>> >>> standard-sockets / http >>> ha-sockets / http >>> full-sockets / http >>> ? >> To account for this instead of returning a simple list we can return an object node equivalent to a Map>. > What is the advantage to expose all possible http capabilities? At the end the attribute value will only contain 'http' right? So do we really need to expose all the possibilities although whatever the user choice, 'http' will be stored in the value? For a given resource attribute value (eg: 'http') the server should be able to compute scopes and identify the right path (one of the 3 possible paths to 'http?). >> >>> >>> When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: >>> >>> :write-attribute(name=complex.nested[2].field,value=http) >>> >>> For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. >>> >>> For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. >>> >>> >>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: >>>> >>>> The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. >>>> I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. >>>> JF >>>> >>>> On 15/09/16 12:41, Harald Pehl wrote: >>>>> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? >>>>> >>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>> Hi, >>>>> >>>>> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). >>>>> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. >>>>> >>>>> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: >>>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, >>>>> attribute=socket-binding) >>>>> { >>>>> ?outcome? => ?success?, >>>>> ?result? => [ >>>>> ?http?, >>>>> ?https? >>>>> ] >>>>> } >>>>> >>>>> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? >>>>> >>>>> Thanks. >>>>> >>>>> JF >>>>> >>>>> >>>>> On 13/09/16 21:50, Harald Pehl wrote: >>>>>> See my answers inline. >>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: >>>>>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. >>>>>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? >>>>>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. >>>>>> >>>>>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java >>>>>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? >>>>>> Yes we read everything from /core-service=capability-registry >>>>>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png >>>>>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? >>>>>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" >>>>>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? >>>>>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. >>>>>> >>>>>> Thank-you. >>>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java >>>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java >>>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 >>>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 >>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>>> -- >>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> JBoss by Red Hat >>> >>> >>> >>> >>> >>> >>> -- >>> --- >>> Harald Pehl >>> JBoss by Red Hat >>> http://hpehl.info -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From jdenise at redhat.com Fri Sep 16 08:59:35 2016 From: jdenise at redhat.com (Jean-Francois Denise) Date: Fri, 16 Sep 2016 14:59:35 +0200 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: <6F64437C-2F18-4148-BC8C-26D5F4CD65E6@redhat.com> References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> <6F64437C-2F18-4148-BC8C-26D5F4CD65E6@redhat.com> Message-ID: <91b43dad-fcd9-2d1f-5add-9a5278d09046@redhat.com> Brian, my replies inlined. You will notice the question I am also asking about the need to return a Map. On 16/09/16 14:53, Brian Stansberry wrote: >> On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise wrote: >> >> My reply inlined. >> >> On 15/09/16 21:15, Brian Stansberry wrote: >>>> On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: >>>> >>>> >>>> >>>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry wrote: >>>> I?m adding wildfly-dev in cc. >>>> >>>> Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: >>>> >>>> ?attribute? ? required=true, alternatives=[parameter] >>>> ?parameter - required=true, alternatives=[attribute], requires=[operation] >>>> ?operation? - required=false >>>> >>>> An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be >>>> >>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) >>>> { >>>> ?outcome? => ?success?, >>>> ?result? => [ >>>> ?http?, >>>> ?https? >>>> ] >>>> } >>>> >>>> From the console's perspective that version would work best for us. >>>> >>> Ok thanks. >>> >>> And both variants are possible if Jeff wants the other one for the CLI. The 'static-name' param could just be an alternative to ?attribute? and ?parameter?+?operation'. >> I am not sure about the right syntax, We are possibly in the same case as HAL. If we offer a proper completion for the :write-attribute name (there is a start for this), we will have already accessed to the value-type and metadata for the deepest property. So we should have the capability-reference and call the operation with the couple Resource Address,Reference. > How about other operations? We are also navigating the value-type for low level operation arguments. So we have the static name too. > > The nice thing is if we just need static-name we can do that, and then if later we find we need more it can be added in a compatible way. > >>>> However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). >>>> >>>> Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. >>>> >>>> Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: >>>> >>>> standard-sockets / http >>>> ha-sockets / http >>>> full-sockets / http >>>> ? >>> To account for this instead of returning a simple list we can return an object node equivalent to a Map>. *** Question on the advantage of having a map? >> What is the advantage to expose all possible http capabilities? At the end the attribute value will only contain 'http' right? So do we really need to expose all the possibilities although whatever the user choice, 'http' will be stored in the value? For a given resource attribute value (eg: 'http') the server should be able to compute scopes and identify the right path (one of the 3 possible paths to 'http?). *** >>>> >>>> When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: >>>> >>>> :write-attribute(name=complex.nested[2].field,value=http) >>>> >>>> For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. >>>> >>>> For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. >>>> >>>> >>>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: >>>>> >>>>> The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. >>>>> I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. >>>>> JF >>>>> >>>>> On 15/09/16 12:41, Harald Pehl wrote: >>>>>> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? >>>>>> >>>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>>> Hi, >>>>>> >>>>>> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). >>>>>> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. >>>>>> >>>>>> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: >>>>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, >>>>>> attribute=socket-binding) >>>>>> { >>>>>> ?outcome? => ?success?, >>>>>> ?result? => [ >>>>>> ?http?, >>>>>> ?https? >>>>>> ] >>>>>> } >>>>>> >>>>>> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> JF >>>>>> >>>>>> >>>>>> On 13/09/16 21:50, Harald Pehl wrote: >>>>>>> See my answers inline. >>>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>>>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: >>>>>>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. >>>>>>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? >>>>>>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. >>>>>>> >>>>>>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java >>>>>>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? >>>>>>> Yes we read everything from /core-service=capability-registry >>>>>>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png >>>>>>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? >>>>>>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" >>>>>>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? >>>>>>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. >>>>>>> >>>>>>> Thank-you. >>>>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java >>>>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java >>>>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 >>>>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 >>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>>>> -- >>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>> -- >>>> Brian Stansberry >>>> Manager, Senior Principal Software Engineer >>>> JBoss by Red Hat >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> --- >>>> Harald Pehl >>>> JBoss by Red Hat >>>> http://hpehl.info From brian.stansberry at redhat.com Fri Sep 16 13:56:05 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 16 Sep 2016 12:56:05 -0500 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: <91b43dad-fcd9-2d1f-5add-9a5278d09046@redhat.com> References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> <6F64437C-2F18-4148-BC8C-26D5F4CD65E6@redhat.com> <91b43dad-fcd9-2d1f-5add-9a5278d09046@redhat.com> Message-ID: Re: only needing to use the static-name variant: Great! Re: the map, I?ll leave that to Harald or Claudio to answer. You made a solid point why it might not be necessary. I could imagine uses for the data (e.g. to let the user navigate to the related part of the UI) but I don?t know if those are real. >From the server side point of view I don?t think it would be particularly challenging to provide the map if it?s useful. From an API design point of view, an advantage of returning a more complex structure is if designed well initialiy it can be enhanced in the future to add more things that are wanted. The downside is a bigger payload than is needed for the simple use case. > On Sep 16, 2016, at 7:59 AM, Jean-Francois Denise wrote: > > Brian, my replies inlined. You will notice the question I am also asking about the need to return a Map. > > > On 16/09/16 14:53, Brian Stansberry wrote: >>> On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise wrote: >>> >>> My reply inlined. >>> >>> On 15/09/16 21:15, Brian Stansberry wrote: >>>>> On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry wrote: >>>>> I?m adding wildfly-dev in cc. >>>>> >>>>> Yes, the names of the parameters are ambiguous. And it?s not necessary for them to be ambiguous, as the ?alternatives?, ?required? and ?requires" stuff lets us use clearly named params for different cases: >>>>> >>>>> ?attribute? ? required=true, alternatives=[parameter] >>>>> ?parameter - required=true, alternatives=[attribute], requires=[operation] >>>>> ?operation? - required=false >>>>> >>>>> An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the ?capability-reference? descriptor. Then it could simply be >>>>> >>>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding) >>>>> { >>>>> ?outcome? => ?success?, >>>>> ?result? => [ >>>>> ?http?, >>>>> ?https? >>>>> ] >>>>> } >>>>> >>>>> From the console's perspective that version would work best for us. >>>>> >>>> Ok thanks. >>>> >>>> And both variants are possible if Jeff wants the other one for the CLI. The 'static-name' param could just be an alternative to ?attribute? and ?parameter?+?operation'. >>> I am not sure about the right syntax, We are possibly in the same case as HAL. If we offer a proper completion for the :write-attribute name (there is a start for this), we will have already accessed to the value-type and metadata for the deepest property. So we should have the capability-reference and call the operation with the couple Resource Address,Reference. >> How about other operations? > We are also navigating the value-type for low level operation arguments. So we have the static name too. > Ok, nice! >> >> The nice thing is if we just need static-name we can do that, and then if later we find we need more it can be added in a compatible way. >> >>>>> However I see one issue using this approach: If there are multiple suggestions having the same name while referring to different resources. This typically happens with attributes which have a capability reference to "org.wildfly.network.socket-binding" (for instance attribute "socket-binding" in "/subsystem=remoting/connector=*"). >>>>> >>>>> Using /core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" which resolves to several "http" socket-bindings in different socket-binding-groups. >>>>> >>>>> Just using the names as suggestions would end up in several "http" suggestions. What we do in that case in the console is to show some context: >>>>> >>>>> standard-sockets / http >>>>> ha-sockets / http >>>>> full-sockets / http >>>>> ? >>>> To account for this instead of returning a simple list we can return an object node equivalent to a Map>. > *** Question on the advantage of having a map? >>> What is the advantage to expose all possible http capabilities? At the end the attribute value will only contain 'http' right? So do we really need to expose all the possibilities although whatever the user choice, 'http' will be stored in the value? For a given resource attribute value (eg: 'http') the server should be able to compute scopes and identify the right path (one of the 3 possible paths to 'http?). > *** > >>>>> When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute: >>>>> >>>>> :write-attribute(name=complex.nested[2].field,value=http) >>>>> >>>>> For the CLI, just passing through ?attribute?=>"complex.nested[2].field? is easier as there is no need for it to unpack the ?.? and ?[]' syntax and find the description of ?field? and get the capabiity-reference. >>>>> >>>>> For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field? to pass to the server. >>>>> >>>>> >>>>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise wrote: >>>>>> >>>>>> The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed. >>>>>> I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities. >>>>>> JF >>>>>> >>>>>> On 15/09/16 12:41, Harald Pehl wrote: >>>>>>> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify? >>>>>>> >>>>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help). >>>>>>> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities. >>>>>>> >>>>>>> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation: >>>>>>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add, >>>>>>> attribute=socket-binding) >>>>>>> { >>>>>>> ?outcome? => ?success?, >>>>>>> ?result? => [ >>>>>>> ?http?, >>>>>>> ?https? >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> JF >>>>>>> >>>>>>> >>>>>>> On 13/09/16 21:50, Harald Pehl wrote: >>>>>>>> See my answers inline. >>>>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise wrote: >>>>>>>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote: >>>>>>>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it. >>>>>>>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities? >>>>>>>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3]. >>>>>>>> >>>>>>>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java >>>>>>>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry? >>>>>>>> Yes we read everything from /core-service=capability-registry >>>>>>>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png >>>>>>>> The //subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational? >>>>>>>> Right, the r-r-d result for //subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference" >>>>>>>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)? >>>>>>>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used. >>>>>>>> >>>>>>>> Thank-you. >>>>>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java >>>>>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss/hal/meta/capabilitiy/Capability.java >>>>>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/hal/client/bootstrap/functions/ReadCapabilities.java#L65 >>>>>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/jboss/hal/client/configuration/subsystem/transactions/TransactionView.mbui.xml#L47 >>>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>>>>> -- >>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> JBoss by Red Hat >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> Harald Pehl >>>>> JBoss by Red Hat >>>>> http://hpehl.info -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From hpehl at redhat.com Mon Sep 19 02:02:47 2016 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 19 Sep 2016 08:02:47 +0200 Subject: [wildfly-dev] Proposing capabiities at completion time In-Reply-To: References: <6415408b-7ddd-450b-d6ef-07bfe93bf6ba@redhat.com> <11fcedc5-89c9-a71a-65e0-549fe3de9412@redhat.com> <3ce9b96f-9bd4-dffb-62b6-eb757fa7ecff@redhat.com> <64e5a79c-9b0b-ca5a-1732-85022b91459e@redhat.com> <2B717163-7807-4F00-8211-A726C4549B50@redhat.com> <73253ad8-c2ae-4e34-862c-0e076382843e@redhat.com> <6F64437C-2F18-4148-BC8C-26D5F4CD65E6@redhat.com> <91b43dad-fcd9-2d1f-5add-9a5278d09046@redhat.com> Message-ID: On Fri, Sep 16, 2016 at 7:56 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > Re: only needing to use the static-name variant: Great! > > Re: the map, I?ll leave that to Harald or Claudio to answer. You made a > solid point why it might not be necessary. I could imagine uses for the > data (e.g. to let the user navigate to the related part of the UI) but I > don?t know if those are real. > I agree that it's not necessary. My motivation was to give the user as much information as possible. Though I see your point - and it might become unnecessary complex to choose from a big list with lots of 'http' socket bindings, when in the end it doesn't matter what entry was chosen. So I'm ok with returning just a flat map. > > From the server side point of view I don?t think it would be particularly > challenging to provide the map if it?s useful. From an API design point of > view, an advantage of returning a more complex structure is if designed > well initialiy it can be enhanced in the future to add more things that are > wanted. The downside is a bigger payload than is needed for the simple use > case. > > > On Sep 16, 2016, at 7:59 AM, Jean-Francois Denise > wrote: > > > > Brian, my replies inlined. You will notice the question I am also asking > about the need to return a Map. > > > > > > On 16/09/16 14:53, Brian Stansberry wrote: > >>> On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise > wrote: > >>> > >>> My reply inlined. > >>> > >>> On 15/09/16 21:15, Brian Stansberry wrote: > >>>>> On Sep 15, 2016, at 2:05 PM, Harald Pehl wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >>>>> I?m adding wildfly-dev in cc. > >>>>> > >>>>> Yes, the names of the parameters are ambiguous. And it?s not > necessary for them to be ambiguous, as the ?alternatives?, ?required? and > ?requires" stuff lets us use clearly named params for different cases: > >>>>> > >>>>> ?attribute? ? required=true, alternatives=[parameter] > >>>>> ?parameter - required=true, alternatives=[attribute], > requires=[operation] > >>>>> ?operation? - required=false > >>>>> > >>>>> An alternative is we could just drop all of those. The operation and > attribute params are not necessary if the client has already done a > read-resource-description or read-operation-description and already knows > the value of the ?capability-reference? descriptor. Then it could simply be > >>>>> > >>>>> /core-service=capability-registry:suggest-capabilities( > address=[(subsystem=foo),(child=bar)],static-name=org. > wildfly.network.socket-binding) > >>>>> { > >>>>> ?outcome? => ?success?, > >>>>> ?result? => [ > >>>>> ?http?, > >>>>> ?https? > >>>>> ] > >>>>> } > >>>>> > >>>>> From the console's perspective that version would work best for us. > >>>>> > >>>> Ok thanks. > >>>> > >>>> And both variants are possible if Jeff wants the other one for the > CLI. The 'static-name' param could just be an alternative to ?attribute? > and ?parameter?+?operation'. > >>> I am not sure about the right syntax, We are possibly in the same case > as HAL. If we offer a proper completion for the :write-attribute name > (there is a start for this), we will have already accessed to the > value-type and metadata for the deepest property. So we should have the > capability-reference and call the operation with the couple Resource > Address,Reference. > >> How about other operations? > > We are also navigating the value-type for low level operation arguments. > So we have the static name too. > > > > Ok, nice! > > >> > >> The nice thing is if we just need static-name we can do that, and then > if later we find we need more it can be added in a compatible way. > >> > >>>>> However I see one issue using this approach: If there are multiple > suggestions having the same name while referring to different resources. > This typically happens with attributes which have a capability reference to > "org.wildfly.network.socket-binding" (for instance attribute > "socket-binding" in "/subsystem=remoting/connector=*"). > >>>>> > >>>>> Using /core-service=capability-registry:get-provider-points( > name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*" > which resolves to several "http" socket-bindings in different > socket-binding-groups. > >>>>> > >>>>> Just using the names as suggestions would end up in several "http" > suggestions. What we do in that case in the console is to show some context: > >>>>> > >>>>> standard-sockets / http > >>>>> ha-sockets / http > >>>>> full-sockets / http > >>>>> ? > >>>> To account for this instead of returning a simple list we can return > an object node equivalent to a Map>. > > *** Question on the advantage of having a map? > >>> What is the advantage to expose all possible http capabilities? At the > end the attribute value will only contain 'http' right? So do we really > need to expose all the possibilities although whatever the user choice, > 'http' will be stored in the value? For a given resource attribute value > (eg: 'http') the server should be able to compute scopes and identify the > right path (one of the 3 possible paths to 'http?). > > *** > > > >>>>> When thinking about this we should remember the dot/bracket syntax > we allow for updating details of complex attributes via write-attribute: > >>>>> > >>>>> :write-attribute(name=complex.nested[2].field,value=http) > >>>>> > >>>>> For the CLI, just passing through ?attribute?=>"complex.nested[2].field? > is easier as there is no need for it to unpack the ?.? and ?[]' syntax and > find the description of ?field? and get the capabiity-reference. > >>>>> > >>>>> For the console, it may be easier to get the capability-reference > and pass it instead. Easier than going from some code backing a gui widget > and synthesizing "complex.nested[2].field? to pass to the server. > >>>>> > >>>>> > >>>>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise < > jdenise at redhat.com> wrote: > >>>>>> > >>>>>> The operation argument is an optional argument that contains the > resource operation name. In case the operation is present, the attribute > argument means operation argument. Otherwise the attribute contains the > name of an attribute. This is a draft of operation, the operation naming > could be reviewed. > >>>>>> I don't think that this operation updates the capabilities > registry, this is a readonly operation to retrieve capabilities. > >>>>>> JF > >>>>>> > >>>>>> On 15/09/16 12:41, Harald Pehl wrote: > >>>>>>> That looks very promising. Having such an operation would also > cover the requirements of HAL. What's behind the "operation" parameter? > Does it allow add / modify? > >>>>>>> > >>>>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise < > jdenise at redhat.com> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have spent some time looking at the semantic of the capability > scopes (thanks to Brian help). > >>>>>>> A client "could" try to base its capability resolution by looking > at capabilities present in the capabilities registry. Scope can be very > complex, are possibly not fully modeled yet, and semantic could evolve in > the future. So difficult for a client to rely on scopes to > resolve the accessible capabilities. > >>>>>>> > >>>>>>> The server side has the logic to check the capabilities and could > expose part of its engine logic to clients for capabilities resolution. > Brian is proposing that the capabilities registry would expose a new > operation: > >>>>>>> /core-service=capability-registry:suggest-capabilities( > address=[(subsystem=foo),(child=bar)],operation=add, > >>>>>>> attribute=socket-binding) > >>>>>>> { > >>>>>>> ?outcome? => ?success?, > >>>>>>> ?result? => [ > >>>>>>> ?http?, > >>>>>>> ?https? > >>>>>>> ] > >>>>>>> } > >>>>>>> > >>>>>>> It seems that the CLI "completion requirements" would be covered > by this addition. I am wandering if it would also cover the HAL ones? > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> JF > >>>>>>> > >>>>>>> > >>>>>>> On 13/09/16 21:50, Harald Pehl wrote: > >>>>>>>> See my answers inline. > >>>>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise < > jdenise at redhat.com> wrote: > >>>>>>>> Hi Claudio and Harald, thank you for your reply. Some questions > in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 > 19:47, Claudio Miranda wrote: > >>>>>>>> Your suggested approach looks similar to the way HAL does, > however there are some differences. 1) There are many attributes that > doesn't declare the capability-reference, (example: subsystem=transactions, > attribute jdbc-store-datasource), then we emulate it. > >>>>>>>> How do you emulate this? You are hard coding the list of > attributes that are reference to capabilities? You can point me to some > code? Harald, what is the technical difficulty there? Are they real > capabilities? If the referenced resource can't register capabilities, are > they actual capabilities? > >>>>>>>> We have an internal registry [1] which is basically a map with > the capability name as key and a class holding information about the > capability as value [2]. Most entries in our registry are taken from > /core-service=capability-registry, but to provide the capabilities also > for WildFly < 11, we need to manually add entries to our registry during > startup [3]. > >>>>>>>> > >>>>>>>> 2) The capabilities and addresses are associated at bootstrap, > this way HAL associates all capability-reference names to the target > address it should lookup on at runtime. https://github.com/hal/core/blob/ > 26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/ > org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java > >>>>>>>> This is the information that the capabilities registry contains? > Right? I should be able to retrieve all that from the registry? > >>>>>>>> Yes we read everything from /core-service=capability-registry > >>>>>>>> 3) For domain mode, the attributes that declares capabilities > resources out of profile, as socket-bindings, there is a small > inconvenient, we need to display the full resource address, as there is no > way to associate the profile to the socket-binding, we need to show all > socket-binding of all socket-binding-groups, see > http://i.imgur.com/86VP1F9.png > >>>>>>>> The //subsystem=transactions/process-id-socket-binding > should be tagged with "capability-reference". Right? And it doesn't seem to > be. Do you now the rational? > >>>>>>>> Right, the r-r-d result for //subsystem=transactions > does not contain a "capabilities-reference" for the attribute > "process-id-socket-binding". This seems to be a bug in the transactions > subsystem. But actually it's a good example how we can still provide > typeahead support for attributes which do not have a "capability-reference" > info [4]. This does not involve the capabilities registry. It's just about > adding typeahead support for attributes which reference some other > resources, but do not yet have a "capabilities-reference" > >>>>>>>> Once the user has chosen a value, what are you setting as the > value for the process-id-socket-binding attribute? Harald, you are saying > that the resource name is taken as form input. So it means that only the > last part of the resource address is stored? For example only "ajp"? Is it > enough to fully identify the actual resource? Don't you need (full > capabilities name + scope)? > >>>>>>>> Yes that's right, only the resource name is stored. Let's take > the server-group resource as an example. It has the attribute "profile" > which declares the "capability-reference" "org.wildfly.domain.profile". > When adding the resource, only the profile name is stored. AIUI to identify > / verify the profile the attribute value and the information from the > capabilities-regisrty are used. > >>>>>>>> > >>>>>>>> Thank-you. > >>>>>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/ > main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java > >>>>>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/ > main/java/org/jboss/hal/meta/capabilitiy/Capability.java > >>>>>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/ > main/java/org/jboss/hal/client/bootstrap/functions/ > ReadCapabilities.java#L65 > >>>>>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/ > main/resources/org/jboss/hal/client/configuration/subsystem/transactions/ > TransactionView.mbui.xml#L47 > >>>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info > >>>>>>> -- > >>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info > >>>>> -- > >>>>> Brian Stansberry > >>>>> Manager, Senior Principal Software Engineer > >>>>> JBoss by Red Hat > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> --- > >>>>> Harald Pehl > >>>>> JBoss by Red Hat > >>>>> http://hpehl.info > > -- > 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/20160919/ec1ddb74/attachment-0001.html From rory.odonnell at oracle.com Tue Sep 20 06:29:43 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 20 Sep 2016 11:29:43 +0100 Subject: [wildfly-dev] Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net Message-ID: <2f66d552-1582-7a05-0e3a-a239f710d0a2@oracle.com> Hi Jason/Tomaz, Early Access b136 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b136 (#5506) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here . There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * 8165723 - b136 - core-libs JarFile::isMultiRelease() method returns false when it should return true * 8165116 - b136 - xml redirect function is not allowed even with enableExtensionFunctions NOTE:- Build 135 included a fix for JDK-8161016 which *has introduced a behavioral change to HttpURLConnection, more info:* The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. Currently, HttpURLConnection.connect() call would fallback to a DIRECT connection attempt if the configured proxy/proxies failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested. This behavior now matches with the HTTP connections made by popular web browsers. But this change will bring compatibility issues for the applications expecting a DIRECT connection when a proxy server is down or when wrong proxies are provided. * JDK 9 Outreach Survey* In order to encourage and receive additional feedback from developers testing their applications with JDK 9, the OpenJDK Quality Outreach effort has put together a very brief survey about your experiences with JDK 9 so far. It is available at***https://www.surveymonkey.de/r/JDK9EA* We would love to hear feedback from you! Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160920/547e3638/attachment.html From jmesnil at redhat.com Tue Sep 20 08:39:20 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 20 Sep 2016 14:39:20 +0200 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core Message-ID: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Hi, TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11. # Use case For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.). Until now this kind of resources related to the server management were put under /core-service=management. However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?). Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly. I propose to create a new extension in wildfly-core project to provide new management resources. It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management). This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11. I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing. Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them. Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile... # What is the scope of this subsystem? The scope would be identical to the /core-service=management resource. Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API. It is *not* a subsystem to manage WildFly or deployed applications ? la JMX or JSR 77. # What is the name of this subsystem? The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API ? la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging). If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]). I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice). We have identified a few resources that are good candidates for this new resource: * the feature to notify user code of server stat changes[1] * Elytron needs a new access=identity resource[3] # Roadmap I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed). Then, we can have different PRs for new management resources that fits in this new subsystem. We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[4] and their implications for compatibility. Would you guys agree with that proposal? [1] https://issues.jboss.org/browse/WFCORE-1405 [2] https://www.jcp.org/en/jsr/detail?id=373 [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity [4] https://issues.jboss.org/browse/WFCORE-1642 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From tomaz.cerar at gmail.com Tue Sep 20 09:00:20 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 20 Sep 2016 15:00:20 +0200 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: How will this behave in domain mode? Will it be host subsystem and as such available on hosts or also on domain profiles? On Tue, Sep 20, 2016 at 2:39 PM, Jeff Mesnil wrote: > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new > management-related resources instead of putting them in > /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user > code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put > under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's > the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new > subsystem instead. This will clarify the semantic of the resources and > uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new > management resources. > It will be the *successor* of /core-service=management (i.e. we stop > adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current > resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate > them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing > nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I > have no idea of the actual effort to do so (and ensure that we remain > compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the > resources underneath it. It also moves us towards the goal of extending > WildFly in an uniform way instead of adding special resources outside of > our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la > JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is > a good name. It is too generic (does it expose a management API ? la JMX? > does it provide management features based on other project such as > Hawkular?) and I don't think we should own such general term (even though > we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be > /subsystem=management-wildfly (feature + name of project providing the > feature) but it does not sound good. The subsystem provides a way to manage > WildFly, it does not provide a management feature *using* WildFly (this > could also clash with name of the extension if/when we implement Java EE > Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as > a 2nd choice). > > We have identified a few resources that are good candidates for this new > resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that > Elytron feature is not blocked by the development of my own feature (It > should be a single commit on wildfly-core and can be fit in Elytron PRs if > needed). > Then, we can have different PRs for new management resources that fits in > this new subsystem. > > We've also identified a simple management resource to evaluate the cost of > moving/migrating/redirecting resources with the > service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManag > ementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160920/3239510f/attachment.html From darran.lofthouse at jboss.com Tue Sep 20 09:06:05 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 20 Sep 2016 14:06:05 +0100 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: Sounds like it could be a nice home for the administrator encouragement feature I want to look at again once I get a chance. On 20/09/16 13:39, Jeff Mesnil wrote: > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new management resources. > It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API ? la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice). > > We have identified a few resources that are good candidates for this new resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed). > Then, we can have different PRs for new management resources that fits in this new subsystem. > > We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > From jmesnil at redhat.com Tue Sep 20 09:22:19 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 20 Sep 2016 15:22:19 +0200 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: <8CB3AEE7-723C-4758-A522-459B0835D0BC@redhat.com> > On 20 Sep 2016, at 15:00, Toma? Cerar wrote: > > How will this behave in domain mode? > > Will it be host subsystem and as such available on hosts or also on domain profiles? It will be available as a host subsystem and on domain profiles. There might be resources that makes sense only for HC or for servers but that?s not different from some existing resources under /core-service=management. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From kabir.khan at jboss.com Tue Sep 20 11:12:13 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 20 Sep 2016 16:12:13 +0100 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: <05E0AFFB-18DD-4A5F-8CAD-F993B66DAD05@jboss.com> Thinking down the line, if we -do migrate everything from /core-service=management, and/or: -add a lot more future 'core' functionality to subsystems I don't think we want one monolithic subsystem replacing this/doing everything. For now that doesn't sound too important, but should be taken into consideration when deciding on the name of the current subsystem. > On 20 Sep 2016, at 13:39, Jeff Mesnil wrote: > > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new management resources. > It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API ? la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice). > > We have identified a few resources that are good candidates for this new resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed). > Then, we can have different PRs for new management resources that fits in this new subsystem. > > We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Tue Sep 20 12:10:11 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 20 Sep 2016 11:10:11 -0500 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <8CB3AEE7-723C-4758-A522-459B0835D0BC@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> <8CB3AEE7-723C-4758-A522-459B0835D0BC@redhat.com> Message-ID: > On Sep 20, 2016, at 8:22 AM, Jeff Mesnil wrote: > > >> On 20 Sep 2016, at 15:00, Toma? Cerar wrote: >> >> How will this behave in domain mode? >> >> Will it be host subsystem and as such available on hosts or also on domain profiles? > > It will be available as a host subsystem and on domain profiles. > There might be resources that makes sense only for HC or for servers but that?s not different from some existing resources under /core-service=management. > This is an important general topic for the roadmap discussion. Right now a domain mode server gets some of its config from its server-group/profile in the domain.xml part of the config, and then some from the host?s own config. And a lot of what comes from the host is currently encapsulated in the core-service=management resources. Right now host controller subsystems don?t allow the option of being applied to the servers; they are only used by the HC process. If we ever want the HC subsystem settings to apply to the servers as well, we?d need to add that (w/o breaking compatibility). For the specific use case you?re working, Jeff, I think the way HC subsystems work right now is fine. Add the subsystem to the domain profile if you want it on the servers; add it to the HC if you want it on the HC. It?s quite realistic people would only want one or the other. As we think about what other things we might migrate to a subsystem=core-management we need to think whether those items will follow that same pattern. If we identify some that won?t, then we need to decide what to do. Ideally there won?t be any such cases. Here?s what?s presently part of a server?s configuration: 1) configuration-changes ? this is one we should consider moving to the subsystem in WF 11 2) security-realms ? now comes from host.xml, but is being replaced by elytron, which presumably is now configured in domain.xml 3) outbound-connections ? now comes from host.xml 4) audit-log ? now comes from host.xml, via a kind of funky config style on the host. Would coming from domain.xml be better? 5) management-interfaces ? now comes from host.xml, and probably can still be set up by the HC. Given the current meaning of these resources, this is not really something particularly user configurable; the HC sets up the connections it wants so *it* can talk to the server; end user connectivity to the server is via the HC. If we start adding more things to these resources (e.g. there?s a discussio of adding other contexts) then it gets more complicated. 6) access-control ? this comes from the domain and is a domain-wide configuration not overridable at any lower level. As such, it?s not a good candidate for subsystem=core-management. > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Tue Sep 20 17:28:24 2016 From: jperkins at redhat.com (James Perkins) Date: Tue, 20 Sep 2016 14:28:24 -0700 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: Something to consider with regards to migration, or possibly even the notifications depending on the configuration, is having it as a subsystem/extension gives the user the option to remove the subsystem and/or extension. In some cases that might be okay, but others the resource might be required. For example I believe the console and possibly CLI are using the /core-management=capability-registry resource to query information about capabilities. On Tue, Sep 20, 2016 at 5:39 AM, Jeff Mesnil wrote: > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new > management-related resources instead of putting them in > /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user > code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put > under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's > the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new > subsystem instead. This will clarify the semantic of the resources and > uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new > management resources. > It will be the *successor* of /core-service=management (i.e. we stop > adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current > resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate > them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing > nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I > have no idea of the actual effort to do so (and ensure that we remain > compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the > resources underneath it. It also moves us towards the goal of extending > WildFly in an uniform way instead of adding special resources outside of > our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la > JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is > a good name. It is too generic (does it expose a management API ? la JMX? > does it provide management features based on other project such as > Hawkular?) and I don't think we should own such general term (even though > we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be > /subsystem=management-wildfly (feature + name of project providing the > feature) but it does not sound good. The subsystem provides a way to manage > WildFly, it does not provide a management feature *using* WildFly (this > could also clash with name of the extension if/when we implement Java EE > Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as > a 2nd choice). > > We have identified a few resources that are good candidates for this new > resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that > Elytron feature is not blocked by the development of my own feature (It > should be a single commit on wildfly-core and can be fit in Elytron PRs if > needed). > Then, we can have different PRs for new management resources that fits in > this new subsystem. > > We've also identified a simple management resource to evaluate the cost of > moving/migrating/redirecting resources with the > service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManag > ementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160920/16d1ee7d/attachment.html From brian.stansberry at redhat.com Tue Sep 20 17:52:22 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 20 Sep 2016 16:52:22 -0500 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: <145E1950-70EB-4E40-B367-0B78A938197F@redhat.com> Right; we would not move things like that to a subsystem. The core-service=management/service=management-operations resource tree is another one. These things are present in the kernel whether the user configures anything or not. > On Sep 20, 2016, at 4:28 PM, James Perkins wrote: > > Something to consider with regards to migration, or possibly even the notifications depending on the configuration, is having it as a subsystem/extension gives the user the option to remove the subsystem and/or extension. In some cases that might be okay, but others the resource might be required. For example I believe the console and possibly CLI are using the /core-management=capability-registry resource to query information about capabilities. > > On Tue, Sep 20, 2016 at 5:39 AM, Jeff Mesnil wrote: > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new management-related resources instead of putting them in /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new subsystem instead. This will clarify the semantic of the resources and uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new management resources. > It will be the *successor* of /core-service=management (i.e. we stop adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I have no idea of the actual effort to do so (and ensure that we remain compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the resources underneath it. It also moves us towards the goal of extending WildFly in an uniform way instead of adding special resources outside of our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is a good name. It is too generic (does it expose a management API ? la JMX? does it provide management features based on other project such as Hawkular?) and I don't think we should own such general term (even though we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be /subsystem=management-wildfly (feature + name of project providing the feature) but it does not sound good. The subsystem provides a way to manage WildFly, it does not provide a management feature *using* WildFly (this could also clash with name of the extension if/when we implement Java EE Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as a 2nd choice). > > We have identified a few resources that are good candidates for this new resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that Elytron feature is not blocked by the development of my own feature (It should be a single commit on wildfly-core and can be fit in Elytron PRs if needed). > Then, we can have different PRs for new management resources that fits in this new subsystem. > > We've also identified a simple management resource to evaluate the cost of moving/migrating/redirecting resources with the service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManagementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From bmcwhirt at redhat.com Wed Sep 21 00:03:12 2016 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 21 Sep 2016 00:03:12 -0400 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> Message-ID: Representing Swarm, +1 because subsystems are more consistent for us. Management core service has been an odd duck for us. We made it work but it's weird compared to the rest. Bob On Tuesday, September 20, 2016, Jeff Mesnil wrote: > Hi, > > TL;DR let's add a new subsystem to wildly-core to add new > management-related resources instead of putting them in > /core-service=management. Let's do that for WFLY 11. > > # Use case > > For WildFly 11, I have planned a new feature[1] to be able to notify user > code when the state of the server changes (running, reload-required, etc.). > Until now this kind of resources related to the server management were put > under /core-service=management. > However, this resource does not have well-defined semantic (e.g. what's > the meaning of /core-service=management for a DC?). > Brian proposed to stop putting resources under this resource and add a new > subsystem instead. This will clarify the semantic of the resources and > uniformize the configuration and management of WildFly. > > I propose to create a new extension in wildfly-core project to provide new > management resources. > It will be the *successor* of /core-service=management (i.e. we stop > adding *new* resources to /core-service=management). > This will not be a replacement for /core-service=management. Current > resources under /core-service=management will remain there for WildFly 11. > > I have no strong opinion about what doing after that: we can move/migrate > them under the new subsystem, redirect them using alias or do nothing. > Some resource related to security will be deprecated by Elytron so doing > nothing sounds correct for them. > Moving everything else to the new subsystem sounds a worthy goal but I > have no idea of the actual effort to do so (and ensure that we remain > compatible). The time and energy spent on this may not be worthwhile... > > # What is the scope of this subsystem? > > The scope would be identical to the /core-service=management resource. > Using a subsystem just make sure we have well-defined semantics for the > resources underneath it. It also moves us towards the goal of extending > WildFly in an uniform way instead of adding special resources outside of > our extension API. > > It is *not* a subsystem to manage WildFly or deployed applications ? la > JMX or JSR 77. > > # What is the name of this subsystem? > > The intuitive name would be /subsystem=management but I don't think it is > a good name. It is too generic (does it expose a management API ? la JMX? > does it provide management features based on other project such as > Hawkular?) and I don't think we should own such general term (even though > we do have such general subsystem names such as io, security, logging). > > If we follow the current convention, the name could be > /subsystem=management-wildfly (feature + name of project providing the > feature) but it does not sound good. The subsystem provides a way to manage > WildFly, it does not provide a management feature *using* WildFly (this > could also clash with name of the extension if/when we implement Java EE > Management API 2.0[2]). > I prefer */subsystem=core-management* (or /subsystem=wildfly-management as > a 2nd choice). > > We have identified a few resources that are good candidates for this new > resource: > > * the feature to notify user code of server stat changes[1] > * Elytron needs a new access=identity resource[3] > > # Roadmap > > I propose to create asap an empty subsystem as a first step so that > Elytron feature is not blocked by the development of my own feature (It > should be a single commit on wildfly-core and can be fit in Elytron PRs if > needed). > Then, we can have different PRs for new management resources that fits in > this new subsystem. > > We've also identified a simple management resource to evaluate the cost of > moving/migrating/redirecting resources with the > service=configuration-changes[4] and their implications for compatibility. > > Would you guys agree with that proposal? > > [1] https://issues.jboss.org/browse/WFCORE-1405 > [2] https://www.jcp.org/en/jsr/detail?id=373 > [3] https://developer.jboss.org/wiki/EnablingWildFlyElytronForManag > ementSecurity > [4] https://issues.jboss.org/browse/WFCORE-1642 > > > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160921/f99e7de2/attachment.html From VARD.ANTINYAN at cse.gu.se Wed Sep 21 11:08:36 2016 From: VARD.ANTINYAN at cse.gu.se (Vard Antinyan) Date: Wed, 21 Sep 2016 15:08:36 +0000 Subject: [wildfly-dev] Code complexity survey Message-ID: <338f6f170f254b43802636ada87e2a2f@cse.gu.se> Dear wildfly developers, We have undertaken a task to assess code complexity triggers and generate recommendations for developing simple and understandable code. Our intension is to share the results with you, developers, so everyone can learn the triggers behind complex software. We need your help for rigorous results. My request to you is - if you get 5-10 min. time, would you please consider to answer the questions of this survey on code complexity? https://goo.gl/forms/h9WXZ8VSEw7BUyHg1 You are welcome to learn preliminary results through this link: https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album&album_id=1639816749664288 The results will be shared in a public webpage and everyone possible will be invited to learn and discuss them. Your knowledge and experience is vital for achieving substantial and generalizable results, and your effort is much appreciated! Sincerely Vard Antinyan PhD candidate in University of Gothenburg, Sweden Tel: 0046317725707 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160921/772ca5d4/attachment.html From ehugonne at redhat.com Thu Sep 22 05:22:51 2016 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 22 Sep 2016 11:22:51 +0200 Subject: [wildfly-dev] How "optional" should the NoSQL integration be for WildFly... In-Reply-To: References: <6BBF3F9E-25E7-4AEB-82C6-A456629D6FFC@redhat.com> Message-ID: <6bf7637d-3114-3e84-1084-3f715f924f06@redhat.com> Hi, I've added a README.md for this part of the test suite on my PR https://github.com/wildfly/wildfly/pull/9063 Can't wait for it to be merged ;) Emmanuel Le 13/09/2016 ? 13:17, Anil Saldanha a ?crit : > Kabir - hi. > > Should this info be put on a wiki page for Wildfly community for test instructions? :-) > >> On Sep 13, 2016, at 4:35 AM, Kabir Khan wrote: >> >> >>> On 12 Sep 2016, at 17:52, Brian Stansberry wrote: >>> >>> >>>> On Sep 12, 2016, at 11:42 AM, Scott Marlow wrote: >>>> >>>> >>>> >>>>> On 09/12/2016 11:00 AM, Brian Stansberry wrote: >>>>> >>>>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm thinking that the NoSQL unit tests should be optional, since most >>>>>> WildFly developers won't have access to a local NoSQL database server. >>>>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g. >>>>>> ./integration-tests.sh -Dnosql-tests). >>>>> >>>>> The standard pattern for this kind of switch is something like >>>>> >>>>> -Dts.nosql >>>> >>>> Thanks, we will switch over to -Dts.nosql >>>> >>>>> >>>>> So please stick with that pattern. >>>>> >>>>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones. >>>> >>>> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases. >>>> >>>> I did a -DallTests run and the NoSQL tests were included. >>> >>> Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn?t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;) >> >> >> To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder >> >> The jboss.test.mixed.domain.dir property servers two purposes: >> - tells testsuite/mixed-domain where to find the directory containing the zips >> - in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml: >> >> >> mixed-domain.module.profile >> jboss.test.mixed.domain.dir >> >> mixed-domain >> >> >> >> >>> >>> Is there any property that defines how to have "(local) access to all of the NoSQL databases?? >>> >>> I ask because in the case of testsuite/mixed domain, there is ? a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There?s no -Dts.mixed-domain involved as that would just have been an extra thing to set. >>> >>>> >>>>> >>>>> That ?allTests? is an unfortunate name as it?s not all any more, but it?s widely known and used as the simple way to execute the vast bulk of the testsuite. >>>>> >>>>>> As we work towards our first (NoSQL integration) pull requests for >>>>>> WildFly master (and some small wildfly-core changes to the Phase class), >>>>>> does anything else need to be optional? >>>>>> >>>>>> Currently we are building WildFly to include the NoSQL driver artifacts, >>>>>> for the specific versions of the drivers that we support. We also allow >>>>>> other versions of the NoSQL drivers to be brought into WildFly, as long >>>>>> as they are (API) compatible with the version that we (loosely) >>>>>> integrate with. >>>>>> >>>>>> Thanks for the feedback! >>>>>> >>>>>> Scott >>>>>> _______________________________________________ >>>>>> 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160922/89dac00c/attachment.bin From jmesnil at redhat.com Fri Sep 23 07:52:24 2016 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 23 Sep 2016 13:52:24 +0200 Subject: [wildfly-dev] Proposal to add a new management subsystem to wildfly-core In-Reply-To: <05E0AFFB-18DD-4A5F-8CAD-F993B66DAD05@jboss.com> References: <80FBE7B8-0ECB-466B-A6DF-3FE8F2B2EF9F@redhat.com> <05E0AFFB-18DD-4A5F-8CAD-F993B66DAD05@jboss.com> Message-ID: <4619F5C3-E870-4E07-A0FB-066B7FCB455C@redhat.com> > On 20 Sep 2016, at 17:12, Kabir Khan wrote: > > Thinking down the line, if we > -do migrate everything from /core-service=management, and/or: > -add a lot more future 'core' functionality to subsystems > > I don't think we want one monolithic subsystem replacing this/doing everything. For now that doesn't sound too important, but should be taken into consideration when deciding on the name of the current subsystem. That?s a good point. My idea was that this core-management subsystem would contain resources targeted for both servers and host controllers. If/when we want to add features that are meant for host controllers only, it?ll be possible to add a 2nd subsystem (e.g. named host-management) that?d be provided by the same extension. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From david.lloyd at redhat.com Mon Sep 26 08:03:36 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 26 Sep 2016 07:03:36 -0500 Subject: [wildfly-dev] JBoss Invocation JIRA project Message-ID: <526b5178-79bc-8b1c-6253-fcccf53adf7b@redhat.com> Just want to let everyone know that jboss-invocation finally has a JIRA project after 5 years [1]. [1] https://issues.jboss.org/projects/JBINV -- - DML From brian.stansberry at redhat.com Mon Sep 26 10:11:35 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 26 Sep 2016 09:11:35 -0500 Subject: [wildfly-dev] JBoss Invocation JIRA project In-Reply-To: <526b5178-79bc-8b1c-6253-fcccf53adf7b@redhat.com> References: <526b5178-79bc-8b1c-6253-fcccf53adf7b@redhat.com> Message-ID: Congratulations! > On Sep 26, 2016, at 7:03 AM, David M. Lloyd wrote: > > Just want to let everyone know that jboss-invocation finally has a JIRA > project after 5 years [1]. > > [1] https://issues.jboss.org/projects/JBINV > -- > - 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 darran.lofthouse at jboss.com Tue Sep 27 10:47:06 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 27 Sep 2016 15:47:06 +0100 Subject: [wildfly-dev] Subsystem Hierarchy Message-ID: I have received the following request regarding the hierarchy of the Elytron subystem so just wanted to get some additional opinions: - https://issues.jboss.org/browse/WFLY-7190 The Elytron subsystem is implemented by having a number of different capabilities that are then chained together in the model to expose four / five capabilities that are then used across the application server to access security related services. https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security The reason for following the capability approach along with a component assembly approach to assembling the configuration is so that we are ready for other subsystems to be added to the server potentially providing their own implementations of these capabilities. For our capabilities we have one or more resource definitions making it possible to configure different implementations of the capabilities whilst having the configuration fully described in the model unlike the previous map approach for login modules. So the general problem is how should an administrator be able to see the resources by type. Within the admin console Claudio it looking at a tabbed interface where different tabs can contain different resources so that seems to be reasonably covered. Within the CLI however an administrator is just presented by all resource types within the subsystem when they use tab completion. One option could be for us to introduce an arbitrary layer in the subsystem and group our resources, e.g. /subsystem=elytron/component=name-rewriter/ /subsystem=elytron/component=security-realm/ But before taking that approach it feels as though this information is already there and there are possibly some other alternatives we could consider. Firstly I wonder if some of the read-* operations could have an opportunity to take into account capabilities of child resources to offer a filtered view? Another possible option could be CLI commands e.g. add-name-rewriter, add-security-realm - not sure if that would be one way to give a better user experience. Anyway just some random thoughts for the moment but wanted to open this up before jumping immediately to the artificial hierarchy solution. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Tue Sep 27 11:59:01 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 27 Sep 2016 10:59:01 -0500 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: References: Message-ID: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> > On Sep 27, 2016, at 9:47 AM, Darran Lofthouse wrote: > > I have received the following request regarding the hierarchy of the > Elytron subystem so just wanted to get some additional opinions: - > > https://issues.jboss.org/browse/WFLY-7190 > > The Elytron subsystem is implemented by having a number of different > capabilities that are then chained together in the model to expose four > / five capabilities that are then used across the application server to > access security related services. > > https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security > > The reason for following the capability approach along with a component > assembly approach to assembling the configuration is so that we are > ready for other subsystems to be added to the server potentially > providing their own implementations of these capabilities. > > For our capabilities we have one or more resource definitions making it > possible to configure different implementations of the capabilities > whilst having the configuration fully described in the model unlike the > previous map approach for login modules. > > So the general problem is how should an administrator be able to see the > resources by type. > > Within the admin console Claudio it looking at a tabbed interface where > different tabs can contain different resources so that seems to be > reasonably covered. > > Within the CLI however an administrator is just presented by all > resource types within the subsystem when they use tab completion. > > One option could be for us to introduce an arbitrary layer in the > subsystem and group our resources, e.g. > > /subsystem=elytron/component=name-rewriter/ > /subsystem=elytron/component=security-realm/ > So then /subsystem=elytron/component=name-rewriter/custom-name-rewriter=foo /subsystem=elytron/component=security-realm/jdbc-realm=bar That?s not clearly a benefit; it may be worse. The point here is better navigation. So the user isn?t sure: /subsystem=elytron/ Now unless there are no normal children, you see whatever stuff remains at the top, and ?component?. Picking a couple at random to provide an example component dir-context empty-role-decoder ... Now ?component? isn?t intuitive at all. But if the list is only 3-4 or less then maybe they guess it. Otherwise it is both obscure and buried amongst other things. /subsystem=elytron/component= Now they get a more refined list, and there is some benefit name-writer security-realm ? /subsystem=elytron/component=name-rewriter/ custom-name-rewriter constant-name-rewriter ?.. And finally they get to /subsystem=elytron/component=name-rewriter/custom-name-rewriter That?s 2 extra tab completes (four if you count the extra ?=? and ?/? in the path), the decision that ?component? is what they want, and the recognition that the thing they want, a ?custom-name-rewriter? is a form of ?name-rewriter?. So it?s dubious there is much of a gain. And of course for other use cases where people know what they want it?s added superfluous typing. A side benefit of the added level is it provides a place to describe the general characteristics of the component category in the read-resource-description output. > But before taking that approach it feels as though this information is > already there and there are possibly some other alternatives we could > consider. > > Firstly I wonder if some of the read-* operations could have an > opportunity to take into account capabilities of child resources to > offer a filtered view? > So /subsystem=elytron:read-children-types(provided-capability=org.wildfly.elytron.name-rewriter) I?m not sure how much that helps. This call would be used by the CLI to feed tab completion, not the user. But somehow the CLI needs the value 'org.wildfly.elytron.name-rewriter? and that cannot be inferred; it requires user input. Or /subsystem=elytron:read-children-resources(provided-capability=org.wildfly.elytron.name-rewriter) Here there?s some benefit but CLI would need to offer tab completion for 'provided-capability?. Before I?d want to invest energy in implementing that I?d like to see some concrete demand for that exact use case. It?s a pretty big jump from ?the subsystem is too flat? to ?significant numbers of users will make use of this specific read-children-resources variant" > Another possible option could be CLI commands e.g. add-name-rewriter, > add-security-realm - not sure if that would be one way to give a better > user experience. > This seems more direct. TBH though I?ve spent most of my thinking on my bits above and haven?t thought hard about this one. :) > Anyway just some random thoughts for the moment but wanted to open this > up before jumping immediately to the artificial hierarchy solution. > > Regards, > Darran Lofthouse. > > _______________________________________________ > 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 darran.lofthouse at jboss.com Wed Sep 28 07:16:48 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 28 Sep 2016 12:16:48 +0100 Subject: [wildfly-dev] ObjectType Review /subsystem=elytron/properties-realm=* Message-ID: A number of resources have been flagged within the Elytron subsystem requesting that we review the use of ObjectTypes (and similar) within the resource definitions. Some I know we can simplify but others I would like to get a second opinion on, firstly I wanted to look at the 'properties-realm' resource. https://gist.github.com/darranl/ef7b06222e4dbe7ba242f7a5a2da991e This is a realm implemented to make use of the legacy properties files users of AS7 through WF10 will be familiar with so we need to reference two different properties files with the group-properties being optional. Where a file is referenced it is common to reference both a path and a relative-to, rather than looking to find unique names for two path attributes and unique names for two relative-to attributes I have wrapped in specific OBJECT type attributes. I could achieve a similar grouping by flattening and using attribute groups but then the path and relative-to attributes would require unique names. Personally I just felt that for two attributes always used as a pair it was cleaner to wrap them into one. Note: Checking the output myself the path should not be nillable and the relative-to should not allow expressions so those two will be corrected. Regards, Darran Lofthouse. From darran.lofthouse at jboss.com Wed Sep 28 07:23:58 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 28 Sep 2016 12:23:58 +0100 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> References: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> Message-ID: Thanks Brian. I kind of think, even if we don't know the solution today but we do think usability is something we should handle in the admin tools then it will be better to leave the hierarchy as-is - alternatively if we felt this is insufficient information from the subsystem then modify the hierarchy there. In the documentation I want to add a structure similar to the grouping Claudio is using for HAL but generally if an administrator is looking to add a resource for a specific capability e.g. security-realm all resources will be listed together in the documentation. Another random CLI option: - Add an add-capability command relative to a point in the hierarchy. - capability would be a parameter which can tab complete based on capabilities at that point. - type can tab complete a much shorter list once we know the desired capability. - name the name the new resource will have. At that point additional parameters could tab complete as we know the resource type. Darran. On 27/09/16 16:59, Brian Stansberry wrote: > >> On Sep 27, 2016, at 9:47 AM, Darran Lofthouse wrote: >> >> I have received the following request regarding the hierarchy of the >> Elytron subystem so just wanted to get some additional opinions: - >> >> https://issues.jboss.org/browse/WFLY-7190 >> >> The Elytron subsystem is implemented by having a number of different >> capabilities that are then chained together in the model to expose four >> / five capabilities that are then used across the application server to >> access security related services. >> >> https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security >> >> The reason for following the capability approach along with a component >> assembly approach to assembling the configuration is so that we are >> ready for other subsystems to be added to the server potentially >> providing their own implementations of these capabilities. >> >> For our capabilities we have one or more resource definitions making it >> possible to configure different implementations of the capabilities >> whilst having the configuration fully described in the model unlike the >> previous map approach for login modules. >> >> So the general problem is how should an administrator be able to see the >> resources by type. >> >> Within the admin console Claudio it looking at a tabbed interface where >> different tabs can contain different resources so that seems to be >> reasonably covered. >> >> Within the CLI however an administrator is just presented by all >> resource types within the subsystem when they use tab completion. >> >> One option could be for us to introduce an arbitrary layer in the >> subsystem and group our resources, e.g. >> >> /subsystem=elytron/component=name-rewriter/ >> /subsystem=elytron/component=security-realm/ >> > > So then > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter=foo > /subsystem=elytron/component=security-realm/jdbc-realm=bar > > That?s not clearly a benefit; it may be worse. > > The point here is better navigation. So the user isn?t sure: > > /subsystem=elytron/ > > Now unless there are no normal children, you see whatever stuff remains at the top, and ?component?. Picking a couple at random to provide an example > > component dir-context empty-role-decoder ... > > Now ?component? isn?t intuitive at all. But if the list is only 3-4 or less then maybe they guess it. Otherwise it is both obscure and buried amongst other things. > > /subsystem=elytron/component= > > Now they get a more refined list, and there is some benefit > > name-writer security-realm ? > > /subsystem=elytron/component=name-rewriter/ > > custom-name-rewriter constant-name-rewriter ?.. > > And finally they get to > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter > > That?s 2 extra tab completes (four if you count the extra ?=? and ?/? in the path), the decision that ?component? is what they want, and the recognition that the thing they want, a ?custom-name-rewriter? is a form of ?name-rewriter?. > > So it?s dubious there is much of a gain. And of course for other use cases where people know what they want it?s added superfluous typing. > > A side benefit of the added level is it provides a place to describe the general characteristics of the component category in the read-resource-description output. > >> But before taking that approach it feels as though this information is >> already there and there are possibly some other alternatives we could >> consider. >> >> Firstly I wonder if some of the read-* operations could have an >> opportunity to take into account capabilities of child resources to >> offer a filtered view? >> > > So > > /subsystem=elytron:read-children-types(provided-capability=org.wildfly.elytron.name-rewriter) > > I?m not sure how much that helps. This call would be used by the CLI to feed tab completion, not the user. But somehow the CLI needs the value 'org.wildfly.elytron.name-rewriter? and that cannot be inferred; it requires user input. > > Or > > /subsystem=elytron:read-children-resources(provided-capability=org.wildfly.elytron.name-rewriter) > > Here there?s some benefit but CLI would need to offer tab completion for 'provided-capability?. > > Before I?d want to invest energy in implementing that I?d like to see some concrete demand for that exact use case. It?s a pretty big jump from ?the subsystem is too flat? to ?significant numbers of users will make use of this specific read-children-resources variant" > >> Another possible option could be CLI commands e.g. add-name-rewriter, >> add-security-realm - not sure if that would be one way to give a better >> user experience. >> > > This seems more direct. TBH though I?ve spent most of my thinking on my bits above and haven?t thought hard about this one. :) > >> Anyway just some random thoughts for the moment but wanted to open this >> up before jumping immediately to the artificial hierarchy solution. >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From hpehl at redhat.com Wed Sep 28 08:53:53 2016 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 28 Sep 2016 14:53:53 +0200 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: References: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> Message-ID: We often derive the navigation in HAL from the management model tree. But it's also quite common that we shuffle things around and add own hierarchies to group resources differently. So I don't think that changing the hierarchy would make any difference in terms of HAL. More important to me is a logical grouping of resources which belong together. This should be reflected in both the documentation and in HAL. On Wed, Sep 28, 2016 at 1:23 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > Thanks Brian. > > I kind of think, even if we don't know the solution today but we do > think usability is something we should handle in the admin tools then it > will be better to leave the hierarchy as-is - alternatively if we felt > this is insufficient information from the subsystem then modify the > hierarchy there. > > In the documentation I want to add a structure similar to the grouping > Claudio is using for HAL but generally if an administrator is looking to > add a resource for a specific capability e.g. security-realm all > resources will be listed together in the documentation. > > Another random CLI option: - > > Add an add-capability command relative to a point in the hierarchy. > - capability would be a parameter which can tab complete based on > capabilities at that point. > - type can tab complete a much shorter list once we know the desired > capability. > - name the name the new resource will have. > > At that point additional parameters could tab complete as we know the > resource type. > > Darran. > > > On 27/09/16 16:59, Brian Stansberry wrote: > > > >> On Sep 27, 2016, at 9:47 AM, Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> > >> I have received the following request regarding the hierarchy of the > >> Elytron subystem so just wanted to get some additional opinions: - > >> > >> https://issues.jboss.org/browse/WFLY-7190 > >> > >> The Elytron subsystem is implemented by having a number of different > >> capabilities that are then chained together in the model to expose four > >> / five capabilities that are then used across the application server to > >> access security related services. > >> > >> https://github.com/wildfly-security-incubator/wildfly- > capabilities/tree/elytron_integration/org/wildfly/security > >> > >> The reason for following the capability approach along with a component > >> assembly approach to assembling the configuration is so that we are > >> ready for other subsystems to be added to the server potentially > >> providing their own implementations of these capabilities. > >> > >> For our capabilities we have one or more resource definitions making it > >> possible to configure different implementations of the capabilities > >> whilst having the configuration fully described in the model unlike the > >> previous map approach for login modules. > >> > >> So the general problem is how should an administrator be able to see the > >> resources by type. > >> > >> Within the admin console Claudio it looking at a tabbed interface where > >> different tabs can contain different resources so that seems to be > >> reasonably covered. > >> > >> Within the CLI however an administrator is just presented by all > >> resource types within the subsystem when they use tab completion. > >> > >> One option could be for us to introduce an arbitrary layer in the > >> subsystem and group our resources, e.g. > >> > >> /subsystem=elytron/component=name-rewriter/ > >> /subsystem=elytron/component=security-realm/ > >> > > > > So then > > > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter=foo > > /subsystem=elytron/component=security-realm/jdbc-realm=bar > > > > That?s not clearly a benefit; it may be worse. > > > > The point here is better navigation. So the user isn?t sure: > > > > /subsystem=elytron/ > > > > Now unless there are no normal children, you see whatever stuff remains > at the top, and ?component?. Picking a couple at random to provide an > example > > > > component dir-context empty-role-decoder ... > > > > Now ?component? isn?t intuitive at all. But if the list is only 3-4 or > less then maybe they guess it. Otherwise it is both obscure and buried > amongst other things. > > > > /subsystem=elytron/component= > > > > Now they get a more refined list, and there is some benefit > > > > name-writer security-realm ? > > > > /subsystem=elytron/component=name-rewriter/ > > > > custom-name-rewriter constant-name-rewriter ?.. > > > > And finally they get to > > > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter > > > > That?s 2 extra tab completes (four if you count the extra ?=? and ?/? in > the path), the decision that ?component? is what they want, and the > recognition that the thing they want, a ?custom-name-rewriter? is a form of > ?name-rewriter?. > > > > So it?s dubious there is much of a gain. And of course for other use > cases where people know what they want it?s added superfluous typing. > > > > A side benefit of the added level is it provides a place to describe the > general characteristics of the component category in the > read-resource-description output. > > > >> But before taking that approach it feels as though this information is > >> already there and there are possibly some other alternatives we could > >> consider. > >> > >> Firstly I wonder if some of the read-* operations could have an > >> opportunity to take into account capabilities of child resources to > >> offer a filtered view? > >> > > > > So > > > > /subsystem=elytron:read-children-types(provided-capability=org.wildfly. > elytron.name-rewriter) > > > > I?m not sure how much that helps. This call would be used by the CLI to > feed tab completion, not the user. But somehow the CLI needs the value > 'org.wildfly.elytron.name-rewriter? and that cannot be inferred; it > requires user input. > > > > Or > > > > /subsystem=elytron:read-children-resources(provided- > capability=org.wildfly.elytron.name-rewriter) > > > > Here there?s some benefit but CLI would need to offer tab completion for > 'provided-capability?. > > > > Before I?d want to invest energy in implementing that I?d like to see > some concrete demand for that exact use case. It?s a pretty big jump from > ?the subsystem is too flat? to ?significant numbers of users will make use > of this specific read-children-resources variant" > > > >> Another possible option could be CLI commands e.g. add-name-rewriter, > >> add-security-realm - not sure if that would be one way to give a better > >> user experience. > >> > > > > This seems more direct. TBH though I?ve spent most of my thinking on my > bits above and haven?t thought hard about this one. :) > > > >> Anyway just some random thoughts for the moment but wanted to open this > >> up before jumping immediately to the artificial hierarchy solution. > >> > >> Regards, > >> Darran Lofthouse. > >> > >> _______________________________________________ > >> 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 > -- --- 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/20160928/4a3e30e3/attachment-0001.html From hpehl at redhat.com Wed Sep 28 10:36:57 2016 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 28 Sep 2016 16:36:57 +0200 Subject: [wildfly-dev] ObjectType Review /subsystem=elytron/properties-realm=* In-Reply-To: References: Message-ID: I see your point grouping similar attributes as one ObjectType attribute. For HAL it's always easier to work with simple attributes. This is especially true for automatically generated UIs. OTOH attributes tuples like {path, relative-to} are quite common. The logging subsystem uses them in various resources. So adding support for those tuples seems reasonable (in fact we already support them in HAL.next). So keeping them for /subsystem=elytron/properties-realm=* is ok for me. What we should avoid though are deeply nested attributes. (e.g. lists inside objects) On Wed, Sep 28, 2016 at 1:16 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > A number of resources have been flagged within the Elytron subsystem > requesting that we review the use of ObjectTypes (and similar) within > the resource definitions. > > Some I know we can simplify but others I would like to get a second > opinion on, firstly I wanted to look at the 'properties-realm' resource. > > https://gist.github.com/darranl/ef7b06222e4dbe7ba242f7a5a2da991e > > This is a realm implemented to make use of the legacy properties files > users of AS7 through WF10 will be familiar with so we need to reference > two different properties files with the group-properties being optional. > > Where a file is referenced it is common to reference both a path and a > relative-to, rather than looking to find unique names for two path > attributes and unique names for two relative-to attributes I have > wrapped in specific OBJECT type attributes. > > I could achieve a similar grouping by flattening and using attribute > groups but then the path and relative-to attributes would require unique > names. Personally I just felt that for two attributes always used as a > pair it was cleaner to wrap them into one. > > Note: Checking the output myself the path should not be nillable and > the relative-to should not allow expressions so those two will be > corrected. > > Regards, > Darran Lofthouse. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160928/885b76bc/attachment.html From claudio at claudius.com.br Wed Sep 28 11:20:30 2016 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 28 Sep 2016 12:20:30 -0300 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: References: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> Message-ID: On Wed, Sep 28, 2016 at 9:53 AM, Harald Pehl wrote: > More important to me is a logical grouping of resources which belong > together. This should be reflected in both the documentation and in HAL. This is the grouping I did, suggestions are welcome * Role Mapper add-prefix-role-mapper add-suffix-role-mapper aggregate-role-mapper constant-role-mapper custom-role-mapper logical-role-mapper * Decoder aggregate-principal-decoder concatenating-principal-decoder constant-principal-decoder custom-principal-decoder x500-attribute-principal-decoder custom-role-decoder empty-role-decoder simple-role-decoder * Factory aggregate-http-server-mechanism-factory aggregate-sasl-server-factory configurable-http-server-mechanism-factory configurable-sasl-server-factory custom-credential-security-factory http-authentication-factory kerberos-security-factory mechanism-provider-filtering-sasl-server-factory provider-http-server-mechanism-factory provider-sasl-server-factory sasl-authentication-factory service-loader-http-server-mechanism-factory service-loader-sasl-server-factory * Realm properties-realm filesystem-realm jdbc-realm ldap-realm key-store-realm aggregate-realm custom-modifiable-realm custom-realm custom-realm-mapper mapped-regex-realm-mapper simple-regex-realm-mapper * Rewriter aggregate-name-rewriter chained-name-rewriter constant-name-rewriter custom-name-rewriter regex-name-validating-rewriter regex-name-rewriter * Permission Mapper custom-permission-mapper logical-permission-mapper simple-permission-mapper * SSL key-managers key-store provider-loader server-ssl-context trust-managers * Security Domain security-domain security-property * LDAP Connection dir-context -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From jdenise at redhat.com Wed Sep 28 11:44:43 2016 From: jdenise at redhat.com (Jean-Francois Denise) Date: Wed, 28 Sep 2016 17:44:43 +0200 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: References: <351DAC47-ED04-4B43-813F-24F16EA91F2B@redhat.com> Message-ID: <6998a4f0-ab37-9c17-c70f-9a8f58ca4ede@redhat.com> Daran, I have looked at the /subsystem=elytron content. From this long list it is difficult to extract use cases. Grouping the resources (as Claudio did) in a way that reflects your object model (https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security) can help. Thinking at various administrator use cases (that would activate multiple resources in sequential steps) could help define the best security related CLI commands. I guess that we would not expose commands for everything but if we cover the main actions, the low level operation support (with completion for capabilities) would help handle the missing pieces. I am available if you are ready to teach me a bit ;-). Thanks. JF On 28/09/16 17:20, Claudio Miranda wrote: > On Wed, Sep 28, 2016 at 9:53 AM, Harald Pehl wrote: >> More important to me is a logical grouping of resources which belong >> together. This should be reflected in both the documentation and in HAL. > This is the grouping I did, suggestions are welcome > > * Role Mapper > add-prefix-role-mapper > add-suffix-role-mapper > aggregate-role-mapper > constant-role-mapper > custom-role-mapper > logical-role-mapper > > * Decoder > aggregate-principal-decoder > concatenating-principal-decoder > constant-principal-decoder > custom-principal-decoder > x500-attribute-principal-decoder > custom-role-decoder > empty-role-decoder > simple-role-decoder > > * Factory > aggregate-http-server-mechanism-factory > aggregate-sasl-server-factory > configurable-http-server-mechanism-factory > configurable-sasl-server-factory > custom-credential-security-factory > http-authentication-factory > kerberos-security-factory > mechanism-provider-filtering-sasl-server-factory > provider-http-server-mechanism-factory > provider-sasl-server-factory > sasl-authentication-factory > service-loader-http-server-mechanism-factory > service-loader-sasl-server-factory > > * Realm > properties-realm > filesystem-realm > jdbc-realm > ldap-realm > key-store-realm > aggregate-realm > custom-modifiable-realm > custom-realm > custom-realm-mapper > mapped-regex-realm-mapper > simple-regex-realm-mapper > > * Rewriter > aggregate-name-rewriter > chained-name-rewriter > constant-name-rewriter > custom-name-rewriter > regex-name-validating-rewriter > regex-name-rewriter > > * Permission Mapper > custom-permission-mapper > logical-permission-mapper > simple-permission-mapper > > * SSL > key-managers > key-store > provider-loader > server-ssl-context > trust-managers > > * Security Domain > security-domain > security-property > > * LDAP Connection > dir-context > > From jcacek at redhat.com Fri Sep 30 04:12:37 2016 From: jcacek at redhat.com (Josef Cacek) Date: Fri, 30 Sep 2016 04:12:37 -0400 (EDT) Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: References: Message-ID: <234337425.525050.1475223157653.JavaMail.zimbra@redhat.com> Hi Darran, thank you for raising this discussion. We've heard from users/customers about complexity of WildFly/EAP management tools and it's one of the reasons why we prefer to split the hierarchy into logical groups instead of using the flat structure. We would also like to hear opinion of the UX team. What was not mentioned before is the fact that one possible grouping is already present in the XSD of the Elytron subsystem: - security-properties - provider-loaders - security-domains - security-realms - credential-security-factories - mappers - http - sasl - tls - dir-contexts IMO the domain model doesn't need to copy the XSD, but it could be a good starting point in the discussion. Introducing the deeper hierarchy in the model would also allow to describe what each group ("component" in your sample) is responsible for and also how it relates to other groups. The objection, that the experienced administrators would need to write longer commands is not so important from our point of view. For us seems much more important the quick boot into the configuration for administrators, which meets the Elytron subsystem for the first time. The flat model solution disallows to work with CLI with the way like: "I know I need some realm, but don't know which exactly". Current flat solution is not able to display all available security-realm. Thanks, -- Josef ----- Original Message ----- > From: "Darran Lofthouse" > To: "WildFly Dev" > Sent: Tuesday, September 27, 2016 4:47:06 PM > Subject: [wildfly-dev] Subsystem Hierarchy > > I have received the following request regarding the hierarchy of the > Elytron subystem so just wanted to get some additional opinions: - > > https://issues.jboss.org/browse/WFLY-7190 > > The Elytron subsystem is implemented by having a number of different > capabilities that are then chained together in the model to expose four > / five capabilities that are then used across the application server to > access security related services. > > https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security > > The reason for following the capability approach along with a component > assembly approach to assembling the configuration is so that we are > ready for other subsystems to be added to the server potentially > providing their own implementations of these capabilities. > > For our capabilities we have one or more resource definitions making it > possible to configure different implementations of the capabilities > whilst having the configuration fully described in the model unlike the > previous map approach for login modules. > > So the general problem is how should an administrator be able to see the > resources by type. > > Within the admin console Claudio it looking at a tabbed interface where > different tabs can contain different resources so that seems to be > reasonably covered. > > Within the CLI however an administrator is just presented by all > resource types within the subsystem when they use tab completion. > > One option could be for us to introduce an arbitrary layer in the > subsystem and group our resources, e.g. > > /subsystem=elytron/component=name-rewriter/ > /subsystem=elytron/component=security-realm/ > > But before taking that approach it feels as though this information is > already there and there are possibly some other alternatives we could > consider. > > Firstly I wonder if some of the read-* operations could have an > opportunity to take into account capabilities of child resources to > offer a filtered view? > > Another possible option could be CLI commands e.g. add-name-rewriter, > add-security-realm - not sure if that would be one way to give a better > user experience. > > Anyway just some random thoughts for the moment but wanted to open this > up before jumping immediately to the artificial hierarchy solution. > > Regards, > Darran Lofthouse. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jcacek at redhat.com Fri Sep 30 04:18:01 2016 From: jcacek at redhat.com (Josef Cacek) Date: Fri, 30 Sep 2016 04:18:01 -0400 (EDT) Subject: [wildfly-dev] Fwd: Subsystem Hierarchy In-Reply-To: <234337425.525050.1475223157653.JavaMail.zimbra@redhat.com> References: <234337425.525050.1475223157653.JavaMail.zimbra@redhat.com> Message-ID: <604661537.525717.1475223481145.JavaMail.zimbra@redhat.com> Hi Josephine, there is ongoing discussion [1] about WildFly Elytron subsystem domain model and its usability from CLI tool. Could you share UX advices for the CLI usability of Elytron subsystem? [1] http://lists.jboss.org/pipermail/wildfly-dev/2016-September/005487.html Thank you, -- Josef Cacek JBoss EAP QE ----- Forwarded Message ----- From: "Josef Cacek" To: "Darran Lofthouse" Cc: "WildFly Dev" Sent: Friday, September 30, 2016 10:12:37 AM Subject: Re: [wildfly-dev] Subsystem Hierarchy Hi Darran, thank you for raising this discussion. We've heard from users/customers about complexity of WildFly/EAP management tools and it's one of the reasons why we prefer to split the hierarchy into logical groups instead of using the flat structure. We would also like to hear opinion of the UX team. What was not mentioned before is the fact that one possible grouping is already present in the XSD of the Elytron subsystem: - security-properties - provider-loaders - security-domains - security-realms - credential-security-factories - mappers - http - sasl - tls - dir-contexts IMO the domain model doesn't need to copy the XSD, but it could be a good starting point in the discussion. Introducing the deeper hierarchy in the model would also allow to describe what each group ("component" in your sample) is responsible for and also how it relates to other groups. The objection, that the experienced administrators would need to write longer commands is not so important from our point of view. For us seems much more important the quick boot into the configuration for administrators, which meets the Elytron subsystem for the first time. The flat model solution disallows to work with CLI with the way like: "I know I need some realm, but don't know which exactly". Current flat solution is not able to display all available security-realm. Thanks, -- Josef ----- Original Message ----- > From: "Darran Lofthouse" > To: "WildFly Dev" > Sent: Tuesday, September 27, 2016 4:47:06 PM > Subject: [wildfly-dev] Subsystem Hierarchy > > I have received the following request regarding the hierarchy of the > Elytron subystem so just wanted to get some additional opinions: - > > https://issues.jboss.org/browse/WFLY-7190 > > The Elytron subsystem is implemented by having a number of different > capabilities that are then chained together in the model to expose four > / five capabilities that are then used across the application server to > access security related services. > > https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security > > The reason for following the capability approach along with a component > assembly approach to assembling the configuration is so that we are > ready for other subsystems to be added to the server potentially > providing their own implementations of these capabilities. > > For our capabilities we have one or more resource definitions making it > possible to configure different implementations of the capabilities > whilst having the configuration fully described in the model unlike the > previous map approach for login modules. > > So the general problem is how should an administrator be able to see the > resources by type. > > Within the admin console Claudio it looking at a tabbed interface where > different tabs can contain different resources so that seems to be > reasonably covered. > > Within the CLI however an administrator is just presented by all > resource types within the subsystem when they use tab completion. > > One option could be for us to introduce an arbitrary layer in the > subsystem and group our resources, e.g. > > /subsystem=elytron/component=name-rewriter/ > /subsystem=elytron/component=security-realm/ > > But before taking that approach it feels as though this information is > already there and there are possibly some other alternatives we could > consider. > > Firstly I wonder if some of the read-* operations could have an > opportunity to take into account capabilities of child resources to > offer a filtered view? > > Another possible option could be CLI commands e.g. add-name-rewriter, > add-security-realm - not sure if that would be one way to give a better > user experience. > > Anyway just some random thoughts for the moment but wanted to open this > up before jumping immediately to the artificial hierarchy solution. > > Regards, > Darran Lofthouse. > > _______________________________________________ > 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 Fri Sep 30 09:56:25 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 30 Sep 2016 14:56:25 +0100 Subject: [wildfly-dev] Subsystem Hierarchy In-Reply-To: <234337425.525050.1475223157653.JavaMail.zimbra@redhat.com> References: <234337425.525050.1475223157653.JavaMail.zimbra@redhat.com> Message-ID: <15ae4bab-22bb-abcc-f473-f8aad32ee01e@jboss.com> I think two very different concepts are getting mixed up here, management tooling usability and subsystem design. At the moment we are talking about very low level access to the subsystem - speaking with various engineers I have not yet heard a compelling argument that this aspect of usability is something to handle all the way at the subsystem level. I think we need to get the original bug reports accurately re-described for the problem they are claiming needs solving, at the moment they are requesting a change rather than describing the problem. Regards, Darran Lofthouse. On 30/09/16 09:12, Josef Cacek wrote: > Hi Darran, > > thank you for raising this discussion. We've heard from users/customers about complexity of WildFly/EAP management tools and it's one of the reasons why we prefer to split the hierarchy into logical groups instead of using the flat structure. We would also like to hear opinion of the UX team. > > What was not mentioned before is the fact that one possible grouping is already present in the XSD of the Elytron subsystem: > - security-properties > - provider-loaders > - security-domains > - security-realms > - credential-security-factories > - mappers > - http > - sasl > - tls > - dir-contexts > > IMO the domain model doesn't need to copy the XSD, but it could be a good starting point in the discussion. > > Introducing the deeper hierarchy in the model would also allow to describe what each group ("component" in your sample) is responsible for and also how it relates to other groups. > > The objection, that the experienced administrators would need to write longer commands is not so important from our point of view. For us seems much more important the quick boot into the configuration for administrators, which meets the Elytron subsystem for the first time. > > The flat model solution disallows to work with CLI with the way like: "I know I need some realm, but don't know which exactly". Current flat solution is not able to display all available security-realm. > > Thanks, > > -- Josef > > ----- Original Message ----- >> From: "Darran Lofthouse" >> To: "WildFly Dev" >> Sent: Tuesday, September 27, 2016 4:47:06 PM >> Subject: [wildfly-dev] Subsystem Hierarchy >> >> I have received the following request regarding the hierarchy of the >> Elytron subystem so just wanted to get some additional opinions: - >> >> https://issues.jboss.org/browse/WFLY-7190 >> >> The Elytron subsystem is implemented by having a number of different >> capabilities that are then chained together in the model to expose four >> / five capabilities that are then used across the application server to >> access security related services. >> >> https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security >> >> The reason for following the capability approach along with a component >> assembly approach to assembling the configuration is so that we are >> ready for other subsystems to be added to the server potentially >> providing their own implementations of these capabilities. >> >> For our capabilities we have one or more resource definitions making it >> possible to configure different implementations of the capabilities >> whilst having the configuration fully described in the model unlike the >> previous map approach for login modules. >> >> So the general problem is how should an administrator be able to see the >> resources by type. >> >> Within the admin console Claudio it looking at a tabbed interface where >> different tabs can contain different resources so that seems to be >> reasonably covered. >> >> Within the CLI however an administrator is just presented by all >> resource types within the subsystem when they use tab completion. >> >> One option could be for us to introduce an arbitrary layer in the >> subsystem and group our resources, e.g. >> >> /subsystem=elytron/component=name-rewriter/ >> /subsystem=elytron/component=security-realm/ >> >> But before taking that approach it feels as though this information is >> already there and there are possibly some other alternatives we could >> consider. >> >> Firstly I wonder if some of the read-* operations could have an >> opportunity to take into account capabilities of child resources to >> offer a filtered view? >> >> Another possible option could be CLI commands e.g. add-name-rewriter, >> add-security-realm - not sure if that would be one way to give a better >> user experience. >> >> Anyway just some random thoughts for the moment but wanted to open this >> up before jumping immediately to the artificial hierarchy solution. >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From ceharris414 at me.com Fri Sep 30 11:42:21 2016 From: ceharris414 at me.com (Carl Harris) Date: Fri, 30 Sep 2016 11:42:21 -0400 Subject: [wildfly-dev] use JGroups in a web application Message-ID: I?m building a web application that targets Wildfly 10, and runs in a Wildfly HA cluster. In the application, I need to do some coordination between application nodes using JGroups. It seems silly to bring JGroups into the application itself, when Wildfly already needs a correctly configured JGroups stack for its own use. I was thinking of making an extension that (through a deployment processor) adds a CDI extension to the web application to process injection points annotated with a @JGroupsChannel qualifier and inject a Channel bean. The CDI extension would be injected with JGroups services registered by Wildfly?s jgroups subsystem. Parameters on the annotation would allow the specification of the JGroups stack and channel name. Before I started down this path, I thought I?d ask if there?s a more straightforward way to accomplish this; i.e. is there a better way to make use of Wildfly?s jgroups subsystem in my web application? Thanks, carl From paul.ferraro at redhat.com Fri Sep 30 11:52:01 2016 From: paul.ferraro at redhat.com (Paul Ferraro) Date: Fri, 30 Sep 2016 11:52:01 -0400 Subject: [wildfly-dev] use JGroups in a web application In-Reply-To: References: Message-ID: Please use the wildfly forums for questions of this nature. https://developer.jboss.org/en/wildfly I promise to reply right away. :) Paul On Fri, Sep 30, 2016 at 11:42 AM, Carl Harris wrote: > I?m building a web application that targets Wildfly 10, and runs in a Wildfly HA cluster. In the application, I need to do some coordination between application nodes using JGroups. It seems silly to bring JGroups into the application itself, when Wildfly already needs a correctly configured JGroups stack for its own use. > > I was thinking of making an extension that (through a deployment processor) adds a CDI extension to the web application to process injection points annotated with a @JGroupsChannel qualifier and inject a Channel bean. The CDI extension would be injected with JGroups services registered by Wildfly?s jgroups subsystem. Parameters on the annotation would allow the specification of the JGroups stack and channel name. > > Before I started down this path, I thought I?d ask if there?s a more straightforward way to accomplish this; i.e. is there a better way to make use of Wildfly?s jgroups subsystem in my web application? > > Thanks, > > carl > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev