From ckujawa_wfd at nhkujawas.com Tue Jul 1 06:53:50 2014 From: ckujawa_wfd at nhkujawas.com (Chris Kujawa) Date: Tue, 1 Jul 2014 06:53:50 -0400 Subject: [wildfly-dev] Documentation to get started? Message-ID: Hello. My name is Chris. I'm a Java developer with over 10 years of commercial experience (and more as a hobbyist) and I was recently looking for an open-source project to contribute to so I can give something back to the community--and since I frequently use jBoss I thought Wildfly just might be the thing. I've worked my way through the "Hacking on Wildfly" page and thought that WFLY-717 (Add ability to launch H2 console...) might be a good place to start. So I started poking around looking for where I might add such a link and can't seem to work out how the "App.html" page is built in the admin console. Is there documentation that I've missed that would walk me through this process? Additionally, I thought that the "home" section might be a good place to add such a link, since the other panels all seem to contain Wildfly specific functionality. Or...perhaps I could add a new panel (H2 or even Utilities) and add the link there...thoughts? Thank you in advance...and I'm looking forward to giving back to this great tool that I've used many times in the past! -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140701/69fd7c23/attachment.html From ssilvert at redhat.com Tue Jul 1 07:55:20 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 07:55:20 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B22042.5010508@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> Message-ID: <53B2A1A8.6090505@redhat.com> On 6/30/2014 10:43 PM, Stuart Douglas wrote: > It really sounds like this should not be part of core, but should be > something extra that just integrates with the core. That may be true, but it's not a decision that should depend on how many modules must be added. The central question is, do we want Keycloak to work out of the box? Before this issue was known, everyone answered "yes". Should we really determine our feature set based on how many modules it requires? I don't think we want do that, which is why I'm having doubts about the current approach. > > In all honesty we are highly unlikely to ever have accepted a PR that > added all these dependencies to the core in any case, so it is a > problem that would have had to be solved at some point anyway. > > Stuart > > Stan Silvert wrote: >> I'm starting to have doubts about this split. >> >> Right now I'm trying to integrate the Keycloak (client-side) adapter >> into build-core so that the web console can use Keycloak for >> authentication. The problem is that there is a huge web of dependencies >> that must be moved over from build to build-core. >> >> What exactly is the split trying to solve? >> >> Stan >> >> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>> Hi all, >>> >>> So I am moderately confident that we will be ready to split out Wildfly >>> core into a separate repository early next week (I'm not saying that it >>> will definitely happen in this time frame, just that it should be >>> possible). >>> >>> Once this is ready to go I think the basic process will be: >>> >>> - Code freeze on Master >>> - Create the core repo, push new rewritten core history >>> - Release core 1.0.0.Beta1 >>> - Create PR against core WF repo that deletes everything in core, and >>> uses the core 1.0.0.Beta1 release >>> - End of code freeze >>> >>> Stuart >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From vtunka at redhat.com Tue Jul 1 08:25:43 2014 From: vtunka at redhat.com (Vaclav Tunka) Date: Tue, 01 Jul 2014 14:25:43 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2A1A8.6090505@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> Message-ID: <53B2A8C7.5030406@redhat.com> I thought core is just: MSC, logging, class loading, modules, management So something fairly generic you can use as a basis for various container projects. My impression is Keycloak does not belong into the categories above, but maybe I don't know all the details. Cheers, Vaclav On 07/01/2014 01:55 PM, Stan Silvert wrote: > On 6/30/2014 10:43 PM, Stuart Douglas wrote: >> It really sounds like this should not be part of core, but should be >> something extra that just integrates with the core. > That may be true, but it's not a decision that should depend on how many > modules must be added. > > The central question is, do we want Keycloak to work out of the box? > Before this issue was known, everyone answered "yes". > > Should we really determine our feature set based on how many modules it > requires? I don't think we want do that, which is why I'm having > doubts about the current approach. > >> >> In all honesty we are highly unlikely to ever have accepted a PR that >> added all these dependencies to the core in any case, so it is a >> problem that would have had to be solved at some point anyway. >> >> Stuart >> >> Stan Silvert wrote: >>> I'm starting to have doubts about this split. >>> >>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>> into build-core so that the web console can use Keycloak for >>> authentication. The problem is that there is a huge web of dependencies >>> that must be moved over from build to build-core. >>> >>> What exactly is the split trying to solve? >>> >>> Stan >>> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>> Hi all, >>>> >>>> So I am moderately confident that we will be ready to split out Wildfly >>>> core into a separate repository early next week (I'm not saying that it >>>> will definitely happen in this time frame, just that it should be >>>> possible). >>>> >>>> Once this is ready to go I think the basic process will be: >>>> >>>> - Code freeze on Master >>>> - Create the core repo, push new rewritten core history >>>> - Release core 1.0.0.Beta1 >>>> - Create PR against core WF repo that deletes everything in core, and >>>> uses the core 1.0.0.Beta1 release >>>> - End of code freeze >>>> >>>> Stuart >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Vaclav Tunka Enterprise Application Platforms JBoss by Red Hat From tomaz.cerar at gmail.com Tue Jul 1 08:32:24 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 1 Jul 2014 14:32:24 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2A8C7.5030406@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> Message-ID: On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka wrote: > My impression is Keycloak does not belong into the categories > above, but maybe I don't know all the details. > You don't have all details, but your reasoning is completely sound. Idea is to have keycloak auth mechanism as an option to have SSO for admin console. But that doesn't mean it needs all those dependencies in the core. We need to distinguish between, auth mechanism that should go to domain-http and keycloak subsystem which is completely different beast and should go to probably full distro. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140701/e2fc817e/attachment.html From ssilvert at redhat.com Tue Jul 1 08:48:15 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 08:48:15 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> Message-ID: <53B2AE0F.2020103@redhat.com> On 7/1/2014 8:32 AM, Tomaz( Cerar wrote: > > On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka > wrote: > > My impression is Keycloak does not belong into the categories > above, but maybe I don't know all the details. > > > > You don't have all details, but your reasoning is completely sound. > > Idea is to have keycloak auth mechanism as an option to have SSO for > admin console. > But that doesn't mean it needs all those dependencies in the core. > > We need to distinguish between, auth mechanism that should go to > domain-http > and keycloak subsystem which is completely different beast and should > go to probably full distro. We don't necessarily need the keycloak subsystem in order to use keycloak for authenticating domain-http. But keycloak subsystem is not the thing that pulls in all the dependencies. It's the keycloak adapter that does this. So if we want keycloak to authenticate domain-http out of the box then we have to include all this stuff with it. That wasn't a problem before the split. Almost everything it needed was already there. > > -- > tomaz > > > _______________________________________________ > 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/20140701/9b416316/attachment.html From stuart.w.douglas at gmail.com Tue Jul 1 08:49:11 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 01 Jul 2014 08:49:11 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2A1A8.6090505@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> Message-ID: <53B2AE47.4000204@gmail.com> Stan Silvert wrote: > On 6/30/2014 10:43 PM, Stuart Douglas wrote: >> It really sounds like this should not be part of core, but should be >> something extra that just integrates with the core. > That may be true, but it's not a decision that should depend on how many > modules must be added. > > The central question is, do we want Keycloak to work out of the box? > Before this issue was known, everyone answered "yes". > > Should we really determine our feature set based on how many modules it > requires? I don't think we want do that, which is why I'm having doubts > about the current approach. This has nothing to do with 'working out of the box', e.g. Servlet and EJB will 'work out of the box', as long as you pick a distribution that includes them. > >> >> In all honesty we are highly unlikely to ever have accepted a PR that >> added all these dependencies to the core in any case, so it is a >> problem that would have had to be solved at some point anyway. >> >> Stuart >> >> Stan Silvert wrote: >>> I'm starting to have doubts about this split. >>> >>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>> into build-core so that the web console can use Keycloak for >>> authentication. The problem is that there is a huge web of dependencies >>> that must be moved over from build to build-core. >>> >>> What exactly is the split trying to solve? >>> >>> Stan >>> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>> Hi all, >>>> >>>> So I am moderately confident that we will be ready to split out Wildfly >>>> core into a separate repository early next week (I'm not saying that it >>>> will definitely happen in this time frame, just that it should be >>>> possible). >>>> >>>> Once this is ready to go I think the basic process will be: >>>> >>>> - Code freeze on Master >>>> - Create the core repo, push new rewritten core history >>>> - Release core 1.0.0.Beta1 >>>> - Create PR against core WF repo that deletes everything in core, and >>>> uses the core 1.0.0.Beta1 release >>>> - End of code freeze >>>> >>>> Stuart >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From ssilvert at redhat.com Tue Jul 1 08:52:00 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 08:52:00 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2AE47.4000204@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> Message-ID: <53B2AEF0.4040406@redhat.com> On 7/1/2014 8:49 AM, Stuart Douglas wrote: > > > Stan Silvert wrote: >> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>> It really sounds like this should not be part of core, but should be >>> something extra that just integrates with the core. >> That may be true, but it's not a decision that should depend on how many >> modules must be added. >> >> The central question is, do we want Keycloak to work out of the box? >> Before this issue was known, everyone answered "yes". >> >> Should we really determine our feature set based on how many modules it >> requires? I don't think we want do that, which is why I'm having doubts >> about the current approach. > > This has nothing to do with 'working out of the box', e.g. Servlet and > EJB will 'work out of the box', as long as you pick a distribution > that includes them. I understand. Perhaps I should have said, 'working out of the box on core'. domain-http is currently in core, which is what I'm talking about here. > > > > >> >>> >>> In all honesty we are highly unlikely to ever have accepted a PR that >>> added all these dependencies to the core in any case, so it is a >>> problem that would have had to be solved at some point anyway. >>> >>> Stuart >>> >>> Stan Silvert wrote: >>>> I'm starting to have doubts about this split. >>>> >>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>> into build-core so that the web console can use Keycloak for >>>> authentication. The problem is that there is a huge web of >>>> dependencies >>>> that must be moved over from build to build-core. >>>> >>>> What exactly is the split trying to solve? >>>> >>>> Stan >>>> >>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>> Hi all, >>>>> >>>>> So I am moderately confident that we will be ready to split out >>>>> Wildfly >>>>> core into a separate repository early next week (I'm not saying >>>>> that it >>>>> will definitely happen in this time frame, just that it should be >>>>> possible). >>>>> >>>>> Once this is ready to go I think the basic process will be: >>>>> >>>>> - Code freeze on Master >>>>> - Create the core repo, push new rewritten core history >>>>> - Release core 1.0.0.Beta1 >>>>> - Create PR against core WF repo that deletes everything in core, and >>>>> uses the core 1.0.0.Beta1 release >>>>> - End of code freeze >>>>> >>>>> Stuart >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From brian.stansberry at redhat.com Tue Jul 1 08:55:42 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 01 Jul 2014 07:55:42 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B1F272.6010100@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <939FF6CA-DA9E-456A-9C28-F56428EF181A@redhat.com> <53B1F272.6010100@redhat.com> Message-ID: <53B2AFCE.2060603@redhat.com> On 6/30/14, 6:27 PM, Stan Silvert wrote: > On 6/30/2014 6:03 PM, Jason Greene wrote: >> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It?s a very real request we have had for a long time. >> >> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn?t belong in core. > I spent most of last week trying out alternatives and teasing out > dependencies. No joy so far. > > What if we moved domain-http into web-build? That would mean that the > web console would not be available in core-build, but I'm not sure it > makes sense to be there anyway. Does web console even run against > core-build? > The http interface is a core capability, even if there is no console. There are other clients. JON plus whatever custom stuff people have added over the years. The console itself is not included in the core. Mostly due to size considerations -- we want the core to be very light. What specific issues are you seeing? >> >> On Jun 30, 2014, at 4:47 PM, Stan Silvert wrote: >> >>> I'm starting to have doubts about this split. >>> >>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>> into build-core so that the web console can use Keycloak for >>> authentication. The problem is that there is a huge web of dependencies >>> that must be moved over from build to build-core. >>> >>> What exactly is the split trying to solve? >>> >>> Stan >>> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>> Hi all, >>>> >>>> So I am moderately confident that we will be ready to split out Wildfly >>>> core into a separate repository early next week (I'm not saying that it >>>> will definitely happen in this time frame, just that it should be possible). >>>> >>>> Once this is ready to go I think the basic process will be: >>>> >>>> - Code freeze on Master >>>> - Create the core repo, push new rewritten core history >>>> - Release core 1.0.0.Beta1 >>>> - Create PR against core WF repo that deletes everything in core, and >>>> uses the core 1.0.0.Beta1 release >>>> - End of code freeze >>>> >>>> Stuart >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> 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 Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Tue Jul 1 08:58:46 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 1 Jul 2014 14:58:46 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2AEF0.4040406@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> Message-ID: Looking at the code of https://github.com/keycloak/keycloak/blob/master/integration/undertow/src/main/java/org/keycloak/adapters/undertow/KeycloakServletExtension.java i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http. It can stay as is for subsystem stuff. Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*) as there will be no servlet requests coming that way. In short I think just moving some code around and modifying few classes we could get rid of many dependancies. On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert wrote: > On 7/1/2014 8:49 AM, Stuart Douglas wrote: > > > > > > Stan Silvert wrote: > >> On 6/30/2014 10:43 PM, Stuart Douglas wrote: > >>> It really sounds like this should not be part of core, but should be > >>> something extra that just integrates with the core. > >> That may be true, but it's not a decision that should depend on how many > >> modules must be added. > >> > >> The central question is, do we want Keycloak to work out of the box? > >> Before this issue was known, everyone answered "yes". > >> > >> Should we really determine our feature set based on how many modules it > >> requires? I don't think we want do that, which is why I'm having doubts > >> about the current approach. > > > > This has nothing to do with 'working out of the box', e.g. Servlet and > > EJB will 'work out of the box', as long as you pick a distribution > > that includes them. > I understand. Perhaps I should have said, 'working out of the box on > core'. domain-http is currently in core, which is what I'm talking > about here. > > > > > > > > > >> > >>> > >>> In all honesty we are highly unlikely to ever have accepted a PR that > >>> added all these dependencies to the core in any case, so it is a > >>> problem that would have had to be solved at some point anyway. > >>> > >>> Stuart > >>> > >>> Stan Silvert wrote: > >>>> I'm starting to have doubts about this split. > >>>> > >>>> Right now I'm trying to integrate the Keycloak (client-side) adapter > >>>> into build-core so that the web console can use Keycloak for > >>>> authentication. The problem is that there is a huge web of > >>>> dependencies > >>>> that must be moved over from build to build-core. > >>>> > >>>> What exactly is the split trying to solve? > >>>> > >>>> Stan > >>>> > >>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: > >>>>> Hi all, > >>>>> > >>>>> So I am moderately confident that we will be ready to split out > >>>>> Wildfly > >>>>> core into a separate repository early next week (I'm not saying > >>>>> that it > >>>>> will definitely happen in this time frame, just that it should be > >>>>> possible). > >>>>> > >>>>> Once this is ready to go I think the basic process will be: > >>>>> > >>>>> - Code freeze on Master > >>>>> - Create the core repo, push new rewritten core history > >>>>> - Release core 1.0.0.Beta1 > >>>>> - Create PR against core WF repo that deletes everything in core, and > >>>>> uses the core 1.0.0.Beta1 release > >>>>> - End of code freeze > >>>>> > >>>>> Stuart > >>>>> _______________________________________________ > >>>>> wildfly-dev mailing list > >>>>> wildfly-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140701/29506579/attachment.html From brian.stansberry at redhat.com Tue Jul 1 09:00:28 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 01 Jul 2014 08:00:28 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2AFCE.2060603@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <939FF6CA-DA9E-456A-9C28-F56428EF181A@redhat.com> <53B1F272.6010100@redhat.com> <53B2AFCE.2060603@redhat.com> Message-ID: <53B2B0EC.3040407@redhat.com> On 7/1/14, 7:55 AM, Brian Stansberry wrote: > On 6/30/14, 6:27 PM, Stan Silvert wrote: >> On 6/30/2014 6:03 PM, Jason Greene wrote: >>> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It?s a very real request we have had for a long time. >>> >>> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn?t belong in core. >> I spent most of last week trying out alternatives and teasing out >> dependencies. No joy so far. >> >> What if we moved domain-http into web-build? That would mean that the >> web console would not be available in core-build, but I'm not sure it >> makes sense to be there anyway. Does web console even run against >> core-build? >> > > The http interface is a core capability, even if there is no console. > There are other clients. JON plus whatever custom stuff people have > added over the years. > > The console itself is not included in the core. Mostly due to size > considerations -- we want the core to be very light. > > What specific issues are you seeing? Never mind this last question -- I replied before getting all my mail and didn't see the rest of the thread. > >>> >>> On Jun 30, 2014, at 4:47 PM, Stan Silvert wrote: >>> >>>> I'm starting to have doubts about this split. >>>> >>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>> into build-core so that the web console can use Keycloak for >>>> authentication. The problem is that there is a huge web of dependencies >>>> that must be moved over from build to build-core. >>>> >>>> What exactly is the split trying to solve? >>>> >>>> Stan >>>> >>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>> Hi all, >>>>> >>>>> So I am moderately confident that we will be ready to split out Wildfly >>>>> core into a separate repository early next week (I'm not saying that it >>>>> will definitely happen in this time frame, just that it should be possible). >>>>> >>>>> Once this is ready to go I think the basic process will be: >>>>> >>>>> - Code freeze on Master >>>>> - Create the core repo, push new rewritten core history >>>>> - Release core 1.0.0.Beta1 >>>>> - Create PR against core WF repo that deletes everything in core, and >>>>> uses the core 1.0.0.Beta1 release >>>>> - End of code freeze >>>>> >>>>> Stuart >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> 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 Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Tue Jul 1 09:01:26 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 01 Jul 2014 09:01:26 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2AEF0.4040406@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> Message-ID: <53B2B126.4040206@gmail.com> > I understand. Perhaps I should have said, 'working out of the box on > core'. domain-http is currently in core, which is what I'm talking about > here. I don't follow your logic here. You are basically saying that unless we can have keycloak in core then there is no point having a core? Core can't actually do anything out of the box, it is a runtime that other distributions will build on. Stuart >> >> >> >> >>> >>>> >>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>> added all these dependencies to the core in any case, so it is a >>>> problem that would have had to be solved at some point anyway. >>>> >>>> Stuart >>>> >>>> Stan Silvert wrote: >>>>> I'm starting to have doubts about this split. >>>>> >>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>> into build-core so that the web console can use Keycloak for >>>>> authentication. The problem is that there is a huge web of >>>>> dependencies >>>>> that must be moved over from build to build-core. >>>>> >>>>> What exactly is the split trying to solve? >>>>> >>>>> Stan >>>>> >>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>> Hi all, >>>>>> >>>>>> So I am moderately confident that we will be ready to split out >>>>>> Wildfly >>>>>> core into a separate repository early next week (I'm not saying >>>>>> that it >>>>>> will definitely happen in this time frame, just that it should be >>>>>> possible). >>>>>> >>>>>> Once this is ready to go I think the basic process will be: >>>>>> >>>>>> - Code freeze on Master >>>>>> - Create the core repo, push new rewritten core history >>>>>> - Release core 1.0.0.Beta1 >>>>>> - Create PR against core WF repo that deletes everything in core, and >>>>>> uses the core 1.0.0.Beta1 release >>>>>> - End of code freeze >>>>>> >>>>>> Stuart >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > From ssilvert at redhat.com Tue Jul 1 09:12:44 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 09:12:44 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> Message-ID: <53B2B3CC.5080202@redhat.com> I'm not using KeycloakServletExtension. I got rid of the dependency on undertow-servlet. On 7/1/2014 8:58 AM, Toma? Cerar wrote: > Looking at the code of > https://github.com/keycloak/keycloak/blob/master/integration/undertow/src/main/java/org/keycloak/adapters/undertow/KeycloakServletExtension.java > > i think there could be better way other than using ServletExtension to > achieve same thing for what you need in domain-http. > It can stay as is for subsystem stuff. > > Also lots of classes in that module, have nothing to do with core SSO > need in domain-http (Servlet*) > as there will be no servlet requests coming that way. > > In short I think just moving some code around and modifying few > classes we could get rid of many dependancies. > > > > On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert > wrote: > > On 7/1/2014 8:49 AM, Stuart Douglas wrote: > > > > > > Stan Silvert wrote: > >> On 6/30/2014 10:43 PM, Stuart Douglas wrote: > >>> It really sounds like this should not be part of core, but > should be > >>> something extra that just integrates with the core. > >> That may be true, but it's not a decision that should depend on > how many > >> modules must be added. > >> > >> The central question is, do we want Keycloak to work out of the > box? > >> Before this issue was known, everyone answered "yes". > >> > >> Should we really determine our feature set based on how many > modules it > >> requires? I don't think we want do that, which is why I'm > having doubts > >> about the current approach. > > > > This has nothing to do with 'working out of the box', e.g. > Servlet and > > EJB will 'work out of the box', as long as you pick a distribution > > that includes them. > I understand. Perhaps I should have said, 'working out of the box on > core'. domain-http is currently in core, which is what I'm talking > about here. > > > > > > > > > >> > >>> > >>> In all honesty we are highly unlikely to ever have accepted a > PR that > >>> added all these dependencies to the core in any case, so it is a > >>> problem that would have had to be solved at some point anyway. > >>> > >>> Stuart > >>> > >>> Stan Silvert wrote: > >>>> I'm starting to have doubts about this split. > >>>> > >>>> Right now I'm trying to integrate the Keycloak (client-side) > adapter > >>>> into build-core so that the web console can use Keycloak for > >>>> authentication. The problem is that there is a huge web of > >>>> dependencies > >>>> that must be moved over from build to build-core. > >>>> > >>>> What exactly is the split trying to solve? > >>>> > >>>> Stan > >>>> > >>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: > >>>>> Hi all, > >>>>> > >>>>> So I am moderately confident that we will be ready to split out > >>>>> Wildfly > >>>>> core into a separate repository early next week (I'm not saying > >>>>> that it > >>>>> will definitely happen in this time frame, just that it > should be > >>>>> possible). > >>>>> > >>>>> Once this is ready to go I think the basic process will be: > >>>>> > >>>>> - Code freeze on Master > >>>>> - Create the core repo, push new rewritten core history > >>>>> - Release core 1.0.0.Beta1 > >>>>> - Create PR against core WF repo that deletes everything in > core, and > >>>>> uses the core 1.0.0.Beta1 release > >>>>> - End of code freeze > >>>>> > >>>>> Stuart > >>>>> _______________________________________________ > >>>>> wildfly-dev mailing list > >>>>> wildfly-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140701/ffffd5a0/attachment.html From ssilvert at redhat.com Tue Jul 1 09:26:40 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 09:26:40 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B126.4040206@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> Message-ID: <53B2B710.9030602@redhat.com> On 7/1/2014 9:01 AM, Stuart Douglas wrote: > >> I understand. Perhaps I should have said, 'working out of the box on >> core'. domain-http is currently in core, which is what I'm talking about >> here. > > I don't follow your logic here. You are basically saying that unless > we can have keycloak in core then there is no point having a core? Of course that's not what I'm saying. I'm saying that domain-http is currently in core. Web console and other clients use domain-http. If we want keycloak to authenticate domain-http then keycloak must also be in core. There are many possible solutions: * Don't do the split * Do the split, but allow core to see the full set of modules. * Move domain-http out of core. * Allow the extra dependencies. * Redesign domain-http * others? > > Core can't actually do anything out of the box, it is a runtime that > other distributions will build on. > > Stuart > > >>> >>> >>> >>> >>>> >>>>> >>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>> added all these dependencies to the core in any case, so it is a >>>>> problem that would have had to be solved at some point anyway. >>>>> >>>>> Stuart >>>>> >>>>> Stan Silvert wrote: >>>>>> I'm starting to have doubts about this split. >>>>>> >>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>> into build-core so that the web console can use Keycloak for >>>>>> authentication. The problem is that there is a huge web of >>>>>> dependencies >>>>>> that must be moved over from build to build-core. >>>>>> >>>>>> What exactly is the split trying to solve? >>>>>> >>>>>> Stan >>>>>> >>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> So I am moderately confident that we will be ready to split out >>>>>>> Wildfly >>>>>>> core into a separate repository early next week (I'm not saying >>>>>>> that it >>>>>>> will definitely happen in this time frame, just that it should be >>>>>>> possible). >>>>>>> >>>>>>> Once this is ready to go I think the basic process will be: >>>>>>> >>>>>>> - Code freeze on Master >>>>>>> - Create the core repo, push new rewritten core history >>>>>>> - Release core 1.0.0.Beta1 >>>>>>> - Create PR against core WF repo that deletes everything in >>>>>>> core, and >>>>>>> uses the core 1.0.0.Beta1 release >>>>>>> - End of code freeze >>>>>>> >>>>>>> Stuart >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> From bburke at redhat.com Tue Jul 1 09:33:01 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 01 Jul 2014 09:33:01 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2AE0F.2020103@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> Message-ID: <53B2B88D.70609@redhat.com> On 7/1/2014 8:48 AM, Stan Silvert wrote: > On 7/1/2014 8:32 AM, Toma? Cerar wrote: >> >> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka > > wrote: >> >> My impression is Keycloak does not belong into the categories >> above, but maybe I don't know all the details. >> >> >> >> You don't have all details, but your reasoning is completely sound. >> >> Idea is to have keycloak auth mechanism as an option to have SSO for >> admin console. >> But that doesn't mean it needs all those dependencies in the core. >> >> We need to distinguish between, auth mechanism that should go to >> domain-http >> and keycloak subsystem which is completely different beast and should >> go to probably full distro. > We don't necessarily need the keycloak subsystem in order to use > keycloak for authenticating domain-http. But keycloak subsystem is not > the thing that pulls in all the dependencies. It's the keycloak adapter > that does this. > > So if we want keycloak to authenticate domain-http out of the box then > we have to include all this stuff with it. That wasn't a problem before > the split. Almost everything it needed was already there. > "All this stuff" is really just Apache Http Client, Jackson and Bouncycastle. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jul 1 09:36:44 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 09:36:44 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B88D.70609@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> Message-ID: <53B2B96C.7050306@redhat.com> On 7/1/2014 9:33 AM, Bill Burke wrote: > > On 7/1/2014 8:48 AM, Stan Silvert wrote: >> On 7/1/2014 8:32 AM, Toma? Cerar wrote: >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka >> > wrote: >>> >>> My impression is Keycloak does not belong into the categories >>> above, but maybe I don't know all the details. >>> >>> >>> >>> You don't have all details, but your reasoning is completely sound. >>> >>> Idea is to have keycloak auth mechanism as an option to have SSO for >>> admin console. >>> But that doesn't mean it needs all those dependencies in the core. >>> >>> We need to distinguish between, auth mechanism that should go to >>> domain-http >>> and keycloak subsystem which is completely different beast and should >>> go to probably full distro. >> We don't necessarily need the keycloak subsystem in order to use >> keycloak for authenticating domain-http. But keycloak subsystem is not >> the thing that pulls in all the dependencies. It's the keycloak adapter >> that does this. >> >> So if we want keycloak to authenticate domain-http out of the box then >> we have to include all this stuff with it. That wasn't a problem before >> the split. Almost everything it needed was already there. >> > "All this stuff" is really just Apache Http Client, Jackson and > Bouncycastle. > > Resteasy got pulled in as well. Maybe that was an error on my part? From tomaz.cerar at gmail.com Tue Jul 1 09:39:28 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 1 Jul 2014 15:39:28 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B96C.7050306@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> Message-ID: "Stuff", that Bill said, sounds ok to be part of core. At least in its most bare versions (as all 3 libs can have many modules) RestEasy should never get pulled in, as it requires servlets again... On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert wrote: > On 7/1/2014 9:33 AM, Bill Burke wrote: > > > > On 7/1/2014 8:48 AM, Stan Silvert wrote: > >> On 7/1/2014 8:32 AM, Toma? Cerar wrote: > >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka >>> > wrote: > >>> > >>> My impression is Keycloak does not belong into the categories > >>> above, but maybe I don't know all the details. > >>> > >>> > >>> > >>> You don't have all details, but your reasoning is completely sound. > >>> > >>> Idea is to have keycloak auth mechanism as an option to have SSO for > >>> admin console. > >>> But that doesn't mean it needs all those dependencies in the core. > >>> > >>> We need to distinguish between, auth mechanism that should go to > >>> domain-http > >>> and keycloak subsystem which is completely different beast and should > >>> go to probably full distro. > >> We don't necessarily need the keycloak subsystem in order to use > >> keycloak for authenticating domain-http. But keycloak subsystem is not > >> the thing that pulls in all the dependencies. It's the keycloak adapter > >> that does this. > >> > >> So if we want keycloak to authenticate domain-http out of the box then > >> we have to include all this stuff with it. That wasn't a problem before > >> the split. Almost everything it needed was already there. > >> > > "All this stuff" is really just Apache Http Client, Jackson and > > Bouncycastle. > > > > > Resteasy got pulled in as well. Maybe that was an error on my part? > _______________________________________________ > 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/20140701/bc400568/attachment-0001.html From stuart.w.douglas at gmail.com Tue Jul 1 09:42:23 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 01 Jul 2014 09:42:23 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B710.9030602@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> Message-ID: <53B2BABF.7050405@gmail.com> Stan Silvert wrote: > On 7/1/2014 9:01 AM, Stuart Douglas wrote: >> >>> I understand. Perhaps I should have said, 'working out of the box on >>> core'. domain-http is currently in core, which is what I'm talking about >>> here. >> >> I don't follow your logic here. You are basically saying that unless >> we can have keycloak in core then there is no point having a core? > Of course that's not what I'm saying. I'm saying that domain-http is > currently in core. Web console and other clients use domain-http. If we > want keycloak to authenticate domain-http then keycloak must also be in > core. > I don't follow your logic. If we want web console and other clients to use keycloak then keycloak must be present, but I really can't see why you think it *must* be in core. IMHO the way this should work is that we identify the extension points you need to integrate keycloak, looking at your kcauth branch this looks fairly simple, basically just a way to add some handlers and Authentication mechanisms. You then have the keycloak module use these extension points to integrate with core. IMHO this will give a much cleaner result and keeps all the keycloak related stuff in the keycloak module. > There are many possible solutions: > * Don't do the split The split has been on the table for over 6 months, it is going ahead. > * Do the split, but allow core to see the full set of modules. This makes no sense. If it has all the modules it is not core. > * Move domain-http out of core. > * Allow the extra dependencies. > * Redesign domain-http If by redesign you mean add some extension points to allow keycloak to hook into it without requiring keycloak code in domain-http then this is exactly what we should do. If you want a hand with this I should be able to help you out. Stuart > * others? > >> >> Core can't actually do anything out of the box, it is a runtime that >> other distributions will build on. >> >> Stuart >> >> >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>>> added all these dependencies to the core in any case, so it is a >>>>>> problem that would have had to be solved at some point anyway. >>>>>> >>>>>> Stuart >>>>>> >>>>>> Stan Silvert wrote: >>>>>>> I'm starting to have doubts about this split. >>>>>>> >>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>>> into build-core so that the web console can use Keycloak for >>>>>>> authentication. The problem is that there is a huge web of >>>>>>> dependencies >>>>>>> that must be moved over from build to build-core. >>>>>>> >>>>>>> What exactly is the split trying to solve? >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> So I am moderately confident that we will be ready to split out >>>>>>>> Wildfly >>>>>>>> core into a separate repository early next week (I'm not saying >>>>>>>> that it >>>>>>>> will definitely happen in this time frame, just that it should be >>>>>>>> possible). >>>>>>>> >>>>>>>> Once this is ready to go I think the basic process will be: >>>>>>>> >>>>>>>> - Code freeze on Master >>>>>>>> - Create the core repo, push new rewritten core history >>>>>>>> - Release core 1.0.0.Beta1 >>>>>>>> - Create PR against core WF repo that deletes everything in >>>>>>>> core, and >>>>>>>> uses the core 1.0.0.Beta1 release >>>>>>>> - End of code freeze >>>>>>>> >>>>>>>> Stuart >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> > From bburke at redhat.com Tue Jul 1 09:46:28 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 01 Jul 2014 09:46:28 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B96C.7050306@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> Message-ID: <53B2BBB4.8070303@redhat.com> On 7/1/2014 9:36 AM, Stan Silvert wrote: >> "All this stuff" is really just Apache Http Client, Jackson and >> Bouncycastle. >> >> > Resteasy got pulled in as well. Maybe that was an error on my part? Resteasy is not required for the adapter. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jul 1 09:50:48 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 01 Jul 2014 09:50:48 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> Message-ID: <53B2BCB8.8030805@redhat.com> Oh and net.iharder, which is just 1 class. A Base64 encoder/decoder. FYI, Resteasy core doesn't require servlets (we have netty3, netty4, and jdk http adapters), but the jaxrs deployer does. On 7/1/2014 9:39 AM, Toma? Cerar wrote: > "Stuff", that Bill said, sounds ok to be part of core. > At least in its most bare versions (as all 3 libs can have many modules) > > > RestEasy should never get pulled in, as it requires servlets again... > > > On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert > wrote: > > On 7/1/2014 9:33 AM, Bill Burke wrote: > > > > On 7/1/2014 8:48 AM, Stan Silvert wrote: > >> On 7/1/2014 8:32 AM, Toma? Cerar wrote: > >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka > >>> >> wrote: > >>> > >>> My impression is Keycloak does not belong into the categories > >>> above, but maybe I don't know all the details. > >>> > >>> > >>> > >>> You don't have all details, but your reasoning is completely sound. > >>> > >>> Idea is to have keycloak auth mechanism as an option to have > SSO for > >>> admin console. > >>> But that doesn't mean it needs all those dependencies in the core. > >>> > >>> We need to distinguish between, auth mechanism that should go to > >>> domain-http > >>> and keycloak subsystem which is completely different beast and > should > >>> go to probably full distro. > >> We don't necessarily need the keycloak subsystem in order to use > >> keycloak for authenticating domain-http. But keycloak subsystem > is not > >> the thing that pulls in all the dependencies. It's the keycloak > adapter > >> that does this. > >> > >> So if we want keycloak to authenticate domain-http out of the > box then > >> we have to include all this stuff with it. That wasn't a > problem before > >> the split. Almost everything it needed was already there. > >> > > "All this stuff" is really just Apache Http Client, Jackson and > > Bouncycastle. > > > > > Resteasy got pulled in as well. Maybe that was an error on my part? > _______________________________________________ > 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jul 1 09:51:38 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 09:51:38 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BBB4.8070303@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> Message-ID: <53B2BCEA.40002@redhat.com> On 7/1/2014 9:46 AM, Bill Burke wrote: > > On 7/1/2014 9:36 AM, Stan Silvert wrote: >>> "All this stuff" is really just Apache Http Client, Jackson and >>> Bouncycastle. >>> >>> >> Resteasy got pulled in as well. Maybe that was an error on my part? > Resteasy is not required for the adapter. > > Then we've got a problem in a module.xml somwhere. jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs From jason.greene at redhat.com Tue Jul 1 09:54:26 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 1 Jul 2014 08:54:26 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> Message-ID: <87ECCFBF-2A13-4897-8044-08F9BC00E6C5@redhat.com> The only thing on the list that can be done with the libraries already provided in Core (and the JDK itself) is bouncy castle, which might very well get added eventually. If you go back and read the proposals though, the eventual plan is to make WildFly extensions remotely downloadable. So if you want KeyCloak integration you will be able to run a prov tool to download and install it. The plan is also to be able to create your own dist from an XML file assembled by that tool (or by editing). So in a nutshell it will be very easy for thirdparty distributions to pull in a keycloak-adapter extension, should that be the direction. No matter we can definitely include this in the primary WildFly distro. Anyway the choose is basically live with a very limited set of deps, or target one of the higher layers. Note that everyone can make an argument that core should include their favorite small set of libs. The aggregate of everyone doing that is a full distribution. On Jul 1, 2014, at 8:39 AM, Toma? Cerar wrote: > "Stuff", that Bill said, sounds ok to be part of core. > At least in its most bare versions (as all 3 libs can have many modules) > > > RestEasy should never get pulled in, as it requires servlets again... > > > On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert wrote: > On 7/1/2014 9:33 AM, Bill Burke wrote: > > > > On 7/1/2014 8:48 AM, Stan Silvert wrote: > >> On 7/1/2014 8:32 AM, Toma? Cerar wrote: > >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka >>> > wrote: > >>> > >>> My impression is Keycloak does not belong into the categories > >>> above, but maybe I don't know all the details. > >>> > >>> > >>> > >>> You don't have all details, but your reasoning is completely sound. > >>> > >>> Idea is to have keycloak auth mechanism as an option to have SSO for > >>> admin console. > >>> But that doesn't mean it needs all those dependencies in the core. > >>> > >>> We need to distinguish between, auth mechanism that should go to > >>> domain-http > >>> and keycloak subsystem which is completely different beast and should > >>> go to probably full distro. > >> We don't necessarily need the keycloak subsystem in order to use > >> keycloak for authenticating domain-http. But keycloak subsystem is not > >> the thing that pulls in all the dependencies. It's the keycloak adapter > >> that does this. > >> > >> So if we want keycloak to authenticate domain-http out of the box then > >> we have to include all this stuff with it. That wasn't a problem before > >> the split. Almost everything it needed was already there. > >> > > "All this stuff" is really just Apache Http Client, Jackson and > > Bouncycastle. > > > > > Resteasy got pulled in as well. Maybe that was an error on my part? > _______________________________________________ > 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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From bburke at redhat.com Tue Jul 1 09:55:19 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 01 Jul 2014 09:55:19 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BCEA.40002@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> <53B2BCEA.40002@redhat.com> Message-ID: <53B2BDC7.9040402@redhat.com> On 7/1/2014 9:51 AM, Stan Silvert wrote: > On 7/1/2014 9:46 AM, Bill Burke wrote: >> >> On 7/1/2014 9:36 AM, Stan Silvert wrote: >>>> "All this stuff" is really just Apache Http Client, Jackson and >>>> Bouncycastle. >>>> >>>> >>> Resteasy got pulled in as well. Maybe that was an error on my part? >> Resteasy is not required for the adapter. >> >> > Then we've got a problem in a module.xml somwhere. > > jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs Adapter doesn't depend on jackson-jaxrs either. I think you did some work to refactor the undertow adapter right? So it didn't need the servlet dependency? Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jul 1 10:03:10 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 01 Jul 2014 10:03:10 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BDC7.9040402@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> <53B2BCEA.40002@redhat.com> <53B2BDC7.9040402@redhat.com> Message-ID: <53B2BF9E.7060202@redhat.com> On 7/1/2014 9:55 AM, Bill Burke wrote: > > On 7/1/2014 9:51 AM, Stan Silvert wrote: >> On 7/1/2014 9:46 AM, Bill Burke wrote: >>> On 7/1/2014 9:36 AM, Stan Silvert wrote: >>>>> "All this stuff" is really just Apache Http Client, Jackson and >>>>> Bouncycastle. >>>>> >>>>> >>>> Resteasy got pulled in as well. Maybe that was an error on my part? >>> Resteasy is not required for the adapter. >>> >>> >> Then we've got a problem in a module.xml somwhere. >> >> jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs > Adapter doesn't depend on jackson-jaxrs either. > > name="org.keycloak.keycloak-undertow-adapter"> > > > > > > > > > > > > > > > > > > > > > > I think you did some work to refactor the undertow adapter right? So it > didn't need the servlet dependency? Right. But it looks like I moved too many of the jackson dependencies from build to core-build. I'll clean this up and come up with a proposal based on the minimum that needs to be moved. > > > Bill > From jason.greene at redhat.com Tue Jul 1 10:26:53 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 1 Jul 2014 09:26:53 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BF9E.7060202@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> <53B2BCEA.40002@redhat.com> <53B2BDC7.9040402@redhat.com> <53B2BF9E.7060202@redhat.com> Message-ID: On Jul 1, 2014, at 9:03 AM, Stan Silvert wrote: > On 7/1/2014 9:55 AM, Bill Burke wrote: >> >> On 7/1/2014 9:51 AM, Stan Silvert wrote: >>> On 7/1/2014 9:46 AM, Bill Burke wrote: >>>> On 7/1/2014 9:36 AM, Stan Silvert wrote: >>>>>> "All this stuff" is really just Apache Http Client, Jackson and >>>>>> Bouncycastle. >>>>>> >>>>>> >>>>> Resteasy got pulled in as well. Maybe that was an error on my part? >>>> Resteasy is not required for the adapter. >>>> >>>> >>> Then we've got a problem in a module.xml somwhere. >>> >>> jackson-jaxrs depends on javax.ws.rs.ap depends on resteasy-jaxrs >> Adapter doesn't depend on jackson-jaxrs either. >> >> > name="org.keycloak.keycloak-undertow-adapter"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I think you did some work to refactor the undertow adapter right? So it >> didn't need the servlet dependency? > Right. But it looks like I moved too many of the jackson dependencies > from build to core-build. I'll clean this up and come up with a > proposal based on the minimum that needs to be moved. Please also keep in mind the relative complexity of what this does to the dependency set it brings in. For example, I imagine you essentially have a small number of cookie cutter HTTP requests, with the most complex aspect being processing a token. Do you really need jackson object bindings for that? I realize this argument may seem counter-intuitive because its basically an argument against reuse, but thats the challenge we have in core. Here are some other options already in core that you could potentially use: - DMR - While it?s primary purpose is not JSON processing it gives you a detyped map like API that can be used for this purpose - JDK URL connections - While not the best API, it can get the job done - Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs. - FlexBase64 - This is a one class base64 encoder/decoder that is already in core, is fast, and can be used with buffers, streams, and arrays. As mentioned in another email, there is really no replacement for bouncy castle, and so is a good candidate to be added. Again, I totally get it if you don?t want to hack something together *just* for wildfly to be in wildfly core, but thats not a bad thing IMO. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From bburke at redhat.com Tue Jul 1 10:54:35 2014 From: bburke at redhat.com (Bill Burke) Date: Tue, 01 Jul 2014 10:54:35 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> <53B2BCEA.40002@redhat.com> <53B2BDC7.9040402@redhat.com> <53B2BF9E.7060202@redhat.com> Message-ID: <53B2CBAB.1000506@redhat.com> On 7/1/2014 10:26 AM, Jason Greene wrote: > > Please also keep in mind the relative complexity of what this does to the dependency set it brings in. For example, I imagine you essentially have a small number of cookie cutter HTTP requests, with the most complex aspect being processing a token. Do you really need jackson object bindings for that? I realize this argument may seem counter-intuitive because its basically an argument against reuse, but thats the challenge we have in core. > There's no need for anything (other than bouncycastle). I could of course hand code everything if need be. But Jackson, Apache HTTP Client sure make life a little easier. > Here are some other options already in core that you could potentially use: > > - DMR - While it?s primary purpose is not JSON processing it gives you a detyped map like API that can be used for this purpose > - JDK URL connections - While not the best API, it can get the job done I remember some peculiarities with JDK URL Connections in which some configuration is done globally through static methods and could be overridden by user code. (Like connection caches and content caches cookies, etc.). Maybe my memory is faulty there though. > - Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs. If it supports SSL with the ability to enable/disable a trust manager, then ya, it could be used. > - FlexBase64 - This is a one class base64 encoder/decoder that is already in core, is fast, and can be used with buffers, streams, and arrays. > > As mentioned in another email, there is really no replacement for bouncy castle, and so is a good candidate to be added. > > Again, I totally get it if you don?t want to hack something together *just* for wildfly to be in wildfly core, but thats not a bad thing IMO. > No, I don't want to hack something together when there is a high probability Keycloak is going to be excluded anyways. Our roadmap is long and deep and we need to pick our battles. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stuart.w.douglas at gmail.com Tue Jul 1 11:10:24 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 01 Jul 2014 11:10:24 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2CBAB.1000506@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BBB4.8070303@redhat.com> <53B2BCEA.40002@redhat.com> <53B2BDC7.9040402@redhat.com> <53B2BF9E.7060202@redhat.com> <53B2CBAB.1000506@redhat.com> Message-ID: <53B2CF60.5090508@gmail.com> >> - Undertow HTTP Client API - this was really just created for the proxy code, so it will be lacking compared to httpclient, but it or the former option might meet your needs. > > If it supports SSL with the ability to enable/disable a trust manager, > then ya, it could be used. > It does, however the main issue you will have is that is designed for use with Undertow proxy, so it can basically only be used from an Xnio IO thread (basically in the proxy the incoming and outgoing request shares the same IO thread, which is much faster as there is no thread safety constructs required). If you are just sending requests from inside an Undertow HttpHandler then this should be ok, otherwise it would be possible to just write a simple thread safe wrapper around it. Stuart From kabir.khan at jboss.com Tue Jul 1 12:21:07 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 1 Jul 2014 17:21:07 +0100 Subject: [wildfly-dev] Documentation to get started? In-Reply-To: References: Message-ID: <8FD41C74-7675-4B95-97D5-A01F15964F35@jboss.com> The admin console is actually a GWT application which gets compiled to client side html + javascript, and it lives at https://github.com/hal. Heiko and Harald are the leads for that. If you feel like doing something more core to WildFly, please take a look at Jira again and find something else. On 1 Jul 2014, at 11:53, Chris Kujawa wrote: > Hello. > > My name is Chris. I'm a Java developer with over 10 years of commercial experience (and more as a hobbyist) and I was recently looking for an open-source project to contribute to so I can give something back to the community--and since I frequently use jBoss I thought Wildfly just might be the thing. I've worked my way through the "Hacking on Wildfly" page and thought that WFLY-717 (Add ability to launch H2 console...) might be a good place to start. So I started poking around looking for where I might add such a link and can't seem to work out how the "App.html" page is built in the admin console. Is there documentation that I've missed that would walk me through this process? > > Additionally, I thought that the "home" section might be a good place to add such a link, since the other panels all seem to contain Wildfly specific functionality. Or...perhaps I could add a new panel (H2 or even Utilities) and add the link there...thoughts? > > > Thank you in advance...and I'm looking forward to giving back to this great tool that I've used many times in the past! > > -Chris > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From sdouglas at redhat.com Tue Jul 1 15:15:31 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 01 Jul 2014 15:15:31 -0400 Subject: [wildfly-dev] Build split stage one is complete Message-ID: <53B308D3.6080801@redhat.com> Hi all, The first stage of the build split has been commited. We now have a wildfly-core repository at https://github.com/wildfly/wildfly-core, and the main Wildfly build now builds using artifacts produced from this. There is still a *lot* of work to do: - Remove Arquillian (there should be nothing stopping this now) - Split up the current build tool into build/provisioning tools, including creating a WF feature pack format - Further split up, the first of which will be a feature pack that corresponds to the current web-build module (although IMHO we should wait a little bit to see if there are any issues with the current split before pressing ahead with this) - General cleanup of dependencies that are no longer needed Stuart From stuart.w.douglas at gmail.com Tue Jul 1 15:36:11 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 01 Jul 2014 15:36:11 -0400 Subject: [wildfly-dev] Build split stage one is complete In-Reply-To: <53B308D3.6080801@redhat.com> References: <53B308D3.6080801@redhat.com> Message-ID: <53B30DAB.5010701@gmail.com> > - Remove Arquillian (there should be nothing stopping this now) Oops, this should have said 'Remove Arquillian from the Wildfly build', i.e. split it out into its own repository. Stuart From sdouglas at redhat.com Wed Jul 2 12:20:52 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 02 Jul 2014 12:20:52 -0400 Subject: [wildfly-dev] Build split stage one is complete In-Reply-To: <53B30DAB.5010701@gmail.com> References: <53B308D3.6080801@redhat.com> <53B30DAB.5010701@gmail.com> Message-ID: <53B43164.3060702@redhat.com> The WF Arquillian adaptor has been removed from the code base, and now lives at: https://github.com/wildfly/wildfly-arquillian Stuart Stuart Douglas wrote: > >> - Remove Arquillian (there should be nothing stopping this now) > > Oops, this should have said 'Remove Arquillian from the Wildfly build', > i.e. split it out into its own repository. > > Stuart From ssilvert at redhat.com Wed Jul 2 13:08:24 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 02 Jul 2014 13:08:24 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BABF.7050405@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> <53B2BABF.7050405@gmail.com> Message-ID: <53B43C88.4030006@redhat.com> On 7/1/2014 9:42 AM, Stuart Douglas wrote: > > There are many possible solutions: >> * Redesign domain-http > > If by redesign you mean add some extension points to allow keycloak to > hook into it without requiring keycloak code in domain-http then this > is exactly what we should do. > > If you want a hand with this I should be able to help you out. > > Stuart Yes, that's pretty much what I was thinking. Thanks for the offer to help. If there are no objections, I'll pursue the "redesign domain-http" solution. This means: * By default, Keycloak is not available in core. But it could possibly be added. * Keycloak will be available in web-build and full build. * Approximately 20 modules will be moved from full build to web-build. * Delivery of Keycloak integration will be delayed. I don't know by how much yet. Sound OK? From stuart.w.douglas at gmail.com Wed Jul 2 13:23:46 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 02 Jul 2014 13:23:46 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B43C88.4030006@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> <53B2BABF.7050405@gmail.com> <53B43C88.4030006@redhat.com> Message-ID: <53B44022.8090603@gmail.com> >> >> Stuart > Yes, that's pretty much what I was thinking. Thanks for the offer to help. > > If there are no objections, I'll pursue the "redesign domain-http" > solution. > > This means: > * By default, Keycloak is not available in core. But it could possibly > be added. > * Keycloak will be available in web-build and full build. > * Approximately 20 modules will be moved from full build to web-build. Do you know which modules? Web build is supposed to be a lightweight build that basically just provides a web server, that can be used as a Tomcat equivalent or as the base for a product that only requires a web server. Stuart > * Delivery of Keycloak integration will be delayed. I don't know by how > much yet. > > Sound OK? From ssilvert at redhat.com Wed Jul 2 14:45:10 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 02 Jul 2014 14:45:10 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B44022.8090603@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> <53B2BABF.7050405@gmail.com> <53B43C88.4030006@redhat.com> <53B44022.8090603@gmail.com> Message-ID: <53B45336.7020205@redhat.com> On 7/2/2014 1:23 PM, Stuart Douglas wrote: > >>> >>> Stuart >> Yes, that's pretty much what I was thinking. Thanks for the offer to >> help. >> >> If there are no objections, I'll pursue the "redesign domain-http" >> solution. >> >> This means: >> * By default, Keycloak is not available in core. But it could possibly >> be added. >> * Keycloak will be available in web-build and full build. >> * Approximately 20 modules will be moved from full build to web-build. > > Do you know which modules? Web build is supposed to be a lightweight > build that basically just provides a web server, that can be used as a > Tomcat equivalent or as the base for a product that only requires a > web server. > > Stuart It's six (very small) keycloak modules, plus the following: ch/qos/cal10n/main/module.xml net/iharder/base64/main/module.xml org/apache/commons/codec/main/module.xml org/apache/commons/logging/main/module.xml org/apache/httpcomponents/main/module.xml org/apache/james/mime4j/main/module.xml org/bouncycastle/main/module.xml org/codehaus/jackson/jackson-core-asl/main/module.xml org/codehaus/jackson/jackson-mapper-asl/main/module.xml org/codehaus/jackson/jackson-xc/main/module.xml org/slf4j/ext/main/module.xml org/slf4j/jcl-over-slf4j/main/module.xml However, this assumes I can remove these two transitive dependencies from jackson: module.xml for jackson-mapper-asl declares a dependency on org.joda.time module.xml for jackson-xc declares a dependency on javax.xml.bind.api I can't find evidence that these dependencies are actually needed. > >> * Delivery of Keycloak integration will be delayed. I don't know by how >> much yet. >> >> Sound OK? From darran.lofthouse at jboss.com Thu Jul 3 05:19:23 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:19:23 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2A1A8.6090505@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> Message-ID: <53B5201B.9010209@jboss.com> > The central question is, do we want Keycloak to work out of the box? > Before this issue was known, everyone answered "yes". I think here we had reached the point we were answering the question "do we want it enableable out of the box?" and the answer to that was "yes" What has not been defined since the split started is what "out of the box" actually means now, are we talking out of the box for the core or out of the box for a complete assembled server? On 01/07/14 12:55, Stan Silvert wrote: > On 6/30/2014 10:43 PM, Stuart Douglas wrote: >> It really sounds like this should not be part of core, but should be >> something extra that just integrates with the core. > That may be true, but it's not a decision that should depend on how many > modules must be added. > > The central question is, do we want Keycloak to work out of the box? > Before this issue was known, everyone answered "yes". > > Should we really determine our feature set based on how many modules it > requires? I don't think we want do that, which is why I'm having > doubts about the current approach. > >> >> In all honesty we are highly unlikely to ever have accepted a PR that >> added all these dependencies to the core in any case, so it is a >> problem that would have had to be solved at some point anyway. >> >> Stuart >> >> Stan Silvert wrote: >>> I'm starting to have doubts about this split. >>> >>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>> into build-core so that the web console can use Keycloak for >>> authentication. The problem is that there is a huge web of dependencies >>> that must be moved over from build to build-core. >>> >>> What exactly is the split trying to solve? >>> >>> Stan >>> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>> Hi all, >>>> >>>> So I am moderately confident that we will be ready to split out Wildfly >>>> core into a separate repository early next week (I'm not saying that it >>>> will definitely happen in this time frame, just that it should be >>>> possible). >>>> >>>> Once this is ready to go I think the basic process will be: >>>> >>>> - Code freeze on Master >>>> - Create the core repo, push new rewritten core history >>>> - Release core 1.0.0.Beta1 >>>> - Create PR against core WF repo that deletes everything in core, and >>>> uses the core 1.0.0.Beta1 release >>>> - End of code freeze >>>> >>>> Stuart >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Jul 3 05:28:04 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:28:04 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> Message-ID: <53B52224.10705@jboss.com> On 01/07/14 13:32, Toma? Cerar wrote: > > On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka > wrote: > > My impression is Keycloak does not belong into the categories > above, but maybe I don't know all the details. > > > > You don't have all details, but your reasoning is completely sound. > > Idea is to have keycloak auth mechanism as an option to have SSO for > admin console. > But that doesn't mean it needs all those dependencies in the core. > > We need to distinguish between, auth mechanism that should go to domain-http > and keycloak subsystem which is completely different beast and should go > to probably full distro. +1 Just to clarify one point, the current security infrastructure within the server be that management or ee is being replaced with Elytron and anything that is integrated such as PicketLink and KeyCloak will be integrated on top of that so what we are learning at the moment is more proof of concept rather than final solution when it comes to the KeyCloak integration. The approach that we are moving to for Elytron is that it will entirely be contained within a subsystem. So for our distributions we are most likely going to want security out of the box so would include the Elytron subsystem - however as advisable as it is I don't see it's inclusion by default as a base requirement on a core of the sever. > -- > tomaz > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Thu Jul 3 05:28:56 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 3 Jul 2014 11:28:56 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B5201B.9010209@jboss.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> Message-ID: I think that for start we can make it by default enablable in full distro. Once this is done, and extra work is done on trimming down dependencies to go as near JDK as possible it could be moved to core distro. Rome was not build in a day, why would KeyCloak integration / implementation be done in just one step. Isn't it better that we start somewhere to get it out to the people to test it as soon as possible and when it is ready we decide where it is best resting place and how to get there. On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > > > The central question is, do we want Keycloak to work out of the box? > > Before this issue was known, everyone answered "yes". > > I think here we had reached the point we were answering the question "do > we want it enableable out of the box?" and the answer to that was "yes" > > What has not been defined since the split started is what "out of the > box" actually means now, are we talking out of the box for the core or > out of the box for a complete assembled server? > > On 01/07/14 12:55, Stan Silvert wrote: > > On 6/30/2014 10:43 PM, Stuart Douglas wrote: > >> It really sounds like this should not be part of core, but should be > >> something extra that just integrates with the core. > > That may be true, but it's not a decision that should depend on how many > > modules must be added. > > > > The central question is, do we want Keycloak to work out of the box? > > Before this issue was known, everyone answered "yes". > > > > Should we really determine our feature set based on how many modules it > > requires? I don't think we want do that, which is why I'm having > > doubts about the current approach. > > > >> > >> In all honesty we are highly unlikely to ever have accepted a PR that > >> added all these dependencies to the core in any case, so it is a > >> problem that would have had to be solved at some point anyway. > >> > >> Stuart > >> > >> Stan Silvert wrote: > >>> I'm starting to have doubts about this split. > >>> > >>> Right now I'm trying to integrate the Keycloak (client-side) adapter > >>> into build-core so that the web console can use Keycloak for > >>> authentication. The problem is that there is a huge web of > dependencies > >>> that must be moved over from build to build-core. > >>> > >>> What exactly is the split trying to solve? > >>> > >>> Stan > >>> > >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: > >>>> Hi all, > >>>> > >>>> So I am moderately confident that we will be ready to split out > Wildfly > >>>> core into a separate repository early next week (I'm not saying that > it > >>>> will definitely happen in this time frame, just that it should be > >>>> possible). > >>>> > >>>> Once this is ready to go I think the basic process will be: > >>>> > >>>> - Code freeze on Master > >>>> - Create the core repo, push new rewritten core history > >>>> - Release core 1.0.0.Beta1 > >>>> - Create PR against core WF repo that deletes everything in core, and > >>>> uses the core 1.0.0.Beta1 release > >>>> - End of code freeze > >>>> > >>>> Stuart > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140703/6caf5ffe/attachment.html From darran.lofthouse at jboss.com Thu Jul 3 05:29:27 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:29:27 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BCB8.8030805@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2A8C7.5030406@redhat.com> <53B2AE0F.2020103@redhat.com> <53B2B88D.70609@redhat.com> <53B2B96C.7050306@redhat.com> <53B2BCB8.8030805@redhat.com> Message-ID: <53B52277.1090608@jboss.com> On 01/07/14 14:50, Bill Burke wrote: > Oh and net.iharder, which is just 1 class. A Base64 encoder/decoder. For that one we must already have a few Base64 encoder/decoder implementations available in the core ;-) > FYI, Resteasy core doesn't require servlets (we have netty3, netty4, and > jdk http adapters), but the jaxrs deployer does. > > On 7/1/2014 9:39 AM, Toma? Cerar wrote: >> "Stuff", that Bill said, sounds ok to be part of core. >> At least in its most bare versions (as all 3 libs can have many modules) >> >> >> RestEasy should never get pulled in, as it requires servlets again... >> >> >> On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert > > wrote: >> >> On 7/1/2014 9:33 AM, Bill Burke wrote: >> > >> > On 7/1/2014 8:48 AM, Stan Silvert wrote: >> >> On 7/1/2014 8:32 AM, Toma? Cerar wrote: >> >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka > >> >>> >> wrote: >> >>> >> >>> My impression is Keycloak does not belong into the categories >> >>> above, but maybe I don't know all the details. >> >>> >> >>> >> >>> >> >>> You don't have all details, but your reasoning is completely sound. >> >>> >> >>> Idea is to have keycloak auth mechanism as an option to have >> SSO for >> >>> admin console. >> >>> But that doesn't mean it needs all those dependencies in the core. >> >>> >> >>> We need to distinguish between, auth mechanism that should go to >> >>> domain-http >> >>> and keycloak subsystem which is completely different beast and >> should >> >>> go to probably full distro. >> >> We don't necessarily need the keycloak subsystem in order to use >> >> keycloak for authenticating domain-http. But keycloak subsystem >> is not >> >> the thing that pulls in all the dependencies. It's the keycloak >> adapter >> >> that does this. >> >> >> >> So if we want keycloak to authenticate domain-http out of the >> box then >> >> we have to include all this stuff with it. That wasn't a >> problem before >> >> the split. Almost everything it needed was already there. >> >> >> > "All this stuff" is really just Apache Http Client, Jackson and >> > Bouncycastle. >> > >> > >> Resteasy got pulled in as well. Maybe that was an error on my part? >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > From darran.lofthouse at jboss.com Thu Jul 3 05:38:50 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:38:50 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2B710.9030602@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> Message-ID: <53B524AA.4060501@jboss.com> On 01/07/14 14:26, Stan Silvert wrote: > On 7/1/2014 9:01 AM, Stuart Douglas wrote: >> >>> I understand. Perhaps I should have said, 'working out of the box on >>> core'. domain-http is currently in core, which is what I'm talking about >>> here. >> >> I don't follow your logic here. You are basically saying that unless >> we can have keycloak in core then there is no point having a core? > Of course that's not what I'm saying. I'm saying that domain-http is > currently in core. Web console and other clients use domain-http. If > we want keycloak to authenticate domain-http then keycloak must also be > in core. I really don't see where you are getting this 'must' from, we may have a requirement of 'we must be able to enable KeyCloak in our platforms' but where are you getting the 'we must include KeyCloak in the core distribution' from? > There are many possible solutions: > * Don't do the split > * Do the split, but allow core to see the full set of modules. > * Move domain-http out of core. In another discussion just starting I have also raised the question could the definition of the management interfaces also be moved into a subsystem. The management interfaces are required in domain mode to allow a slave to connection back and the app server instances to connect back but in standalone mode I do also see them as something that should be optional. > * Allow the extra dependencies. > * Redesign domain-http From the perspective of security integration that is already the path we are moving down. > * others? > >> >> Core can't actually do anything out of the box, it is a runtime that >> other distributions will build on. >> >> Stuart >> >> >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>>> added all these dependencies to the core in any case, so it is a >>>>>> problem that would have had to be solved at some point anyway. >>>>>> >>>>>> Stuart >>>>>> >>>>>> Stan Silvert wrote: >>>>>>> I'm starting to have doubts about this split. >>>>>>> >>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>>> into build-core so that the web console can use Keycloak for >>>>>>> authentication. The problem is that there is a huge web of >>>>>>> dependencies >>>>>>> that must be moved over from build to build-core. >>>>>>> >>>>>>> What exactly is the split trying to solve? >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> So I am moderately confident that we will be ready to split out >>>>>>>> Wildfly >>>>>>>> core into a separate repository early next week (I'm not saying >>>>>>>> that it >>>>>>>> will definitely happen in this time frame, just that it should be >>>>>>>> possible). >>>>>>>> >>>>>>>> Once this is ready to go I think the basic process will be: >>>>>>>> >>>>>>>> - Code freeze on Master >>>>>>>> - Create the core repo, push new rewritten core history >>>>>>>> - Release core 1.0.0.Beta1 >>>>>>>> - Create PR against core WF repo that deletes everything in >>>>>>>> core, and >>>>>>>> uses the core 1.0.0.Beta1 release >>>>>>>> - End of code freeze >>>>>>>> >>>>>>>> Stuart >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Jul 3 05:42:26 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:42:26 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B2BABF.7050405@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B2AE47.4000204@gmail.com> <53B2AEF0.4040406@redhat.com> <53B2B126.4040206@gmail.com> <53B2B710.9030602@redhat.com> <53B2BABF.7050405@gmail.com> Message-ID: <53B52582.8040005@jboss.com> On 01/07/14 14:42, Stuart Douglas wrote: > > > Stan Silvert wrote: >> On 7/1/2014 9:01 AM, Stuart Douglas wrote: >>> >>>> I understand. Perhaps I should have said, 'working out of the box on >>>> core'. domain-http is currently in core, which is what I'm talking about >>>> here. >>> >>> I don't follow your logic here. You are basically saying that unless >>> we can have keycloak in core then there is no point having a core? >> Of course that's not what I'm saying. I'm saying that domain-http is >> currently in core. Web console and other clients use domain-http. If we >> want keycloak to authenticate domain-http then keycloak must also be in >> core. >> > > I don't follow your logic. If we want web console and other clients to > use keycloak then keycloak must be present, but I really can't see why > you think it *must* be in core. > > IMHO the way this should work is that we identify the extension points > you need to integrate keycloak, WildFly Elytron would be the fundamental core of this. > looking at your kcauth branch this looks > fairly simple, basically just a way to add some handlers and > Authentication mechanisms. You then have the keycloak module use these > extension points to integrate with core. IMHO this will give a much > cleaner result and keeps all the keycloak related stuff in the keycloak > module. > > >> There are many possible solutions: >> * Don't do the split > > The split has been on the table for over 6 months, it is going ahead. > >> * Do the split, but allow core to see the full set of modules. > This makes no sense. If it has all the modules it is not core. > >> * Move domain-http out of core. >> * Allow the extra dependencies. >> * Redesign domain-http > > If by redesign you mean add some extension points to allow keycloak to > hook into it without requiring keycloak code in domain-http then this is > exactly what we should do. > > If you want a hand with this I should be able to help you out. Just keep in mind the security code that exists today is being re-worked and a lot will be replaced. We will be having one security solution that applies to the whole app server whether that be management or ee. > > Stuart > >> * others? >> >>> >>> Core can't actually do anything out of the box, it is a runtime that >>> other distributions will build on. >>> >>> Stuart >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>>>> added all these dependencies to the core in any case, so it is a >>>>>>> problem that would have had to be solved at some point anyway. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> Stan Silvert wrote: >>>>>>>> I'm starting to have doubts about this split. >>>>>>>> >>>>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>>>> into build-core so that the web console can use Keycloak for >>>>>>>> authentication. The problem is that there is a huge web of >>>>>>>> dependencies >>>>>>>> that must be moved over from build to build-core. >>>>>>>> >>>>>>>> What exactly is the split trying to solve? >>>>>>>> >>>>>>>> Stan >>>>>>>> >>>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> So I am moderately confident that we will be ready to split out >>>>>>>>> Wildfly >>>>>>>>> core into a separate repository early next week (I'm not saying >>>>>>>>> that it >>>>>>>>> will definitely happen in this time frame, just that it should be >>>>>>>>> possible). >>>>>>>>> >>>>>>>>> Once this is ready to go I think the basic process will be: >>>>>>>>> >>>>>>>>> - Code freeze on Master >>>>>>>>> - Create the core repo, push new rewritten core history >>>>>>>>> - Release core 1.0.0.Beta1 >>>>>>>>> - Create PR against core WF repo that deletes everything in >>>>>>>>> core, and >>>>>>>>> uses the core 1.0.0.Beta1 release >>>>>>>>> - End of code freeze >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Jul 3 05:45:20 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:45:20 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> Message-ID: <53B52630.7090508@jboss.com> On 03/07/14 10:28, Toma? Cerar wrote: > I think that for start we can make it by default enablable in full distro. > > Once this is done, and extra work is done on trimming down dependencies > to go as near JDK as possible > it could be moved to core distro. > > Rome was not build in a day, why would KeyCloak integration / > implementation be done in just one step. > > Isn't it better that we start somewhere to get it out to the people to > test it as soon as possible > and when it is ready we decide where it is best resting place and how to > get there. +1 That has been my thinking when I suggested we follow an approach of get it enableable by default rather than enabled by default as we reach the point it is useable. > > > > On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse > > wrote: > > > > The central question is, do we want Keycloak to work out of the box? > > Before this issue was known, everyone answered "yes". > > I think here we had reached the point we were answering the question "do > we want it enableable out of the box?" and the answer to that was "yes" > > What has not been defined since the split started is what "out of the > box" actually means now, are we talking out of the box for the core or > out of the box for a complete assembled server? > > On 01/07/14 12:55, Stan Silvert wrote: > > On 6/30/2014 10:43 PM, Stuart Douglas wrote: > >> It really sounds like this should not be part of core, but should be > >> something extra that just integrates with the core. > > That may be true, but it's not a decision that should depend on > how many > > modules must be added. > > > > The central question is, do we want Keycloak to work out of the box? > > Before this issue was known, everyone answered "yes". > > > > Should we really determine our feature set based on how many > modules it > > requires? I don't think we want do that, which is why I'm having > > doubts about the current approach. > > > >> > >> In all honesty we are highly unlikely to ever have accepted a PR > that > >> added all these dependencies to the core in any case, so it is a > >> problem that would have had to be solved at some point anyway. > >> > >> Stuart > >> > >> Stan Silvert wrote: > >>> I'm starting to have doubts about this split. > >>> > >>> Right now I'm trying to integrate the Keycloak (client-side) > adapter > >>> into build-core so that the web console can use Keycloak for > >>> authentication. The problem is that there is a huge web of > dependencies > >>> that must be moved over from build to build-core. > >>> > >>> What exactly is the split trying to solve? > >>> > >>> Stan > >>> > >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: > >>>> Hi all, > >>>> > >>>> So I am moderately confident that we will be ready to split > out Wildfly > >>>> core into a separate repository early next week (I'm not > saying that it > >>>> will definitely happen in this time frame, just that it should be > >>>> possible). > >>>> > >>>> Once this is ready to go I think the basic process will be: > >>>> > >>>> - Code freeze on Master > >>>> - Create the core repo, push new rewritten core history > >>>> - Release core 1.0.0.Beta1 > >>>> - Create PR against core WF repo that deletes everything in > core, and > >>>> uses the core 1.0.0.Beta1 release > >>>> - End of code freeze > >>>> > >>>> Stuart > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From darran.lofthouse at jboss.com Thu Jul 3 05:52:23 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 10:52:23 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B52630.7090508@jboss.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B52630.7090508@jboss.com> Message-ID: <53B527D7.10307@jboss.com> Should have added, I think it is the split that has complicated what by default means now. To me the critical point is that the full security services we can provide need to be included in the final distribution that will be used which to me does not automatically mean the core distribution. On 03/07/14 10:45, Darran Lofthouse wrote: > On 03/07/14 10:28, Toma? Cerar wrote: >> I think that for start we can make it by default enablable in full >> distro. >> >> Once this is done, and extra work is done on trimming down dependencies >> to go as near JDK as possible >> it could be moved to core distro. >> >> Rome was not build in a day, why would KeyCloak integration / >> implementation be done in just one step. >> >> Isn't it better that we start somewhere to get it out to the people to >> test it as soon as possible >> and when it is ready we decide where it is best resting place and how to >> get there. > > +1 That has been my thinking when I suggested we follow an approach of > get it enableable by default rather than enabled by default as we reach > the point it is useable. > >> >> >> >> On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse >> > wrote: >> >> >> > The central question is, do we want Keycloak to work out of >> the box? >> > Before this issue was known, everyone answered "yes". >> >> I think here we had reached the point we were answering the >> question "do >> we want it enableable out of the box?" and the answer to that was >> "yes" >> >> What has not been defined since the split started is what "out of the >> box" actually means now, are we talking out of the box for the >> core or >> out of the box for a complete assembled server? >> >> On 01/07/14 12:55, Stan Silvert wrote: >> > On 6/30/2014 10:43 PM, Stuart Douglas wrote: >> >> It really sounds like this should not be part of core, but >> should be >> >> something extra that just integrates with the core. >> > That may be true, but it's not a decision that should depend on >> how many >> > modules must be added. >> > >> > The central question is, do we want Keycloak to work out of the >> box? >> > Before this issue was known, everyone answered "yes". >> > >> > Should we really determine our feature set based on how many >> modules it >> > requires? I don't think we want do that, which is why I'm having >> > doubts about the current approach. >> > >> >> >> >> In all honesty we are highly unlikely to ever have accepted a PR >> that >> >> added all these dependencies to the core in any case, so it is a >> >> problem that would have had to be solved at some point anyway. >> >> >> >> Stuart >> >> >> >> Stan Silvert wrote: >> >>> I'm starting to have doubts about this split. >> >>> >> >>> Right now I'm trying to integrate the Keycloak (client-side) >> adapter >> >>> into build-core so that the web console can use Keycloak for >> >>> authentication. The problem is that there is a huge web of >> dependencies >> >>> that must be moved over from build to build-core. >> >>> >> >>> What exactly is the split trying to solve? >> >>> >> >>> Stan >> >>> >> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >> >>>> Hi all, >> >>>> >> >>>> So I am moderately confident that we will be ready to split >> out Wildfly >> >>>> core into a separate repository early next week (I'm not >> saying that it >> >>>> will definitely happen in this time frame, just that it >> should be >> >>>> possible). >> >>>> >> >>>> Once this is ready to go I think the basic process will be: >> >>>> >> >>>> - Code freeze on Master >> >>>> - Create the core repo, push new rewritten core history >> >>>> - Release core 1.0.0.Beta1 >> >>>> - Create PR against core WF repo that deletes everything in >> core, and >> >>>> uses the core 1.0.0.Beta1 release >> >>>> - End of code freeze >> >>>> >> >>>> Stuart >> >>>> _______________________________________________ >> >>>> wildfly-dev mailing list >> >>>> wildfly-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> >> >>> _______________________________________________ >> >>> wildfly-dev mailing list >> >>> wildfly-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> From jmesnil at redhat.com Thu Jul 3 05:56:52 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 3 Jul 2014 11:56:52 +0200 Subject: [wildfly-dev] Core and subsystem capabilities and requirements In-Reply-To: <65B2411F-733A-4C3C-BFC7-19223046CABC@jboss.com> References: <53A86FD7.6020502@redhat.com> <53A88599.1090003@redhat.com> <7630471E-0B96-44E7-9C0F-2C92C5D9FFE7@redhat.com> <65B2411F-733A-4C3C-BFC7-19223046CABC@jboss.com> Message-ID: On 23 Jun 2014, at 22:38, Kabir Khan wrote: > > On 23 Jun 2014, at 21:31, Jason Greene wrote: > >> >> On Jun 23, 2014, at 2:52 PM, David M. Lloyd wrote: >> >>> On 06/23/2014 01:20 PM, Brian Stansberry wrote: >>>> As we continue with our work splitting the WildFly code base into a core >>>> repo and then separate repos related to sets of features that we need to >>>> solidify the contracts between the various features and between features >>>> and the core. >>>> >>>> I've taken a crack at an initial design document on this: see [1]. We >>>> also need to do the practical work of identifying the various >>>> dependencies between our existing subsystems, see [2] for a start on that. >>>> >>>> I'd love to get feedback on this thread regarding the proposed design, >>>> as well as get direct edits on the [2] doc to flesh out the existing >>>> relationships. >>> >>> Here is what jumps out at me at first. >>> >>> ? I don't understand the reason to not allow optional dependencies on >>> capabilities. It would be of similar implementation complexity to the >>> suggested permutation implementation, however it would avoid the problem >>> of requiring 2? permutations for n optional dependencies. >> >> I had the same thought. > I don?t really understand what you two are getting at here. What would an optional requirement be? I can?t really get my head around ?I would like this to be there but I don?t care if it isn?t?. I think we have such an use case in the messaging subsystem. We will have a MESSAGING:CLUSTERED capability that will provide clustered messaging. This capability may require JGROUPS:BASE capability to use the JGroups stack but it is not mandatory since HornetQ also provides its own UDP stack that can be used if JGroups is not there. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Thu Jul 3 07:09:58 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 3 Jul 2014 13:09:58 +0200 Subject: [wildfly-dev] Core and subsystem capabilities and requirements In-Reply-To: <53A8947B.6010300@redhat.com> References: <53A86FD7.6020502@redhat.com> <53A88599.1090003@redhat.com> <53A8947B.6010300@redhat.com> Message-ID: <19EFAAE4-D29A-47FF-AC25-4EBB8FB5D66D@redhat.com> On 23 Jun 2014, at 22:56, Brian Stansberry wrote: > On 6/23/14, 2:52 PM, David M. Lloyd wrote: >> On 06/23/2014 01:20 PM, Brian Stansberry wrote >> ? I don't understand the purpose of binding capability identifiers to >> subsystem identifiers. It seems plausible to have a subsystem provide, >> for example, two capabilities now, but allow for a capability to be >> implemented separately in the future. A concrete example would be the >> way we ultimately moved Servlet from JBoss Web to Undertow. Ideally >> we'd only ever depend on the capability, making subsystems completely >> interchangeable. >> > > See your question about uniqueness. Associating these with subsystems > provides a form of namespacing; without that we'd have to come up with > something else. > > It's a valid point that we don't have to use association with subsystems > to provide this though. Any other suggestions? I?m not sure to understand the full scope of a capability. Is it planned to use capabilities to let different subsystems provides the same set of features? For example, if we had capabilities in AS7, would have both the web subsystem (with JBoss Web) and undertow subsystem provided the same capability for Servlets (e.g. HTTP:SERVLET) or two different (UNDERTOW:SERVLET and JBOSS-WEB:SERVLET). In the first case, a subsystem needing to use Servlets would not need to know which subsystems provides it (but we have to ensure only one subsystem providing the capability is present). In the second case, the subsystem may chose the provider of the capability based on the capability name (and both can be present). I?m trying to figure out how I would name the messaging/JMS capability. At first glance, I am not sure I want to have the implementation (HORNETQ) be part of the capability name. I would prefer MESSAGING:JMS as it leaves open to change the JMS provider without affecting the capability to provide JMS. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From Juergen.Zimmermann at HS-Karlsruhe.de Thu Jul 3 07:50:39 2014 From: Juergen.Zimmermann at HS-Karlsruhe.de (Juergen Zimmermann) Date: Thu, 3 Jul 2014 13:50:39 +0200 Subject: [wildfly-dev] Warnings when compiling WildFly Message-ID: <003601cf96b5$0292b610$07b82230$@HS-Karlsruhe.de> I just downloaded the sources of WildFly Core and WildFly. The compilations are working fine. However, for WildFly I'm getting these warnings right at the beginning: [WARNING] Some problems were encountered while building the effective model for org.wildfly:wildfly-ts-integ-smoke:jar:9.0.0.Alpha1-SNAPSHOT [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> duplicate declaration of version (?) @ org.wildfly:wildfly-testsuite:9.0.0.Alpha1-SNAPSHOT, C:\temp\wildfly-master-20140703\testsuite\pom.xml, line 215, column 21 [WARNING] [WARNING] Some problems were encountered while building the effective model for org.wildfly:wildfly-ts-integ:pom:9.0.0.Alpha1-SNAPSHOT [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> duplicate declaration of version (?) @ org.wildfly:wildfly-testsuite:9.0.0.Alpha1-SNAPSHOT, C:\temp\wildfly-master-20140703\testsuite\pom.xml, line 215, column 21 [WARNING] [WARNING] Some problems were encountered while building the effective model for org.wildfly:wildfly-testsuite:pom:9.0.0.Alpha1-SNAPSHOT [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> duplicate declaration of version (?) @ line 215, column 21 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140703/6627e262/attachment-0001.html From ssilvert at redhat.com Thu Jul 3 08:54:44 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 03 Jul 2014 08:54:44 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B5201B.9010209@jboss.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> Message-ID: <53B55294.6080705@redhat.com> On 7/3/2014 5:19 AM, Darran Lofthouse wrote: > > > The central question is, do we want Keycloak to work out of the box? > > Before this issue was known, everyone answered "yes". > > I think here we had reached the point we were answering the question > "do we want it enableable out of the box?" and the answer to that was > "yes" > > What has not been defined since the split started is what "out of the > box" actually means now, are we talking out of the box for the core or > out of the box for a complete assembled server? We now have three "out of the boxes". Three distributions. So what is available by default on these three distros? core-build web-build full-build First, which of these should have dmr over http available by default, out of the box? Second, of those with dmr over http available, which should have keycloak available by default, out of the box? For now, let's make no distinction about what is enabled by default. We only care about what is available by default. > > On 01/07/14 12:55, Stan Silvert wrote: >> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>> It really sounds like this should not be part of core, but should be >>> something extra that just integrates with the core. >> That may be true, but it's not a decision that should depend on how many >> modules must be added. >> >> The central question is, do we want Keycloak to work out of the box? >> Before this issue was known, everyone answered "yes". >> >> Should we really determine our feature set based on how many modules it >> requires? I don't think we want do that, which is why I'm having >> doubts about the current approach. >> >>> >>> In all honesty we are highly unlikely to ever have accepted a PR that >>> added all these dependencies to the core in any case, so it is a >>> problem that would have had to be solved at some point anyway. >>> >>> Stuart >>> >>> Stan Silvert wrote: >>>> I'm starting to have doubts about this split. >>>> >>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>> into build-core so that the web console can use Keycloak for >>>> authentication. The problem is that there is a huge web of >>>> dependencies >>>> that must be moved over from build to build-core. >>>> >>>> What exactly is the split trying to solve? >>>> >>>> Stan >>>> >>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>> Hi all, >>>>> >>>>> So I am moderately confident that we will be ready to split out >>>>> Wildfly >>>>> core into a separate repository early next week (I'm not saying >>>>> that it >>>>> will definitely happen in this time frame, just that it should be >>>>> possible). >>>>> >>>>> Once this is ready to go I think the basic process will be: >>>>> >>>>> - Code freeze on Master >>>>> - Create the core repo, push new rewritten core history >>>>> - Release core 1.0.0.Beta1 >>>>> - Create PR against core WF repo that deletes everything in core, and >>>>> uses the core 1.0.0.Beta1 release >>>>> - End of code freeze >>>>> >>>>> Stuart >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From bmcwhirt at redhat.com Thu Jul 3 09:05:35 2014 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 3 Jul 2014 09:05:35 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B55294.6080705@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> Message-ID: <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> I admitted haven?t been paying super-close attention, but as a member of several teams which build stuff upon AS/WildFly, I?d prefer that anything -core makes zero assumptions, and is as close to a nil container as possible. Then, let me mix in what I need. If the minimal baseline includes much more than nothing, then the overhead of building upon WildFly has increased. When you put things into WildFly ?by default?, you might be satisfying the 80% case, but there will still be 20% that won?t want whatever is jammed into the box and will consider it gratuitous for their needs. I vote for -core being only MSC/Modules/DeploymentUnitProcessor stuff, and a pert-near empty standalone.xml. -Bob On Jul 3, 2014, at 8:54 AM, Stan Silvert wrote: > On 7/3/2014 5:19 AM, Darran Lofthouse wrote: >> >>> The central question is, do we want Keycloak to work out of the box? >>> Before this issue was known, everyone answered "yes". >> >> I think here we had reached the point we were answering the question >> "do we want it enableable out of the box?" and the answer to that was >> "yes" >> >> What has not been defined since the split started is what "out of the >> box" actually means now, are we talking out of the box for the core or >> out of the box for a complete assembled server? > > We now have three "out of the boxes". Three distributions. So what is > available by default on these three distros? > core-build > web-build > full-build > > First, which of these should have dmr over http available by default, > out of the box? > Second, of those with dmr over http available, which should have > keycloak available by default, out of the box? > > For now, let's make no distinction about what is enabled by default. We > only care about what is available by default. > >> >> On 01/07/14 12:55, Stan Silvert wrote: >>> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>>> It really sounds like this should not be part of core, but should be >>>> something extra that just integrates with the core. >>> That may be true, but it's not a decision that should depend on how many >>> modules must be added. >>> >>> The central question is, do we want Keycloak to work out of the box? >>> Before this issue was known, everyone answered "yes". >>> >>> Should we really determine our feature set based on how many modules it >>> requires? I don't think we want do that, which is why I'm having >>> doubts about the current approach. >>> >>>> >>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>> added all these dependencies to the core in any case, so it is a >>>> problem that would have had to be solved at some point anyway. >>>> >>>> Stuart >>>> >>>> Stan Silvert wrote: >>>>> I'm starting to have doubts about this split. >>>>> >>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>> into build-core so that the web console can use Keycloak for >>>>> authentication. The problem is that there is a huge web of >>>>> dependencies >>>>> that must be moved over from build to build-core. >>>>> >>>>> What exactly is the split trying to solve? >>>>> >>>>> Stan >>>>> >>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>> Hi all, >>>>>> >>>>>> So I am moderately confident that we will be ready to split out >>>>>> Wildfly >>>>>> core into a separate repository early next week (I'm not saying >>>>>> that it >>>>>> will definitely happen in this time frame, just that it should be >>>>>> possible). >>>>>> >>>>>> Once this is ready to go I think the basic process will be: >>>>>> >>>>>> - Code freeze on Master >>>>>> - Create the core repo, push new rewritten core history >>>>>> - Release core 1.0.0.Beta1 >>>>>> - Create PR against core WF repo that deletes everything in core, and >>>>>> uses the core 1.0.0.Beta1 release >>>>>> - End of code freeze >>>>>> >>>>>> Stuart >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stuart.w.douglas at gmail.com Thu Jul 3 09:21:36 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 03 Jul 2014 09:21:36 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> Message-ID: <53B558E0.8050100@gmail.com> Bob McWhirter wrote: > I admitted haven?t been paying super-close attention, but as a member of several teams which build stuff upon AS/WildFly, I?d prefer that anything -core makes zero assumptions, and is as close to a nil container as possible. > > Then, let me mix in what I need. > > If the minimal baseline includes much more than nothing, then the overhead of building upon WildFly has increased. When you put things into WildFly ?by default?, you might be satisfying the 80% case, but there will still be 20% that won?t want whatever is jammed into the box and will consider it gratuitous for their needs. > > I vote for -core being only MSC/Modules/DeploymentUnitProcessor stuff, and a pert-near empty standalone.xml. > That is the intention. You also need to keep in mind that you can't actually do anything with core without first installing some extensions. Nothing works out of the box on core, because there is nothing there to do any work. Stuart > -Bob > > > On Jul 3, 2014, at 8:54 AM, Stan Silvert wrote: > >> On 7/3/2014 5:19 AM, Darran Lofthouse wrote: >>>> The central question is, do we want Keycloak to work out of the box? >>>> Before this issue was known, everyone answered "yes". >>> I think here we had reached the point we were answering the question >>> "do we want it enableable out of the box?" and the answer to that was >>> "yes" >>> >>> What has not been defined since the split started is what "out of the >>> box" actually means now, are we talking out of the box for the core or >>> out of the box for a complete assembled server? >> We now have three "out of the boxes". Three distributions. So what is >> available by default on these three distros? >> core-build >> web-build >> full-build >> >> First, which of these should have dmr over http available by default, >> out of the box? >> Second, of those with dmr over http available, which should have >> keycloak available by default, out of the box? >> >> For now, let's make no distinction about what is enabled by default. We >> only care about what is available by default. >> >>> On 01/07/14 12:55, Stan Silvert wrote: >>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>>>> It really sounds like this should not be part of core, but should be >>>>> something extra that just integrates with the core. >>>> That may be true, but it's not a decision that should depend on how many >>>> modules must be added. >>>> >>>> The central question is, do we want Keycloak to work out of the box? >>>> Before this issue was known, everyone answered "yes". >>>> >>>> Should we really determine our feature set based on how many modules it >>>> requires? I don't think we want do that, which is why I'm having >>>> doubts about the current approach. >>>> >>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>> added all these dependencies to the core in any case, so it is a >>>>> problem that would have had to be solved at some point anyway. >>>>> >>>>> Stuart >>>>> >>>>> Stan Silvert wrote: >>>>>> I'm starting to have doubts about this split. >>>>>> >>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>> into build-core so that the web console can use Keycloak for >>>>>> authentication. The problem is that there is a huge web of >>>>>> dependencies >>>>>> that must be moved over from build to build-core. >>>>>> >>>>>> What exactly is the split trying to solve? >>>>>> >>>>>> Stan >>>>>> >>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> So I am moderately confident that we will be ready to split out >>>>>>> Wildfly >>>>>>> core into a separate repository early next week (I'm not saying >>>>>>> that it >>>>>>> will definitely happen in this time frame, just that it should be >>>>>>> possible). >>>>>>> >>>>>>> Once this is ready to go I think the basic process will be: >>>>>>> >>>>>>> - Code freeze on Master >>>>>>> - Create the core repo, push new rewritten core history >>>>>>> - Release core 1.0.0.Beta1 >>>>>>> - Create PR against core WF repo that deletes everything in core, and >>>>>>> uses the core 1.0.0.Beta1 release >>>>>>> - End of code freeze >>>>>>> >>>>>>> Stuart >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Thu Jul 3 09:22:46 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 03 Jul 2014 14:22:46 +0100 Subject: [wildfly-dev] Pending core split In-Reply-To: <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> Message-ID: <53B55926.8080408@jboss.com> +1 In terms of security capabilities I think the core must be developed in a way that leaves it ready for security services to be added but that those services should be added in the distributions built on top of the core. This thread has really had most of it's traffic in relation to enabling KeyCloak but I anticipate we would also have similar discussions when it comes to enabling capabilities provided by PicketLink. WildFly ELytron is being developed to provide SPIs to allow different providers to be used IMO choosing which providers to make available is something that should happen when the higher level distribution is defined - that should also be the point the default out of the box policy is defined as again different distributions would have different requirements. Regards, Darran Lofthouse. On 03/07/14 14:05, Bob McWhirter wrote: > I admitted haven?t been paying super-close attention, but as a member of several teams which build stuff upon AS/WildFly, I?d prefer that anything -core makes zero assumptions, and is as close to a nil container as possible. > > Then, let me mix in what I need. > > If the minimal baseline includes much more than nothing, then the overhead of building upon WildFly has increased. When you put things into WildFly ?by default?, you might be satisfying the 80% case, but there will still be 20% that won?t want whatever is jammed into the box and will consider it gratuitous for their needs. > > I vote for -core being only MSC/Modules/DeploymentUnitProcessor stuff, and a pert-near empty standalone.xml. > > -Bob > > > On Jul 3, 2014, at 8:54 AM, Stan Silvert wrote: > >> On 7/3/2014 5:19 AM, Darran Lofthouse wrote: >>> >>>> The central question is, do we want Keycloak to work out of the box? >>>> Before this issue was known, everyone answered "yes". >>> >>> I think here we had reached the point we were answering the question >>> "do we want it enableable out of the box?" and the answer to that was >>> "yes" >>> >>> What has not been defined since the split started is what "out of the >>> box" actually means now, are we talking out of the box for the core or >>> out of the box for a complete assembled server? >> >> We now have three "out of the boxes". Three distributions. So what is >> available by default on these three distros? >> core-build >> web-build >> full-build >> >> First, which of these should have dmr over http available by default, >> out of the box? >> Second, of those with dmr over http available, which should have >> keycloak available by default, out of the box? >> >> For now, let's make no distinction about what is enabled by default. We >> only care about what is available by default. >> >>> >>> On 01/07/14 12:55, Stan Silvert wrote: >>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>>>> It really sounds like this should not be part of core, but should be >>>>> something extra that just integrates with the core. >>>> That may be true, but it's not a decision that should depend on how many >>>> modules must be added. >>>> >>>> The central question is, do we want Keycloak to work out of the box? >>>> Before this issue was known, everyone answered "yes". >>>> >>>> Should we really determine our feature set based on how many modules it >>>> requires? I don't think we want do that, which is why I'm having >>>> doubts about the current approach. >>>> >>>>> >>>>> In all honesty we are highly unlikely to ever have accepted a PR that >>>>> added all these dependencies to the core in any case, so it is a >>>>> problem that would have had to be solved at some point anyway. >>>>> >>>>> Stuart >>>>> >>>>> Stan Silvert wrote: >>>>>> I'm starting to have doubts about this split. >>>>>> >>>>>> Right now I'm trying to integrate the Keycloak (client-side) adapter >>>>>> into build-core so that the web console can use Keycloak for >>>>>> authentication. The problem is that there is a huge web of >>>>>> dependencies >>>>>> that must be moved over from build to build-core. >>>>>> >>>>>> What exactly is the split trying to solve? >>>>>> >>>>>> Stan >>>>>> >>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> So I am moderately confident that we will be ready to split out >>>>>>> Wildfly >>>>>>> core into a separate repository early next week (I'm not saying >>>>>>> that it >>>>>>> will definitely happen in this time frame, just that it should be >>>>>>> possible). >>>>>>> >>>>>>> Once this is ready to go I think the basic process will be: >>>>>>> >>>>>>> - Code freeze on Master >>>>>>> - Create the core repo, push new rewritten core history >>>>>>> - Release core 1.0.0.Beta1 >>>>>>> - Create PR against core WF repo that deletes everything in core, and >>>>>>> uses the core 1.0.0.Beta1 release >>>>>>> - End of code freeze >>>>>>> >>>>>>> Stuart >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From ssilvert at redhat.com Thu Jul 3 10:02:49 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 03 Jul 2014 10:02:49 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B558E0.8050100@gmail.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> Message-ID: <53B56289.1050509@redhat.com> On 7/3/2014 9:21 AM, Stuart Douglas wrote: > > > Bob McWhirter wrote: >> I admitted haven?t been paying super-close attention, but as a member >> of several teams which build stuff upon AS/WildFly, I?d prefer that >> anything -core makes zero assumptions, and is as close to a nil >> container as possible. >> >> Then, let me mix in what I need. >> >> If the minimal baseline includes much more than nothing, then the >> overhead of building upon WildFly has increased. When you put things >> into WildFly ?by default?, you might be satisfying the 80% case, but >> there will still be 20% that won?t want whatever is jammed into the >> box and will consider it gratuitous for their needs. >> >> I vote for -core being only MSC/Modules/DeploymentUnitProcessor >> stuff, and a pert-near empty standalone.xml. >> > > That is the intention. > > You also need to keep in mind that you can't actually do anything with > core without first installing some extensions. Nothing works out of > the box on core, because there is nothing there to do any work. Nothing works out of the box on core? Does this mean web console doesn't work? Does this mean CLI doesn't work? I think it's perfectly acceptable to choose yes or no to any of these, but we need to answer those questions to move forward. > > Stuart > >> -Bob >> >> >> On Jul 3, 2014, at 8:54 AM, Stan Silvert wrote: >> >>> On 7/3/2014 5:19 AM, Darran Lofthouse wrote: >>>>> The central question is, do we want Keycloak to work out of the box? >>>>> Before this issue was known, everyone answered "yes". >>>> I think here we had reached the point we were answering the question >>>> "do we want it enableable out of the box?" and the answer to that was >>>> "yes" >>>> >>>> What has not been defined since the split started is what "out of the >>>> box" actually means now, are we talking out of the box for the core or >>>> out of the box for a complete assembled server? >>> We now have three "out of the boxes". Three distributions. So what is >>> available by default on these three distros? >>> core-build >>> web-build >>> full-build >>> >>> First, which of these should have dmr over http available by default, >>> out of the box? >>> Second, of those with dmr over http available, which should have >>> keycloak available by default, out of the box? >>> >>> For now, let's make no distinction about what is enabled by >>> default. We >>> only care about what is available by default. >>> >>>> On 01/07/14 12:55, Stan Silvert wrote: >>>>> On 6/30/2014 10:43 PM, Stuart Douglas wrote: >>>>>> It really sounds like this should not be part of core, but should be >>>>>> something extra that just integrates with the core. >>>>> That may be true, but it's not a decision that should depend on >>>>> how many >>>>> modules must be added. >>>>> >>>>> The central question is, do we want Keycloak to work out of the box? >>>>> Before this issue was known, everyone answered "yes". >>>>> >>>>> Should we really determine our feature set based on how many >>>>> modules it >>>>> requires? I don't think we want do that, which is why I'm having >>>>> doubts about the current approach. >>>>> >>>>>> In all honesty we are highly unlikely to ever have accepted a PR >>>>>> that >>>>>> added all these dependencies to the core in any case, so it is a >>>>>> problem that would have had to be solved at some point anyway. >>>>>> >>>>>> Stuart >>>>>> >>>>>> Stan Silvert wrote: >>>>>>> I'm starting to have doubts about this split. >>>>>>> >>>>>>> Right now I'm trying to integrate the Keycloak (client-side) >>>>>>> adapter >>>>>>> into build-core so that the web console can use Keycloak for >>>>>>> authentication. The problem is that there is a huge web of >>>>>>> dependencies >>>>>>> that must be moved over from build to build-core. >>>>>>> >>>>>>> What exactly is the split trying to solve? >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> On 6/27/2014 12:19 PM, Stuart Douglas wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> So I am moderately confident that we will be ready to split out >>>>>>>> Wildfly >>>>>>>> core into a separate repository early next week (I'm not saying >>>>>>>> that it >>>>>>>> will definitely happen in this time frame, just that it should be >>>>>>>> possible). >>>>>>>> >>>>>>>> Once this is ready to go I think the basic process will be: >>>>>>>> >>>>>>>> - Code freeze on Master >>>>>>>> - Create the core repo, push new rewritten core history >>>>>>>> - Release core 1.0.0.Beta1 >>>>>>>> - Create PR against core WF repo that deletes everything in >>>>>>>> core, and >>>>>>>> uses the core 1.0.0.Beta1 release >>>>>>>> - End of code freeze >>>>>>>> >>>>>>>> Stuart >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Thu Jul 3 10:06:09 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 3 Jul 2014 16:06:09 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B56289.1050509@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> Message-ID: On Thu, Jul 3, 2014 at 4:02 PM, Stan Silvert wrote: > Does this mean web console doesn't work? > No it doesn't, you can add if you need it > Does this mean CLI doesn't work? > CLI and domain mode both work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140703/4ba04339/attachment.html From david.lloyd at redhat.com Thu Jul 3 10:11:19 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 03 Jul 2014 09:11:19 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B56289.1050509@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> Message-ID: <53B56487.2090706@redhat.com> On 07/03/2014 09:02 AM, Stan Silvert wrote: > On 7/3/2014 9:21 AM, Stuart Douglas wrote: >> >> >> Bob McWhirter wrote: >>> I admitted haven?t been paying super-close attention, but as a member >>> of several teams which build stuff upon AS/WildFly, I?d prefer that >>> anything -core makes zero assumptions, and is as close to a nil >>> container as possible. >>> >>> Then, let me mix in what I need. >>> >>> If the minimal baseline includes much more than nothing, then the >>> overhead of building upon WildFly has increased. When you put things >>> into WildFly ?by default?, you might be satisfying the 80% case, but >>> there will still be 20% that won?t want whatever is jammed into the >>> box and will consider it gratuitous for their needs. >>> >>> I vote for -core being only MSC/Modules/DeploymentUnitProcessor >>> stuff, and a pert-near empty standalone.xml. >>> >> >> That is the intention. >> >> You also need to keep in mind that you can't actually do anything with >> core without first installing some extensions. Nothing works out of >> the box on core, because there is nothing there to do any work. > Nothing works out of the box on core? > Does this mean web console doesn't work? > Does this mean CLI doesn't work? > > I think it's perfectly acceptable to choose yes or no to any of these, > but we need to answer those questions to move forward. In point of fact, no we don't. In order to move forward, we need to terminate this pointless email thread. The core split is necessarily going to be incremental and iterative - we are still quite a ways away from being able to apply this kind of broad principle, and anyway it has zero bearing on what you need to be doing, AFAICT. Splitting up a monolithic codebase as big and complex as WildFly isn't something that can or should be armchair quarterbacked. Either help directly in a pragmatic and incremental manner, or just let it happen as it needs to happen; competent hands are on the helm. -- - DML From theute at redhat.com Thu Jul 3 10:26:08 2014 From: theute at redhat.com (Thomas Heute) Date: Thu, 03 Jul 2014 16:26:08 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B56487.2090706@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> <53B56487.2090706@redhat.com> Message-ID: <53B56800.9020608@redhat.com> We just had a quick call, here is the summary: Tomaz Cerar Stan Silvert Darran Lofthouse Thomas Heute Stian Thorgersen WF "distributions": WF Core = bare minimum (CLI included, DMR over HTTP, no console), CLI/DMR over HTTP would be secured the way it is already (ie: without KC) WF Web = WF Core + Servlet Container (Tomcat alternative) WF Full = What we have today Future: Support for extensions on host controller Elytron Plan: Keep KC integration pluggable and added in WF Full first (could go down to WF Web or whatever other profiles but after). Domain HTTP module needs an "optional" dependency on KC No need to wait on Elytron Additional link/info: https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration Thomas On 07/03/2014 04:11 PM, David M. Lloyd wrote: > On 07/03/2014 09:02 AM, Stan Silvert wrote: >> On 7/3/2014 9:21 AM, Stuart Douglas wrote: >>> >>> Bob McWhirter wrote: >>>> I admitted haven?t been paying super-close attention, but as a member >>>> of several teams which build stuff upon AS/WildFly, I?d prefer that >>>> anything -core makes zero assumptions, and is as close to a nil >>>> container as possible. >>>> >>>> Then, let me mix in what I need. >>>> >>>> If the minimal baseline includes much more than nothing, then the >>>> overhead of building upon WildFly has increased. When you put things >>>> into WildFly ?by default?, you might be satisfying the 80% case, but >>>> there will still be 20% that won?t want whatever is jammed into the >>>> box and will consider it gratuitous for their needs. >>>> >>>> I vote for -core being only MSC/Modules/DeploymentUnitProcessor >>>> stuff, and a pert-near empty standalone.xml. >>>> >>> That is the intention. >>> >>> You also need to keep in mind that you can't actually do anything with >>> core without first installing some extensions. Nothing works out of >>> the box on core, because there is nothing there to do any work. >> Nothing works out of the box on core? >> Does this mean web console doesn't work? >> Does this mean CLI doesn't work? >> >> I think it's perfectly acceptable to choose yes or no to any of these, >> but we need to answer those questions to move forward. > In point of fact, no we don't. In order to move forward, we need to > terminate this pointless email thread. The core split is necessarily > going to be incremental and iterative - we are still quite a ways away > from being able to apply this kind of broad principle, and anyway it has > zero bearing on what you need to be doing, AFAICT. > > Splitting up a monolithic codebase as big and complex as WildFly isn't > something that can or should be armchair quarterbacked. Either help > directly in a pragmatic and incremental manner, or just let it happen as > it needs to happen; competent hands are on the helm. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140703/9dc73bd4/attachment.html From david.lloyd at redhat.com Thu Jul 3 10:29:08 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 03 Jul 2014 09:29:08 -0500 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B56800.9020608@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> <53B56487.2090706@redhat.com> <53B56800.9020608@redhat.com> Message-ID: <53B568B4.2040609@redhat.com> Now that we've democratically wasted everyone's time fairly on this, can we please all get back to work? Note that all this dickering has not actually changed the course in any measurable way - a sure sign of wasted effort. On 07/03/2014 09:26 AM, Thomas Heute wrote: > We just had a quick call, here is the summary: > > Tomaz Cerar > Stan Silvert > Darran Lofthouse > Thomas Heute > Stian Thorgersen > > WF "distributions": > WF Core = bare minimum (CLI included, DMR over HTTP, no console), > CLI/DMR over HTTP would be secured the way it is already (ie: without KC) > WF Web = WF Core + Servlet Container (Tomcat alternative) > WF Full = What we have today > > Future: > Support for extensions on host controller > Elytron > > Plan: > Keep KC integration pluggable and added in WF Full first (could go > down to WF Web or whatever other profiles but after). > Domain HTTP module needs an "optional" dependency on KC > No need to wait on Elytron > > Additional link/info: > https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration > > Thomas > > > > On 07/03/2014 04:11 PM, David M. Lloyd wrote: >> On 07/03/2014 09:02 AM, Stan Silvert wrote: >>> On 7/3/2014 9:21 AM, Stuart Douglas wrote: >>>> >>>> Bob McWhirter wrote: >>>>> I admitted haven?t been paying super-close attention, but as a member >>>>> of several teams which build stuff upon AS/WildFly, I?d prefer that >>>>> anything -core makes zero assumptions, and is as close to a nil >>>>> container as possible. >>>>> >>>>> Then, let me mix in what I need. >>>>> >>>>> If the minimal baseline includes much more than nothing, then the >>>>> overhead of building upon WildFly has increased. When you put things >>>>> into WildFly ?by default?, you might be satisfying the 80% case, but >>>>> there will still be 20% that won?t want whatever is jammed into the >>>>> box and will consider it gratuitous for their needs. >>>>> >>>>> I vote for -core being only MSC/Modules/DeploymentUnitProcessor >>>>> stuff, and a pert-near empty standalone.xml. >>>>> >>>> That is the intention. >>>> >>>> You also need to keep in mind that you can't actually do anything with >>>> core without first installing some extensions. Nothing works out of >>>> the box on core, because there is nothing there to do any work. >>> Nothing works out of the box on core? >>> Does this mean web console doesn't work? >>> Does this mean CLI doesn't work? >>> >>> I think it's perfectly acceptable to choose yes or no to any of these, >>> but we need to answer those questions to move forward. >> In point of fact, no we don't. In order to move forward, we need to >> terminate this pointless email thread. The core split is necessarily >> going to be incremental and iterative - we are still quite a ways away >> from being able to apply this kind of broad principle, and anyway it has >> zero bearing on what you need to be doing, AFAICT. >> >> Splitting up a monolithic codebase as big and complex as WildFly isn't >> something that can or should be armchair quarterbacked. Either help >> directly in a pragmatic and incremental manner, or just let it happen as >> it needs to happen; competent hands are on the helm. >> > -- - DML From stuart.w.douglas at gmail.com Thu Jul 3 10:41:55 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 03 Jul 2014 10:41:55 -0400 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B56289.1050509@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> Message-ID: <53B56BB3.1090200@gmail.com> > Nothing works out of the box on core? > Does this mean web console doesn't work? > Does this mean CLI doesn't work? > CLI will work, but there is nothing really there to manage, except for logging and the core server (system properties, management interface etc). You could deploy something, but as there are no subsystems the deployment can't really do anything (there is no Servlet, no EJB etc). The whole point of core is that it is a platform for other projects (like the ones Bob mentioned earlier) to build on. Stuart From sdouglas at redhat.com Thu Jul 3 12:24:37 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 03 Jul 2014 12:24:37 -0400 Subject: [wildfly-dev] Wildfly provisioning tools and packaging format Message-ID: <53B583C5.2010405@redhat.com> Hi all, So now that the core split has happened, I want to start work on the new tooling for creating Wildfly feature packs. At the moment the build is using a simple maven plugin that I created, that will take an existing server (e.g. the core server), layer some extra modules over the top of it, build the config files, and perform any other build tasks that are required. It can also turn a 'thin' server into a traditional fat server. This is going to change to having two separate tools, the build tool and the provisioning tool. The build tool will be used to create Wildfly feature packs. A feature pack is kinda similar to what is already produced, but with some major differences: - It does not contain the contents of any feature packs it was built on. For example at the moment the results of web-build also contains the server core. The web-build feature pack will only contain modules provided by the web-build pack. - It is not a server, in that it cannot just be unzipped and ran, the provisioning tool must be used first to create a runnable server from a set of feature packs. Once the build tool has created the feature packs, it is then up to the provisioning tool to use them to assemble a working server. The provision tool will be written as a library, with multiple front ends. At the very least we will provide a standalone version and a maven plugin. The provisioning tool takes a server descriptor, and uses that to download all the relevant feature packs and assemble them into a server. This process will give the user a lot of flexibility over how the server is configured, including: - The ability to specify only the subsystems they are after, and a cut down subsystem with just these subsystems and their dependents will be installed. - The ability to override versions, e.g. to provision a server with an updated version of Resteasy. - The ability to install deployments into the server by specifying the deployments GAV. - The ability to customise the default config (not sure how this will work yet. A yuck solution would be xslt, but no one likes that. A nicer solution could be some kind of CLI script that is run on first boot). This provisioning tool will also be used to build our server for our traditional distribution and test suite. Basically as part of the build process the maven plugin will be run to provision a server from the constituent feature packs. The feature pack layout will look like below: ------ versions.properties wildfly-pack.xml modules/ com/acme/mymodule module.xml ... repository (optional) com/acme/myartifact/my-artifact.jar ... configuration standalone.xml standalone-full.xml domain.xml ... content bin/README.txt bin/LICENSE.txt ... ------ The contents of these files and directories is as follows: versions.properties - properties file with the format G:A(:C)=V, e.g. org.jboss.resteasy:resteasy-jaxrs=3.0.0.Final wildfly-pack.xml - This contains all additional pack metadata: pack name: The name of the feature pack, must not contain spaces pack description: Self explanatory packaging version: This is inferred from the schema required tool version: The minimum version of the provisioning tool that is required to handle this pack permissions: A section to set unix file permissions version overrides: A section that allows for specific overrides of versions in the base system dependencies: Information on the feature packs this pack depends on modules: Similar to the modules dir we have today, with some exceptions: - only artifact references are used, and these artifacts just refer to group and artifact, without the version number. See the modules.xml files in the current build for an example. repository: Contains maven artifacts in the maven repository layout. This allows for the creation of 'offline' feature packs, where the pack does not need access to an external maven repository. This is not required, and in most cases will not be used. I am not 100% sure if we actually want this. configuration: contains configuration template files, e.g. standalone.xml template content: anything in this directory will be copied directly into the server Comments? It is expected that work will be started on this tooling very shortly to replace the current build plugin. I am going to create a wildfly-build-tools repository to hold these new plugins. Stuart From rory.odonnell at oracle.com Fri Jul 4 05:18:15 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Fri, 04 Jul 2014 10:18:15 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b21, JDK 8u20 b21 are available on java.net Message-ID: <53B67157.2090000@oracle.com> Hi Guys, Early Access builds for JDK 9 b21 and JDK 8u20 b21 are available on java.net. As we enter the later phases of development for JDK 8u20 , please log any show stoppers as soon as possible. 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/20140704/54b3d367/attachment.html From darran.lofthouse at jboss.com Fri Jul 4 06:51:27 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 04 Jul 2014 11:51:27 +0100 Subject: [wildfly-dev] Wildfly provisioning tools and packaging format In-Reply-To: <53B583C5.2010405@redhat.com> References: <53B583C5.2010405@redhat.com> Message-ID: <53B6872F.705@jboss.com> On 03/07/14 17:24, Stuart Douglas wrote: > - The ability to customise the default config (not sure how this will > work yet. A yuck solution would be xslt, but no one likes that. A nicer > solution could be some kind of CLI script that is run on first boot). I think we should avoid XML manipulation as much as we can, really it is just our chosen approach to persist the servers config - there is nothing to stop us from changing to something different so persistence format could even become something selected when creating a distribution. CLI commands could be very nice, the tool could even run the server in admin mode to execute them and there have been various discussions on running the server in the CLI or the CLI in the server. Could this also be a time to consider all configuration for the server starting from CLI commands? I believe our current approach is an evolution from where we used to just have fully defined configurations in the codebase, assembling XML fragments enabled re-use. But now that tooling to create a distribution is being considered again maybe 100% if the configuration could come from defined management ops. From theute at redhat.com Fri Jul 4 09:42:53 2014 From: theute at redhat.com (Thomas Heute) Date: Fri, 04 Jul 2014 15:42:53 +0200 Subject: [wildfly-dev] Pending core split In-Reply-To: <53B568B4.2040609@redhat.com> References: <53AD9974.8020108@gmail.com> <53B1DAEA.5090305@redhat.com> <53B22042.5010508@gmail.com> <53B2A1A8.6090505@redhat.com> <53B5201B.9010209@jboss.com> <53B55294.6080705@redhat.com> <20395197-024B-422F-8537-0C0862A15EC7@redhat.com> <53B558E0.8050100@gmail.com> <53B56289.1050509@redhat.com> <53B56487.2090706@redhat.com> <53B56800.9020608@redhat.com> <53B568B4.2040609@redhat.com> Message-ID: <53B6AF5D.1000406@redhat.com> I think it just needed clarifications. On 07/03/2014 04:29 PM, David M. Lloyd wrote: > Now that we've democratically wasted everyone's time fairly on this, can > we please all get back to work? > > Note that all this dickering has not actually changed the course in any > measurable way - a sure sign of wasted effort. > > On 07/03/2014 09:26 AM, Thomas Heute wrote: >> We just had a quick call, here is the summary: >> >> Tomaz Cerar >> Stan Silvert >> Darran Lofthouse >> Thomas Heute >> Stian Thorgersen >> >> WF "distributions": >> WF Core = bare minimum (CLI included, DMR over HTTP, no console), >> CLI/DMR over HTTP would be secured the way it is already (ie: without KC) >> WF Web = WF Core + Servlet Container (Tomcat alternative) >> WF Full = What we have today >> >> Future: >> Support for extensions on host controller >> Elytron >> >> Plan: >> Keep KC integration pluggable and added in WF Full first (could go >> down to WF Web or whatever other profiles but after). >> Domain HTTP module needs an "optional" dependency on KC >> No need to wait on Elytron >> >> Additional link/info: >> https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration >> >> Thomas >> >> >> >> On 07/03/2014 04:11 PM, David M. Lloyd wrote: >>> On 07/03/2014 09:02 AM, Stan Silvert wrote: >>>> On 7/3/2014 9:21 AM, Stuart Douglas wrote: >>>>> >>>>> Bob McWhirter wrote: >>>>>> I admitted haven?t been paying super-close attention, but as a member >>>>>> of several teams which build stuff upon AS/WildFly, I?d prefer that >>>>>> anything -core makes zero assumptions, and is as close to a nil >>>>>> container as possible. >>>>>> >>>>>> Then, let me mix in what I need. >>>>>> >>>>>> If the minimal baseline includes much more than nothing, then the >>>>>> overhead of building upon WildFly has increased. When you put things >>>>>> into WildFly ?by default?, you might be satisfying the 80% case, but >>>>>> there will still be 20% that won?t want whatever is jammed into the >>>>>> box and will consider it gratuitous for their needs. >>>>>> >>>>>> I vote for -core being only MSC/Modules/DeploymentUnitProcessor >>>>>> stuff, and a pert-near empty standalone.xml. >>>>>> >>>>> That is the intention. >>>>> >>>>> You also need to keep in mind that you can't actually do anything with >>>>> core without first installing some extensions. Nothing works out of >>>>> the box on core, because there is nothing there to do any work. >>>> Nothing works out of the box on core? >>>> Does this mean web console doesn't work? >>>> Does this mean CLI doesn't work? >>>> >>>> I think it's perfectly acceptable to choose yes or no to any of these, >>>> but we need to answer those questions to move forward. >>> In point of fact, no we don't. In order to move forward, we need to >>> terminate this pointless email thread. The core split is necessarily >>> going to be incremental and iterative - we are still quite a ways away >>> from being able to apply this kind of broad principle, and anyway it has >>> zero bearing on what you need to be doing, AFAICT. >>> >>> Splitting up a monolithic codebase as big and complex as WildFly isn't >>> something that can or should be armchair quarterbacked. Either help >>> directly in a pragmatic and incremental manner, or just let it happen as >>> it needs to happen; competent hands are on the helm. >>> >> > From kabir.khan at jboss.com Sat Jul 5 05:57:39 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Sat, 5 Jul 2014 10:57:39 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests Message-ID: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. From kabir.khan at jboss.com Sun Jul 6 06:45:23 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Sun, 6 Jul 2014 11:45:23 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> Message-ID: <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit * infinispan - something goes wrong in ther * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. On 5 Jul 2014, at 10:57, Kabir Khan wrote: > I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). > > Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Sun Jul 6 07:22:41 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Sun, 6 Jul 2014 12:22:41 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> Message-ID: On 6 Jul 2014, at 11:45, Kabir Khan wrote: > https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. > > All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x > * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit s/s commit/a commit > * infinispan - something goes wrong in the ? 7.1.x tests, I?ve not looked into it > * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. > > These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. > > On 5 Jul 2014, at 10:57, Kabir Khan wrote: > >> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >> >> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >> >> >> >> >> >> _______________________________________________ >> 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 frank.langelage at osnanet.de Sun Jul 6 15:03:38 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 06 Jul 2014 21:03:38 +0200 Subject: [wildfly-dev] Warnings when compiling WildFly In-Reply-To: <003601cf96b5$0292b610$07b82230$@HS-Karlsruhe.de> References: <003601cf96b5$0292b610$07b82230$@HS-Karlsruhe.de> Message-ID: <53B99D8A.3090403@osnanet.de> Pull request https://github.com/wildfly/wildfly/pull/6482 sent to fix this issue. On 03.07.14 13:50, Juergen Zimmermann wrote: > > I just downloaded the sources of WildFly Core and WildFly. The > compilations are working fine. However, for WildFly I'm getting these > warnings right at the beginning: > > [WARNING] Some problems were encountered while building the effective > model for org.wildfly:wildfly-ts-integ-smoke:jar:9.0.0.Alpha1-SNAPSHOT > > [WARNING] > 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be > unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> > duplicate declaration of version (?) @ > org.wildfly:wildfly-testsuite:9.0.0.Alpha1-SNAPSHOT, > C:\temp\wildfly-master-20140703\testsuite\pom.xml, line 215, column 21 > > [WARNING] > > [WARNING] Some problems were encountered while building the effective > model for org.wildfly:wildfly-ts-integ:pom:9.0.0.Alpha1-SNAPSHOT > > [WARNING] > 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be > unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> > duplicate declaration of version (?) @ > org.wildfly:wildfly-testsuite:9.0.0.Alpha1-SNAPSHOT, > C:\temp\wildfly-master-20140703\testsuite\pom.xml, line 215, column 21 > > [WARNING] > > [WARNING] Some problems were encountered while building the effective > model for org.wildfly:wildfly-testsuite:pom:9.0.0.Alpha1-SNAPSHOT > > [WARNING] > 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be > unique: org.jboss.arquillian.junit:arquillian-junit-container:jar -> > duplicate declaration of version (?) @ line 215, column 21 > > [WARNING] > > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > > [WARNING] > > [WARNING] For this reason, future Maven versions might no longer > support building such malformed projects. > > > > _______________________________________________ > 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/20140706/c3615234/attachment-0001.html From ewertz at redhat.com Mon Jul 7 01:36:24 2014 From: ewertz at redhat.com (Edward Wertz) Date: Mon, 7 Jul 2014 01:36:24 -0400 (EDT) Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53AD8D3D.1020301@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> Message-ID: <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> I've been thinking about the UX considerations over the last week. Generally there seem to be 3 basic situations involved. 1) There can be expressions in the result and the CLI can, in some manner, successfully resolve those expressions. This is dependent on the context that the command/operation is executed in, domain/standalone mode and the location in the configuration tree, but seems solvable. 2) There can be expressions in the result and the CLI can't resolve those expressions. For example if they're looking at a domain profile there's nothing to resolve against. 3) There won't be expressions in the result. There are lots of places in the CLI that would never return an expression. Which means the user would never need the argument/param. I think it's ok to hide the argument/param in situation 3. If expressions won't show up in the results there's no reason to have an option to resolve them really. It seems confusing to include it here. The main question is what to do in situation 2, where there will be expressions in a result but it's impossible to resolve. Hiding the argument there seems like it could be confusing for people. They'll see an expression and if they know the argument is available elsewhere they'll wonder why they can't use it here. Frustration ensues. I think it would be better to have some type of error message explaining, somehow, that their location within the configuration tree doesn't allow for expressions to be resolved. I'm not sure what it should say though or how many of these situations exist. Any suggestions? The other question is whether there are situations where 1 and 2 actually overlap. Where some expressions are resolvable, but others are not. I haven't been able to figure out if that's an actual problem yet. I'm going to implement the ability to hide the argument for the 'ls' command this week, which Alexey pointed me towards on Friday, and look into how to add a param to the server-side operations. Once I have both working successfully I'll try to create a comprehensive list of all the applicable situations I can figure out. No sense in doing that before I can get it actually working for both the CLI commands and server-side operations first. Joe Wertz ----- Original Message ----- > > On 06/27/2014 04:45 PM, Brian Stansberry wrote: > > On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: > >> On 06/26/2014 05:31 PM, Brian Stansberry wrote: > >>> Thanks, Joe, for looking into this. > >>> > >>> I'm curious what you've done so far with your 'ls > >>> --resolve-expressions' > >>> work. Did you use the existing > >>> ':resolve-expression(expression=___)' low > >>> level operation to process any expressions found in the > >>> :read-resource > >>> response? > >>> > >>> There are a few aspects of this I'd like to explore. > >>> > >>> One is the UX one. Is allowing 'resolve-expressions' in some > >>> contexts > >>> and not others a good UX? Will users understand that? I'm > >>> ambivalent > >>> about that, and am interested in others' opinions. > >>> > >>> If it can work for a server and for anything under /host=*, then > >>> I'm > >>> ambivalent. Any restriction at all is unintuitive, but once the > >>> user > >>> learns that there is a restriction, that's a pretty > >>> understandable one. > >>> If it only works for a patchwork of stuff under /host=* then I'm > >>> real > >>> negative about it. An area of concern is /host=*/server-config=*, > >>> where > >>> an expression might be irrelevant to the host, only resolving > >>> correctly > >>> on the server that is created using that server-config. That will > >>> need > >>> careful examination. > >>> > >>> A second one is how this data would be displayed with 'ls'. A > >>> separate > >>> additional column? Or replacing the current data? The answer to > >>> this > >>> might impact how it would be implemented server side. > >> > >> Keep in mind that ls is an example. There are other commands that > >> will > >> have to support this feature once it's implemented in one place. > >> Another > >> example is read-attribute command. The ability to resolve > >> expressions > >> elsewhere will be a natural expectation then. > >> So, it has to be thought of as a general features that can be > >> applied to > >> various cli commands. > >> > > > > Good point. Joe, we'd need a clear understanding of all the > > commands > > that would be affected. > > At this point, it's ls, read-attribute and commands handled by > GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, > -queue, -connection-factory, etc). > > The generic handler includes action read-resource (e.g. w/o other > optional arguments 'data-source read-resource --name=ExampleDS'), > which > is basically a formatted result of :read-resource. > > In general, it could be applied to any command displaying an > attribute > value to the user. > > Alexey > > > > >> IMO, the values returned should just be replaced with the resolved > >> ones > >> for display. Some commands support --verbose argument, in which > >> case > >> additional info is displayed in columns, there we could include > >> the > >> original value. > >> The output of the cli commands in some cases is parsed by scripts > >> or > >> other code, so keeping it simple will help there too. > >> > >>> The third aspect is the technical issue of how to make any > >>> 'resolve-expressions' param or CLI argument available in certain > >>> contexts and not in others. That's very likely solvable on the > >>> server > >>> side; not sure how difficult it would be in the CLI high-level > >>> command. > >> > >> Current tab-completion supports dependencies of command arguments > >> and > >> their values on the current context (connection to the controller, > >> standalone/domain mode, the presence of other arguments on the > >> line and > >> the values specified for them, etc). Technically, there shouldn't > >> be an > >> issue. > > > > Ok, good. > > > >> I am more concerned about how intuitive that will look like for > >> the user > >> in various contexts. > >> > > > > Yes, I think the UX aspects are the more significant ones. > > > >> Alexey > >> > >>> FYI, for others reading this, offline Joe pointed out there's a > >>> related > >>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. > >>> > >>> On 6/26/14, 5:41 AM, Edward Wertz wrote: > >>>> I'm looking into whether it's possible to automatically resolve > >>>> expressions when executing operations and commands in the CLI. > >>>> > >>>> >From my understanding, there are two variations of the problem. > >>>> > >>>> * Operations are server-side processes that are accessed > >>>> via ':' in the CLI and, currently, the CLI presents the > >>>> results returned as-is to the users. ex: ':read-resource' > >>>> > >>>> * Commands are processes that get manipulated by the CLI > >>>> before getting presented to users. ex: 'ls' > >>>> > >>>> I've been experimenting with adding arguments to the CLI > >>>> commands, like 'ls --resolve-expressions', and gotten it > >>>> working for the standalone and domain side of things. However, > >>>> I can't control the scope of the argument, so it's available in > >>>> situations that cannot accurately resolve expressions like the > >>>> 'profile=full' section of the domain tree. The results wouldn't > >>>> be reliable. > >>>> > >>>> The same problem would apply to adding parameters to the > >>>> server-side operations. The scope of the operations themselves > >>>> can be controlled, but not their parameters. An execution like > >>>> ':read-resource(recursive=true resolve-expressions=true)' can't > >>>> resolve expressions unless it's used against an actual server > >>>> or host, but the operation is available almost everywhere. > >>>> Again, the results wouldn't be reliable. > >>>> > >>>> I'm wondering if anyone can suggest a way to attack this > >>>> problem? There is already a > >>>> ':resolve-expression(expression=___)' operation, so users can > >>>> somewhat laboriously get the runtime values they want, but I > >>>> can't figure out a way to integrate the values into the > >>>> existing framework successfully. Other than creating entirely > >>>> new operations and commands, like 'ls-resolve' and > >>>> ':read-resource-resolve', which seems like an unsustainable way > >>>> to solve the problem. > >>>> > >>>> Thanks, > >>>> > >>>> Joe Wertz > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>>> > >>> > >>> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From kabir.khan at jboss.com Mon Jul 7 06:43:29 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 7 Jul 2014 11:43:29 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> Message-ID: <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> This has been merged to wildfly-core. To test the transformers against 7.1.x and EAP 6.0.x use -Djboss.test.transformers.subsystem.old. To get the EAP ones you will also need -Djboss.test.transformers.eap, as usual. On 6 Jul 2014, at 12:22, Kabir Khan wrote: > On 6 Jul 2014, at 11:45, Kabir Khan wrote: > >> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. >> >> All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x >> * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit > s/s commit/a commit >> * infinispan - something goes wrong in the > ? 7.1.x tests, I?ve not looked into it >> * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. >> >> These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. >> >> On 5 Jul 2014, at 10:57, Kabir Khan wrote: >> >>> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >>> >>> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jmesnil at redhat.com Mon Jul 7 10:46:47 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 7 Jul 2014 16:46:47 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API Message-ID: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> # Add Notification support to WildFly Management Tracked by https://issues.jboss.org/browse/WFLY-266 Use Cases --------- Notifications are an useful mechanism to observe management changes on WildFly servers. It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. The most expected use cases for WildFly notifications are: - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) Part 1: Notification Definition ------------------------------- A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. { "description" => "A manageable resource", "attributes" => { ... }, "operations" => { ... }, "notifications" => { "resource-added" => { ... } }, "children" => { ... } } The description of a notification will be composed of: * type - String - the type of notification (resource-added, server-stopped, etc.) * description - String - i18ned description of the notification * access-constraints - the RBAC access constraints that controls who can receive the notifications * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. Part 2: Emitting a notification ------------------------------- A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { // perform some actions ... context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); context.stepCompleted(); } The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. A Notification is a simple Java class that represents the notification. It is composed of: * type - String - the notification type * address - PathAddress - the address of the resource that emits the notification * message - String - the i18ned description of the message * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. Part 3: Global Resource Notifications ?????????????????? In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: * resource-added - when a resource is added, it emits a resource-added notification * resource-removed - when a resource is removed, it emits a resource-removed notification * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: * name - String - the name of the attribute * old-value - the detyped representation of the previous value of the attribute * new-value - the detyped representation of the new value Part 4: Notification Handlers ?????????????? Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. The source is a path address to handle notifications emitted by resources at this address. The NotificationHandler is an interface with a single handleNotification(Notification notification) method. The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. There is a similar unregister method to unregister a (handler, filter) To be useful, the source path address will have to accept wildcards for the address' values: * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. However until the resource is created, there is no way to register a notification listener on it without using a wildcard. If that proves problematic, we could change this approach with two alternatives: * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree?) I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... Part 5: Domain Notifications ?????????????? Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): * server-started * server-stopped * server-restarted * server-destroyed * server-killed Part 6: Integration with local JMX ????????????????? The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. Part 7: Integration with Remote Management API ??????????????????????? We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) The Management HTTP API will also be enhance to support notifications with its REST API. A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications Part 8: Integration with Remote JMX ????????????????? Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it). Part 9: Web Console UX improvement ????????????????? Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX. This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit. What do you think? jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From darran.lofthouse at jboss.com Mon Jul 7 11:11:23 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 07 Jul 2014 16:11:23 +0100 Subject: [wildfly-dev] Elytron Subsystem Message-ID: <53BAB89B.8070508@jboss.com> For anyone looking for information on a complete subsystem for Elytron we are not quite there yet, this e-mail is just to describe the location of an empty subsystem. I have just added the subsystem to it's own git repo here: - https://github.com/wildfly-security/elytron-subsystem If we need to track issues we can just use github for now. Regarding names I have just literally made up the names as I went along, any objects to names or the hierarchy ping me, send a pull request or raise an issue in the project. I have taken the decision to add support for creating a WildFly distribution that includes the Elytron subsystem in it's own repo - the distribution creation I expect only to be temporary until Elytron is included by default whilst the subsystem could live on in it's own repo long term. The repo that contains the build to assemble the distribution is here: - https://github.com/wildfly-security/elytron-distribution Note: For the moment the module definitions live in the distribution project and not the subsystem project, if in the future the build plug-in supports pulling in module definitions hopefully we can move them to the subsystem project. As the work on the WildFly core split continues these projects will also evolve further. SNAPSHOT dependencies are in place between these two project and the core wildfly-elytron project however I have deployed snapshots to nexus for each of them and will keep nexus up to date as additional changes are merged. Regards, Darran Lofthouse. From brian.stansberry at redhat.com Mon Jul 7 13:24:50 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 12:24:50 -0500 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> Message-ID: <53BAD7E2.8070203@redhat.com> Thanks for all this, Kabir. On 7/7/14, 5:43 AM, Kabir Khan wrote: > This has been merged to wildfly-core. > To test the transformers against 7.1.x and EAP 6.0.x use -Djboss.test.transformers.subsystem.old. > To get the EAP ones you will also need -Djboss.test.transformers.eap, as usual. > > On 6 Jul 2014, at 12:22, Kabir Khan wrote: > >> On 6 Jul 2014, at 11:45, Kabir Khan wrote: >> >>> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. >>> >>> All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x >>> * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit >> s/s commit/a commit >>> * infinispan - something goes wrong in the >> ? 7.1.x tests, I?ve not looked into it >>> * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. >>> >>> These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. >>> >>> On 5 Jul 2014, at 10:57, Kabir Khan wrote: >>> >>>> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >>>> >>>> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jul 7 13:44:52 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 12:44:52 -0500 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> Message-ID: <53BADC94.8060705@redhat.com> On 7/7/14, 12:36 AM, Edward Wertz wrote: > I've been thinking about the UX considerations over the last week. Generally there seem to be 3 basic situations involved. > > 1) There can be expressions in the result and the CLI can, in some manner, successfully resolve those expressions. This is dependent on the context that the command/operation is executed in, domain/standalone mode and the location in the configuration tree, but seems solvable. > > 2) There can be expressions in the result and the CLI can't resolve those expressions. For example if they're looking at a domain profile there's nothing to resolve against. > > 3) There won't be expressions in the result. There are lots of places in the CLI that would never return an expression. Which means the user would never need the argument/param. > > I think it's ok to hide the argument/param in situation 3. If expressions won't show up in the results there's no reason to have an option to resolve them really. It seems confusing to include it here. > I don't really follow this. For sure we won't include any --resolve-expressions param on commands where it isn't relevant, like 'cd' or something. If that's what you mean, that's fine. Otherwise I don't see what situation you're referring to. > The main question is what to do in situation 2, where there will be expressions in a result but it's impossible to resolve. Hiding the argument there seems like it could be confusing for people. They'll see an expression and if they know the argument is available elsewhere they'll wonder why they can't use it here. Frustration ensues. I think it would be better to have some type of error message explaining, somehow, that their location within the configuration tree doesn't allow for expressions to be resolved. I'm not sure what it should say though or how many of these situations exist. Any suggestions? > There are actually 2 variants of 2). One is the expression can't be resolved at all, and the other is it can be resolved, but the resolution is not meaningful because the resolutions is not occurring in a meaningful process. For example, in a managed domain, /profile=x/subsystem=y: max-size="${com.user.thingy.max-size:10} That can always be resolved, but the resolution is meaningless except on a server at /host=a/server=1/subsystem=y. A another example would be: enabled="${java.net.preferIPv4Stack}" where the system property might be set on a Host Controller, so it resolves, but again the value is meaningless because a server might have a different value for the system property. Because of this, simply trying to resolve the expression and handling a failure will not work. (Sounds like a bad approach anyway.) The tool is going to have to know in advance whether the resolution can be performed. That would either have to be statically built into the tool (bad) or the management API is going to have to indicate this for each resource. I see the latter being done by either adding a param to the API of read-resource-description for resources where it is allowed, or by creating a separate op registered only where allowed. Any error handling I want done client side, i.e. if you and Alexey decide to add --resolve-expressions everywhere and then put out a failure if it's not supported, I want the CLI to decide to fail based on the management metadata, not to count on the server side providing some expected failure if it's not supported. > The other question is whether there are situations where 1 and 2 actually overlap. Where some expressions are resolvable, but others are not. I haven't been able to figure out if that's an actual problem yet. > > I'm going to implement the ability to hide the argument for the 'ls' command this week, which Alexey pointed me towards on Friday, and look into how to add a param to the server-side operations. Once I have both working successfully I'll try to create a comprehensive list of all the applicable situations I can figure out. No sense in doing that before I can get it actually working for both the CLI commands and server-side operations first. > What's tricky is the subtree under host=*, excluding host=*/server=*. Everything in a domain not under host=* is cannot support resolution, and everything under host=*/server=* can. Places where this is an issue are: /host=*/system-property=* This resource is not relevant on the HC process; it drives the config of the server. So --resolve-expressions cannot be supported here. /host=*/path=* This one is a bit tricky, as the expression must be resolvable on the HC, so --resolve-expressions could work, but it's possible that the path gets passed to the server and gets resolved differently there. But I think that's an ok semantic. /host=*/interface=* Same as path. /host=*/server-config=*/system-property=* /host=*/server-config=*/interface=* /host=*/server-config=*/path=* None of these resources are relevant on the HC process; they drive the config of the server. So --resolve-expressions cannot be supported here. It can be supported on /host=*/server-config=* itself though. > Joe Wertz > > > > ----- Original Message ----- >> >> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>> Thanks, Joe, for looking into this. >>>>> >>>>> I'm curious what you've done so far with your 'ls >>>>> --resolve-expressions' >>>>> work. Did you use the existing >>>>> ':resolve-expression(expression=___)' low >>>>> level operation to process any expressions found in the >>>>> :read-resource >>>>> response? >>>>> >>>>> There are a few aspects of this I'd like to explore. >>>>> >>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>> contexts >>>>> and not others a good UX? Will users understand that? I'm >>>>> ambivalent >>>>> about that, and am interested in others' opinions. >>>>> >>>>> If it can work for a server and for anything under /host=*, then >>>>> I'm >>>>> ambivalent. Any restriction at all is unintuitive, but once the >>>>> user >>>>> learns that there is a restriction, that's a pretty >>>>> understandable one. >>>>> If it only works for a patchwork of stuff under /host=* then I'm >>>>> real >>>>> negative about it. An area of concern is /host=*/server-config=*, >>>>> where >>>>> an expression might be irrelevant to the host, only resolving >>>>> correctly >>>>> on the server that is created using that server-config. That will >>>>> need >>>>> careful examination. >>>>> >>>>> A second one is how this data would be displayed with 'ls'. A >>>>> separate >>>>> additional column? Or replacing the current data? The answer to >>>>> this >>>>> might impact how it would be implemented server side. >>>> >>>> Keep in mind that ls is an example. There are other commands that >>>> will >>>> have to support this feature once it's implemented in one place. >>>> Another >>>> example is read-attribute command. The ability to resolve >>>> expressions >>>> elsewhere will be a natural expectation then. >>>> So, it has to be thought of as a general features that can be >>>> applied to >>>> various cli commands. >>>> >>> >>> Good point. Joe, we'd need a clear understanding of all the >>> commands >>> that would be affected. >> >> At this point, it's ls, read-attribute and commands handled by >> GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, >> -queue, -connection-factory, etc). >> >> The generic handler includes action read-resource (e.g. w/o other >> optional arguments 'data-source read-resource --name=ExampleDS'), >> which >> is basically a formatted result of :read-resource. >> >> In general, it could be applied to any command displaying an >> attribute >> value to the user. >> >> Alexey >> >>> >>>> IMO, the values returned should just be replaced with the resolved >>>> ones >>>> for display. Some commands support --verbose argument, in which >>>> case >>>> additional info is displayed in columns, there we could include >>>> the >>>> original value. >>>> The output of the cli commands in some cases is parsed by scripts >>>> or >>>> other code, so keeping it simple will help there too. >>>> >>>>> The third aspect is the technical issue of how to make any >>>>> 'resolve-expressions' param or CLI argument available in certain >>>>> contexts and not in others. That's very likely solvable on the >>>>> server >>>>> side; not sure how difficult it would be in the CLI high-level >>>>> command. >>>> >>>> Current tab-completion supports dependencies of command arguments >>>> and >>>> their values on the current context (connection to the controller, >>>> standalone/domain mode, the presence of other arguments on the >>>> line and >>>> the values specified for them, etc). Technically, there shouldn't >>>> be an >>>> issue. >>> >>> Ok, good. >>> >>>> I am more concerned about how intuitive that will look like for >>>> the user >>>> in various contexts. >>>> >>> >>> Yes, I think the UX aspects are the more significant ones. >>> >>>> Alexey >>>> >>>>> FYI, for others reading this, offline Joe pointed out there's a >>>>> related >>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>> >>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>> I'm looking into whether it's possible to automatically resolve >>>>>> expressions when executing operations and commands in the CLI. >>>>>> >>>>>> >From my understanding, there are two variations of the problem. >>>>>> >>>>>> * Operations are server-side processes that are accessed >>>>>> via ':' in the CLI and, currently, the CLI presents the >>>>>> results returned as-is to the users. ex: ':read-resource' >>>>>> >>>>>> * Commands are processes that get manipulated by the CLI >>>>>> before getting presented to users. ex: 'ls' >>>>>> >>>>>> I've been experimenting with adding arguments to the CLI >>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>> working for the standalone and domain side of things. However, >>>>>> I can't control the scope of the argument, so it's available in >>>>>> situations that cannot accurately resolve expressions like the >>>>>> 'profile=full' section of the domain tree. The results wouldn't >>>>>> be reliable. >>>>>> >>>>>> The same problem would apply to adding parameters to the >>>>>> server-side operations. The scope of the operations themselves >>>>>> can be controlled, but not their parameters. An execution like >>>>>> ':read-resource(recursive=true resolve-expressions=true)' can't >>>>>> resolve expressions unless it's used against an actual server >>>>>> or host, but the operation is available almost everywhere. >>>>>> Again, the results wouldn't be reliable. >>>>>> >>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>> problem? There is already a >>>>>> ':resolve-expression(expression=___)' operation, so users can >>>>>> somewhat laboriously get the runtime values they want, but I >>>>>> can't figure out a way to integrate the values into the >>>>>> existing framework successfully. Other than creating entirely >>>>>> new operations and commands, like 'ls-resolve' and >>>>>> ':read-resource-resolve', which seems like an unsustainable way >>>>>> to solve the problem. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Joe Wertz >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From kabir.khan at jboss.com Mon Jul 7 14:25:40 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 7 Jul 2014 19:25:40 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: <53BAD7E2.8070203@redhat.com> References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> <53BAD7E2.8070203@redhat.com> Message-ID: I am looking at adding chained transformers to the core model transformers, i.e. DomainTransformers and the classes it uses. However, I?d like to get an extra eye on the sequence of versions in the chains used. https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/domain/controller/transformers/DomainTransformers.java#L57 contains the following versions and comments: //AS 7.1.2.Final / EAP 6.0.0 private static final ModelVersion VERSION_1_2 = ModelVersion.create(1, 2, 0); //AS 7.1.3.Final / EAP 6.0.1 private static final ModelVersion VERSION_1_3 = ModelVersion.create(1, 3, 0); //AS 7.2.0.Final / EAP 6.1.0 / EAP 6.1.1 private static final ModelVersion VERSION_1_4 = ModelVersion.create(1, 4, 0); // EAP 6.2.0 private static final ModelVersion VERSION_1_5 = ModelVersion.create(1, 5, 0); // EAP 6.3.0 private static final ModelVersion VERSION_1_6 = ModelVersion.create(1, 6, 0); //WF 8.0.0.Final private static final ModelVersion VERSION_2_0 = ModelVersion.create(2, 0, 0); //WF 8.1.0.Final private static final ModelVersion VERSION_2_1 = ModelVersion.create(2, 1, 0); Since some features were introduced in 1.6.0 and 1.5.0 for EAP which also exist in 2.0.0 (and probably 2.1.0) I guess that the chains should be: * For WildFly: 3.0.0->2.1.0->2.0.0 * For JBoss EAP and AS 7 releases: 3.0.0->1.6.0->1.5.0->1.4.0->1.3.0->1.2.0 To get good coverage of my refactoring, and of the chained transformers themselves, I am also reintroducing the core-model-test 7.1.2 test controller again. Once I am done with the chained transformers, I will look at pulling the legacy test controllers for both core-model-test and subsystem-test out into their own repository. That way they can be kept around without polluting the codebase. This should end the days of having 3 versions of WildFly/AS7 classes appear in the IDE classpath, which is annoying when you want to look up a class by name. On 7 Jul 2014, at 18:24, Brian Stansberry wrote: > Thanks for all this, Kabir. > > On 7/7/14, 5:43 AM, Kabir Khan wrote: >> This has been merged to wildfly-core. >> To test the transformers against 7.1.x and EAP 6.0.x use -Djboss.test.transformers.subsystem.old. >> To get the EAP ones you will also need -Djboss.test.transformers.eap, as usual. >> >> On 6 Jul 2014, at 12:22, Kabir Khan wrote: >> >>> On 6 Jul 2014, at 11:45, Kabir Khan wrote: >>> >>>> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. >>>> >>>> All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x >>>> * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit >>> s/s commit/a commit >>>> * infinispan - something goes wrong in the >>> ? 7.1.x tests, I?ve not looked into it >>>> * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. >>>> >>>> These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. >>>> >>>> On 5 Jul 2014, at 10:57, Kabir Khan wrote: >>>> >>>>> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >>>>> >>>>> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > -- > Brian Stansberry > 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 Mon Jul 7 14:59:01 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 13:59:01 -0500 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> <53BAD7E2.8070203@redhat.com> Message-ID: <53BAEDF5.3080507@redhat.com> On 7/7/14, 1:25 PM, Kabir Khan wrote: > I am looking at adding chained transformers to the core model transformers, i.e. DomainTransformers and the classes it uses. However, I?d like to get an extra eye on the sequence of versions in the chains used. > > https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/domain/controller/transformers/DomainTransformers.java#L57 contains the following versions and comments: > > //AS 7.1.2.Final / EAP 6.0.0 > private static final ModelVersion VERSION_1_2 = ModelVersion.create(1, 2, 0); > //AS 7.1.3.Final / EAP 6.0.1 > private static final ModelVersion VERSION_1_3 = ModelVersion.create(1, 3, 0); > //AS 7.2.0.Final / EAP 6.1.0 / EAP 6.1.1 > private static final ModelVersion VERSION_1_4 = ModelVersion.create(1, 4, 0); > // EAP 6.2.0 > private static final ModelVersion VERSION_1_5 = ModelVersion.create(1, 5, 0); > // EAP 6.3.0 > private static final ModelVersion VERSION_1_6 = ModelVersion.create(1, 6, 0); > //WF 8.0.0.Final > private static final ModelVersion VERSION_2_0 = ModelVersion.create(2, 0, 0); > //WF 8.1.0.Final > private static final ModelVersion VERSION_2_1 = ModelVersion.create(2, 1, 0); > > Since some features were introduced in 1.6.0 and 1.5.0 for EAP which also exist in 2.0.0 (and probably 2.1.0) I guess that the chains should be: > * For WildFly: 3.0.0->2.1.0->2.0.0 > * For JBoss EAP and AS 7 releases: 3.0.0->1.6.0->1.5.0->1.4.0->1.3.0->1.2.0 > Yes. > To get good coverage of my refactoring, and of the chained transformers themselves, I am also reintroducing the core-model-test 7.1.2 test controller again. Once I am done with the chained transformers, I will look at pulling the legacy test controllers for both core-model-test and subsystem-test out into their own repository. That way they can be kept around without polluting the codebase. This should end the days of having 3 versions of WildFly/AS7 classes appear in the IDE classpath, which is annoying when you want to look up a class by name. > :) > On 7 Jul 2014, at 18:24, Brian Stansberry wrote: > >> Thanks for all this, Kabir. >> >> On 7/7/14, 5:43 AM, Kabir Khan wrote: >>> This has been merged to wildfly-core. >>> To test the transformers against 7.1.x and EAP 6.0.x use -Djboss.test.transformers.subsystem.old. >>> To get the EAP ones you will also need -Djboss.test.transformers.eap, as usual. >>> >>> On 6 Jul 2014, at 12:22, Kabir Khan wrote: >>> >>>> On 6 Jul 2014, at 11:45, Kabir Khan wrote: >>>> >>>>> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. >>>>> >>>>> All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x >>>>> * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit >>>> s/s commit/a commit >>>>> * infinispan - something goes wrong in the >>>> ? 7.1.x tests, I?ve not looked into it >>>>> * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. >>>>> >>>>> These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. >>>>> >>>>> On 5 Jul 2014, at 10:57, Kabir Khan wrote: >>>>> >>>>>> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >>>>>> >>>>>> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> 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 Senior Principal Software Engineer JBoss by Red Hat From alexey.loubyansky at redhat.com Mon Jul 7 17:11:03 2014 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Mon, 07 Jul 2014 23:11:03 +0200 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53BADC94.8060705@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> Message-ID: <53BB0CE7.3000306@redhat.com> In case where the target environment against which the expressions have to be resolved is ambiguous, we could actually require an extra argument, logging a failure if it's missing. E.g. ls --resolve-expressions --against=host=h1/server=server1 We would still need to figure out where and what (target wise) we expect from the tool's point of view though and help to tab-complete it. On 07/07/2014 07:44 PM, Brian Stansberry wrote: > On 7/7/14, 12:36 AM, Edward Wertz wrote: >> I've been thinking about the UX considerations over the last week. Generally there seem to be 3 basic situations involved. >> >> 1) There can be expressions in the result and the CLI can, in some manner, successfully resolve those expressions. This is dependent on the context that the command/operation is executed in, domain/standalone mode and the location in the configuration tree, but seems solvable. >> >> 2) There can be expressions in the result and the CLI can't resolve those expressions. For example if they're looking at a domain profile there's nothing to resolve against. >> >> 3) There won't be expressions in the result. There are lots of places in the CLI that would never return an expression. Which means the user would never need the argument/param. >> >> I think it's ok to hide the argument/param in situation 3. If expressions won't show up in the results there's no reason to have an option to resolve them really. It seems confusing to include it here. >> > > I don't really follow this. For sure we won't include any > --resolve-expressions param on commands where it isn't relevant, like > 'cd' or something. If that's what you mean, that's fine. Otherwise I > don't see what situation you're referring to. > >> The main question is what to do in situation 2, where there will be expressions in a result but it's impossible to resolve. Hiding the argument there seems like it could be confusing for people. They'll see an expression and if they know the argument is available elsewhere they'll wonder why they can't use it here. Frustration ensues. I think it would be better to have some type of error message explaining, somehow, that their location within the configuration tree doesn't allow for expressions to be resolved. I'm not sure what it should say though or how many of these situations exist. Any suggestions? >> > > There are actually 2 variants of 2). One is the expression can't be > resolved at all, and the other is it can be resolved, but the resolution > is not meaningful because the resolutions is not occurring in a > meaningful process. > > For example, in a managed domain, /profile=x/subsystem=y: > > max-size="${com.user.thingy.max-size:10} > > That can always be resolved, but the resolution is meaningless except on > a server at /host=a/server=1/subsystem=y. > > A another example would be: > > enabled="${java.net.preferIPv4Stack}" > > where the system property might be set on a Host Controller, so it > resolves, but again the value is meaningless because a server might have > a different value for the system property. > > Because of this, simply trying to resolve the expression and handling a > failure will not work. (Sounds like a bad approach anyway.) The tool is > going to have to know in advance whether the resolution can be > performed. That would either have to be statically built into the tool > (bad) or the management API is going to have to indicate this for each > resource. I see the latter being done by either adding a param to the > API of read-resource-description for resources where it is allowed, or > by creating a separate op registered only where allowed. > > Any error handling I want done client side, i.e. if you and Alexey > decide to add --resolve-expressions everywhere and then put out a > failure if it's not supported, I want the CLI to decide to fail based on > the management metadata, not to count on the server side providing some > expected failure if it's not supported. > >> The other question is whether there are situations where 1 and 2 actually overlap. Where some expressions are resolvable, but others are not. I haven't been able to figure out if that's an actual problem yet. >> >> I'm going to implement the ability to hide the argument for the 'ls' command this week, which Alexey pointed me towards on Friday, and look into how to add a param to the server-side operations. Once I have both working successfully I'll try to create a comprehensive list of all the applicable situations I can figure out. No sense in doing that before I can get it actually working for both the CLI commands and server-side operations first. >> > > What's tricky is the subtree under host=*, excluding host=*/server=*. > Everything in a domain not under host=* is cannot support resolution, > and everything under host=*/server=* can. > > Places where this is an issue are: > > /host=*/system-property=* > > This resource is not relevant on the HC process; it drives the config of > the server. So --resolve-expressions cannot be supported here. > > /host=*/path=* > > This one is a bit tricky, as the expression must be resolvable on the > HC, so --resolve-expressions could work, but it's possible that the path > gets passed to the server and gets resolved differently there. But I > think that's an ok semantic. > > /host=*/interface=* > > Same as path. > > /host=*/server-config=*/system-property=* > /host=*/server-config=*/interface=* > /host=*/server-config=*/path=* > > None of these resources are relevant on the HC process; they drive the > config of the server. So --resolve-expressions cannot be supported here. > It can be supported on /host=*/server-config=* itself though. > >> Joe Wertz >> >> >> >> ----- Original Message ----- >>> >>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>>> Thanks, Joe, for looking into this. >>>>>> >>>>>> I'm curious what you've done so far with your 'ls >>>>>> --resolve-expressions' >>>>>> work. Did you use the existing >>>>>> ':resolve-expression(expression=___)' low >>>>>> level operation to process any expressions found in the >>>>>> :read-resource >>>>>> response? >>>>>> >>>>>> There are a few aspects of this I'd like to explore. >>>>>> >>>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>>> contexts >>>>>> and not others a good UX? Will users understand that? I'm >>>>>> ambivalent >>>>>> about that, and am interested in others' opinions. >>>>>> >>>>>> If it can work for a server and for anything under /host=*, then >>>>>> I'm >>>>>> ambivalent. Any restriction at all is unintuitive, but once the >>>>>> user >>>>>> learns that there is a restriction, that's a pretty >>>>>> understandable one. >>>>>> If it only works for a patchwork of stuff under /host=* then I'm >>>>>> real >>>>>> negative about it. An area of concern is /host=*/server-config=*, >>>>>> where >>>>>> an expression might be irrelevant to the host, only resolving >>>>>> correctly >>>>>> on the server that is created using that server-config. That will >>>>>> need >>>>>> careful examination. >>>>>> >>>>>> A second one is how this data would be displayed with 'ls'. A >>>>>> separate >>>>>> additional column? Or replacing the current data? The answer to >>>>>> this >>>>>> might impact how it would be implemented server side. >>>>> >>>>> Keep in mind that ls is an example. There are other commands that >>>>> will >>>>> have to support this feature once it's implemented in one place. >>>>> Another >>>>> example is read-attribute command. The ability to resolve >>>>> expressions >>>>> elsewhere will be a natural expectation then. >>>>> So, it has to be thought of as a general features that can be >>>>> applied to >>>>> various cli commands. >>>>> >>>> >>>> Good point. Joe, we'd need a clear understanding of all the >>>> commands >>>> that would be affected. >>> >>> At this point, it's ls, read-attribute and commands handled by >>> GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, >>> -queue, -connection-factory, etc). >>> >>> The generic handler includes action read-resource (e.g. w/o other >>> optional arguments 'data-source read-resource --name=ExampleDS'), >>> which >>> is basically a formatted result of :read-resource. >>> >>> In general, it could be applied to any command displaying an >>> attribute >>> value to the user. >>> >>> Alexey >>> >>>> >>>>> IMO, the values returned should just be replaced with the resolved >>>>> ones >>>>> for display. Some commands support --verbose argument, in which >>>>> case >>>>> additional info is displayed in columns, there we could include >>>>> the >>>>> original value. >>>>> The output of the cli commands in some cases is parsed by scripts >>>>> or >>>>> other code, so keeping it simple will help there too. >>>>> >>>>>> The third aspect is the technical issue of how to make any >>>>>> 'resolve-expressions' param or CLI argument available in certain >>>>>> contexts and not in others. That's very likely solvable on the >>>>>> server >>>>>> side; not sure how difficult it would be in the CLI high-level >>>>>> command. >>>>> >>>>> Current tab-completion supports dependencies of command arguments >>>>> and >>>>> their values on the current context (connection to the controller, >>>>> standalone/domain mode, the presence of other arguments on the >>>>> line and >>>>> the values specified for them, etc). Technically, there shouldn't >>>>> be an >>>>> issue. >>>> >>>> Ok, good. >>>> >>>>> I am more concerned about how intuitive that will look like for >>>>> the user >>>>> in various contexts. >>>>> >>>> >>>> Yes, I think the UX aspects are the more significant ones. >>>> >>>>> Alexey >>>>> >>>>>> FYI, for others reading this, offline Joe pointed out there's a >>>>>> related >>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>>> >>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>>> I'm looking into whether it's possible to automatically resolve >>>>>>> expressions when executing operations and commands in the CLI. >>>>>>> >>>>>>> >From my understanding, there are two variations of the problem. >>>>>>> >>>>>>> * Operations are server-side processes that are accessed >>>>>>> via ':' in the CLI and, currently, the CLI presents the >>>>>>> results returned as-is to the users. ex: ':read-resource' >>>>>>> >>>>>>> * Commands are processes that get manipulated by the CLI >>>>>>> before getting presented to users. ex: 'ls' >>>>>>> >>>>>>> I've been experimenting with adding arguments to the CLI >>>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>>> working for the standalone and domain side of things. However, >>>>>>> I can't control the scope of the argument, so it's available in >>>>>>> situations that cannot accurately resolve expressions like the >>>>>>> 'profile=full' section of the domain tree. The results wouldn't >>>>>>> be reliable. >>>>>>> >>>>>>> The same problem would apply to adding parameters to the >>>>>>> server-side operations. The scope of the operations themselves >>>>>>> can be controlled, but not their parameters. An execution like >>>>>>> ':read-resource(recursive=true resolve-expressions=true)' can't >>>>>>> resolve expressions unless it's used against an actual server >>>>>>> or host, but the operation is available almost everywhere. >>>>>>> Again, the results wouldn't be reliable. >>>>>>> >>>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>>> problem? There is already a >>>>>>> ':resolve-expression(expression=___)' operation, so users can >>>>>>> somewhat laboriously get the runtime values they want, but I >>>>>>> can't figure out a way to integrate the values into the >>>>>>> existing framework successfully. Other than creating entirely >>>>>>> new operations and commands, like 'ls-resolve' and >>>>>>> ':read-resource-resolve', which seems like an unsustainable way >>>>>>> to solve the problem. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Joe Wertz >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Mon Jul 7 17:26:43 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 16:26:43 -0500 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53BB0CE7.3000306@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <53BB0CE7.3000306@redhat.com> Message-ID: <53BB1093.8020200@redhat.com> Figuring out the target would need to be quite sophisticated; e.g. /profile=x/subsystem=y 1) Maps to host=/server=/subsystem=y with no intervening "profile=x". The various permutations of that kind of mapping would need to be understood. 2) and should be constrained to servers and in server groups that use profile=x. Perhaps the best way to do that is via some op on the root node of the domain and on the host root (for host.xml stuff) that takes a path address and replies with a data structure outlining how that path address translates into a server-level address. Might be a useful thing in general. On 7/7/14, 4:11 PM, Alexey Loubyansky wrote: > In case where the target environment against which the expressions have > to be resolved is ambiguous, we could actually require an extra > argument, logging a failure if it's missing. E.g. > > ls --resolve-expressions --against=host=h1/server=server1 > > We would still need to figure out where and what (target wise) we expect > from the tool's point of view though and help to tab-complete it. > > On 07/07/2014 07:44 PM, Brian Stansberry wrote: >> On 7/7/14, 12:36 AM, Edward Wertz wrote: >>> I've been thinking about the UX considerations over the last week. Generally there seem to be 3 basic situations involved. >>> >>> 1) There can be expressions in the result and the CLI can, in some manner, successfully resolve those expressions. This is dependent on the context that the command/operation is executed in, domain/standalone mode and the location in the configuration tree, but seems solvable. >>> >>> 2) There can be expressions in the result and the CLI can't resolve those expressions. For example if they're looking at a domain profile there's nothing to resolve against. >>> >>> 3) There won't be expressions in the result. There are lots of places in the CLI that would never return an expression. Which means the user would never need the argument/param. >>> >>> I think it's ok to hide the argument/param in situation 3. If expressions won't show up in the results there's no reason to have an option to resolve them really. It seems confusing to include it here. >>> >> >> I don't really follow this. For sure we won't include any >> --resolve-expressions param on commands where it isn't relevant, like >> 'cd' or something. If that's what you mean, that's fine. Otherwise I >> don't see what situation you're referring to. >> >>> The main question is what to do in situation 2, where there will be expressions in a result but it's impossible to resolve. Hiding the argument there seems like it could be confusing for people. They'll see an expression and if they know the argument is available elsewhere they'll wonder why they can't use it here. Frustration ensues. I think it would be better to have some type of error message explaining, somehow, that their location within the configuration tree doesn't allow for expressions to be resolved. I'm not sure what it should say though or how many of these situations exist. Any suggestions? >>> >> >> There are actually 2 variants of 2). One is the expression can't be >> resolved at all, and the other is it can be resolved, but the resolution >> is not meaningful because the resolutions is not occurring in a >> meaningful process. >> >> For example, in a managed domain, /profile=x/subsystem=y: >> >> max-size="${com.user.thingy.max-size:10} >> >> That can always be resolved, but the resolution is meaningless except on >> a server at /host=a/server=1/subsystem=y. >> >> A another example would be: >> >> enabled="${java.net.preferIPv4Stack}" >> >> where the system property might be set on a Host Controller, so it >> resolves, but again the value is meaningless because a server might have >> a different value for the system property. >> >> Because of this, simply trying to resolve the expression and handling a >> failure will not work. (Sounds like a bad approach anyway.) The tool is >> going to have to know in advance whether the resolution can be >> performed. That would either have to be statically built into the tool >> (bad) or the management API is going to have to indicate this for each >> resource. I see the latter being done by either adding a param to the >> API of read-resource-description for resources where it is allowed, or >> by creating a separate op registered only where allowed. >> >> Any error handling I want done client side, i.e. if you and Alexey >> decide to add --resolve-expressions everywhere and then put out a >> failure if it's not supported, I want the CLI to decide to fail based on >> the management metadata, not to count on the server side providing some >> expected failure if it's not supported. >> >>> The other question is whether there are situations where 1 and 2 actually overlap. Where some expressions are resolvable, but others are not. I haven't been able to figure out if that's an actual problem yet. >>> >>> I'm going to implement the ability to hide the argument for the 'ls' command this week, which Alexey pointed me towards on Friday, and look into how to add a param to the server-side operations. Once I have both working successfully I'll try to create a comprehensive list of all the applicable situations I can figure out. No sense in doing that before I can get it actually working for both the CLI commands and server-side operations first. >>> >> >> What's tricky is the subtree under host=*, excluding host=*/server=*. >> Everything in a domain not under host=* is cannot support resolution, >> and everything under host=*/server=* can. >> >> Places where this is an issue are: >> >> /host=*/system-property=* >> >> This resource is not relevant on the HC process; it drives the config of >> the server. So --resolve-expressions cannot be supported here. >> >> /host=*/path=* >> >> This one is a bit tricky, as the expression must be resolvable on the >> HC, so --resolve-expressions could work, but it's possible that the path >> gets passed to the server and gets resolved differently there. But I >> think that's an ok semantic. >> >> /host=*/interface=* >> >> Same as path. >> >> /host=*/server-config=*/system-property=* >> /host=*/server-config=*/interface=* >> /host=*/server-config=*/path=* >> >> None of these resources are relevant on the HC process; they drive the >> config of the server. So --resolve-expressions cannot be supported here. >> It can be supported on /host=*/server-config=* itself though. >> >>> Joe Wertz >>> >>> >>> >>> ----- Original Message ----- >>>> >>>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>>>> Thanks, Joe, for looking into this. >>>>>>> >>>>>>> I'm curious what you've done so far with your 'ls >>>>>>> --resolve-expressions' >>>>>>> work. Did you use the existing >>>>>>> ':resolve-expression(expression=___)' low >>>>>>> level operation to process any expressions found in the >>>>>>> :read-resource >>>>>>> response? >>>>>>> >>>>>>> There are a few aspects of this I'd like to explore. >>>>>>> >>>>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>>>> contexts >>>>>>> and not others a good UX? Will users understand that? I'm >>>>>>> ambivalent >>>>>>> about that, and am interested in others' opinions. >>>>>>> >>>>>>> If it can work for a server and for anything under /host=*, then >>>>>>> I'm >>>>>>> ambivalent. Any restriction at all is unintuitive, but once the >>>>>>> user >>>>>>> learns that there is a restriction, that's a pretty >>>>>>> understandable one. >>>>>>> If it only works for a patchwork of stuff under /host=* then I'm >>>>>>> real >>>>>>> negative about it. An area of concern is /host=*/server-config=*, >>>>>>> where >>>>>>> an expression might be irrelevant to the host, only resolving >>>>>>> correctly >>>>>>> on the server that is created using that server-config. That will >>>>>>> need >>>>>>> careful examination. >>>>>>> >>>>>>> A second one is how this data would be displayed with 'ls'. A >>>>>>> separate >>>>>>> additional column? Or replacing the current data? The answer to >>>>>>> this >>>>>>> might impact how it would be implemented server side. >>>>>> >>>>>> Keep in mind that ls is an example. There are other commands that >>>>>> will >>>>>> have to support this feature once it's implemented in one place. >>>>>> Another >>>>>> example is read-attribute command. The ability to resolve >>>>>> expressions >>>>>> elsewhere will be a natural expectation then. >>>>>> So, it has to be thought of as a general features that can be >>>>>> applied to >>>>>> various cli commands. >>>>>> >>>>> >>>>> Good point. Joe, we'd need a clear understanding of all the >>>>> commands >>>>> that would be affected. >>>> >>>> At this point, it's ls, read-attribute and commands handled by >>>> GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, >>>> -queue, -connection-factory, etc). >>>> >>>> The generic handler includes action read-resource (e.g. w/o other >>>> optional arguments 'data-source read-resource --name=ExampleDS'), >>>> which >>>> is basically a formatted result of :read-resource. >>>> >>>> In general, it could be applied to any command displaying an >>>> attribute >>>> value to the user. >>>> >>>> Alexey >>>> >>>>> >>>>>> IMO, the values returned should just be replaced with the resolved >>>>>> ones >>>>>> for display. Some commands support --verbose argument, in which >>>>>> case >>>>>> additional info is displayed in columns, there we could include >>>>>> the >>>>>> original value. >>>>>> The output of the cli commands in some cases is parsed by scripts >>>>>> or >>>>>> other code, so keeping it simple will help there too. >>>>>> >>>>>>> The third aspect is the technical issue of how to make any >>>>>>> 'resolve-expressions' param or CLI argument available in certain >>>>>>> contexts and not in others. That's very likely solvable on the >>>>>>> server >>>>>>> side; not sure how difficult it would be in the CLI high-level >>>>>>> command. >>>>>> >>>>>> Current tab-completion supports dependencies of command arguments >>>>>> and >>>>>> their values on the current context (connection to the controller, >>>>>> standalone/domain mode, the presence of other arguments on the >>>>>> line and >>>>>> the values specified for them, etc). Technically, there shouldn't >>>>>> be an >>>>>> issue. >>>>> >>>>> Ok, good. >>>>> >>>>>> I am more concerned about how intuitive that will look like for >>>>>> the user >>>>>> in various contexts. >>>>>> >>>>> >>>>> Yes, I think the UX aspects are the more significant ones. >>>>> >>>>>> Alexey >>>>>> >>>>>>> FYI, for others reading this, offline Joe pointed out there's a >>>>>>> related >>>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>>>> >>>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>>>> I'm looking into whether it's possible to automatically resolve >>>>>>>> expressions when executing operations and commands in the CLI. >>>>>>>> >>>>>>>> >From my understanding, there are two variations of the problem. >>>>>>>> >>>>>>>> * Operations are server-side processes that are accessed >>>>>>>> via ':' in the CLI and, currently, the CLI presents the >>>>>>>> results returned as-is to the users. ex: ':read-resource' >>>>>>>> >>>>>>>> * Commands are processes that get manipulated by the CLI >>>>>>>> before getting presented to users. ex: 'ls' >>>>>>>> >>>>>>>> I've been experimenting with adding arguments to the CLI >>>>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>>>> working for the standalone and domain side of things. However, >>>>>>>> I can't control the scope of the argument, so it's available in >>>>>>>> situations that cannot accurately resolve expressions like the >>>>>>>> 'profile=full' section of the domain tree. The results wouldn't >>>>>>>> be reliable. >>>>>>>> >>>>>>>> The same problem would apply to adding parameters to the >>>>>>>> server-side operations. The scope of the operations themselves >>>>>>>> can be controlled, but not their parameters. An execution like >>>>>>>> ':read-resource(recursive=true resolve-expressions=true)' can't >>>>>>>> resolve expressions unless it's used against an actual server >>>>>>>> or host, but the operation is available almost everywhere. >>>>>>>> Again, the results wouldn't be reliable. >>>>>>>> >>>>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>>>> problem? There is already a >>>>>>>> ':resolve-expression(expression=___)' operation, so users can >>>>>>>> somewhat laboriously get the runtime values they want, but I >>>>>>>> can't figure out a way to integrate the values into the >>>>>>>> existing framework successfully. Other than creating entirely >>>>>>>> new operations and commands, like 'ls-resolve' and >>>>>>>> ':read-resource-resolve', which seems like an unsustainable way >>>>>>>> to solve the problem. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joe Wertz >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jul 7 17:52:58 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 16:52:58 -0500 Subject: [wildfly-dev] Core and subsystem capabilities and requirements In-Reply-To: <19EFAAE4-D29A-47FF-AC25-4EBB8FB5D66D@redhat.com> References: <53A86FD7.6020502@redhat.com> <53A88599.1090003@redhat.com> <53A8947B.6010300@redhat.com> <19EFAAE4-D29A-47FF-AC25-4EBB8FB5D66D@redhat.com> Message-ID: <53BB16BA.5070207@redhat.com> On 7/3/14, 6:09 AM, Jeff Mesnil wrote: > > On 23 Jun 2014, at 22:56, Brian Stansberry wrote: > >> On 6/23/14, 2:52 PM, David M. Lloyd wrote: >>> On 06/23/2014 01:20 PM, Brian Stansberry wrote >>> ? I don't understand the purpose of binding capability identifiers to >>> subsystem identifiers. It seems plausible to have a subsystem provide, >>> for example, two capabilities now, but allow for a capability to be >>> implemented separately in the future. A concrete example would be the >>> way we ultimately moved Servlet from JBoss Web to Undertow. Ideally >>> we'd only ever depend on the capability, making subsystems completely >>> interchangeable. >>> >> >> See your question about uniqueness. Associating these with subsystems >> provides a form of namespacing; without that we'd have to come up with >> something else. >> >> It's a valid point that we don't have to use association with subsystems >> to provide this though. Any other suggestions? > > I?m not sure to understand the full scope of a capability. > Is it planned to use capabilities to let different subsystems provides the same set of features? > > For example, if we had capabilities in AS7, would have both the web subsystem (with JBoss Web) and undertow subsystem provided the same capability for Servlets (e.g. HTTP:SERVLET) or two different (UNDERTOW:SERVLET and JBOSS-WEB:SERVLET). > > In the first case, a subsystem needing to use Servlets would not need to know which subsystems provides it (but we have to ensure only one subsystem providing the capability is present). Ensuring that would be fairly simple by simply failing if the same capability is registered twice. > In the second case, the subsystem may chose the provider of the capability based on the capability name (and both can be present). > That could be interesting, but I think it will likely prove to not be something we can consistently support. There will be various rules that would make having two implementations of the same capability in the same runtime impossible. For example, the default connection factory in JMS 2.0, static registries that may be in different EE impls, etc. It's an interesting question whether we want to try to support that kind of thing. If we did there would need to be some way for the core to distinguish cases where only one provider of a capability is allowed, and if more than one is allowed to decide which one is the "default" to provide to other capabilities that weren't specific about who provided the capability. > I?m trying to figure out how I would name the messaging/JMS capability. At first glance, I am not sure I want to have the implementation (HORNETQ) be part of the capability name. I would prefer MESSAGING:JMS as it leaves open to change the JMS provider without affecting the capability to provide JMS. > I've updated that doc[1] to remove the requirement for including subsystem names in capability names, opting instead for simple namespacing by putting capabilities provided by the WildFly project under org.wildfly and mandating that other capability providers should use some rational namespace. The other doc where I'm trying to document the existing relationships[2] still has the SUBYSTEM_NAME:XYZ syntax, but that's just because the goal is to write down what's currently there in easily understood terms, not so much to create the new names. [1] https://community.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements [2] https://community.jboss.org/wiki/CoreAndSubsystemCapabilityAndRequirementListing > jeff > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jul 7 18:18:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 07 Jul 2014 17:18:13 -0500 Subject: [wildfly-dev] Wildfly provisioning tools and packaging format In-Reply-To: <53B6872F.705@jboss.com> References: <53B583C5.2010405@redhat.com> <53B6872F.705@jboss.com> Message-ID: <53BB1CA5.2060109@redhat.com> On 7/4/14, 5:51 AM, Darran Lofthouse wrote: > On 03/07/14 17:24, Stuart Douglas wrote: >> - The ability to customise the default config (not sure how this will >> work yet. A yuck solution would be xslt, but no one likes that. A nicer >> solution could be some kind of CLI script that is run on first boot). > > I think we should avoid XML manipulation as much as we can, really it is > just our chosen approach to persist the servers config - there is > nothing to stop us from changing to something different so persistence > format could even become something selected when creating a distribution. > > CLI commands could be very nice, the tool could even run the server in > admin mode to execute them and there have been various discussions on > running the server in the CLI or the CLI in the server. > > Could this also be a time to consider all configuration for the server > starting from CLI commands? I believe our current approach is an > evolution from where we used to just have fully defined configurations > in the codebase, assembling XML fragments enabled re-use. But now that > tooling to create a distribution is being considered again maybe 100% if > the configuration could come from defined management ops. > I like the idea of that a lot, but I'm concerned about it becoming a blocking priority. How adaptable is the stuff we already have for building configs for this usage, at least as a temporary solution? It has some of the basic elements, i.e. chunks of config associated with a name (one that often smells like a capability name) that get included if relevant. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From mlittle at redhat.com Mon Jul 7 11:57:37 2014 From: mlittle at redhat.com (Mark Little) Date: Mon, 7 Jul 2014 16:57:37 +0100 Subject: [wildfly-dev] Design Proposal: Server suspend/resume (AKA Graceful Shutdown) In-Reply-To: <53970460.1070900@redhat.com> References: <5396377F.80003@redhat.com> <22131731.5850.1402355055126.JavaMail.andrig@worklaptop.miller.org> <786BAC10-7BCE-47B8-BD87-968FE3FA4830@gmail.com> <5396D506.1030402@redhat.com> <31464906.7003.1402404649117.JavaMail.andrig@worklaptop.miller.org> <53970460.1070900@redhat.com> Message-ID: <31CC2816-8C5C-42CC-93C9-D16A11F83E96@redhat.com> Are we talking about really shutting down the app server or just suspending it, with a view to resuming activity later? The answer is different for these two scenarios. If we just consider the former, then since the transaction system can cope with a crash failure and ensure consistency, technically we could just SIGKILL (or equivalent) and let it tidy up later. Of course we don't want to do that because we could end up with heuristics etc. So I assume what we're trying to achieve is as graceful a shutdown as possible, reducing the number of log recoveries and amount of tidying up we need to do. We should wait for the transaction to terminate and prevent any new transactions from starting. There's a mechanism in Narayana which allows it to be started/stopped (or suspended/resumed) so that no new transactions can be created once the switch is flicked. Those inflight transactions that haven't been prepared *could* have setRollbackOnly called on them to force them to end quicker (potentially add a JBoss specific option to change the timeout value as well - speed up time, but that would be risky). Those transactions which get past prepare need to be waited upon, but obviously there's a possibility they could block. We have some interrupt code in the transaction reaper to help there and that should be sufficient. Using a combination of the above would help to shorten the time to wait in the case there are a lot of inflight transactions. Mark. On 10 Jun 2014, at 14:13, Stuart Douglas wrote: > >> >> If the transaction will never abort, can we force a rollback? This could lead to a never ending "graceful" shutdown. >> > > That is why we have a timeout, once the timeout is done the server will > shutdown anyway. We should probably have some kind of post-timeout > callback that gets invoked, so the TX subsystem could potentially take > some action. > > I'm not sure what the best action would be, the subsystem specific > details will be up to the team that maintains the subsystem. > > Stuart > >> Andy >> >>> Note also that suspending before an in-flight transaction has >>> prepared is probably safe since the resource will either: >>> >>> - rollback the branch if all connections to the db are closed (when >>> the system suspends); or >>> - rollback the branch if the XAResource timeout (set via the >>> XAResource.setTransactionTimeout()) value is reached >>> >>> [And since it was never prepared we have no log record for it so we >>> would not do anything on resume] >>> >>> Mike >>> >>>> IIRC the behavior for a tx timeout is a rollback, but we should >>>> check that. >>>> >>>>> On Jun 9, 2014, at 6:50 PM, Stuart Douglas >>>>> wrote: >>>>> >>>>> Something I forgot to mention is that we will need a switch to >>>>> turn this off, as there is a small but noticeable cost with >>>>> tracking in flight requests. >>>>> >>>>> >>>>>> On 9 Jun 2014, at 18:04, Andrig Miller >>>>>> wrote: >>>>>> >>>>>> What I am bringing up is more subsystem specific, but it might be >>>>>> valuable to think about. In case of the time out of the >>>>>> graceful shutdown, what behavior would we consider correct in >>>>>> terms of an inflight transaction? >>>>> It waits for the transaction to finish before shutting down. >>>>> >>>>> Stuart >>>>> >>>>>> Should it be a forced rollback, so that when the server is >>>>>> started back up, the transaction manager will not find in the >>>>>> log a transaction to be recovered? >>>>>> >>>>>> Or, should it be considered the same as a crashed state, where >>>>>> transactions should be recoverable, and the recover manager >>>>>> wouuld try to recover the transaction? >>>>>> >>>>>> I would lean towards the first, as this would be considered >>>>>> graceful by the administrator, and having a transaction be in a >>>>>> state where it would be recovered on a restart, doesn't seem >>>>>> graceful to me. >>>>>> >>>>>> Andy >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Stuart Douglas" >>>>>>> To: "Wildfly Dev mailing list" >>>>>>> Sent: Monday, June 9, 2014 4:38:55 PM >>>>>>> Subject: [wildfly-dev] Design Proposal: Server suspend/resume >>>>>>> (AKA Graceful Shutdown) >>>>>>> >>>>>>> Server suspend and resume is a feature that allows a running >>>>>>> server >>>>>>> to >>>>>>> gracefully finish of all running requests. The most common use >>>>>>> case >>>>>>> for >>>>>>> this is graceful shutdown, where you would like a server to >>>>>>> complete >>>>>>> all >>>>>>> running requests, reject any new ones, and then shut down, >>>>>>> however >>>>>>> there >>>>>>> are also plenty of other valid use cases (e.g. suspend the >>>>>>> server, >>>>>>> modify a data source or some other config, then resume). >>>>>>> >>>>>>> User View: >>>>>>> >>>>>>> For the users point of view two new operations will be added to >>>>>>> the >>>>>>> server: >>>>>>> >>>>>>> suspend(timeout) >>>>>>> resume() >>>>>>> >>>>>>> A runtime only attribute suspend-state (is this a good name?) >>>>>>> will >>>>>>> also >>>>>>> be added, that can take one of three possible values, RUNNING, >>>>>>> SUSPENDING, SUSPENDED. >>>>>>> >>>>>>> A timeout attribute will also be added to the shutdown >>>>>>> operation. If >>>>>>> this is present then the server will first be suspended, and the >>>>>>> server >>>>>>> will not shut down until either the suspend is successful or the >>>>>>> timeout >>>>>>> occurs. If no timeout parameter is passed to the operation then >>>>>>> a >>>>>>> normal >>>>>>> non-graceful shutdown will take place. >>>>>>> >>>>>>> In domain mode these operations will be added to both individual >>>>>>> server >>>>>>> and a complete server group. >>>>>>> >>>>>>> Implementation Details >>>>>>> >>>>>>> Suspend/resume operates on entry points to the server. Any >>>>>>> request >>>>>>> that >>>>>>> is currently running must not be affected by the suspend state, >>>>>>> however >>>>>>> any new request should be rejected. In general subsystems will >>>>>>> track >>>>>>> the >>>>>>> number of outstanding requests, and when this hits zero they are >>>>>>> considered suspended. >>>>>>> >>>>>>> We will introduce the notion of a global SuspendController, that >>>>>>> manages >>>>>>> the servers suspend state. All subsystems that wish to do a >>>>>>> graceful >>>>>>> shutdown register callback handlers with this controller. >>>>>>> >>>>>>> When the suspend() operation is invoked the controller will >>>>>>> invoke >>>>>>> all >>>>>>> these callbacks, letting the subsystem know that the server is >>>>>>> suspend, >>>>>>> and providing the subsystem with a SuspendContext object that >>>>>>> the >>>>>>> subsystem can then use to notify the controller that the suspend >>>>>>> is >>>>>>> complete. >>>>>>> >>>>>>> What the subsystem does when it receives a suspend command, and >>>>>>> when >>>>>>> it >>>>>>> considers itself suspended will vary, but in the common case it >>>>>>> will >>>>>>> immediatly start rejecting external requests (e.g. Undertow will >>>>>>> start >>>>>>> responding with a 503 to all new requests). The subsystem will >>>>>>> also >>>>>>> track the number of outstanding requests, and when this hits >>>>>>> zero >>>>>>> then >>>>>>> the subsystem will notify the controller that is has >>>>>>> successfully >>>>>>> suspended. >>>>>>> Some subsystems will obviously want to do other actions on >>>>>>> suspend, >>>>>>> e.g. >>>>>>> clustering will likely want to fail over, mod_cluster will >>>>>>> notify the >>>>>>> load balancer that the node is no longer available etc. In some >>>>>>> cases >>>>>>> we >>>>>>> may want to make this configurable to an extent (e.g. Undertow >>>>>>> could >>>>>>> be >>>>>>> configured to allow requests with an existing session, and not >>>>>>> consider >>>>>>> itself timed out until all sessions have either timed out or >>>>>>> been >>>>>>> invalidated, although this will obviously take a while). >>>>>>> >>>>>>> If anyone has any feedback let me know. In terms of >>>>>>> implementation my >>>>>>> basic plan is to get the core functionality and the Undertow >>>>>>> implementation into Wildfly, and then work with subsystem >>>>>>> authors to >>>>>>> implement subsystem specific functionality once the core is in >>>>>>> place. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The >>>>>>> >>>>>>> A timeout attribute will also be added to the shutdown command, >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Michael Musgrove >>> Transactions Team >>> e: mmusgrov at redhat.com >>> t: +44 191 243 0870 >>> >>> Registered in England and Wales under Company Registration No. >>> 03798903 >>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson >>> (US), Michael O'Neill(Ireland) >>> >>> _______________________________________________ >>> 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 --- Mark Little mlittle at redhat.com JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). From stuart.w.douglas at gmail.com Tue Jul 8 00:34:40 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 08 Jul 2014 14:34:40 +1000 Subject: [wildfly-dev] Design Proposal: Server suspend/resume (AKA Graceful Shutdown) In-Reply-To: <31CC2816-8C5C-42CC-93C9-D16A11F83E96@redhat.com> References: <5396377F.80003@redhat.com> <22131731.5850.1402355055126.JavaMail.andrig@worklaptop.miller.org> <786BAC10-7BCE-47B8-BD87-968FE3FA4830@gmail.com> <5396D506.1030402@redhat.com> <31464906.7003.1402404649117.JavaMail.andrig@worklaptop.miller.org> <53970460.1070900@redhat.com> <31CC2816-8C5C-42CC-93C9-D16A11F83E96@redhat.com> Message-ID: <53BB74E0.1000502@gmail.com> Mark Little wrote: > Are we talking about really shutting down the app server or just suspending it, with a view to resuming activity later? The answer is different for these two scenarios. > It could be either. > If we just consider the former, then since the transaction system can cope with a crash failure and ensure consistency, technically we could just SIGKILL (or equivalent) and let it tidy up later. Of course we don't want to do that because we could end up with heuristics etc. So I assume what we're trying to achieve is as graceful a shutdown as possible, reducing the number of log recoveries and amount of tidying up we need to do. In the case of a fully graceful shutdown the transaction subsystem should not have to do anything, new requests will be rejected at the connector (or entry point) level, and existing requests will continue to run as normal. The question is what to do if the requests don't finish within some timeout, in this case from a transactions point of view I think recovery is inevitable. > > We should wait for the transaction to terminate and prevent any new transactions from starting. There's a mechanism in Narayana which allows it to be started/stopped (or suspended/resumed) so that no new transactions can be created once the switch is flicked. Those inflight transactions that haven't been prepared *could* have setRollbackOnly called on them to force them to end quicker (potentially add a JBoss specific option to change the timeout value as well - speed up time, but that would be risky). Those transactions which get past prepare need to be waited upon, but obviously there's a possibility they could block. We have some interrupt code in the transaction reaper to help there and that should be sufficient. > > Using a combination of the above would help to shorten the time to wait in the case there are a lot of inflight transactions. The problem is that this should only happen after the initial timeout has been hit. Before that the server has to work as normal for all currently running requests. You could potentially do this after the initial timeout has been hit, but then you would need a second timeout to see if it has worked. This makes me think it is worth the extra complexity, especially given that it is not going to be very graceful anyway. Stuart > > Mark. > > > On 10 Jun 2014, at 14:13, Stuart Douglas wrote: > >>> If the transaction will never abort, can we force a rollback? This could lead to a never ending "graceful" shutdown. >>> >> That is why we have a timeout, once the timeout is done the server will >> shutdown anyway. We should probably have some kind of post-timeout >> callback that gets invoked, so the TX subsystem could potentially take >> some action. >> >> I'm not sure what the best action would be, the subsystem specific >> details will be up to the team that maintains the subsystem. >> >> Stuart >> >>> Andy >>> >>>> Note also that suspending before an in-flight transaction has >>>> prepared is probably safe since the resource will either: >>>> >>>> - rollback the branch if all connections to the db are closed (when >>>> the system suspends); or >>>> - rollback the branch if the XAResource timeout (set via the >>>> XAResource.setTransactionTimeout()) value is reached >>>> >>>> [And since it was never prepared we have no log record for it so we >>>> would not do anything on resume] >>>> >>>> Mike >>>> >>>>> IIRC the behavior for a tx timeout is a rollback, but we should >>>>> check that. >>>>> >>>>>> On Jun 9, 2014, at 6:50 PM, Stuart Douglas >>>>>> wrote: >>>>>> >>>>>> Something I forgot to mention is that we will need a switch to >>>>>> turn this off, as there is a small but noticeable cost with >>>>>> tracking in flight requests. >>>>>> >>>>>> >>>>>>> On 9 Jun 2014, at 18:04, Andrig Miller >>>>>>> wrote: >>>>>>> >>>>>>> What I am bringing up is more subsystem specific, but it might be >>>>>>> valuable to think about. In case of the time out of the >>>>>>> graceful shutdown, what behavior would we consider correct in >>>>>>> terms of an inflight transaction? >>>>>> It waits for the transaction to finish before shutting down. >>>>>> >>>>>> Stuart >>>>>> >>>>>>> Should it be a forced rollback, so that when the server is >>>>>>> started back up, the transaction manager will not find in the >>>>>>> log a transaction to be recovered? >>>>>>> >>>>>>> Or, should it be considered the same as a crashed state, where >>>>>>> transactions should be recoverable, and the recover manager >>>>>>> wouuld try to recover the transaction? >>>>>>> >>>>>>> I would lean towards the first, as this would be considered >>>>>>> graceful by the administrator, and having a transaction be in a >>>>>>> state where it would be recovered on a restart, doesn't seem >>>>>>> graceful to me. >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Stuart Douglas" >>>>>>>> To: "Wildfly Dev mailing list" >>>>>>>> Sent: Monday, June 9, 2014 4:38:55 PM >>>>>>>> Subject: [wildfly-dev] Design Proposal: Server suspend/resume >>>>>>>> (AKA Graceful Shutdown) >>>>>>>> >>>>>>>> Server suspend and resume is a feature that allows a running >>>>>>>> server >>>>>>>> to >>>>>>>> gracefully finish of all running requests. The most common use >>>>>>>> case >>>>>>>> for >>>>>>>> this is graceful shutdown, where you would like a server to >>>>>>>> complete >>>>>>>> all >>>>>>>> running requests, reject any new ones, and then shut down, >>>>>>>> however >>>>>>>> there >>>>>>>> are also plenty of other valid use cases (e.g. suspend the >>>>>>>> server, >>>>>>>> modify a data source or some other config, then resume). >>>>>>>> >>>>>>>> User View: >>>>>>>> >>>>>>>> For the users point of view two new operations will be added to >>>>>>>> the >>>>>>>> server: >>>>>>>> >>>>>>>> suspend(timeout) >>>>>>>> resume() >>>>>>>> >>>>>>>> A runtime only attribute suspend-state (is this a good name?) >>>>>>>> will >>>>>>>> also >>>>>>>> be added, that can take one of three possible values, RUNNING, >>>>>>>> SUSPENDING, SUSPENDED. >>>>>>>> >>>>>>>> A timeout attribute will also be added to the shutdown >>>>>>>> operation. If >>>>>>>> this is present then the server will first be suspended, and the >>>>>>>> server >>>>>>>> will not shut down until either the suspend is successful or the >>>>>>>> timeout >>>>>>>> occurs. If no timeout parameter is passed to the operation then >>>>>>>> a >>>>>>>> normal >>>>>>>> non-graceful shutdown will take place. >>>>>>>> >>>>>>>> In domain mode these operations will be added to both individual >>>>>>>> server >>>>>>>> and a complete server group. >>>>>>>> >>>>>>>> Implementation Details >>>>>>>> >>>>>>>> Suspend/resume operates on entry points to the server. Any >>>>>>>> request >>>>>>>> that >>>>>>>> is currently running must not be affected by the suspend state, >>>>>>>> however >>>>>>>> any new request should be rejected. In general subsystems will >>>>>>>> track >>>>>>>> the >>>>>>>> number of outstanding requests, and when this hits zero they are >>>>>>>> considered suspended. >>>>>>>> >>>>>>>> We will introduce the notion of a global SuspendController, that >>>>>>>> manages >>>>>>>> the servers suspend state. All subsystems that wish to do a >>>>>>>> graceful >>>>>>>> shutdown register callback handlers with this controller. >>>>>>>> >>>>>>>> When the suspend() operation is invoked the controller will >>>>>>>> invoke >>>>>>>> all >>>>>>>> these callbacks, letting the subsystem know that the server is >>>>>>>> suspend, >>>>>>>> and providing the subsystem with a SuspendContext object that >>>>>>>> the >>>>>>>> subsystem can then use to notify the controller that the suspend >>>>>>>> is >>>>>>>> complete. >>>>>>>> >>>>>>>> What the subsystem does when it receives a suspend command, and >>>>>>>> when >>>>>>>> it >>>>>>>> considers itself suspended will vary, but in the common case it >>>>>>>> will >>>>>>>> immediatly start rejecting external requests (e.g. Undertow will >>>>>>>> start >>>>>>>> responding with a 503 to all new requests). The subsystem will >>>>>>>> also >>>>>>>> track the number of outstanding requests, and when this hits >>>>>>>> zero >>>>>>>> then >>>>>>>> the subsystem will notify the controller that is has >>>>>>>> successfully >>>>>>>> suspended. >>>>>>>> Some subsystems will obviously want to do other actions on >>>>>>>> suspend, >>>>>>>> e.g. >>>>>>>> clustering will likely want to fail over, mod_cluster will >>>>>>>> notify the >>>>>>>> load balancer that the node is no longer available etc. In some >>>>>>>> cases >>>>>>>> we >>>>>>>> may want to make this configurable to an extent (e.g. Undertow >>>>>>>> could >>>>>>>> be >>>>>>>> configured to allow requests with an existing session, and not >>>>>>>> consider >>>>>>>> itself timed out until all sessions have either timed out or >>>>>>>> been >>>>>>>> invalidated, although this will obviously take a while). >>>>>>>> >>>>>>>> If anyone has any feedback let me know. In terms of >>>>>>>> implementation my >>>>>>>> basic plan is to get the core functionality and the Undertow >>>>>>>> implementation into Wildfly, and then work with subsystem >>>>>>>> authors to >>>>>>>> implement subsystem specific functionality once the core is in >>>>>>>> place. >>>>>>>> >>>>>>>> Stuart >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The >>>>>>>> >>>>>>>> A timeout attribute will also be added to the shutdown command, >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> -- >>>> Michael Musgrove >>>> Transactions Team >>>> e: mmusgrov at redhat.com >>>> t: +44 191 243 0870 >>>> >>>> Registered in England and Wales under Company Registration No. >>>> 03798903 >>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson >>>> (US), Michael O'Neill(Ireland) >>>> >>>> _______________________________________________ >>>> 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 > > --- > Mark Little > mlittle at redhat.com > > JBoss, by Red Hat > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. > Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). > > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tsegismo at redhat.com Tue Jul 8 04:45:40 2014 From: tsegismo at redhat.com (Thomas Segismont) Date: Tue, 08 Jul 2014 10:45:40 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> Message-ID: <53BBAFB4.5070806@redhat.com> Le 07/07/2014 16:46, Jeff Mesnil a ?crit : > Part 7: Integration with Remote Management API > ??????????????????????? > > We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient > > void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); > > The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) > > The Management HTTP API will also be enhance to support notifications with its REST API. > A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). > => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications Hi Jeff, Just to let you know, in the RHQ team we're also interested in this part, as our Wildfly monitoring is based on the HTTP management interface. I hope we'll be able to find a solution which works nicely with Javascript as well as Java clients. Regards, Thomas From ewertz at redhat.com Tue Jul 8 07:37:11 2014 From: ewertz at redhat.com (Edward Wertz) Date: Tue, 8 Jul 2014 07:37:11 -0400 (EDT) Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53BADC94.8060705@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> Message-ID: <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> ----- Original Message ----- > On 7/7/14, 12:36 AM, Edward Wertz wrote: > > I've been thinking about the UX considerations over the last week. > > Generally there seem to be 3 basic situations involved. > > > > 1) There can be expressions in the result and the CLI can, in some > > manner, successfully resolve those expressions. This is dependent > > on the context that the command/operation is executed in, > > domain/standalone mode and the location in the configuration tree, > > but seems solvable. > > > > 2) There can be expressions in the result and the CLI can't resolve > > those expressions. For example if they're looking at a domain > > profile there's nothing to resolve against. > > > > 3) There won't be expressions in the result. There are lots of > > places in the CLI that would never return an expression. Which > > means the user would never need the argument/param. > > > > I think it's ok to hide the argument/param in situation 3. If > > expressions won't show up in the results there's no reason to have > > an option to resolve them really. It seems confusing to include it > > here. > > > > I don't really follow this. For sure we won't include any > --resolve-expressions param on commands where it isn't relevant, like > 'cd' or something. If that's what you mean, that's fine. Otherwise I > don't see what situation you're referring to. > I'm thinking about this as it applies to the 'ls' command mostly, since it seems to be the broadest command and is available basically everywhere in the system tree. However, there are lots of locations in that tree where expressions simply would never exist aren't there? Would 'ls' on the root ever return an expression? That information is all version numbers and names and, I suspect, it's impossible to see an expression at that location. Thus no reason to have the ability to resolve one. I'm thinking it's ok to hide the argument in that situation. I'm not sure how widely this problem exists with other operations and commands though. ls might be somewhat unique in this regard since it's available throughout the entire CLI. > > The main question is what to do in situation 2, where there will be > > expressions in a result but it's impossible to resolve. Hiding the > > argument there seems like it could be confusing for people. > > They'll see an expression and if they know the argument is > > available elsewhere they'll wonder why they can't use it here. > > Frustration ensues. I think it would be better to have some type > > of error message explaining, somehow, that their location within > > the configuration tree doesn't allow for expressions to be > > resolved. I'm not sure what it should say though or how many of > > these situations exist. Any suggestions? > > > > There are actually 2 variants of 2). One is the expression can't be > resolved at all, and the other is it can be resolved, but the > resolution > is not meaningful because the resolutions is not occurring in a > meaningful process. > > For example, in a managed domain, /profile=x/subsystem=y: > > max-size="${com.user.thingy.max-size:10} > > That can always be resolved, but the resolution is meaningless except > on > a server at /host=a/server=1/subsystem=y. > > A another example would be: > > enabled="${java.net.preferIPv4Stack}" > > where the system property might be set on a Host Controller, so it > resolves, but again the value is meaningless because a server might > have > a different value for the system property. > > Because of this, simply trying to resolve the expression and handling > a > failure will not work. (Sounds like a bad approach anyway.) The tool > is > going to have to know in advance whether the resolution can be > performed. That would either have to be statically built into the > tool > (bad) or the management API is going to have to indicate this for > each > resource. I see the latter being done by either adding a param to the > API of read-resource-description for resources where it is allowed, > or > by creating a separate op registered only where allowed. > > Any error handling I want done client side, i.e. if you and Alexey > decide to add --resolve-expressions everywhere and then put out a > failure if it's not supported, I want the CLI to decide to fail based > on > the management metadata, not to count on the server side providing > some > expected failure if it's not supported. > I definitely agree. I didn't make that clear, but it was always my intention for it to be a pre-determined failure message. I lumped the 'meaningless' resolve in with 'no resolve', and thought the CLI should be able to determine based on the location in the tree whether a resolve makes any sense. If it doesn't, an error message would stop the command from executing and tell the user it's not possible to resolve expressions at this location. > > The other question is whether there are situations where 1 and 2 > > actually overlap. Where some expressions are resolvable, but > > others are not. I haven't been able to figure out if that's an > > actual problem yet. > > > > I'm going to implement the ability to hide the argument for the > > 'ls' command this week, which Alexey pointed me towards on Friday, > > and look into how to add a param to the server-side operations. > > Once I have both working successfully I'll try to create a > > comprehensive list of all the applicable situations I can figure > > out. No sense in doing that before I can get it actually working > > for both the CLI commands and server-side operations first. > > > > What's tricky is the subtree under host=*, excluding host=*/server=*. > Everything in a domain not under host=* is cannot support resolution, > and everything under host=*/server=* can. > > Places where this is an issue are: > > /host=*/system-property=* > > This resource is not relevant on the HC process; it drives the config > of > the server. So --resolve-expressions cannot be supported here. > > /host=*/path=* > > This one is a bit tricky, as the expression must be resolvable on the > HC, so --resolve-expressions could work, but it's possible that the > path > gets passed to the server and gets resolved differently there. But I > think that's an ok semantic. > > /host=*/interface=* > > Same as path. > > /host=*/server-config=*/system-property=* > /host=*/server-config=*/interface=* > /host=*/server-config=*/path=* > > None of these resources are relevant on the HC process; they drive > the > config of the server. So --resolve-expressions cannot be supported > here. > It can be supported on /host=*/server-config=* itself though. > > > Joe Wertz > > > > > > > > ----- Original Message ----- > >> > >> On 06/27/2014 04:45 PM, Brian Stansberry wrote: > >>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: > >>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: > >>>>> Thanks, Joe, for looking into this. > >>>>> > >>>>> I'm curious what you've done so far with your 'ls > >>>>> --resolve-expressions' > >>>>> work. Did you use the existing > >>>>> ':resolve-expression(expression=___)' low > >>>>> level operation to process any expressions found in the > >>>>> :read-resource > >>>>> response? > >>>>> > >>>>> There are a few aspects of this I'd like to explore. > >>>>> > >>>>> One is the UX one. Is allowing 'resolve-expressions' in some > >>>>> contexts > >>>>> and not others a good UX? Will users understand that? I'm > >>>>> ambivalent > >>>>> about that, and am interested in others' opinions. > >>>>> > >>>>> If it can work for a server and for anything under /host=*, > >>>>> then > >>>>> I'm > >>>>> ambivalent. Any restriction at all is unintuitive, but once the > >>>>> user > >>>>> learns that there is a restriction, that's a pretty > >>>>> understandable one. > >>>>> If it only works for a patchwork of stuff under /host=* then > >>>>> I'm > >>>>> real > >>>>> negative about it. An area of concern is > >>>>> /host=*/server-config=*, > >>>>> where > >>>>> an expression might be irrelevant to the host, only resolving > >>>>> correctly > >>>>> on the server that is created using that server-config. That > >>>>> will > >>>>> need > >>>>> careful examination. > >>>>> > >>>>> A second one is how this data would be displayed with 'ls'. A > >>>>> separate > >>>>> additional column? Or replacing the current data? The answer to > >>>>> this > >>>>> might impact how it would be implemented server side. > >>>> > >>>> Keep in mind that ls is an example. There are other commands > >>>> that > >>>> will > >>>> have to support this feature once it's implemented in one place. > >>>> Another > >>>> example is read-attribute command. The ability to resolve > >>>> expressions > >>>> elsewhere will be a natural expectation then. > >>>> So, it has to be thought of as a general features that can be > >>>> applied to > >>>> various cli commands. > >>>> > >>> > >>> Good point. Joe, we'd need a clear understanding of all the > >>> commands > >>> that would be affected. > >> > >> At this point, it's ls, read-attribute and commands handled by > >> GenericTypeOperationHandler (which means [xa-]data-source, > >> jms-topic, > >> -queue, -connection-factory, etc). > >> > >> The generic handler includes action read-resource (e.g. w/o other > >> optional arguments 'data-source read-resource --name=ExampleDS'), > >> which > >> is basically a formatted result of :read-resource. > >> > >> In general, it could be applied to any command displaying an > >> attribute > >> value to the user. > >> > >> Alexey > >> > >>> > >>>> IMO, the values returned should just be replaced with the > >>>> resolved > >>>> ones > >>>> for display. Some commands support --verbose argument, in which > >>>> case > >>>> additional info is displayed in columns, there we could include > >>>> the > >>>> original value. > >>>> The output of the cli commands in some cases is parsed by > >>>> scripts > >>>> or > >>>> other code, so keeping it simple will help there too. > >>>> > >>>>> The third aspect is the technical issue of how to make any > >>>>> 'resolve-expressions' param or CLI argument available in > >>>>> certain > >>>>> contexts and not in others. That's very likely solvable on the > >>>>> server > >>>>> side; not sure how difficult it would be in the CLI high-level > >>>>> command. > >>>> > >>>> Current tab-completion supports dependencies of command > >>>> arguments > >>>> and > >>>> their values on the current context (connection to the > >>>> controller, > >>>> standalone/domain mode, the presence of other arguments on the > >>>> line and > >>>> the values specified for them, etc). Technically, there > >>>> shouldn't > >>>> be an > >>>> issue. > >>> > >>> Ok, good. > >>> > >>>> I am more concerned about how intuitive that will look like for > >>>> the user > >>>> in various contexts. > >>>> > >>> > >>> Yes, I think the UX aspects are the more significant ones. > >>> > >>>> Alexey > >>>> > >>>>> FYI, for others reading this, offline Joe pointed out there's a > >>>>> related > >>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. > >>>>> > >>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: > >>>>>> I'm looking into whether it's possible to automatically > >>>>>> resolve > >>>>>> expressions when executing operations and commands in the CLI. > >>>>>> > >>>>>> >From my understanding, there are two variations of the > >>>>>> >problem. > >>>>>> > >>>>>> * Operations are server-side processes that are accessed > >>>>>> via ':' in the CLI and, currently, the CLI presents the > >>>>>> results returned as-is to the users. ex: > >>>>>> ':read-resource' > >>>>>> > >>>>>> * Commands are processes that get manipulated by the CLI > >>>>>> before getting presented to users. ex: 'ls' > >>>>>> > >>>>>> I've been experimenting with adding arguments to the CLI > >>>>>> commands, like 'ls --resolve-expressions', and gotten it > >>>>>> working for the standalone and domain side of things. However, > >>>>>> I can't control the scope of the argument, so it's available > >>>>>> in > >>>>>> situations that cannot accurately resolve expressions like the > >>>>>> 'profile=full' section of the domain tree. The results > >>>>>> wouldn't > >>>>>> be reliable. > >>>>>> > >>>>>> The same problem would apply to adding parameters to the > >>>>>> server-side operations. The scope of the operations themselves > >>>>>> can be controlled, but not their parameters. An execution like > >>>>>> ':read-resource(recursive=true resolve-expressions=true)' > >>>>>> can't > >>>>>> resolve expressions unless it's used against an actual server > >>>>>> or host, but the operation is available almost everywhere. > >>>>>> Again, the results wouldn't be reliable. > >>>>>> > >>>>>> I'm wondering if anyone can suggest a way to attack this > >>>>>> problem? There is already a > >>>>>> ':resolve-expression(expression=___)' operation, so users can > >>>>>> somewhat laboriously get the runtime values they want, but I > >>>>>> can't figure out a way to integrate the values into the > >>>>>> existing framework successfully. Other than creating entirely > >>>>>> new operations and commands, like 'ls-resolve' and > >>>>>> ':read-resource-resolve', which seems like an unsustainable > >>>>>> way > >>>>>> to solve the problem. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Joe Wertz > >>>>>> _______________________________________________ > >>>>>> wildfly-dev mailing list > >>>>>> wildfly-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>>> > >>> > >>> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > 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 Tue Jul 8 09:27:23 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 08 Jul 2014 08:27:23 -0500 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> Message-ID: <53BBF1BB.5040704@redhat.com> On 7/8/14, 6:37 AM, Edward Wertz wrote: > > > ----- Original Message ----- >> On 7/7/14, 12:36 AM, Edward Wertz wrote: >>> I've been thinking about the UX considerations over the last week. >>> Generally there seem to be 3 basic situations involved. >>> >>> 1) There can be expressions in the result and the CLI can, in some >>> manner, successfully resolve those expressions. This is dependent >>> on the context that the command/operation is executed in, >>> domain/standalone mode and the location in the configuration tree, >>> but seems solvable. >>> >>> 2) There can be expressions in the result and the CLI can't resolve >>> those expressions. For example if they're looking at a domain >>> profile there's nothing to resolve against. >>> >>> 3) There won't be expressions in the result. There are lots of >>> places in the CLI that would never return an expression. Which >>> means the user would never need the argument/param. >>> >>> I think it's ok to hide the argument/param in situation 3. If >>> expressions won't show up in the results there's no reason to have >>> an option to resolve them really. It seems confusing to include it >>> here. >>> >> >> I don't really follow this. For sure we won't include any >> --resolve-expressions param on commands where it isn't relevant, like >> 'cd' or something. If that's what you mean, that's fine. Otherwise I >> don't see what situation you're referring to. >> > > I'm thinking about this as it applies to the 'ls' command mostly, since it seems to be the broadest command and is available basically everywhere in the system tree. However, there are lots of locations in that tree where expressions simply would never exist aren't there? Would 'ls' on the root ever return an expression? That information is all version numbers and names and, I suspect, it's impossible to see an expression at that location. Thus no reason to have the ability to resolve one. I'm thinking it's ok to hide the argument in that situation. I'm not sure how widely this problem exists with other operations and commands though. ls might be somewhat unique in this regard since it's available throughout the entire CLI. > Ok, I don't think we should worry about this. IMHO it would be confusing, since it would cause the --resolve-expressions param to not appear in locations where the user would have no intuitive understanding as to why not. My assumption here is if --resolve-expressions were set, attributes that didn't have expressions would be displayed as they are now. So if a user set the param where there were no actual expressions, there's no harm. >>> The main question is what to do in situation 2, where there will be >>> expressions in a result but it's impossible to resolve. Hiding the >>> argument there seems like it could be confusing for people. >>> They'll see an expression and if they know the argument is >>> available elsewhere they'll wonder why they can't use it here. >>> Frustration ensues. I think it would be better to have some type >>> of error message explaining, somehow, that their location within >>> the configuration tree doesn't allow for expressions to be >>> resolved. I'm not sure what it should say though or how many of >>> these situations exist. Any suggestions? >>> >> >> There are actually 2 variants of 2). One is the expression can't be >> resolved at all, and the other is it can be resolved, but the >> resolution >> is not meaningful because the resolutions is not occurring in a >> meaningful process. >> >> For example, in a managed domain, /profile=x/subsystem=y: >> >> max-size="${com.user.thingy.max-size:10} >> >> That can always be resolved, but the resolution is meaningless except >> on >> a server at /host=a/server=1/subsystem=y. >> >> A another example would be: >> >> enabled="${java.net.preferIPv4Stack}" >> >> where the system property might be set on a Host Controller, so it >> resolves, but again the value is meaningless because a server might >> have >> a different value for the system property. >> >> Because of this, simply trying to resolve the expression and handling >> a >> failure will not work. (Sounds like a bad approach anyway.) The tool >> is >> going to have to know in advance whether the resolution can be >> performed. That would either have to be statically built into the >> tool >> (bad) or the management API is going to have to indicate this for >> each >> resource. I see the latter being done by either adding a param to the >> API of read-resource-description for resources where it is allowed, >> or >> by creating a separate op registered only where allowed. >> >> Any error handling I want done client side, i.e. if you and Alexey >> decide to add --resolve-expressions everywhere and then put out a >> failure if it's not supported, I want the CLI to decide to fail based >> on >> the management metadata, not to count on the server side providing >> some >> expected failure if it's not supported. >> > > I definitely agree. I didn't make that clear, but it was always my intention for it to be a pre-determined failure message. I lumped the 'meaningless' resolve in with 'no resolve', and thought the CLI should be able to determine based on the location in the tree whether a resolve makes any sense. If it doesn't, an error message would stop the command from executing and tell the user it's not possible to resolve expressions at this location. > Ok, good. For the CLI to determine if the command is present it will need to do a :read-resource-description call against the current resource address. >>> The other question is whether there are situations where 1 and 2 >>> actually overlap. Where some expressions are resolvable, but >>> others are not. I haven't been able to figure out if that's an >>> actual problem yet. >>> >>> I'm going to implement the ability to hide the argument for the >>> 'ls' command this week, which Alexey pointed me towards on Friday, >>> and look into how to add a param to the server-side operations. >>> Once I have both working successfully I'll try to create a >>> comprehensive list of all the applicable situations I can figure >>> out. No sense in doing that before I can get it actually working >>> for both the CLI commands and server-side operations first. >>> >> >> What's tricky is the subtree under host=*, excluding host=*/server=*. >> Everything in a domain not under host=* is cannot support resolution, >> and everything under host=*/server=* can. >> >> Places where this is an issue are: >> >> /host=*/system-property=* >> >> This resource is not relevant on the HC process; it drives the config >> of >> the server. So --resolve-expressions cannot be supported here. >> >> /host=*/path=* >> >> This one is a bit tricky, as the expression must be resolvable on the >> HC, so --resolve-expressions could work, but it's possible that the >> path >> gets passed to the server and gets resolved differently there. But I >> think that's an ok semantic. >> >> /host=*/interface=* >> >> Same as path. >> >> /host=*/server-config=*/system-property=* >> /host=*/server-config=*/interface=* >> /host=*/server-config=*/path=* >> >> None of these resources are relevant on the HC process; they drive >> the >> config of the server. So --resolve-expressions cannot be supported >> here. >> It can be supported on /host=*/server-config=* itself though. >> >>> Joe Wertz >>> >>> >>> >>> ----- Original Message ----- >>>> >>>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>>>> Thanks, Joe, for looking into this. >>>>>>> >>>>>>> I'm curious what you've done so far with your 'ls >>>>>>> --resolve-expressions' >>>>>>> work. Did you use the existing >>>>>>> ':resolve-expression(expression=___)' low >>>>>>> level operation to process any expressions found in the >>>>>>> :read-resource >>>>>>> response? >>>>>>> >>>>>>> There are a few aspects of this I'd like to explore. >>>>>>> >>>>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>>>> contexts >>>>>>> and not others a good UX? Will users understand that? I'm >>>>>>> ambivalent >>>>>>> about that, and am interested in others' opinions. >>>>>>> >>>>>>> If it can work for a server and for anything under /host=*, >>>>>>> then >>>>>>> I'm >>>>>>> ambivalent. Any restriction at all is unintuitive, but once the >>>>>>> user >>>>>>> learns that there is a restriction, that's a pretty >>>>>>> understandable one. >>>>>>> If it only works for a patchwork of stuff under /host=* then >>>>>>> I'm >>>>>>> real >>>>>>> negative about it. An area of concern is >>>>>>> /host=*/server-config=*, >>>>>>> where >>>>>>> an expression might be irrelevant to the host, only resolving >>>>>>> correctly >>>>>>> on the server that is created using that server-config. That >>>>>>> will >>>>>>> need >>>>>>> careful examination. >>>>>>> >>>>>>> A second one is how this data would be displayed with 'ls'. A >>>>>>> separate >>>>>>> additional column? Or replacing the current data? The answer to >>>>>>> this >>>>>>> might impact how it would be implemented server side. >>>>>> >>>>>> Keep in mind that ls is an example. There are other commands >>>>>> that >>>>>> will >>>>>> have to support this feature once it's implemented in one place. >>>>>> Another >>>>>> example is read-attribute command. The ability to resolve >>>>>> expressions >>>>>> elsewhere will be a natural expectation then. >>>>>> So, it has to be thought of as a general features that can be >>>>>> applied to >>>>>> various cli commands. >>>>>> >>>>> >>>>> Good point. Joe, we'd need a clear understanding of all the >>>>> commands >>>>> that would be affected. >>>> >>>> At this point, it's ls, read-attribute and commands handled by >>>> GenericTypeOperationHandler (which means [xa-]data-source, >>>> jms-topic, >>>> -queue, -connection-factory, etc). >>>> >>>> The generic handler includes action read-resource (e.g. w/o other >>>> optional arguments 'data-source read-resource --name=ExampleDS'), >>>> which >>>> is basically a formatted result of :read-resource. >>>> >>>> In general, it could be applied to any command displaying an >>>> attribute >>>> value to the user. >>>> >>>> Alexey >>>> >>>>> >>>>>> IMO, the values returned should just be replaced with the >>>>>> resolved >>>>>> ones >>>>>> for display. Some commands support --verbose argument, in which >>>>>> case >>>>>> additional info is displayed in columns, there we could include >>>>>> the >>>>>> original value. >>>>>> The output of the cli commands in some cases is parsed by >>>>>> scripts >>>>>> or >>>>>> other code, so keeping it simple will help there too. >>>>>> >>>>>>> The third aspect is the technical issue of how to make any >>>>>>> 'resolve-expressions' param or CLI argument available in >>>>>>> certain >>>>>>> contexts and not in others. That's very likely solvable on the >>>>>>> server >>>>>>> side; not sure how difficult it would be in the CLI high-level >>>>>>> command. >>>>>> >>>>>> Current tab-completion supports dependencies of command >>>>>> arguments >>>>>> and >>>>>> their values on the current context (connection to the >>>>>> controller, >>>>>> standalone/domain mode, the presence of other arguments on the >>>>>> line and >>>>>> the values specified for them, etc). Technically, there >>>>>> shouldn't >>>>>> be an >>>>>> issue. >>>>> >>>>> Ok, good. >>>>> >>>>>> I am more concerned about how intuitive that will look like for >>>>>> the user >>>>>> in various contexts. >>>>>> >>>>> >>>>> Yes, I think the UX aspects are the more significant ones. >>>>> >>>>>> Alexey >>>>>> >>>>>>> FYI, for others reading this, offline Joe pointed out there's a >>>>>>> related >>>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>>>> >>>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>>>> I'm looking into whether it's possible to automatically >>>>>>>> resolve >>>>>>>> expressions when executing operations and commands in the CLI. >>>>>>>> >>>>>>>> >From my understanding, there are two variations of the >>>>>>>>> problem. >>>>>>>> >>>>>>>> * Operations are server-side processes that are accessed >>>>>>>> via ':' in the CLI and, currently, the CLI presents the >>>>>>>> results returned as-is to the users. ex: >>>>>>>> ':read-resource' >>>>>>>> >>>>>>>> * Commands are processes that get manipulated by the CLI >>>>>>>> before getting presented to users. ex: 'ls' >>>>>>>> >>>>>>>> I've been experimenting with adding arguments to the CLI >>>>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>>>> working for the standalone and domain side of things. However, >>>>>>>> I can't control the scope of the argument, so it's available >>>>>>>> in >>>>>>>> situations that cannot accurately resolve expressions like the >>>>>>>> 'profile=full' section of the domain tree. The results >>>>>>>> wouldn't >>>>>>>> be reliable. >>>>>>>> >>>>>>>> The same problem would apply to adding parameters to the >>>>>>>> server-side operations. The scope of the operations themselves >>>>>>>> can be controlled, but not their parameters. An execution like >>>>>>>> ':read-resource(recursive=true resolve-expressions=true)' >>>>>>>> can't >>>>>>>> resolve expressions unless it's used against an actual server >>>>>>>> or host, but the operation is available almost everywhere. >>>>>>>> Again, the results wouldn't be reliable. >>>>>>>> >>>>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>>>> problem? There is already a >>>>>>>> ':resolve-expression(expression=___)' operation, so users can >>>>>>>> somewhat laboriously get the runtime values they want, but I >>>>>>>> can't figure out a way to integrate the values into the >>>>>>>> existing framework successfully. Other than creating entirely >>>>>>>> new operations and commands, like 'ls-resolve' and >>>>>>>> ':read-resource-resolve', which seems like an unsustainable >>>>>>>> way >>>>>>>> to solve the problem. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Joe Wertz -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From alexey.loubyansky at redhat.com Tue Jul 8 10:39:09 2014 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 08 Jul 2014 16:39:09 +0200 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53BBF1BB.5040704@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AC3CBC.6050403@redhat.com> <53AD715C.8000505@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> Message-ID: <53BC028D.7050904@redhat.com> On 07/08/2014 03:27 PM, Brian Stansberry wrote: > On 7/8/14, 6:37 AM, Edward Wertz wrote: >> >> >> ----- Original Message ----- >>> On 7/7/14, 12:36 AM, Edward Wertz wrote: >>>> I've been thinking about the UX considerations over the last week. >>>> Generally there seem to be 3 basic situations involved. >>>> >>>> 1) There can be expressions in the result and the CLI can, in some >>>> manner, successfully resolve those expressions. This is dependent >>>> on the context that the command/operation is executed in, >>>> domain/standalone mode and the location in the configuration tree, >>>> but seems solvable. >>>> >>>> 2) There can be expressions in the result and the CLI can't resolve >>>> those expressions. For example if they're looking at a domain >>>> profile there's nothing to resolve against. >>>> >>>> 3) There won't be expressions in the result. There are lots of >>>> places in the CLI that would never return an expression. Which >>>> means the user would never need the argument/param. >>>> >>>> I think it's ok to hide the argument/param in situation 3. If >>>> expressions won't show up in the results there's no reason to have >>>> an option to resolve them really. It seems confusing to include it >>>> here. >>>> >>> >>> I don't really follow this. For sure we won't include any >>> --resolve-expressions param on commands where it isn't relevant, like >>> 'cd' or something. If that's what you mean, that's fine. Otherwise I >>> don't see what situation you're referring to. >>> >> >> I'm thinking about this as it applies to the 'ls' command mostly, since it seems to be the broadest command and is available basically everywhere in the system tree. However, there are lots of locations in that tree where expressions simply would never exist aren't there? Would 'ls' on the root ever return an expression? That information is all version numbers and names and, I suspect, it's impossible to see an expression at that location. Thus no reason to have the ability to resolve one. I'm thinking it's ok to hide the argument in that situation. I'm not sure how widely this problem exists with other operations and commands though. ls might be somewhat unique in this regard since it's available throughout the entire CLI. >> > > Ok, I don't think we should worry about this. IMHO it would be > confusing, since it would cause the --resolve-expressions param to not > appear in locations where the user would have no intuitive understanding > as to why not. > > My assumption here is if --resolve-expressions were set, attributes that > didn't have expressions would be displayed as they are now. So if a user > set the param where there were no actual expressions, there's no harm. Right. Joe, keep in mind that hiding arguments as not exposing them through the tab-completion is one thing, any argument and any rubbish may still appear on the command line just because the user is able type in whatever the keyboard is capable of. We'll still have to recognize the context of the input and decide what to do. So, don't overcomplicate the tab-completion logic. Alexey > >>>> The main question is what to do in situation 2, where there will be >>>> expressions in a result but it's impossible to resolve. Hiding the >>>> argument there seems like it could be confusing for people. >>>> They'll see an expression and if they know the argument is >>>> available elsewhere they'll wonder why they can't use it here. >>>> Frustration ensues. I think it would be better to have some type >>>> of error message explaining, somehow, that their location within >>>> the configuration tree doesn't allow for expressions to be >>>> resolved. I'm not sure what it should say though or how many of >>>> these situations exist. Any suggestions? >>>> >>> >>> There are actually 2 variants of 2). One is the expression can't be >>> resolved at all, and the other is it can be resolved, but the >>> resolution >>> is not meaningful because the resolutions is not occurring in a >>> meaningful process. >>> >>> For example, in a managed domain, /profile=x/subsystem=y: >>> >>> max-size="${com.user.thingy.max-size:10} >>> >>> That can always be resolved, but the resolution is meaningless except >>> on >>> a server at /host=a/server=1/subsystem=y. >>> >>> A another example would be: >>> >>> enabled="${java.net.preferIPv4Stack}" >>> >>> where the system property might be set on a Host Controller, so it >>> resolves, but again the value is meaningless because a server might >>> have >>> a different value for the system property. >>> >>> Because of this, simply trying to resolve the expression and handling >>> a >>> failure will not work. (Sounds like a bad approach anyway.) The tool >>> is >>> going to have to know in advance whether the resolution can be >>> performed. That would either have to be statically built into the >>> tool >>> (bad) or the management API is going to have to indicate this for >>> each >>> resource. I see the latter being done by either adding a param to the >>> API of read-resource-description for resources where it is allowed, >>> or >>> by creating a separate op registered only where allowed. >>> >>> Any error handling I want done client side, i.e. if you and Alexey >>> decide to add --resolve-expressions everywhere and then put out a >>> failure if it's not supported, I want the CLI to decide to fail based >>> on >>> the management metadata, not to count on the server side providing >>> some >>> expected failure if it's not supported. >>> >> >> I definitely agree. I didn't make that clear, but it was always my intention for it to be a pre-determined failure message. I lumped the 'meaningless' resolve in with 'no resolve', and thought the CLI should be able to determine based on the location in the tree whether a resolve makes any sense. If it doesn't, an error message would stop the command from executing and tell the user it's not possible to resolve expressions at this location. >> > > Ok, good. For the CLI to determine if the command is present it will > need to do a :read-resource-description call against the current > resource address. > >>>> The other question is whether there are situations where 1 and 2 >>>> actually overlap. Where some expressions are resolvable, but >>>> others are not. I haven't been able to figure out if that's an >>>> actual problem yet. >>>> >>>> I'm going to implement the ability to hide the argument for the >>>> 'ls' command this week, which Alexey pointed me towards on Friday, >>>> and look into how to add a param to the server-side operations. >>>> Once I have both working successfully I'll try to create a >>>> comprehensive list of all the applicable situations I can figure >>>> out. No sense in doing that before I can get it actually working >>>> for both the CLI commands and server-side operations first. >>>> >>> >>> What's tricky is the subtree under host=*, excluding host=*/server=*. >>> Everything in a domain not under host=* is cannot support resolution, >>> and everything under host=*/server=* can. >>> >>> Places where this is an issue are: >>> >>> /host=*/system-property=* >>> >>> This resource is not relevant on the HC process; it drives the config >>> of >>> the server. So --resolve-expressions cannot be supported here. >>> >>> /host=*/path=* >>> >>> This one is a bit tricky, as the expression must be resolvable on the >>> HC, so --resolve-expressions could work, but it's possible that the >>> path >>> gets passed to the server and gets resolved differently there. But I >>> think that's an ok semantic. >>> >>> /host=*/interface=* >>> >>> Same as path. >>> >>> /host=*/server-config=*/system-property=* >>> /host=*/server-config=*/interface=* >>> /host=*/server-config=*/path=* >>> >>> None of these resources are relevant on the HC process; they drive >>> the >>> config of the server. So --resolve-expressions cannot be supported >>> here. >>> It can be supported on /host=*/server-config=* itself though. >>> >>>> Joe Wertz >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>>>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>>>>> Thanks, Joe, for looking into this. >>>>>>>> >>>>>>>> I'm curious what you've done so far with your 'ls >>>>>>>> --resolve-expressions' >>>>>>>> work. Did you use the existing >>>>>>>> ':resolve-expression(expression=___)' low >>>>>>>> level operation to process any expressions found in the >>>>>>>> :read-resource >>>>>>>> response? >>>>>>>> >>>>>>>> There are a few aspects of this I'd like to explore. >>>>>>>> >>>>>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>>>>> contexts >>>>>>>> and not others a good UX? Will users understand that? I'm >>>>>>>> ambivalent >>>>>>>> about that, and am interested in others' opinions. >>>>>>>> >>>>>>>> If it can work for a server and for anything under /host=*, >>>>>>>> then >>>>>>>> I'm >>>>>>>> ambivalent. Any restriction at all is unintuitive, but once the >>>>>>>> user >>>>>>>> learns that there is a restriction, that's a pretty >>>>>>>> understandable one. >>>>>>>> If it only works for a patchwork of stuff under /host=* then >>>>>>>> I'm >>>>>>>> real >>>>>>>> negative about it. An area of concern is >>>>>>>> /host=*/server-config=*, >>>>>>>> where >>>>>>>> an expression might be irrelevant to the host, only resolving >>>>>>>> correctly >>>>>>>> on the server that is created using that server-config. That >>>>>>>> will >>>>>>>> need >>>>>>>> careful examination. >>>>>>>> >>>>>>>> A second one is how this data would be displayed with 'ls'. A >>>>>>>> separate >>>>>>>> additional column? Or replacing the current data? The answer to >>>>>>>> this >>>>>>>> might impact how it would be implemented server side. >>>>>>> >>>>>>> Keep in mind that ls is an example. There are other commands >>>>>>> that >>>>>>> will >>>>>>> have to support this feature once it's implemented in one place. >>>>>>> Another >>>>>>> example is read-attribute command. The ability to resolve >>>>>>> expressions >>>>>>> elsewhere will be a natural expectation then. >>>>>>> So, it has to be thought of as a general features that can be >>>>>>> applied to >>>>>>> various cli commands. >>>>>>> >>>>>> >>>>>> Good point. Joe, we'd need a clear understanding of all the >>>>>> commands >>>>>> that would be affected. >>>>> >>>>> At this point, it's ls, read-attribute and commands handled by >>>>> GenericTypeOperationHandler (which means [xa-]data-source, >>>>> jms-topic, >>>>> -queue, -connection-factory, etc). >>>>> >>>>> The generic handler includes action read-resource (e.g. w/o other >>>>> optional arguments 'data-source read-resource --name=ExampleDS'), >>>>> which >>>>> is basically a formatted result of :read-resource. >>>>> >>>>> In general, it could be applied to any command displaying an >>>>> attribute >>>>> value to the user. >>>>> >>>>> Alexey >>>>> >>>>>> >>>>>>> IMO, the values returned should just be replaced with the >>>>>>> resolved >>>>>>> ones >>>>>>> for display. Some commands support --verbose argument, in which >>>>>>> case >>>>>>> additional info is displayed in columns, there we could include >>>>>>> the >>>>>>> original value. >>>>>>> The output of the cli commands in some cases is parsed by >>>>>>> scripts >>>>>>> or >>>>>>> other code, so keeping it simple will help there too. >>>>>>> >>>>>>>> The third aspect is the technical issue of how to make any >>>>>>>> 'resolve-expressions' param or CLI argument available in >>>>>>>> certain >>>>>>>> contexts and not in others. That's very likely solvable on the >>>>>>>> server >>>>>>>> side; not sure how difficult it would be in the CLI high-level >>>>>>>> command. >>>>>>> >>>>>>> Current tab-completion supports dependencies of command >>>>>>> arguments >>>>>>> and >>>>>>> their values on the current context (connection to the >>>>>>> controller, >>>>>>> standalone/domain mode, the presence of other arguments on the >>>>>>> line and >>>>>>> the values specified for them, etc). Technically, there >>>>>>> shouldn't >>>>>>> be an >>>>>>> issue. >>>>>> >>>>>> Ok, good. >>>>>> >>>>>>> I am more concerned about how intuitive that will look like for >>>>>>> the user >>>>>>> in various contexts. >>>>>>> >>>>>> >>>>>> Yes, I think the UX aspects are the more significant ones. >>>>>> >>>>>>> Alexey >>>>>>> >>>>>>>> FYI, for others reading this, offline Joe pointed out there's a >>>>>>>> related >>>>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>>>>> >>>>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>>>>> I'm looking into whether it's possible to automatically >>>>>>>>> resolve >>>>>>>>> expressions when executing operations and commands in the CLI. >>>>>>>>> >>>>>>>>> >From my understanding, there are two variations of the >>>>>>>>>> problem. >>>>>>>>> >>>>>>>>> * Operations are server-side processes that are accessed >>>>>>>>> via ':' in the CLI and, currently, the CLI presents the >>>>>>>>> results returned as-is to the users. ex: >>>>>>>>> ':read-resource' >>>>>>>>> >>>>>>>>> * Commands are processes that get manipulated by the CLI >>>>>>>>> before getting presented to users. ex: 'ls' >>>>>>>>> >>>>>>>>> I've been experimenting with adding arguments to the CLI >>>>>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>>>>> working for the standalone and domain side of things. However, >>>>>>>>> I can't control the scope of the argument, so it's available >>>>>>>>> in >>>>>>>>> situations that cannot accurately resolve expressions like the >>>>>>>>> 'profile=full' section of the domain tree. The results >>>>>>>>> wouldn't >>>>>>>>> be reliable. >>>>>>>>> >>>>>>>>> The same problem would apply to adding parameters to the >>>>>>>>> server-side operations. The scope of the operations themselves >>>>>>>>> can be controlled, but not their parameters. An execution like >>>>>>>>> ':read-resource(recursive=true resolve-expressions=true)' >>>>>>>>> can't >>>>>>>>> resolve expressions unless it's used against an actual server >>>>>>>>> or host, but the operation is available almost everywhere. >>>>>>>>> Again, the results wouldn't be reliable. >>>>>>>>> >>>>>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>>>>> problem? There is already a >>>>>>>>> ':resolve-expression(expression=___)' operation, so users can >>>>>>>>> somewhat laboriously get the runtime values they want, but I >>>>>>>>> can't figure out a way to integrate the values into the >>>>>>>>> existing framework successfully. Other than creating entirely >>>>>>>>> new operations and commands, like 'ls-resolve' and >>>>>>>>> ':read-resource-resolve', which seems like an unsustainable >>>>>>>>> way >>>>>>>>> to solve the problem. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Joe Wertz > > From brian.stansberry at redhat.com Tue Jul 8 17:07:48 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 08 Jul 2014 16:07:48 -0500 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> Message-ID: <53BC5DA4.6000801@redhat.com> On 7/7/14, 9:46 AM, Jeff Mesnil wrote: > # Add Notification support to WildFly Management > > Tracked by https://issues.jboss.org/browse/WFLY-266 > > Use Cases > --------- > > Notifications are an useful mechanism to observe management changes on WildFly servers. > It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) > > Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. > > The most expected use cases for WildFly notifications are: > - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. > - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications > - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) > > Part 1: Notification Definition > ------------------------------- > > A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. > > { > "description" => "A manageable resource", > "attributes" => { > ... > }, > "operations" => { > ... > }, > "notifications" => { > "resource-added" => { > ... > } > }, > "children" => { > ... > } > } > > The description of a notification will be composed of: > > * type - String - the type of notification (resource-added, server-stopped, etc.) > * description - String - i18ned description of the notification > * access-constraints - the RBAC access constraints that controls who can receive the notifications > * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value > > The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). > > The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. > > Part 2: Emitting a notification > ------------------------------- > > A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) > > public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { > > // perform some actions > ... > > context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); > context.stepCompleted(); > } > > The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. To clarify: I believe your intent was delivery is at the end of the overall operation execution, when it commits, not at the end of the "operation step". I mention this because an operation execution can consist of many steps, with even a basic write involving 2 or 3. > Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. > > A Notification is a simple Java class that represents the notification. It is composed of: > > * type - String - the notification type > * address - PathAddress - the address of the resource that emits the notification > * message - String - the i18ned description of the message > * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. > * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). > > If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. > We also need to use SecurityManager permissions around the handler registration. Non-remote registrations basically get all permissions, same as internal management clients like the deployment-scanner do. We control the ability of internal management clients like the scanner to create a ModelControllerClient using SecurityManager permissions. > Part 3: Global Resource Notifications > ?????????????????? > > In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: > > * resource-added - when a resource is added, it emits a resource-added notification > * resource-removed - when a resource is removed, it emits a resource-removed notification > * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: > * name - String - the name of the attribute > * old-value - the detyped representation of the previous value of the attribute > * new-value - the detyped representation of the new value > > > Part 4: Notification Handlers > ?????????????? > > Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. > > The source is a path address to handle notifications emitted by resources at this address. > The NotificationHandler is an interface with a single handleNotification(Notification notification) method. > The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. > > There is a similar unregister method to unregister a (handler, filter) > > To be useful, the source path address will have to accept wildcards for the address' values: > * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources > * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources > > Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). > > This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). > > The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. Agreed. I don't think this should be an issue. We shouldn't use the Resource tree anyway as the data structure for retaining the registered handlers; a separate structure is needed. The wildcards are fine as long as there's a relevant ManagementResourceRegistration. > However until the resource is created, there is no way to register a notification listener on it without using a wildcard. > If that proves problematic, we could change this approach with two alternatives: > * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management > * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree?) > > I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... > It's not critical until you get to Part 7 but we'll need to sort it out before even starting on Part 7. The user-related inputs into the existing RBAC logic (see org.jboss.as.controller.access.Authorizer) are the Caller and Environment. The Caller basically just wraps a Subject, exposing the data from the relevant Principal types (name and groups). We could just cache the Caller in effect when the handler is registered and use it for authorizing delivery of each notification. The problem is if the user if no longer valid or the groups associated with the user have changed, this won't be picked up. We don't want to cache any "roles". First, the mapping of the Caller to roles can change from time to time so we don't want to cache that result. Second, "roles" are not first-class parts of the Authorizer API; they are used by our standard impls of it, but we want to allow custom impls that may not care about roles. > Part 5: Domain Notifications > ?????????????? > > Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. > > The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): > * server-started > * server-stopped > * server-restarted > * server-destroyed > * server-killed > > Part 6: Integration with local JMX > ????????????????? > > The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: > * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo > * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. > * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). > > In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. > Everything up to this point I'd like to see in 8.2. > Part 7: Integration with Remote Management API > ??????????????????????? > > We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient > > void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter); > > The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...) > Last we talked about this we planned to do a new controller client variant that could better handle this. > The Management HTTP API will also be enhance to support notifications with its REST API. > A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets). > => the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications > > Part 8: Integration with Remote JMX > ????????????????? > > Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it). > > Part 9: Web Console UX improvement > ????????????????? > > Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX. > > This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit. > > What do you think? > Sounds good. > jeff > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Wed Jul 9 03:33:51 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 9 Jul 2014 09:33:51 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> Message-ID: <58756C66-3A5A-4063-84B4-61DFCD1B4F87@redhat.com> On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: > The description of a notification will be composed of: > > * type - String - the type of notification (resource-added, server-stopped, etc.) > * description - String - i18ned description of the notification > * access-constraints - the RBAC access constraints that controls who can receive the notifications > * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce? How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description() Regards, Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140709/748ce7d7/attachment.html From darran.lofthouse at jboss.com Wed Jul 9 06:47:16 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 09 Jul 2014 11:47:16 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? Message-ID: <53BD1DB4.7050908@jboss.com> Working with the split repo just questioning if JMX is really needed in core? Whilst most distributions would include it I am not convinced it is a subsystem all must have. Regards, Darran Lofthouse. From tomaz.cerar at gmail.com Wed Jul 9 07:52:35 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 9 Jul 2014 13:52:35 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD1DB4.7050908@jboss.com> References: <53BD1DB4.7050908@jboss.com> Message-ID: Unfortunately it is needed. At least at this point of the project. I tired hard not to have it back when I was doing just separate core build. Current dependency tree for it includes: - wildfly-server - wildfly-system-jmx + arquillian, but that is not a problem anymore given that we moved it out of core and it is not required anymore. But probably we can revisit that and try to remove it now that there is no need for arq anymore in core. Big chunk of core testsuite will need to be updated to not use jmx subsystem anymore. Darren, can you create jira for this and assign it to me? I will take look. -- tomaz On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > Working with the split repo just questioning if JMX is really needed in > core? > > Whilst most distributions would include it I am not convinced it is a > subsystem all must have. > > Regards, > Darran Lofthouse. > _______________________________________________ > 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/20140709/595aa818/attachment.html From brian.stansberry at redhat.com Wed Jul 9 09:26:40 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 09 Jul 2014 08:26:40 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> Message-ID: <53BD4310.2030309@redhat.com> IMHO wildfly-system-jmx does not need to be in core. It's analogous to wildfly-pojo and that's not in core. We should sort out the wildfly-server dependency, whatever it is, and either eliminate it or make it something that relies on an optional capability. On 7/9/14, 6:52 AM, Toma? Cerar wrote: > Unfortunately it is needed. > > At least at this point of the project. > I tired hard not to have it back when I was doing just separate core build. > > Current dependency tree for it includes: > > - wildfly-server > - wildfly-system-jmx > > + arquillian, but that is not a problem anymore given that we moved it > out of core and it is not required anymore. > > But probably we can revisit that and try to remove it now that there is > no need for arq anymore in core. > Big chunk of core testsuite will need to be updated to not use jmx > subsystem anymore. > > > Darren, can you create jira for this and assign it to me? I will take look. > > -- > tomaz > > > > On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse > > wrote: > > Working with the split repo just questioning if JMX is really needed in > core? > > Whilst most distributions would include it I am not convinced it is a > subsystem all must have. > > 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Wed Jul 9 13:13:52 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 09 Jul 2014 18:13:52 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> Message-ID: <53BD7850.7070301@jboss.com> As requested: - https://issues.jboss.org/browse/WFLY-3605 Regards, Darran Lofthouse. On 09/07/14 12:52, Toma? Cerar wrote: > Unfortunately it is needed. > > At least at this point of the project. > I tired hard not to have it back when I was doing just separate core build. > > Current dependency tree for it includes: > > - wildfly-server > - wildfly-system-jmx > > + arquillian, but that is not a problem anymore given that we moved it > out of core and it is not required anymore. > > But probably we can revisit that and try to remove it now that there is > no need for arq anymore in core. > Big chunk of core testsuite will need to be updated to not use jmx > subsystem anymore. > > > Darren, can you create jira for this and assign it to me? I will take look. > > -- > tomaz > > > > On Wed, Jul 9, 2014 at 12:47 PM, Darran Lofthouse > > wrote: > > Working with the split repo just questioning if JMX is really needed in > core? > > Whilst most distributions would include it I am not convinced it is a > subsystem all must have. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From tomaz.cerar at gmail.com Wed Jul 9 13:53:02 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 9 Jul 2014 19:53:02 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD4310.2030309@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD4310.2030309@redhat.com> Message-ID: On Wed, Jul 9, 2014 at 3:26 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > We should sort out the wildfly-server dependency, whatever it is, and > either eliminate it or make it something that relies on an optional > capability. > Agreed, most of the hard deps ware because of ARQ container needs, but that is gone now. I have most of work done to move it out. just need some more testing. One thing that looks fishy is Audit logging (part of controller) that has hard coded mgmt paths to JMX subsystem not really sure how this works if jmx is not present. Kabir, if we move jmx out will there be any issues with that? Beyond fact that audit logging working only when jmx subsystem is present? -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140709/c70be072/attachment.html From tomaz.cerar at gmail.com Wed Jul 9 13:53:14 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 9 Jul 2014 19:53:14 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD7850.7070301@jboss.com> References: <53BD1DB4.7050908@jboss.com> <53BD7850.7070301@jboss.com> Message-ID: On Wed, Jul 9, 2014 at 7:13 PM, Darran Lofthouse wrote: > As requested: - > https://issues.jboss.org/browse/WFLY-3605 > Tnx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140709/7ca1fa08/attachment.html From brian.stansberry at redhat.com Wed Jul 9 14:27:47 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 09 Jul 2014 13:27:47 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD1DB4.7050908@jboss.com> References: <53BD1DB4.7050908@jboss.com> Message-ID: <53BD89A3.10600@redhat.com> My earlier reply on this thread was in the branch focused on the technical detail of how the dependency arises. Which should be fixed; sounds like that's happening. On the broader question of where stuff belongs, JMX is an interesting case. Lots of users will want JMX. A number of subsystems have optional dependencies on it, including some like jgroups and infinispan that may end up being part of their own dist, separate from the full dist. So what's the plan for catering to these needs? Ship it in the full dist and those who want it depend on the full dist but configure the provisioning tool to only grab the JMX modules? Make it a micro-dist? Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as the "deploy your own services" dist? (I don't like that last one, just brainstorming...) On 7/9/14, 5:47 AM, Darran Lofthouse wrote: > Working with the split repo just questioning if JMX is really needed in > core? > > Whilst most distributions would include it I am not convinced it is a > subsystem all must have. > Manageable logging isn't either. Lots of people used logging.properties for a long time. Note I'm not advocating removing logging from core; I'm just saying that no subsystem has to be in core if that's the criteria. > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From fnasser at redhat.com Wed Jul 9 14:32:30 2014 From: fnasser at redhat.com (Fernando Nasser) Date: Wed, 09 Jul 2014 14:32:30 -0400 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD89A3.10600@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> Message-ID: <53BD8ABE.1060907@redhat.com> Shouldn't it be like an onion? A more bare core. A Core with monitoring capabilities. And so on. On 2014-07-09, 2:27 PM, Brian Stansberry wrote: > My earlier reply on this thread was in the branch focused on the > technical detail of how the dependency arises. Which should be fixed; > sounds like that's happening. > > On the broader question of where stuff belongs, JMX is an interesting > case. Lots of users will want JMX. A number of subsystems have optional > dependencies on it, including some like jgroups and infinispan that may > end up being part of their own dist, separate from the full dist. > > So what's the plan for catering to these needs? Ship it in the full dist > and those who want it depend on the full dist but configure the > provisioning tool to only grab the JMX modules? Make it a micro-dist? > Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as > the "deploy your own services" dist? (I don't like that last one, just > brainstorming...) > > On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >> Working with the split repo just questioning if JMX is really needed in >> core? >> >> Whilst most distributions would include it I am not convinced it is a >> subsystem all must have. >> > Manageable logging isn't either. Lots of people used logging.properties > for a long time. > > Note I'm not advocating removing logging from core; I'm just saying that > no subsystem has to be in core if that's the criteria. > >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > From John.Patton at searshc.com Wed Jul 9 14:55:38 2014 From: John.Patton at searshc.com (Patton, John) Date: Wed, 9 Jul 2014 18:55:38 +0000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD89A3.10600@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> Message-ID: I'd like to vote for adding it into the full dist and configuring the provisioning tool to grab the JMX modules. We rely on JMX for accessing specific monitoring metrics and it's difficult to get at some of the metrics that used to be easily available in prior versions for some metrics. We've had to jump through some hoops to get JMX working the way we need in wildfly 8 -- with the new undertow module, we had to write some code to expose some metrics that used to be part of the jbossweb module, like avgResponseTimeMS and requestCount. Would be awesome if JMX support was more complete and part of the full dist. Cheers, John H Patton On 7/9/14 1:27 PM, "Brian Stansberry" wrote: >My earlier reply on this thread was in the branch focused on the >technical detail of how the dependency arises. Which should be fixed; >sounds like that's happening. > >On the broader question of where stuff belongs, JMX is an interesting >case. Lots of users will want JMX. A number of subsystems have optional >dependencies on it, including some like jgroups and infinispan that may >end up being part of their own dist, separate from the full dist. > >So what's the plan for catering to these needs? Ship it in the full dist >and those who want it depend on the full dist but configure the >provisioning tool to only grab the JMX modules? Make it a micro-dist? >Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >the "deploy your own services" dist? (I don't like that last one, just >brainstorming...) > >On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >> Working with the split repo just questioning if JMX is really needed in >> core? >> >> Whilst most distributions would include it I am not convinced it is a >> subsystem all must have. >> > >Manageable logging isn't either. Lots of people used logging.properties >for a long time. > >Note I'm not advocating removing logging from core; I'm just saying that >no subsystem has to be in core if that's the criteria. > >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > >-- >Brian Stansberry >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 This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you. From stuart.w.douglas at gmail.com Wed Jul 9 14:59:59 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 10 Jul 2014 04:59:59 +1000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD8ABE.1060907@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> Message-ID: <53BD912F.1010504@gmail.com> The problem with that is that if you take it to its fullest extent you end up with one subsystem per repo, which is not something we want. I am not sure where the best place for it is, even if it stays in core it should be possible for the tooling to exclude it, same with logging. Otherwise I think the place for it to live would be the web distro, as I think that people will definitely want to be able to use JMX to manage that. Stuart Fernando Nasser wrote: > Shouldn't it be like an onion? > > A more bare core. A Core with monitoring capabilities. And so on. > > > On 2014-07-09, 2:27 PM, Brian Stansberry wrote: >> My earlier reply on this thread was in the branch focused on the >> technical detail of how the dependency arises. Which should be fixed; >> sounds like that's happening. >> >> On the broader question of where stuff belongs, JMX is an interesting >> case. Lots of users will want JMX. A number of subsystems have optional >> dependencies on it, including some like jgroups and infinispan that may >> end up being part of their own dist, separate from the full dist. >> >> So what's the plan for catering to these needs? Ship it in the full dist >> and those who want it depend on the full dist but configure the >> provisioning tool to only grab the JMX modules? Make it a micro-dist? >> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >> the "deploy your own services" dist? (I don't like that last one, just >> brainstorming...) >> >> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>> Working with the split repo just questioning if JMX is really needed in >>> core? >>> >>> Whilst most distributions would include it I am not convinced it is a >>> subsystem all must have. >>> >> Manageable logging isn't either. Lots of people used logging.properties >> for a long time. >> >> Note I'm not advocating removing logging from core; I'm just saying that >> no subsystem has to be in core if that's the criteria. >> >>> 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 brian.stansberry at redhat.com Wed Jul 9 15:12:34 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 09 Jul 2014 14:12:34 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> Message-ID: <53BD9422.7060900@redhat.com> If things you need are not exposed via the undertow subsystem management API, please file feature request JIRAs. Or even better, send a patch if you exposed it via the subsystem. On 7/9/14, 1:55 PM, Patton, John wrote: > I'd like to vote for adding it into the full dist and configuring the > provisioning tool to grab the JMX modules. > > We rely on JMX for accessing specific monitoring metrics and it's > difficult to get at some of the metrics that used to be easily available > in prior versions for some metrics. We've had to jump through some hoops > to get JMX working the way we need in wildfly 8 -- with the new undertow > module, we had to write some code to expose some metrics that used to be > part of the jbossweb module, like avgResponseTimeMS and requestCount. > Would be awesome if JMX support was more complete and part of the full > dist. > > Cheers, > > John H Patton > > > > On 7/9/14 1:27 PM, "Brian Stansberry" wrote: > >> My earlier reply on this thread was in the branch focused on the >> technical detail of how the dependency arises. Which should be fixed; >> sounds like that's happening. >> >> On the broader question of where stuff belongs, JMX is an interesting >> case. Lots of users will want JMX. A number of subsystems have optional >> dependencies on it, including some like jgroups and infinispan that may >> end up being part of their own dist, separate from the full dist. >> >> So what's the plan for catering to these needs? Ship it in the full dist >> and those who want it depend on the full dist but configure the >> provisioning tool to only grab the JMX modules? Make it a micro-dist? >> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >> the "deploy your own services" dist? (I don't like that last one, just >> brainstorming...) >> >> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>> Working with the split repo just questioning if JMX is really needed in >>> core? >>> >>> Whilst most distributions would include it I am not convinced it is a >>> subsystem all must have. >>> >> >> Manageable logging isn't either. Lots of people used logging.properties >> for a long time. >> >> Note I'm not advocating removing logging from core; I'm just saying that >> no subsystem has to be in core if that's the criteria. >> >>> Regards, >>> Darran Lofthouse. >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> 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 > > This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you. > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From John.Patton at searshc.com Wed Jul 9 15:26:49 2014 From: John.Patton at searshc.com (Patton, John) Date: Wed, 9 Jul 2014 19:26:49 +0000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9422.7060900@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD9422.7060900@redhat.com> Message-ID: I'll check if we did. We're looking into releasing the code we built to expose the metrics, but we have to get approvals and it's taking a while. Perhaps my thoughts are out of scope for the one conversation I decided to jump into. :) But, I do like having JMX available in the full dist and enabling the modules in the provisioning tool. That sounds appealing irrespective of the trouble we had grabbing various metrics once we got JMX working. JMX has felt a bit like an afterthought with wildfly. Cheers, -john On 7/9/14 2:12 PM, "Brian Stansberry" wrote: >If things you need are not exposed via the undertow subsystem management >API, please file feature request JIRAs. Or even better, send a patch if >you exposed it via the subsystem. > >On 7/9/14, 1:55 PM, Patton, John wrote: >> I'd like to vote for adding it into the full dist and configuring the >> provisioning tool to grab the JMX modules. >> >> We rely on JMX for accessing specific monitoring metrics and it's >> difficult to get at some of the metrics that used to be easily available >> in prior versions for some metrics. We've had to jump through some >>hoops >> to get JMX working the way we need in wildfly 8 -- with the new undertow >> module, we had to write some code to expose some metrics that used to be >> part of the jbossweb module, like avgResponseTimeMS and requestCount. >> Would be awesome if JMX support was more complete and part of the full >> dist. >> >> Cheers, >> >> John H Patton >> >> >> >> On 7/9/14 1:27 PM, "Brian Stansberry" >>wrote: >> >>> My earlier reply on this thread was in the branch focused on the >>> technical detail of how the dependency arises. Which should be fixed; >>> sounds like that's happening. >>> >>> On the broader question of where stuff belongs, JMX is an interesting >>> case. Lots of users will want JMX. A number of subsystems have optional >>> dependencies on it, including some like jgroups and infinispan that may >>> end up being part of their own dist, separate from the full dist. >>> >>> So what's the plan for catering to these needs? Ship it in the full >>>dist >>> and those who want it depend on the full dist but configure the >>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>> the "deploy your own services" dist? (I don't like that last one, just >>> brainstorming...) >>> >>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>> Working with the split repo just questioning if JMX is really needed >>>>in >>>> core? >>>> >>>> Whilst most distributions would include it I am not convinced it is a >>>> subsystem all must have. >>>> >>> >>> Manageable logging isn't either. Lots of people used logging.properties >>> for a long time. >>> >>> Note I'm not advocating removing logging from core; I'm just saying >>>that >>> no subsystem has to be in core if that's the criteria. >>> >>>> Regards, >>>> Darran Lofthouse. >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> -- >>> Brian Stansberry >>> 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 >> >> This message, including any attachments, is the property of Sears >>Holdings Corporation and/or one of its subsidiaries. It is confidential >>and may contain proprietary or legally privileged information. If you >>are not the intended recipient, please delete it without reading the >>contents. Thank you. >> > > >-- >Brian Stansberry >Senior Principal Software Engineer >JBoss by Red Hat This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you. From stuart.w.douglas at gmail.com Wed Jul 9 15:31:12 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 10 Jul 2014 05:31:12 +1000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD9422.7060900@redhat.com> Message-ID: <53BD9880.5000801@gmail.com> Patton, John wrote: > I'll check if we did. We're looking into releasing the code we built to > expose the metrics, but we have to get approvals and it's taking a while. > > Perhaps my thoughts are out of scope for the one conversation I decided to > jump into. :) But, I do like having JMX available in the full dist and > enabling the modules in the provisioning tool. That sounds appealing > irrespective of the trouble we had grabbing various metrics once we got > JMX working. JMX has felt a bit like an afterthought with wildfly. Where JMX lives in the distro should not have any effect on the capabilities of the JMX subsystem. It will still be the same subsystem with the same functionality wether it lives in core or the full dist. Stuart > > Cheers, > > -john > > > > > On 7/9/14 2:12 PM, "Brian Stansberry" wrote: > >> If things you need are not exposed via the undertow subsystem management >> API, please file feature request JIRAs. Or even better, send a patch if >> you exposed it via the subsystem. >> >> On 7/9/14, 1:55 PM, Patton, John wrote: >>> I'd like to vote for adding it into the full dist and configuring the >>> provisioning tool to grab the JMX modules. >>> >>> We rely on JMX for accessing specific monitoring metrics and it's >>> difficult to get at some of the metrics that used to be easily available >>> in prior versions for some metrics. We've had to jump through some >>> hoops >>> to get JMX working the way we need in wildfly 8 -- with the new undertow >>> module, we had to write some code to expose some metrics that used to be >>> part of the jbossweb module, like avgResponseTimeMS and requestCount. >>> Would be awesome if JMX support was more complete and part of the full >>> dist. >>> >>> Cheers, >>> >>> John H Patton >>> >>> >>> >>> On 7/9/14 1:27 PM, "Brian Stansberry" >>> wrote: >>> >>>> My earlier reply on this thread was in the branch focused on the >>>> technical detail of how the dependency arises. Which should be fixed; >>>> sounds like that's happening. >>>> >>>> On the broader question of where stuff belongs, JMX is an interesting >>>> case. Lots of users will want JMX. A number of subsystems have optional >>>> dependencies on it, including some like jgroups and infinispan that may >>>> end up being part of their own dist, separate from the full dist. >>>> >>>> So what's the plan for catering to these needs? Ship it in the full >>>> dist >>>> and those who want it depend on the full dist but configure the >>>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>>> the "deploy your own services" dist? (I don't like that last one, just >>>> brainstorming...) >>>> >>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>>> Working with the split repo just questioning if JMX is really needed >>>>> in >>>>> core? >>>>> >>>>> Whilst most distributions would include it I am not convinced it is a >>>>> subsystem all must have. >>>>> >>>> Manageable logging isn't either. Lots of people used logging.properties >>>> for a long time. >>>> >>>> Note I'm not advocating removing logging from core; I'm just saying >>>> that >>>> no subsystem has to be in core if that's the criteria. >>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> -- >>>> Brian Stansberry >>>> 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 >>> This message, including any attachments, is the property of Sears >>> Holdings Corporation and/or one of its subsidiaries. It is confidential >>> and may contain proprietary or legally privileged information. If you >>> are not the intended recipient, please delete it without reading the >>> contents. Thank you. >>> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat > > This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From John.Patton at searshc.com Wed Jul 9 15:33:28 2014 From: John.Patton at searshc.com (Patton, John) Date: Wed, 9 Jul 2014 19:33:28 +0000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9880.5000801@gmail.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD9422.7060900@redhat.com> <53BD9880.5000801@gmail.com> Message-ID: On 7/9/14 2:31 PM, "Stuart Douglas" wrote: > > >Patton, John wrote: >> I'll check if we did. We're looking into releasing the code we built to >> expose the metrics, but we have to get approvals and it's taking a >>while. >> >> Perhaps my thoughts are out of scope for the one conversation I decided >>to >> jump into. :) But, I do like having JMX available in the full dist and >> enabling the modules in the provisioning tool. That sounds appealing >> irrespective of the trouble we had grabbing various metrics once we got >> JMX working. JMX has felt a bit like an afterthought with wildfly. > >Where JMX lives in the distro should not have any effect on the >capabilities of the JMX subsystem. It will still be the same subsystem >with the same functionality wether it lives in core or the full dist. Yep, that makes sense. :) I'll go back to lurking again. Cheers, -john > >Stuart > >> >> Cheers, >> >> -john >> >> >> >> >> On 7/9/14 2:12 PM, "Brian Stansberry" >>wrote: >> >>> If things you need are not exposed via the undertow subsystem >>>management >>> API, please file feature request JIRAs. Or even better, send a patch if >>> you exposed it via the subsystem. >>> >>> On 7/9/14, 1:55 PM, Patton, John wrote: >>>> I'd like to vote for adding it into the full dist and configuring the >>>> provisioning tool to grab the JMX modules. >>>> >>>> We rely on JMX for accessing specific monitoring metrics and it's >>>> difficult to get at some of the metrics that used to be easily >>>>available >>>> in prior versions for some metrics. We've had to jump through some >>>> hoops >>>> to get JMX working the way we need in wildfly 8 -- with the new >>>>undertow >>>> module, we had to write some code to expose some metrics that used to >>>>be >>>> part of the jbossweb module, like avgResponseTimeMS and requestCount. >>>> Would be awesome if JMX support was more complete and part of the full >>>> dist. >>>> >>>> Cheers, >>>> >>>> John H Patton >>>> >>>> >>>> >>>> On 7/9/14 1:27 PM, "Brian Stansberry" >>>> wrote: >>>> >>>>> My earlier reply on this thread was in the branch focused on the >>>>> technical detail of how the dependency arises. Which should be fixed; >>>>> sounds like that's happening. >>>>> >>>>> On the broader question of where stuff belongs, JMX is an interesting >>>>> case. Lots of users will want JMX. A number of subsystems have >>>>>optional >>>>> dependencies on it, including some like jgroups and infinispan that >>>>>may >>>>> end up being part of their own dist, separate from the full dist. >>>>> >>>>> So what's the plan for catering to these needs? Ship it in the full >>>>> dist >>>>> and those who want it depend on the full dist but configure the >>>>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>>>> the "deploy your own services" dist? (I don't like that last one, >>>>>just >>>>> brainstorming...) >>>>> >>>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>>>> Working with the split repo just questioning if JMX is really needed >>>>>> in >>>>>> core? >>>>>> >>>>>> Whilst most distributions would include it I am not convinced it is >>>>>>a >>>>>> subsystem all must have. >>>>>> >>>>> Manageable logging isn't either. Lots of people used >>>>>logging.properties >>>>> for a long time. >>>>> >>>>> Note I'm not advocating removing logging from core; I'm just saying >>>>> that >>>>> no subsystem has to be in core if that's the criteria. >>>>> >>>>>> Regards, >>>>>> Darran Lofthouse. >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> 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 >>>> This message, including any attachments, is the property of Sears >>>> Holdings Corporation and/or one of its subsidiaries. It is >>>>confidential >>>> and may contain proprietary or legally privileged information. If you >>>> are not the intended recipient, please delete it without reading the >>>> contents. Thank you. >>>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >> >> This message, including any attachments, is the property of Sears >>Holdings Corporation and/or one of its subsidiaries. It is confidential >>and may contain proprietary or legally privileged information. If you >>are not the intended recipient, please delete it without reading the >>contents. Thank you. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you. From kabir.khan at jboss.com Wed Jul 9 15:34:24 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 9 Jul 2014 20:34:24 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD4310.2030309@redhat.com> Message-ID: On 9 Jul 2014, at 18:53, Toma? Cerar wrote: > > On Wed, Jul 9, 2014 at 3:26 PM, Brian Stansberry wrote: > We should sort out the wildfly-server dependency, whatever it is, and > either eliminate it or make it something that relies on an optional > capability. > > > Agreed, most of the hard deps ware because of ARQ container needs, but that is gone now. > I have most of work done to move it out. just need some more testing. > > One thing that looks fishy is Audit logging (part of controller) that has hard coded mgmt paths to JMX subsystem > not really sure how this works if jmx is not present. > > Kabir, if we move jmx out will there be any issues with that? Beyond fact that audit logging working only when jmx subsystem is present? IIRC all it does is when you remove an audit log handler, to look under subsystem=jmx to make sure it?s audit logger is not using the handler. So it should not be an issue. > > -- > tomaz > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Jul 9 15:35:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 09 Jul 2014 14:35:13 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD912F.1010504@gmail.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> Message-ID: <53BD9971.2020904@redhat.com> On 7/9/14, 1:59 PM, Stuart Douglas wrote: > The problem with that is that if you take it to its fullest extent you > end up with one subsystem per repo, which is not something we want. > > I am not sure where the best place for it is, even if it stays in core > it should be possible for the tooling to exclude it, same with logging. > > Otherwise I think the place for it to live would be the web distro, as I > think that people will definitely want to be able to use JMX to manage > that. > So the web build is becoming the spot where foundational stuff like this and Elytron come in? The core is uber-minimal for the folks who really want that, and then web has these things that lots and lots of folks will want. In the odd case where folks want this foundational stuff but not undertow etc, they can just depend on the web build and exclude undertow. Real corner case. And folks who don't want the foundational stuff exclude it. I can see that working out pretty well. Does logging belong in web then then? Still seems like something that even the uber-minimalists would want. I ask because it bugs me that we have two meanings now for "core" -- the old "core" notion that was the true core with zero subsystems, and now this new wildfly-core dist, which has subsystems. > > > > Fernando Nasser wrote: >> Shouldn't it be like an onion? >> >> A more bare core. A Core with monitoring capabilities. And so on. >> >> >> On 2014-07-09, 2:27 PM, Brian Stansberry wrote: >>> My earlier reply on this thread was in the branch focused on the >>> technical detail of how the dependency arises. Which should be fixed; >>> sounds like that's happening. >>> >>> On the broader question of where stuff belongs, JMX is an interesting >>> case. Lots of users will want JMX. A number of subsystems have optional >>> dependencies on it, including some like jgroups and infinispan that may >>> end up being part of their own dist, separate from the full dist. >>> >>> So what's the plan for catering to these needs? Ship it in the full dist >>> and those who want it depend on the full dist but configure the >>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>> the "deploy your own services" dist? (I don't like that last one, just >>> brainstorming...) >>> >>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>> Working with the split repo just questioning if JMX is really needed in >>>> core? >>>> >>>> Whilst most distributions would include it I am not convinced it is a >>>> subsystem all must have. >>>> >>> Manageable logging isn't either. Lots of people used logging.properties >>> for a long time. >>> >>> Note I'm not advocating removing logging from core; I'm just saying that >>> no subsystem has to be in core if that's the criteria. >>> >>>> 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From anmiller at redhat.com Wed Jul 9 15:56:13 2014 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 9 Jul 2014 15:56:13 -0400 (EDT) Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9422.7060900@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD9422.7060900@redhat.com> Message-ID: <25333285.1079.1404935671356.JavaMail.andrig@worklaptop.miller.org> +1000. The subsystem management API is what everyone should be using, and not JMX. Andy ----- Original Message ----- > From: "Brian Stansberry" > To: "John Patton" , wildfly-dev at lists.jboss.org > Sent: Wednesday, July 9, 2014 1:12:34 PM > Subject: Re: [wildfly-dev] Is JMX Needed in Core? > > If things you need are not exposed via the undertow subsystem > management > API, please file feature request JIRAs. Or even better, send a patch > if > you exposed it via the subsystem. > > On 7/9/14, 1:55 PM, Patton, John wrote: > > I'd like to vote for adding it into the full dist and configuring > > the > > provisioning tool to grab the JMX modules. > > > > We rely on JMX for accessing specific monitoring metrics and it's > > difficult to get at some of the metrics that used to be easily > > available > > in prior versions for some metrics. We've had to jump through some > > hoops > > to get JMX working the way we need in wildfly 8 -- with the new > > undertow > > module, we had to write some code to expose some metrics that used > > to be > > part of the jbossweb module, like avgResponseTimeMS and > > requestCount. > > Would be awesome if JMX support was more complete and part of the > > full > > dist. > > > > Cheers, > > > > John H Patton > > > > > > > > On 7/9/14 1:27 PM, "Brian Stansberry" > > wrote: > > > >> My earlier reply on this thread was in the branch focused on the > >> technical detail of how the dependency arises. Which should be > >> fixed; > >> sounds like that's happening. > >> > >> On the broader question of where stuff belongs, JMX is an > >> interesting > >> case. Lots of users will want JMX. A number of subsystems have > >> optional > >> dependencies on it, including some like jgroups and infinispan > >> that may > >> end up being part of their own dist, separate from the full dist. > >> > >> So what's the plan for catering to these needs? Ship it in the > >> full dist > >> and those who want it depend on the full dist but configure the > >> provisioning tool to only grab the JMX modules? Make it a > >> micro-dist? > >> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo > >> as > >> the "deploy your own services" dist? (I don't like that last one, > >> just > >> brainstorming...) > >> > >> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: > >>> Working with the split repo just questioning if JMX is really > >>> needed in > >>> core? > >>> > >>> Whilst most distributions would include it I am not convinced it > >>> is a > >>> subsystem all must have. > >>> > >> > >> Manageable logging isn't either. Lots of people used > >> logging.properties > >> for a long time. > >> > >> Note I'm not advocating removing logging from core; I'm just > >> saying that > >> no subsystem has to be in core if that's the criteria. > >> > >>> Regards, > >>> Darran Lofthouse. > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >> > >> > >> -- > >> Brian Stansberry > >> 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 > > > > This message, including any attachments, is the property of Sears > > Holdings Corporation and/or one of its subsidiaries. It is > > confidential and may contain proprietary or legally privileged > > information. If you are not the intended recipient, please delete > > it without reading the contents. Thank you. > > > > > -- > Brian Stansberry > 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 stuart.w.douglas at gmail.com Wed Jul 9 16:09:36 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 10 Jul 2014 06:09:36 +1000 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9971.2020904@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> Message-ID: <53BDA180.6060205@gmail.com> Brian Stansberry wrote: > On 7/9/14, 1:59 PM, Stuart Douglas wrote: >> The problem with that is that if you take it to its fullest extent you >> end up with one subsystem per repo, which is not something we want. >> >> I am not sure where the best place for it is, even if it stays in core >> it should be possible for the tooling to exclude it, same with logging. >> >> Otherwise I think the place for it to live would be the web distro, as I >> think that people will definitely want to be able to use JMX to manage >> that. >> > > So the web build is becoming the spot where foundational stuff like this > and Elytron come in? The core is uber-minimal for the folks who really > want that, and then web has these things that lots and lots of folks > will want. > > In the odd case where folks want this foundational stuff but not > undertow etc, they can just depend on the web build and exclude > undertow. Real corner case. And folks who don't want the foundational > stuff exclude it. > > I can see that working out pretty well. > > Does logging belong in web then then? Still seems like something that > even the uber-minimalists would want. I ask because it bugs me that we > have two meanings now for "core" -- the old "core" notion that was the > true core with zero subsystems, and now this new wildfly-core dist, > which has subsystems. I'm really not sure. TBH from a practical sense I don't think it makes any real difference, its more of an idealogical thing. I guess if we look at web as being 'all the stuff that people will probably need' then it makes sense that logging, jmx and deployment-scanner live there instead of core. Stuart > >> >> >> Fernando Nasser wrote: >>> Shouldn't it be like an onion? >>> >>> A more bare core. A Core with monitoring capabilities. And so on. >>> >>> >>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote: >>>> My earlier reply on this thread was in the branch focused on the >>>> technical detail of how the dependency arises. Which should be fixed; >>>> sounds like that's happening. >>>> >>>> On the broader question of where stuff belongs, JMX is an interesting >>>> case. Lots of users will want JMX. A number of subsystems have optional >>>> dependencies on it, including some like jgroups and infinispan that may >>>> end up being part of their own dist, separate from the full dist. >>>> >>>> So what's the plan for catering to these needs? Ship it in the full dist >>>> and those who want it depend on the full dist but configure the >>>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>>> the "deploy your own services" dist? (I don't like that last one, just >>>> brainstorming...) >>>> >>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>>> Working with the split repo just questioning if JMX is really needed in >>>>> core? >>>>> >>>>> Whilst most distributions would include it I am not convinced it is a >>>>> subsystem all must have. >>>>> >>>> Manageable logging isn't either. Lots of people used logging.properties >>>> for a long time. >>>> >>>> Note I'm not advocating removing logging from core; I'm just saying that >>>> no subsystem has to be in core if that's the criteria. >>>> >>>>> 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 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From jason.greene at redhat.com Wed Jul 9 16:26:22 2014 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 9 Jul 2014 15:26:22 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BDA180.6060205@gmail.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BDA180.6060205@gmail.com> Message-ID: On Jul 9, 2014, at 3:09 PM, Stuart Douglas wrote: > > > Brian Stansberry wrote: >> On 7/9/14, 1:59 PM, Stuart Douglas wrote: >>> The problem with that is that if you take it to its fullest extent you >>> end up with one subsystem per repo, which is not something we want. >>> >>> I am not sure where the best place for it is, even if it stays in core >>> it should be possible for the tooling to exclude it, same with logging. >>> >>> Otherwise I think the place for it to live would be the web distro, as I >>> think that people will definitely want to be able to use JMX to manage >>> that. >>> >> >> So the web build is becoming the spot where foundational stuff like this >> and Elytron come in? The core is uber-minimal for the folks who really >> want that, and then web has these things that lots and lots of folks >> will want. >> >> In the odd case where folks want this foundational stuff but not >> undertow etc, they can just depend on the web build and exclude >> undertow. Real corner case. And folks who don't want the foundational >> stuff exclude it. >> >> I can see that working out pretty well. >> >> Does logging belong in web then then? Still seems like something that >> even the uber-minimalists would want. I ask because it bugs me that we >> have two meanings now for "core" -- the old "core" notion that was the >> true core with zero subsystems, and now this new wildfly-core dist, >> which has subsystems. > > I'm really not sure. TBH from a practical sense I don't think it makes > any real difference, its more of an idealogical thing. > > I guess if we look at web as being 'all the stuff that people will > probably need' then it makes sense that logging, jmx and > deployment-scanner live there instead of core. -1 to moving deployment scanner and logging out of core. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Wed Jul 9 18:18:47 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 09 Jul 2014 17:18:47 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BDA180.6060205@gmail.com> Message-ID: <53BDBFC7.2040205@redhat.com> On 7/9/14, 3:26 PM, Jason Greene wrote: > > On Jul 9, 2014, at 3:09 PM, Stuart Douglas wrote: > >> >> >> Brian Stansberry wrote: >>> On 7/9/14, 1:59 PM, Stuart Douglas wrote: >>>> The problem with that is that if you take it to its fullest extent you >>>> end up with one subsystem per repo, which is not something we want. >>>> >>>> I am not sure where the best place for it is, even if it stays in core >>>> it should be possible for the tooling to exclude it, same with logging. >>>> >>>> Otherwise I think the place for it to live would be the web distro, as I >>>> think that people will definitely want to be able to use JMX to manage >>>> that. >>>> >>> >>> So the web build is becoming the spot where foundational stuff like this >>> and Elytron come in? The core is uber-minimal for the folks who really >>> want that, and then web has these things that lots and lots of folks >>> will want. >>> >>> In the odd case where folks want this foundational stuff but not >>> undertow etc, they can just depend on the web build and exclude >>> undertow. Real corner case. And folks who don't want the foundational >>> stuff exclude it. >>> >>> I can see that working out pretty well. >>> >>> Does logging belong in web then then? Still seems like something that >>> even the uber-minimalists would want. I ask because it bugs me that we >>> have two meanings now for "core" -- the old "core" notion that was the >>> true core with zero subsystems, and now this new wildfly-core dist, >>> which has subsystems. >> >> I'm really not sure. TBH from a practical sense I don't think it makes >> any real difference, its more of an idealogical thing. >> I'd say it's more of a documentation thing. IOW I'm not so much concerned about conceptual purity of the core dist as I am about having the same word mean two different things in things like docs. The term also appears in the management model: /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=credential vs subsystem specific stuff: /core-service=management/access=authorization/constraint=sensitivity-classification/type=datasources/classification=data-source-security It probably won't really matter though. People are smart and the ones who aren't probably won't notice. >> I guess if we look at web as being 'all the stuff that people will >> probably need' then it makes sense that logging, jmx and >> deployment-scanner live there instead of core. > I forgot about the scanner. > -1 to moving deployment scanner and logging out of core. > And the gavel slams. :) I love the sound of the gavel. > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Wed Jul 9 19:00:55 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 10 Jul 2014 01:00:55 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9971.2020904@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> Message-ID: On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > > Does logging belong in web then then? Still seems like something that > even the uber-minimalists would want. I ask because it bugs me that we > have two meanings now for "core" -- the old "core" notion that was the > true core with zero subsystems, and now this new wildfly-core dist, > which has subsystems. Core *current* comes with following subsystems: - logging - jmx (on the way out) - deployment-scanner - remoting - io (because of remoting) I agree that jmx needs to go out, deployment scanner needs to stay. And remoting is needed to make cli & alike work... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140710/bfbf8723/attachment.html From jmesnil at redhat.com Thu Jul 10 05:41:56 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 10 Jul 2014 11:41:56 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <58756C66-3A5A-4063-84B4-61DFCD1B4F87@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <58756C66-3A5A-4063-84B4-61DFCD1B4F87@redhat.com> Message-ID: <17C35081-FEFF-4ECF-801E-3165C3E232DD@redhat.com> On 9 Jul 2014, at 09:33, Heiko Braun wrote: > > On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: > >> The description of a notification will be composed of: >> >> * type - String - the type of notification (resource-added, server-stopped, etc.) >> * description - String - i18ned description of the notification >> * access-constraints - the RBAC access constraints that controls who can receive the notifications >> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value > > > I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce? Yes, default notification types provided by all resources are described in Part 3: Global Resource Notifications and would be resource-added, resource-removed and attribute-value-written. Specific notification types can then be introduced by any resource. For example, in domain mode, the /host=X/server-config=Y resource will emit notifications for server lifecycle (started, stopped, killed, etc.) as described in Part 5: Domain Notifications. Once the notification support is put into WildFy core, subsystems would be able to leverage them. For example, I plan to add a notification in the messaging subsystem when failover occurs and a backup server becomes live. > How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description() The notification types will be put into the read-resource-description operation as described in Part 1: Notification Definition. A management client would be able to know which notifications can be emitted by the resource by calling :read-resource-description(notifications=true). The notification definition has a i18ned description attribute that is human-readable. In my current prototype, I have a design issue because a resource can emit a notification without having a corresponding notification definition in its description. I?m not sure if that is a significant issue. If a resource emits a notification without describing it, it would not help clients discover that it is emitted. On the other hand, if I want to enforce that, I can only do it when the notification is emitted at runtime and I am not sure it is a good idea (the server would boot fine and only when the code is run, it would become apparent the resource is incorrectly defined?). I am still pondering what is the best way to handle this but ideally I want the resource description to be consistent with the notifications that are effectively emitted by the resource. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Thu Jul 10 05:52:04 2014 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 10 Jul 2014 11:52:04 +0200 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <53BC5DA4.6000801@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <53BC5DA4.6000801@redhat.com> Message-ID: <2D5957F6-277B-4E4F-B3B3-D00E56D44CC3@redhat.com> On 8 Jul 2014, at 23:07, Brian Stansberry wrote: > On 7/7/14, 9:46 AM, Jeff Mesnil wrote: >> # Add Notification support to WildFly Management >> >> Tracked by https://issues.jboss.org/browse/WFLY-266 >> >> Use Cases >> --------- >> >> Notifications are an useful mechanism to observe management changes on WildFly servers. >> It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.) >> >> Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use. >> >> The most expected use cases for WildFly notifications are: >> - enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions. >> - replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications >> - integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered) >> >> Part 1: Notification Definition >> ------------------------------- >> >> A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource. >> >> { >> "description" => "A manageable resource", >> "attributes" => { >> ... >> }, >> "operations" => { >> ... >> }, >> "notifications" => { >> "resource-added" => { >> ... >> } >> }, >> "children" => { >> ... >> } >> } >> >> The description of a notification will be composed of: >> >> * type - String - the type of notification (resource-added, server-stopped, etc.) >> * description - String - i18ned description of the notification >> * access-constraints - the RBAC access constraints that controls who can receive the notifications >> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value >> >> The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter). >> >> The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API. >> >> Part 2: Emitting a notification >> ------------------------------- >> >> A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method) >> >> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { >> >> // perform some actions >> ... >> >> context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted())); >> context.stepCompleted(); >> } >> >> The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back. > > To clarify: I believe your intent was delivery is at the end of the > overall operation execution, when it commits, not at the end of the > "operation step". I mention this because an operation execution can > consist of many steps, with even a basic write involving 2 or 3. You are right, my description was not correct. The notifications are all emitted at the end of the overall operation execution after it commits. Either all notifications are emitted or none are. > >> Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation. >> >> A Notification is a simple Java class that represents the notification. It is composed of: >> >> * type - String - the notification type >> * address - PathAddress - the address of the resource that emits the notification >> * message - String - the i18ned description of the message >> * timestamp - long - the timestamp of the notification. It is set when the Notification object is created. >> * data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter). >> >> If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly. >> > > We also need to use SecurityManager permissions around the handler > registration. Non-remote registrations basically get all permissions, > same as internal management clients like the deployment-scanner do. We > control the ability of internal management clients like the scanner to > create a ModelControllerClient using SecurityManager permissions. > >> Part 3: Global Resource Notifications >> ?????????????????? >> >> In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model: >> >> * resource-added - when a resource is added, it emits a resource-added notification >> * resource-removed - when a resource is removed, it emits a resource-removed notification >> * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: >> * name - String - the name of the attribute >> * old-value - the detyped representation of the previous value of the attribute >> * new-value - the detyped representation of the new value >> > >> >> Part 4: Notification Handlers >> ?????????????? >> >> Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method. >> >> The source is a path address to handle notifications emitted by resources at this address. >> The NotificationHandler is an interface with a single handleNotification(Notification notification) method. >> The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications. >> >> There is a similar unregister method to unregister a (handler, filter) >> >> To be useful, the source path address will have to accept wildcards for the address' values: >> * /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources >> * /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources >> >> Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid). >> >> This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI). >> >> The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. > > Agreed. I don't think this should be an issue. We shouldn't use the > Resource tree anyway as the data structure for retaining the registered > handlers; a separate structure is needed. The wildcards are fine as long > as there's a relevant ManagementResourceRegistration. In my POC, I am using a single Map to retain the handler and is separate from the resource tree. The Map keys are the path address from the registerNotificationHandler() method (that can be wildcard addresses). When a notification is emitted, I iterate on its entries to find the handlers that match the actual address of resource emitting the notification. I.e. the data structure grows with the number of handlers, not with the resources that emits notifications. >> However until the resource is created, there is no way to register a notification listener on it without using a wildcard. >> If that proves problematic, we could change this approach with two alternatives: >> * have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management >> * the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree?) >> >> I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC... >> > > It's not critical until you get to Part 7 but we'll need to sort it out > before even starting on Part 7. > > The user-related inputs into the existing RBAC logic (see > org.jboss.as.controller.access.Authorizer) are the Caller and > Environment. The Caller basically just wraps a Subject, exposing the > data from the relevant Principal types (name and groups). > > We could just cache the Caller in effect when the handler is registered > and use it for authorizing delivery of each notification. The problem is > if the user if no longer valid or the groups associated with the user > have changed, this won't be picked up. > > We don't want to cache any "roles". First, the mapping of the Caller to > roles can change from time to time so we don't want to cache that > result. Second, "roles" are not first-class parts of the Authorizer API; > they are used by our standard impls of it, but we want to allow custom > impls that may not care about roles. > >> Part 5: Domain Notifications >> ?????????????? >> >> Notifications are also intended to work in domain mode. In particular, they will be used to observe server state. >> >> The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server): >> * server-started >> * server-stopped >> * server-restarted >> * server-destroyed >> * server-killed >> >> Part 6: Integration with local JMX >> ????????????????? >> >> The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model: >> * the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo >> * when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName. >> * depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered). >> >> In a first step, integration will be limited to use of JMX locally. Remoting will not be supported. >> > > Everything up to this point I'd like to see in 8.2. I have create JIRA issues for the parts (as dependencies of the umbrella issue http://issues.jboss.org//browse/WFLY-266) and set their fix versions for both 8.2.0.CR1 and 9.0.0.Alpha1. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From kabir.khan at jboss.com Thu Jul 10 06:12:44 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 10 Jul 2014 11:12:44 +0100 Subject: [wildfly-dev] Proposal to add notifications to WildFly management model and API In-Reply-To: <17C35081-FEFF-4ECF-801E-3165C3E232DD@redhat.com> References: <15AE5265-6745-4CA8-B3A6-B0E11867CC37@redhat.com> <58756C66-3A5A-4063-84B4-61DFCD1B4F87@redhat.com> <17C35081-FEFF-4ECF-801E-3165C3E232DD@redhat.com> Message-ID: On 10 Jul 2014, at 10:41, Jeff Mesnil wrote: > > On 9 Jul 2014, at 09:33, Heiko Braun wrote: > >> >> On 07 Jul 2014, at 16:46, Jeff Mesnil wrote: >> >>> The description of a notification will be composed of: >>> >>> * type - String - the type of notification (resource-added, server-stopped, etc.) >>> * description - String - i18ned description of the notification >>> * access-constraints - the RBAC access constraints that controls who can receive the notifications >>> * data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value >> >> >> I assume there will be default notification types provided by all resources and specific notifications types that subsystems can introduce? > > Yes, default notification types provided by all resources are described in Part 3: Global Resource Notifications and would be resource-added, resource-removed and attribute-value-written. > > Specific notification types can then be introduced by any resource. For example, in domain mode, the /host=X/server-config=Y resource will emit notifications for server lifecycle (started, stopped, killed, etc.) as described in Part 5: Domain Notifications. > > Once the notification support is put into WildFy core, subsystems would be able to leverage them. For example, I plan to add a notification in the messaging subsystem when failover occurs and a backup server becomes live. > >> How do we get to the supported types that resources can emit? Will there be a textual description, similar to read-resource-description() > > The notification types will be put into the read-resource-description operation as described in Part 1: Notification Definition. > A management client would be able to know which notifications can be emitted by the resource by calling :read-resource-description(notifications=true). > The notification definition has a i18ned description attribute that is human-readable. > > In my current prototype, I have a design issue because a resource can emit a notification without having a corresponding notification definition in its description. I?m not sure if that is a significant issue. If a resource emits a notification without describing it, it would not help clients discover that it is emitted. On the other hand, if I want to enforce that, I can only do it when the notification is emitted at runtime and I am not sure it is a good idea (the server would boot fine and only when the code is run, it would become apparent the resource is incorrectly defined?). I am still pondering what is the best way to handle this but ideally I want the resource description to be consistent with the notifications that are effectively emitted by the resource. Not enforcing, a big fat warning if not defined, and some asserts to pick this up during testing when assertions are enabled could be a happy middle ground. We can probably add some notification testing to model-/subsystem-/core-model-test as well. > > jeff > > -- > 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 darran.lofthouse at jboss.com Thu Jul 10 06:44:18 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 10 Jul 2014 11:44:18 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD89A3.10600@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> Message-ID: <53BE6E82.4080403@jboss.com> Can't a subsystem like this live in it's own repo? Then any distribution that needs it can just pull it in? On 09/07/14 19:27, Brian Stansberry wrote: > My earlier reply on this thread was in the branch focused on the > technical detail of how the dependency arises. Which should be fixed; > sounds like that's happening. > > On the broader question of where stuff belongs, JMX is an interesting > case. Lots of users will want JMX. A number of subsystems have optional > dependencies on it, including some like jgroups and infinispan that may > end up being part of their own dist, separate from the full dist. > > So what's the plan for catering to these needs? Ship it in the full dist > and those who want it depend on the full dist but configure the > provisioning tool to only grab the JMX modules? Make it a micro-dist? > Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as > the "deploy your own services" dist? (I don't like that last one, just > brainstorming...) > > On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >> Working with the split repo just questioning if JMX is really needed in >> core? >> >> Whilst most distributions would include it I am not convinced it is a >> subsystem all must have. >> > > Manageable logging isn't either. Lots of people used logging.properties > for a long time. > > Note I'm not advocating removing logging from core; I'm just saying that > no subsystem has to be in core if that's the criteria. > >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From darran.lofthouse at jboss.com Thu Jul 10 06:47:42 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 10 Jul 2014 11:47:42 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BD9971.2020904@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> Message-ID: <53BE6F4E.60105@jboss.com> On 09/07/14 20:35, Brian Stansberry wrote: > On 7/9/14, 1:59 PM, Stuart Douglas wrote: >> The problem with that is that if you take it to its fullest extent you >> end up with one subsystem per repo, which is not something we want. >> >> I am not sure where the best place for it is, even if it stays in core >> it should be possible for the tooling to exclude it, same with logging. >> >> Otherwise I think the place for it to live would be the web distro, as I >> think that people will definitely want to be able to use JMX to manage >> that. >> > > So the web build is becoming the spot where foundational stuff like this > and Elytron come in? My view on Elytron is that the core is going to have to have a dependency on the Elytron module, the actual APIs and SPIs of Elytron are going to have to be tightly integrated in the core. But the subsystem itself and any related additional providers e.g. PicketLink / KeyCloak are things I would see added in the functional distributions so yeah based on what Stuart said web probably becomes the entry point for this. > The core is uber-minimal for the folks who really > want that, and then web has these things that lots and lots of folks > will want. > > In the odd case where folks want this foundational stuff but not > undertow etc, they can just depend on the web build and exclude > undertow. Real corner case. And folks who don't want the foundational > stuff exclude it. > > I can see that working out pretty well. > > Does logging belong in web then then? Still seems like something that > even the uber-minimalists would want. I ask because it bugs me that we > have two meanings now for "core" -- the old "core" notion that was the > true core with zero subsystems, and now this new wildfly-core dist, > which has subsystems. > >> >> >> >> Fernando Nasser wrote: >>> Shouldn't it be like an onion? >>> >>> A more bare core. A Core with monitoring capabilities. And so on. >>> >>> >>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote: >>>> My earlier reply on this thread was in the branch focused on the >>>> technical detail of how the dependency arises. Which should be fixed; >>>> sounds like that's happening. >>>> >>>> On the broader question of where stuff belongs, JMX is an interesting >>>> case. Lots of users will want JMX. A number of subsystems have optional >>>> dependencies on it, including some like jgroups and infinispan that may >>>> end up being part of their own dist, separate from the full dist. >>>> >>>> So what's the plan for catering to these needs? Ship it in the full dist >>>> and those who want it depend on the full dist but configure the >>>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>>> the "deploy your own services" dist? (I don't like that last one, just >>>> brainstorming...) >>>> >>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>>> Working with the split repo just questioning if JMX is really needed in >>>>> core? >>>>> >>>>> Whilst most distributions would include it I am not convinced it is a >>>>> subsystem all must have. >>>>> >>>> Manageable logging isn't either. Lots of people used logging.properties >>>> for a long time. >>>> >>>> Note I'm not advocating removing logging from core; I'm just saying that >>>> no subsystem has to be in core if that's the criteria. >>>> >>>>> 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 >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From darran.lofthouse at jboss.com Thu Jul 10 06:49:31 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 10 Jul 2014 11:49:31 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BDA180.6060205@gmail.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BDA180.6060205@gmail.com> Message-ID: <53BE6FBB.4090609@jboss.com> To me in this thread 'web' is really sounding like the common base most would really want to use - they can go back to core if they really want minimalistic. Web seems to be the holder for the subsystems that get identified as required by most just not all. On 09/07/14 21:09, Stuart Douglas wrote: > > > Brian Stansberry wrote: >> On 7/9/14, 1:59 PM, Stuart Douglas wrote: >>> The problem with that is that if you take it to its fullest extent you >>> end up with one subsystem per repo, which is not something we want. >>> >>> I am not sure where the best place for it is, even if it stays in core >>> it should be possible for the tooling to exclude it, same with logging. >>> >>> Otherwise I think the place for it to live would be the web distro, as I >>> think that people will definitely want to be able to use JMX to manage >>> that. >>> >> >> So the web build is becoming the spot where foundational stuff like this >> and Elytron come in? The core is uber-minimal for the folks who really >> want that, and then web has these things that lots and lots of folks >> will want. >> >> In the odd case where folks want this foundational stuff but not >> undertow etc, they can just depend on the web build and exclude >> undertow. Real corner case. And folks who don't want the foundational >> stuff exclude it. >> >> I can see that working out pretty well. >> >> Does logging belong in web then then? Still seems like something that >> even the uber-minimalists would want. I ask because it bugs me that we >> have two meanings now for "core" -- the old "core" notion that was the >> true core with zero subsystems, and now this new wildfly-core dist, >> which has subsystems. > > I'm really not sure. TBH from a practical sense I don't think it makes > any real difference, its more of an idealogical thing. > > I guess if we look at web as being 'all the stuff that people will > probably need' then it makes sense that logging, jmx and > deployment-scanner live there instead of core. > > Stuart > > >> >>> >>> >>> Fernando Nasser wrote: >>>> Shouldn't it be like an onion? >>>> >>>> A more bare core. A Core with monitoring capabilities. And so on. >>>> >>>> >>>> On 2014-07-09, 2:27 PM, Brian Stansberry wrote: >>>>> My earlier reply on this thread was in the branch focused on the >>>>> technical detail of how the dependency arises. Which should be fixed; >>>>> sounds like that's happening. >>>>> >>>>> On the broader question of where stuff belongs, JMX is an interesting >>>>> case. Lots of users will want JMX. A number of subsystems have optional >>>>> dependencies on it, including some like jgroups and infinispan that may >>>>> end up being part of their own dist, separate from the full dist. >>>>> >>>>> So what's the plan for catering to these needs? Ship it in the full dist >>>>> and those who want it depend on the full dist but configure the >>>>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>>>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>>>> the "deploy your own services" dist? (I don't like that last one, just >>>>> brainstorming...) >>>>> >>>>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>>>> Working with the split repo just questioning if JMX is really needed in >>>>>> core? >>>>>> >>>>>> Whilst most distributions would include it I am not convinced it is a >>>>>> subsystem all must have. >>>>>> >>>>> Manageable logging isn't either. Lots of people used logging.properties >>>>> for a long time. >>>>> >>>>> Note I'm not advocating removing logging from core; I'm just saying that >>>>> no subsystem has to be in core if that's the criteria. >>>>> >>>>>> 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 >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Thu Jul 10 06:51:54 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 10 Jul 2014 11:51:54 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> Message-ID: <53BE704A.3060406@jboss.com> On 10/07/14 00:00, Toma? Cerar wrote: > > On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry > > wrote: > > > Does logging belong in web then then? Still seems like something that > even the uber-minimalists would want. I ask because it bugs me that we > have two meanings now for "core" -- the old "core" notion that was the > true core with zero subsystems, and now this new wildfly-core dist, > which has subsystems. > > > Core *current* comes with following subsystems: > - logging > - jmx (on the way out) > - deployment-scanner > - remoting > - io (because of remoting) > > I agree that jmx needs to go out, > deployment scanner needs to stay. > And remoting is needed to make cli & alike work... In my mind the main thing I think that defines the core is that is provides you with a base manageable server, Remoting is an integral part of that. JMX on the other hand is additional functionality layered on top, closely related to management but not a requirement of it. > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From kabir.khan at jboss.com Thu Jul 10 07:16:30 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 10 Jul 2014 12:16:30 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BE6E82.4080403@jboss.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BE6E82.4080403@jboss.com> Message-ID: <29014288-6261-4B97-A300-C1C1193E24E0@jboss.com> I don?t think we want too many repos, that will become a nightmare. Once we are able to do better assembly of servers depending on capabilities, I think the problem is gone? On 10 Jul 2014, at 11:44, Darran Lofthouse wrote: > Can't a subsystem like this live in it's own repo? Then any > distribution that needs it can just pull it in? > > On 09/07/14 19:27, Brian Stansberry wrote: >> My earlier reply on this thread was in the branch focused on the >> technical detail of how the dependency arises. Which should be fixed; >> sounds like that's happening. >> >> On the broader question of where stuff belongs, JMX is an interesting >> case. Lots of users will want JMX. A number of subsystems have optional >> dependencies on it, including some like jgroups and infinispan that may >> end up being part of their own dist, separate from the full dist. >> >> So what's the plan for catering to these needs? Ship it in the full dist >> and those who want it depend on the full dist but configure the >> provisioning tool to only grab the JMX modules? Make it a micro-dist? >> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >> the "deploy your own services" dist? (I don't like that last one, just >> brainstorming...) >> >> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>> Working with the split repo just questioning if JMX is really needed in >>> core? >>> >>> Whilst most distributions would include it I am not convinced it is a >>> subsystem all must have. >>> >> >> Manageable logging isn't either. Lots of people used logging.properties >> for a long time. >> >> Note I'm not advocating removing logging from core; I'm just saying that >> no subsystem has to be in core if that's the criteria. >> >>> 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 Thu Jul 10 07:25:55 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 10 Jul 2014 12:25:55 +0100 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <29014288-6261-4B97-A300-C1C1193E24E0@jboss.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BE6E82.4080403@jboss.com> <29014288-6261-4B97-A300-C1C1193E24E0@jboss.com> Message-ID: <53BE7843.7040300@jboss.com> Ok so maybe the alternative we need is. The subsystem still lives in core but just not included by default, every sub distribution can then choose to add it if it wants. On 10/07/14 12:16, Kabir Khan wrote: > I don?t think we want too many repos, that will become a nightmare. > Once we are able to do better assembly of servers depending on capabilities, I think the problem is gone? > On 10 Jul 2014, at 11:44, Darran Lofthouse wrote: > >> Can't a subsystem like this live in it's own repo? Then any >> distribution that needs it can just pull it in? >> >> On 09/07/14 19:27, Brian Stansberry wrote: >>> My earlier reply on this thread was in the branch focused on the >>> technical detail of how the dependency arises. Which should be fixed; >>> sounds like that's happening. >>> >>> On the broader question of where stuff belongs, JMX is an interesting >>> case. Lots of users will want JMX. A number of subsystems have optional >>> dependencies on it, including some like jgroups and infinispan that may >>> end up being part of their own dist, separate from the full dist. >>> >>> So what's the plan for catering to these needs? Ship it in the full dist >>> and those who want it depend on the full dist but configure the >>> provisioning tool to only grab the JMX modules? Make it a micro-dist? >>> Maybe a mini-dist packaged with some others? JMX, system-jmx, pojo as >>> the "deploy your own services" dist? (I don't like that last one, just >>> brainstorming...) >>> >>> On 7/9/14, 5:47 AM, Darran Lofthouse wrote: >>>> Working with the split repo just questioning if JMX is really needed in >>>> core? >>>> >>>> Whilst most distributions would include it I am not convinced it is a >>>> subsystem all must have. >>>> >>> >>> Manageable logging isn't either. Lots of people used logging.properties >>> for a long time. >>> >>> Note I'm not advocating removing logging from core; I'm just saying that >>> no subsystem has to be in core if that's the criteria. >>> >>>> 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 brian.stansberry at redhat.com Thu Jul 10 10:03:36 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 10 Jul 2014 09:03:36 -0500 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> Message-ID: <53BE9D38.4020607@redhat.com> On 7/9/14, 6:00 PM, Toma? Cerar wrote: > > On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry > > wrote: > > > Does logging belong in web then then? Still seems like something that > even the uber-minimalists would want. I ask because it bugs me that we > have two meanings now for "core" -- the old "core" notion that was the > true core with zero subsystems, and now this new wildfly-core dist, > which has subsystems. > > > Core *current* comes with following subsystems: > - logging > - jmx (on the way out) > - deployment-scanner > - remoting > - io (because of remoting) > > I agree that jmx needs to go out, > deployment scanner needs to stay. > And remoting is needed to make cli & alike work... > Remoting and io libs are needed, but not the subsystems themselves. But, we've discussed some having the current stuff becoming subsystems once we have proper HC extensions/subsystems, so at that point there *will be* subsystems needed for core. Seems my concern about two meanings of "core" won't matter at that point anyway. Thanks. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Thu Jul 10 10:23:55 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 10 Jul 2014 16:23:55 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs Message-ID: <53BEA1FB.2070408@redhat.com> # Ability to read boot errors via WildFly Management APIs Tracked by https://issues.jboss.org/browse/WFLY-543 Use Cases --------- If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to searching the logs. This information needs to be captured and stored for later reporting. If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of the service. Implementation -------------- Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot errors and missing dependencies near seems like a good place. thus we would have : core-service => service-container { boot-errors => { failures => { service-name => stackTrace; .... } missing-deps => { ... list of missing dependencies as String } } } This structure is based on the structure of the failure description returned during verification when starting a service. All these informations should be collected in the ModelControllerImpl. This resource would have restricted access of course. What do you think? Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140710/5c0e3fa1/attachment.bin From wfink at redhat.com Thu Jul 10 10:24:51 2014 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Thu, 10 Jul 2014 16:24:51 +0200 Subject: [wildfly-dev] Module references in wildfly9 (after build upstream) Message-ID: <53BEA233.3070200@redhat.com> Hi, I noticed that the module.xml contains no jar file but a reference I wonder how that works as after the build a copy of the target/wildfly directory will use the update, but I don't see an updated jar in my maven repo. My question is how can I have a full snapshot with the full jars, i.e. to compare with an older version? And how does that work if we create a release ? Do the zip provide all the jar files as before? maybe a already documented issue, but I don't found any - Wolf From tomaz.cerar at gmail.com Thu Jul 10 11:06:03 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 10 Jul 2014 17:06:03 +0200 Subject: [wildfly-dev] Module references in wildfly9 (after build upstream) In-Reply-To: <53BEA233.3070200@redhat.com> References: <53BEA233.3070200@redhat.com> Message-ID: In dist/ directory you have "inflated" version of distribution with proper jars. otherwise, this is controlled by copy-module-artifacts flag in in server-build.xml for example see: https://github.com/wildfly/wildfly/blob/master/build/server-build.xml or https://github.com/wildfly/wildfly-core/blob/master/core-build/server-build.xml -- tomaz On Thu, Jul 10, 2014 at 4:24 PM, Wolf-Dieter Fink wrote: > Hi, > > I noticed that the module.xml contains no jar file but a reference > > > > I wonder how that works as after the build a copy of the target/wildfly > directory will use the update, but I don't see an updated jar in my > maven repo. > > My question is how can I have a full snapshot with the full jars, i.e. > to compare with an older version? > And how does that work if we create a release ? Do the zip provide all > the jar files as before? > > maybe a already documented issue, but I don't found any > > - Wolf > _______________________________________________ > 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/20140710/83a10eb1/attachment.html From ssilvert at redhat.com Thu Jul 10 15:02:07 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 10 Jul 2014 15:02:07 -0400 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53BEE32F.7040407@redhat.com> You can read the error messages with the read-log-file operation. Does that not meet the requirements? /subsystem=logging/:read-log-file(name=server.log,lines=500,skip=0,tail=false) On 7/10/2014 10:23 AM, Emmanuel Hugonnet wrote: > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. > > What do you think? > > Emmanuel > > > > _______________________________________________ > 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/20140710/f5ab5140/attachment.html From brian.stansberry at redhat.com Thu Jul 10 15:16:37 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 10 Jul 2014 14:16:37 -0500 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53BEE695.2040609@redhat.com> What's reported there is a subset of possible management errors during boot; i.e. not all errors that can occur during execution of the boot ops need to manifest themselves as service failures or missing dependencies. I also think there needs to be more context; i.e. what management operation was being invoked when a problem occurred. We get lots of complaints about how users can't understand what our service names mean when they try and understand failures. Showing address data doesn't solve that completely, but it certainly helps. On 7/10/14, 9:23 AM, Emmanuel Hugonnet wrote: > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. > > What do you think? > > Emmanuel > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Thu Jul 10 15:41:17 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 10 Jul 2014 14:41:17 -0500 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53BEEC5D.7080808@redhat.com> On 07/10/2014 09:23 AM, Emmanuel Hugonnet wrote: > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. I think this makes more sense as an operation than a resource - i.e. "give me all the boot errors" => "okay, here you go as a big list". The rule of thumb (for me) is that a resource typically corresponds to one or more services. -- - DML From hbraun at redhat.com Fri Jul 11 02:34:15 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 11 Jul 2014 08:34:15 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <35E44E07-0FF4-46EA-992B-5A33E7192015@redhat.com> +1 Especially useful within a manged domain > Am 10.07.2014 um 16:23 schrieb Emmanuel Hugonnet : > > Ability to read boot errors via WildFly Management APIs From hbraun at redhat.com Fri Jul 11 02:36:18 2014 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 11 Jul 2014 08:36:18 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <35E44E07-0FF4-46EA-992B-5A33E7192015@redhat.com> References: <53BEA1FB.2070408@redhat.com> <35E44E07-0FF4-46EA-992B-5A33E7192015@redhat.com> Message-ID: What nonsense post of mine. > Am 11.07.2014 um 08:34 schrieb Heiko Braun : > > Especially useful within a manged domain From ehugonne at redhat.com Fri Jul 11 04:02:05 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Fri, 11 Jul 2014 10:02:05 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53BF99FD.30005@redhat.com> So we could have something like : boot-errors => { boot-error => { operation => operationModelNode.asString(); or should we clone the whole operation modelNode ? failures => { service-name => stackTrace; .... }; missing-deps => list of missing dependencies as String; }; }; returned from a read-boot-errors operation. I'm wondering also if we should have a "has-boot-errors" operation which would be useful to just display/check the status ? Emmanuel Le 10/07/2014 16:23, Emmanuel Hugonnet a ?crit : > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. > > What do you think? > > Emmanuel > > > > _______________________________________________ > 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: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140711/59958d10/attachment.bin From kabir.khan at jboss.com Fri Jul 11 05:58:15 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 11 Jul 2014 10:58:15 +0100 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BF99FD.30005@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53BF99FD.30005@redhat.com> Message-ID: <16FB9243-49D4-4C9F-9C5F-E2C069475767@jboss.com> On 11 Jul 2014, at 09:02, Emmanuel Hugonnet wrote: > So we could have something like : > boot-errors => { > boot-error => { > operation => operationModelNode.asString(); or should we clone the whole operation modelNode ? I think it is better to use it as the operation ModelNode > failures => { > service-name => stackTrace; > .... > }; > missing-deps => list of missing dependencies as String; > }; > }; > returned from a read-boot-errors operation. > > I'm wondering also if we should have a "has-boot-errors" operation which would be useful to just display/check the status ? > > Emmanuel > > Le 10/07/2014 16:23, Emmanuel Hugonnet a ?crit : >> # Ability to read boot errors via WildFly Management APIs >> >> Tracked by https://issues.jboss.org/browse/WFLY-543 >> >> Use Cases >> --------- >> >> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >> searching the logs. >> This information needs to be captured and stored for later reporting. >> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >> the service. >> >> Implementation >> -------------- >> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >> errors and missing dependencies near seems like a good place. >> thus we would have : >> core-service => service-container { >> boot-errors => { >> failures => { >> service-name => stackTrace; >> .... >> } >> missing-deps => { >> ... list of missing dependencies as String >> } >> } >> } >> >> This structure is based on the structure of the failure description returned during verification when starting a service. >> All these informations should be collected in the ModelControllerImpl. >> This resource would have restricted access of course. >> >> What do you think? >> >> Emmanuel >> >> >> >> _______________________________________________ >> 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 smarlow at redhat.com Fri Jul 11 09:21:52 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 11 Jul 2014 09:21:52 -0400 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53BFE4F0.402@redhat.com> On 07/10/2014 10:23 AM, Emmanuel Hugonnet wrote: > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. > > What do you think? Should the application server terminate (with a failure code) when errors occur during boot? This might make it more obvious that the server didn't start correctly and that logs should be scanned for the cause. > > Emmanuel > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From smarlow at redhat.com Fri Jul 11 09:45:15 2014 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 11 Jul 2014 09:45:15 -0400 Subject: [wildfly-dev] EJB3 + Java security manager error during TCK testing... Message-ID: <53BFEA6B.2060503@redhat.com> Can someone look into http://paste.fedoraproject.org/117262/08612514 Its a Permission check failed for ("java.lang.RuntimePermission" "getProtectionDomain") from org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.getEJBObject or org.jboss.as.ejb3.context.SessionContextImpl.getEJBObject Thanks, Scott From paranoiabla at gmail.com Fri Jul 11 10:32:29 2014 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Fri, 11 Jul 2014 17:32:29 +0300 Subject: [wildfly-dev] Hibernate + Log4J2 Performance Problem Message-ID: Hi guys, I'm reposting this from hibernate-dev following the advice I was given there. ----------------------------------------------------------------------------------------------------------- So here's my question. I'm reading this issue: https://issues.jboss.org/browse/JBLOGGING-95 and I'm trying to make my hibernate use log4j2. So far I had org.jboss.logging jboss-logging-log4j ${jboss.logging.version} and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a log4j.log file and log4j prints the messages to the command line (still no log4j2) :( So I got rid of this dependency and I added the jboss-logging. So now here's my set of jars: hibernate-core hibernate-entitymanager hibernate-c3p0 hibernate-validator log4j2 org.jboss.logging:jboss-logging:jar:3.2.0.Beta1 then I run my task and I get performance of: [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3:12.951s [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014 [INFO] Final Memory: 128M/508M [INFO] ------------------------------------------------------------------------ 3 minutes and 12 seconds. Performance is quite good. However I use the maven enforcer plugin and maven did warn me I have duplicate classes: Duplicate classes found: Found in: org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile Duplicate classes: org/jboss/logging/Field.class org/jboss/logging/LoggerProvider.class org/jboss/logging/Log4jLoggerProvider.class org/jboss/logging/NDC.class org/jboss/logging/MessageBundle.class org/jboss/logging/AbstractMdcLoggerProvider.class org/jboss/logging/Log4jLogger$1.class org/jboss/logging/Messages$1.class org/jboss/logging/JDKLevel.class org/jboss/logging/DelegatingBasicLogger.class org/jboss/logging/JDKLoggerProvider.class org/jboss/logging/Slf4jLoggerProvider.class org/jboss/logging/LoggingClass.class org/jboss/logging/Messages.class org/jboss/logging/AbstractLoggerProvider.class org/jboss/logging/Property.class org/jboss/logging/JBossLogRecord.class org/jboss/logging/SerializedLogger.class org/jboss/logging/Message.class org/jboss/logging/MDC.class org/jboss/logging/Message$Format.class org/jboss/logging/JBossLogManagerProvider$1.class org/jboss/logging/Cause.class org/jboss/logging/Param.class org/jboss/logging/JDKLogger$1.class org/jboss/logging/JBossLogManagerLogger.class org/jboss/logging/Slf4jLogger.class org/jboss/logging/JBossLogManagerProvider.class org/jboss/logging/FormatWith.class org/jboss/logging/Slf4jLocationAwareLogger$1.class org/jboss/logging/Logger$Level.class org/jboss/logging/BasicLogger.class org/jboss/logging/Logger$1.class org/jboss/logging/JDKLogger.class org/jboss/logging/JBossLogManagerLogger$1.class org/jboss/logging/MessageLogger.class org/jboss/logging/ParameterConverter.class org/jboss/logging/Logger.class org/jboss/logging/Slf4jLocationAwareLogger.class org/jboss/logging/Log4jLogger.class org/jboss/logging/LoggerProviders$1.class org/jboss/logging/Slf4jLogger$1.class org/jboss/logging/AbstractLoggerProvider$Entry.class org/jboss/logging/LogMessage.class org/jboss/logging/LoggerProviders.class I excluded the jboss-logging from all hibernate dependencies like this: org.hibernate hibernate-validator ${hibernate.validator.version} org.jboss.logging jboss-logging No more duplicate classes :) . I run the same task again and here's the performance: [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1:30:04.829s [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014 [INFO] Final Memory: 118M/512M [INFO] ------------------------------------------------------------------------ 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And on top of this no Log4j messages are coming through :( This is probably a bug or I'm clearly missing how to setup Hibernate and LOG4J2. Can you please help me, or at least point me to a forum or mailing list where I can post this. --------------------------------------------------------------------------------------------------------- -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140711/469657fd/attachment-0001.html From brian.stansberry at redhat.com Fri Jul 11 10:33:11 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 11 Jul 2014 09:33:11 -0500 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BFE4F0.402@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53BFE4F0.402@redhat.com> Message-ID: <53BFF5A7.6080605@redhat.com> On 7/11/14, 8:21 AM, Scott Marlow wrote: > On 07/10/2014 10:23 AM, Emmanuel Hugonnet wrote: > > Should the application server terminate (with a failure code) when > errors occur during boot? This might make it more obvious that the > server didn't start correctly and that logs should be scanned for the > cause. > At some point we'll offer an option for that, but I don't see it becoming our only mode of operation. Personally, I don't like having the default being continuing to run "normally." Brainstorming a bit, I could also see having the server switch into admin-only mode instead of terminating. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From kabir.khan at jboss.com Fri Jul 11 13:35:23 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 11 Jul 2014 18:35:23 +0100 Subject: [wildfly-dev] Legacy subsystem tests Message-ID: I?ve pulled out the legacy test controllers for subsystem-test and core-model-test to a separate repository at https://github.com/wildfly/wildfly-legacy-test. Once https://github.com/wildfly/wildfly-core/pull/25 has been merged and released in the next wildfly-core release this means that you will be able to test your 7.1.x controllers again. By default only 7.2.0 (EAP 6.1.x transformations get run). To run the 7.1.x tests you will need to pass in: -Djboss.test.transformers.subsystem.old - for subsystem tests -Djboss.test.transformers.core.old - for core model tests -Djboss.test.transformers.eap - is used to enable EAP tests as before The -Djboss.test.transformers.subsystem.old and -Djboss.test.transformers.core.old will presently also enable testing against WildFly 8, although there is no controller for that at present in https://github.com/wildfly/wildfly-legacy-test. We will look at adding that next week. One thing which should make everybody?s lives a bit easier it that once this is merged there well no longer be old versions of wildfly-core classes on the classpath, so you will now only get one copy of e.g. ModelControllerImpl when searching in your IDE. From stuart.w.douglas at gmail.com Fri Jul 11 17:15:35 2014 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sat, 12 Jul 2014 07:15:35 +1000 Subject: [wildfly-dev] EJB3 + Java security manager error during TCK testing... In-Reply-To: <53BFEA6B.2060503@redhat.com> References: <53BFEA6B.2060503@redhat.com> Message-ID: <53C053F7.1010808@gmail.com> https://github.com/wildfly/wildfly/pull/6505 Stuart Scott Marlow wrote: > Can someone look into http://paste.fedoraproject.org/117262/08612514 > > Its a Permission check failed for ("java.lang.RuntimePermission" > "getProtectionDomain") from > org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.getEJBObject > or org.jboss.as.ejb3.context.SessionContextImpl.getEJBObject > > Thanks, > Scott > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From kabir.khan at jboss.com Fri Jul 11 17:18:54 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 11 Jul 2014 22:18:54 +0100 Subject: [wildfly-dev] Legacy subsystem tests In-Reply-To: References: Message-ID: On 11 Jul 2014, at 18:35, Kabir Khan wrote: > I?ve pulled out the legacy test controllers for subsystem-test and core-model-test to a separate repository at https://github.com/wildfly/wildfly-legacy-test. > > Once https://github.com/wildfly/wildfly-core/pull/25 has been merged and released in the next wildfly-core release this means that you will be able to test your 7.1.x controllers again. > > By default only 7.2.0 (EAP 6.1.x transformations get run). To run the 7.1.x tests you will need to pass in: > > -Djboss.test.transformers.subsystem.old - for subsystem tests > -Djboss.test.transformers.core.old - for core model tests > > -Djboss.test.transformers.eap - is used to enable EAP tests as before > > > The -Djboss.test.transformers.subsystem.old and -Djboss.test.transformers.core.old will presently also enable testing against WildFly 8, although there is no controller for that at present in https://github.com/wildfly/wildfly-legacy-test. We will look at adding that next week. There actually seems to be no need for a WF 8 controller at the moment, as the current one is compatible. Still it is probably best to add one > > One thing which should make everybody?s lives a bit easier it that once this is merged there well no longer be old versions of wildfly-core classes on the classpath, so you will now only get one copy of e.g. ModelControllerImpl when searching in your IDE. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Fri Jul 11 18:59:15 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Sat, 12 Jul 2014 00:59:15 +0200 Subject: [wildfly-dev] Legacy subsystem tests In-Reply-To: References: Message-ID: On Fri, Jul 11, 2014 at 11:18 PM, Kabir Khan wrote: > There actually seems to be no need for a WF 8 controller at the moment That might not be 100% true, I was doing some cleanup that removed lots deprecated api in wildfly-controller master In case some legacy versions subsystems ware using that api in 8.x it could break. AFAIK there are only handful of cases that we ware using deprecated api in subsystems in 8.x but there ware few. We can go on and use current test controller and later add 8.x if needed. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140712/b905cee3/attachment.html From kabir.khan at jboss.com Sat Jul 12 03:44:58 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Sat, 12 Jul 2014 08:44:58 +0100 Subject: [wildfly-dev] Legacy subsystem tests In-Reply-To: References: Message-ID: You?re right. I ran into some problems, and realised that is most likely the reason. I?ll try to add the 8.0 controller this week On 11 Jul 2014, at 23:59, Toma? Cerar wrote: > > On Fri, Jul 11, 2014 at 11:18 PM, Kabir Khan wrote: > There actually seems to be no need for a WF 8 controller at the moment > > > That might not be 100% true, I was doing some cleanup that removed lots deprecated api in wildfly-controller master > In case some legacy versions subsystems ware using that api in 8.x it could break. > > AFAIK there are only handful of cases that we ware using deprecated api in subsystems in 8.x but there ware few. > > We can go on and use current test controller and later add 8.x if needed. > > -- > tomaz From brian.stansberry at redhat.com Mon Jul 14 11:12:21 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 14 Jul 2014 10:12:21 -0500 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C3E823.9050009@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53BF99FD.30005@redhat.com> <53C3E823.9050009@redhat.com> Message-ID: <53C3F355.3000603@redhat.com> On 7/14/14, 9:24 AM, Brian Stansberry wrote: > On 7/11/14, 3:02 AM, Emmanuel Hugonnet wrote: >> So we could have something like : >> boot-errors => { >> boot-error => { > > operation => operationModelNode.asString(); > > For this structure to work, it would need to be a list. > > boot-errors => [ { > operation => ... > ... > }, > { > operations => ... > } > ] > > That's a list whose elements are complex items. > > A hassle here is we are working to get rid of such attributes and > convert them to child resources. To do that though we'd need > > 1) to have those be child resources, we'd need some id for each boot > error. I don't really see a pure one; the best I can think of would be a > CLI-syntax like conversion of the operation address and name. > > 2) we need some solid way of provide a list-like ordered semantic for > child resources. > > The latter is a big issue that should not block this, so I don't think > you should work initially toward child resources, and instead toward a > list. I was chatting a bit with David and he kindly pointed out that this doesn't have to be a resource or attribute at all; it can just be an operation response. > > > or should we clone the whole operation modelNode ? > > We should make the ModelNode structure available. (Aside: we'll need to > sanitize it for RBAC unless we make all this data security sensitive.) > >> failures => { >> service-name => stackTrace; >> .... >> }; >> missing-deps => list of missing dependencies as String; >> }; > > You can't count on there being that kind of data for individual boot > operations. When all the Stage.RUNTIME steps have run, that kind of data > is gathered for the overall large set of boot ops (see [1]) but not for > each individual boot op, which are just steps processed by the > OperationContext. The data available for each step is just any exception > thrown by the OperationStepHandler or any data it provides using > OperationContext.getFailureDescription(). See [2]. > >> }; >> returned from a read-boot-errors operation. >> >> I'm wondering also if we should have a "has-boot-errors" operation >> which would be useful to just display/check the status ? > > What are the chances a caller would call that and then not read the > errors if there are any? There's a bit of value (smaller payload) if > there will be such callers. > > I suspect what any such caller would more likely want though would be > some representation of the current state vs the boot state. The > "failures => ..., missing-deps =>" data, but currently rather than what > happened at boot. > > > [1] > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L457 > > > [2] > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L613 > for the exception case and just a bit above, > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L605 > for the getFailureDescription() case. > >> >> Emmanuel >> >> Le 10/07/2014 16:23, Emmanuel Hugonnet a ?crit : >>> # Ability to read boot errors via WildFly Management APIs >>> >>> Tracked by https://issues.jboss.org/browse/WFLY-543 >>> >>> Use Cases >>> --------- >>> >>> If a server starts but reported errors during boot, there is no way >>> to access the error data via the Management API and users are reduced to >>> searching the logs. >>> This information needs to be captured and stored for later reporting. >>> If some problem happens that gets logged at boot but somehow doesn't >>> become visible to the management layer, that's out of scope. A problem >>> getting logged but not becoming visible would basically mean some >>> runtime service logged an error but the error didn't prevent the >>> start of >>> the service. >>> >>> Implementation >>> -------------- >>> Create a new sub resource of core-service=service-container because >>> it has the ability to dump services, thus having all the services boot >>> errors and missing dependencies near seems like a good place. >>> thus we would have : >>> core-service => service-container { >>> boot-errors => { >>> failures => { >>> service-name => stackTrace; >>> .... >>> } >>> missing-deps => { >>> ... list of missing dependencies as String >>> } >>> } >>> } >>> >>> This structure is based on the structure of the failure description >>> returned during verification when starting a service. >>> All these informations should be collected in the ModelControllerImpl. >>> This resource would have restricted access of course. >>> >>> What do you think? >>> >>> Emmanuel >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Jul 14 10:24:35 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 14 Jul 2014 09:24:35 -0500 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BF99FD.30005@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53BF99FD.30005@redhat.com> Message-ID: <53C3E823.9050009@redhat.com> On 7/11/14, 3:02 AM, Emmanuel Hugonnet wrote: > So we could have something like : > boot-errors => { > boot-error => { > operation => operationModelNode.asString(); For this structure to work, it would need to be a list. boot-errors => [ { operation => ... ... }, { operations => ... } ] That's a list whose elements are complex items. A hassle here is we are working to get rid of such attributes and convert them to child resources. To do that though we'd need 1) to have those be child resources, we'd need some id for each boot error. I don't really see a pure one; the best I can think of would be a CLI-syntax like conversion of the operation address and name. 2) we need some solid way of provide a list-like ordered semantic for child resources. The latter is a big issue that should not block this, so I don't think you should work initially toward child resources, and instead toward a list. > or should we clone the whole operation modelNode ? We should make the ModelNode structure available. (Aside: we'll need to sanitize it for RBAC unless we make all this data security sensitive.) > failures => { > service-name => stackTrace; > .... > }; > missing-deps => list of missing dependencies as String; > }; You can't count on there being that kind of data for individual boot operations. When all the Stage.RUNTIME steps have run, that kind of data is gathered for the overall large set of boot ops (see [1]) but not for each individual boot op, which are just steps processed by the OperationContext. The data available for each step is just any exception thrown by the OperationStepHandler or any data it provides using OperationContext.getFailureDescription(). See [2]. > }; > returned from a read-boot-errors operation. > > I'm wondering also if we should have a "has-boot-errors" operation which would be useful to just display/check the status ? What are the chances a caller would call that and then not read the errors if there are any? There's a bit of value (smaller payload) if there will be such callers. I suspect what any such caller would more likely want though would be some representation of the current state vs the boot state. The "failures => ..., missing-deps =>" data, but currently rather than what happened at boot. [1] https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L457 [2] https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L613 for the exception case and just a bit above, https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L605 for the getFailureDescription() case. > > Emmanuel > > Le 10/07/2014 16:23, Emmanuel Hugonnet a ?crit : >> # Ability to read boot errors via WildFly Management APIs >> >> Tracked by https://issues.jboss.org/browse/WFLY-543 >> >> Use Cases >> --------- >> >> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >> searching the logs. >> This information needs to be captured and stored for later reporting. >> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >> the service. >> >> Implementation >> -------------- >> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >> errors and missing dependencies near seems like a good place. >> thus we would have : >> core-service => service-container { >> boot-errors => { >> failures => { >> service-name => stackTrace; >> .... >> } >> missing-deps => { >> ... list of missing dependencies as String >> } >> } >> } >> >> This structure is based on the structure of the failure description returned during verification when starting a service. >> All these informations should be collected in the ModelControllerImpl. >> This resource would have restricted access of course. >> >> What do you think? >> >> Emmanuel >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Mon Jul 14 20:23:30 2014 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 14 Jul 2014 17:23:30 -0700 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53BEA1FB.2070408@redhat.com> References: <53BEA1FB.2070408@redhat.com> Message-ID: <53C47482.1040808@redhat.com> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: > # Ability to read boot errors via WildFly Management APIs > > Tracked by https://issues.jboss.org/browse/WFLY-543 > > Use Cases > --------- > > If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to > searching the logs. > This information needs to be captured and stored for later reporting. > If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem > getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of > the service. > > Implementation > -------------- > Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot > errors and missing dependencies near seems like a good place. > thus we would have : > core-service => service-container { > boot-errors => { > failures => { > service-name => stackTrace; > .... > } > missing-deps => { > ... list of missing dependencies as String > } > } > } > > This structure is based on the structure of the failure description returned during verification when starting a service. > All these informations should be collected in the ModelControllerImpl. > This resource would have restricted access of course. > > What do you think? > > Emmanuel > > > > _______________________________________________ > 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/20140714/1053ff72/attachment.html From jperkins at redhat.com Mon Jul 14 11:29:47 2014 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 14 Jul 2014 08:29:47 -0700 Subject: [wildfly-dev] Hibernate + Log4J2 Performance Problem In-Reply-To: References: Message-ID: <53C3F76B.5030900@redhat.com> This would probably a better conversion on the forum, https://community.jboss.org/en/wildfly/content. WildFly does not currently provide log4j2 and no longer uses jboss-logging-log4j. On 07/11/2014 07:32 AM, Petar Tahchiev wrote: > Hi guys, > > I'm reposting this from hibernate-dev following the advice I was given > there. > ----------------------------------------------------------------------------------------------------------- > So here's my question. I'm reading this issue: > > https://issues.jboss.org/browse/JBLOGGING-95 > > and I'm trying to make my hibernate use log4j2. So far I had > > > org.jboss.logging > jboss-logging-log4j > ${jboss.logging.version} > > > and I have log4j -> log4j2 routed. Unfortunately now my hibernate > creates a log4j.log file and log4j prints the messages to the command > line (still no log4j2) :( > > So I got rid of this dependency and I added the jboss-logging. So now > here's my set of jars: > > hibernate-core > hibernate-entitymanager > hibernate-c3p0 > hibernate-validator > log4j2 > org.jboss.logging:jboss-logging:jar:3.2.0.Beta1 > > then I run my task and I get performance of: > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 3:12.951s > [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014 > [INFO] Final Memory: 128M/508M > [INFO] > ------------------------------------------------------------------------ > > 3 minutes and 12 seconds. Performance is quite good. However I use the > maven enforcer plugin and maven did warn me I have duplicate classes: > > Duplicate classes found: > > Found in: > org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile > org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile > Duplicate classes: > org/jboss/logging/Field.class > org/jboss/logging/LoggerProvider.class > org/jboss/logging/Log4jLoggerProvider.class > org/jboss/logging/NDC.class > org/jboss/logging/MessageBundle.class > org/jboss/logging/AbstractMdcLoggerProvider.class > org/jboss/logging/Log4jLogger$1.class > org/jboss/logging/Messages$1.class > org/jboss/logging/JDKLevel.class > org/jboss/logging/DelegatingBasicLogger.class > org/jboss/logging/JDKLoggerProvider.class > org/jboss/logging/Slf4jLoggerProvider.class > org/jboss/logging/LoggingClass.class > org/jboss/logging/Messages.class > org/jboss/logging/AbstractLoggerProvider.class > org/jboss/logging/Property.class > org/jboss/logging/JBossLogRecord.class > org/jboss/logging/SerializedLogger.class > org/jboss/logging/Message.class > org/jboss/logging/MDC.class > org/jboss/logging/Message$Format.class > org/jboss/logging/JBossLogManagerProvider$1.class > org/jboss/logging/Cause.class > org/jboss/logging/Param.class > org/jboss/logging/JDKLogger$1.class > org/jboss/logging/JBossLogManagerLogger.class > org/jboss/logging/Slf4jLogger.class > org/jboss/logging/JBossLogManagerProvider.class > org/jboss/logging/FormatWith.class > org/jboss/logging/Slf4jLocationAwareLogger$1.class > org/jboss/logging/Logger$Level.class > org/jboss/logging/BasicLogger.class > org/jboss/logging/Logger$1.class > org/jboss/logging/JDKLogger.class > org/jboss/logging/JBossLogManagerLogger$1.class > org/jboss/logging/MessageLogger.class > org/jboss/logging/ParameterConverter.class > org/jboss/logging/Logger.class > org/jboss/logging/Slf4jLocationAwareLogger.class > org/jboss/logging/Log4jLogger.class > org/jboss/logging/LoggerProviders$1.class > org/jboss/logging/Slf4jLogger$1.class > org/jboss/logging/AbstractLoggerProvider$Entry.class > org/jboss/logging/LogMessage.class > org/jboss/logging/LoggerProviders.class > > I excluded the jboss-logging from all hibernate dependencies like this: > > org.hibernate > hibernate-validator > ${hibernate.validator.version} > > > org.jboss.logging > jboss-logging > > > > > No more duplicate classes :) . I run the same task again and here's > the performance: > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 1:30:04.829s > [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014 > [INFO] Final Memory: 118M/512M > [INFO] > ------------------------------------------------------------------------ > > 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? > And on top of this no Log4j messages are coming through :( > > This is probably a bug or I'm clearly missing how to setup Hibernate > and LOG4J2. Can you please help me, or at least point me to a forum or > mailing list where I can post this. > > --------------------------------------------------------------------------------------------------------- > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > > > _______________________________________________ > 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/20140714/492f4944/attachment-0001.html From ewertz at redhat.com Tue Jul 15 23:40:49 2014 From: ewertz at redhat.com (Edward Wertz) Date: Tue, 15 Jul 2014 23:40:49 -0400 (EDT) Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <53BC028D.7050904@redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> <53BC028D.7050904@redhat.com> Message-ID: <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> I've got a better broad solution to this now, but I'm having some trouble figuring out how to create limitations on the functionality. I added a 'resolve-expressions' parameter to ':read-attribute', which can enable the handler to simply call ModelNode.resolve() on the return value and replace all the expressions with their runtime values from that server. That parameter can simply be passed down the command chain from the 'ls' and ':read-resource' commands to get the functionality. A lot cleaner than executing resolve-expression operations for each expression returned to the CLI I think. However, the issue is how to limit it within the configuration tree. I've been trying to figure out how to add something to the description that identifies locations where a resolve would be valid, but the problem with this idea seems to be that the ':read-resource-description' on the '/profile=*' areas resolves all that information against the HC by treating it like any normal server. There doesn't seem to be a way to tell the difference between values returned from a HC and values returned from a 'live' server simply from the description. Is there some way to identify that a command is getting executed on a HC within the actual HC? Or to get that information back out of the HC? I don't think there's a place on a live server where this functionality needs to be restricted, so if it can somehow be identified that the execution is on a HC it could be easier to restrict the functionality to things that are valid on *both* the HC and live server. However, this is sounding more like a server-side error-handling pattern, which isn't what we wanted originally. Thoughts? Joe Wertz ----- Original Message ----- > On 07/08/2014 03:27 PM, Brian Stansberry wrote: > > On 7/8/14, 6:37 AM, Edward Wertz wrote: > >> > >> > >> ----- Original Message ----- > >>> On 7/7/14, 12:36 AM, Edward Wertz wrote: > >>>> I've been thinking about the UX considerations over the last > >>>> week. > >>>> Generally there seem to be 3 basic situations involved. > >>>> > >>>> 1) There can be expressions in the result and the CLI can, in > >>>> some > >>>> manner, successfully resolve those expressions. This is > >>>> dependent > >>>> on the context that the command/operation is executed in, > >>>> domain/standalone mode and the location in the configuration > >>>> tree, > >>>> but seems solvable. > >>>> > >>>> 2) There can be expressions in the result and the CLI can't > >>>> resolve > >>>> those expressions. For example if they're looking at a domain > >>>> profile there's nothing to resolve against. > >>>> > >>>> 3) There won't be expressions in the result. There are lots of > >>>> places in the CLI that would never return an expression. Which > >>>> means the user would never need the argument/param. > >>>> > >>>> I think it's ok to hide the argument/param in situation 3. If > >>>> expressions won't show up in the results there's no reason to > >>>> have > >>>> an option to resolve them really. It seems confusing to include > >>>> it > >>>> here. > >>>> > >>> > >>> I don't really follow this. For sure we won't include any > >>> --resolve-expressions param on commands where it isn't relevant, > >>> like > >>> 'cd' or something. If that's what you mean, that's fine. > >>> Otherwise I > >>> don't see what situation you're referring to. > >>> > >> > >> I'm thinking about this as it applies to the 'ls' command mostly, > >> since it seems to be the broadest command and is available > >> basically everywhere in the system tree. However, there are lots > >> of locations in that tree where expressions simply would never > >> exist aren't there? Would 'ls' on the root ever return an > >> expression? That information is all version numbers and names > >> and, I suspect, it's impossible to see an expression at that > >> location. Thus no reason to have the ability to resolve one. I'm > >> thinking it's ok to hide the argument in that situation. I'm not > >> sure how widely this problem exists with other operations and > >> commands though. ls might be somewhat unique in this regard since > >> it's available throughout the entire CLI. > >> > > > > Ok, I don't think we should worry about this. IMHO it would be > > confusing, since it would cause the --resolve-expressions param to > > not > > appear in locations where the user would have no intuitive > > understanding > > as to why not. > > > > My assumption here is if --resolve-expressions were set, attributes > > that > > didn't have expressions would be displayed as they are now. So if a > > user > > set the param where there were no actual expressions, there's no > > harm. > > Right. Joe, keep in mind that hiding arguments as not exposing them > through the tab-completion is one thing, any argument and any rubbish > may still appear on the command line just because the user is able > type > in whatever the keyboard is capable of. We'll still have to recognize > the context of the input and decide what to do. > So, don't overcomplicate the tab-completion logic. > > Alexey > > > > >>>> The main question is what to do in situation 2, where there will > >>>> be > >>>> expressions in a result but it's impossible to resolve. Hiding > >>>> the > >>>> argument there seems like it could be confusing for people. > >>>> They'll see an expression and if they know the argument is > >>>> available elsewhere they'll wonder why they can't use it here. > >>>> Frustration ensues. I think it would be better to have some type > >>>> of error message explaining, somehow, that their location within > >>>> the configuration tree doesn't allow for expressions to be > >>>> resolved. I'm not sure what it should say though or how many of > >>>> these situations exist. Any suggestions? > >>>> > >>> > >>> There are actually 2 variants of 2). One is the expression can't > >>> be > >>> resolved at all, and the other is it can be resolved, but the > >>> resolution > >>> is not meaningful because the resolutions is not occurring in a > >>> meaningful process. > >>> > >>> For example, in a managed domain, /profile=x/subsystem=y: > >>> > >>> max-size="${com.user.thingy.max-size:10} > >>> > >>> That can always be resolved, but the resolution is meaningless > >>> except > >>> on > >>> a server at /host=a/server=1/subsystem=y. > >>> > >>> A another example would be: > >>> > >>> enabled="${java.net.preferIPv4Stack}" > >>> > >>> where the system property might be set on a Host Controller, so > >>> it > >>> resolves, but again the value is meaningless because a server > >>> might > >>> have > >>> a different value for the system property. > >>> > >>> Because of this, simply trying to resolve the expression and > >>> handling > >>> a > >>> failure will not work. (Sounds like a bad approach anyway.) The > >>> tool > >>> is > >>> going to have to know in advance whether the resolution can be > >>> performed. That would either have to be statically built into the > >>> tool > >>> (bad) or the management API is going to have to indicate this for > >>> each > >>> resource. I see the latter being done by either adding a param to > >>> the > >>> API of read-resource-description for resources where it is > >>> allowed, > >>> or > >>> by creating a separate op registered only where allowed. > >>> > >>> Any error handling I want done client side, i.e. if you and > >>> Alexey > >>> decide to add --resolve-expressions everywhere and then put out a > >>> failure if it's not supported, I want the CLI to decide to fail > >>> based > >>> on > >>> the management metadata, not to count on the server side > >>> providing > >>> some > >>> expected failure if it's not supported. > >>> > >> > >> I definitely agree. I didn't make that clear, but it was always my > >> intention for it to be a pre-determined failure message. I lumped > >> the 'meaningless' resolve in with 'no resolve', and thought the > >> CLI should be able to determine based on the location in the tree > >> whether a resolve makes any sense. If it doesn't, an error > >> message would stop the command from executing and tell the user > >> it's not possible to resolve expressions at this location. > >> > > > > Ok, good. For the CLI to determine if the command is present it > > will > > need to do a :read-resource-description call against the current > > resource address. > > > >>>> The other question is whether there are situations where 1 and 2 > >>>> actually overlap. Where some expressions are resolvable, but > >>>> others are not. I haven't been able to figure out if that's an > >>>> actual problem yet. > >>>> > >>>> I'm going to implement the ability to hide the argument for the > >>>> 'ls' command this week, which Alexey pointed me towards on > >>>> Friday, > >>>> and look into how to add a param to the server-side operations. > >>>> Once I have both working successfully I'll try to create a > >>>> comprehensive list of all the applicable situations I can figure > >>>> out. No sense in doing that before I can get it actually working > >>>> for both the CLI commands and server-side operations first. > >>>> > >>> > >>> What's tricky is the subtree under host=*, excluding > >>> host=*/server=*. > >>> Everything in a domain not under host=* is cannot support > >>> resolution, > >>> and everything under host=*/server=* can. > >>> > >>> Places where this is an issue are: > >>> > >>> /host=*/system-property=* > >>> > >>> This resource is not relevant on the HC process; it drives the > >>> config > >>> of > >>> the server. So --resolve-expressions cannot be supported here. > >>> > >>> /host=*/path=* > >>> > >>> This one is a bit tricky, as the expression must be resolvable on > >>> the > >>> HC, so --resolve-expressions could work, but it's possible that > >>> the > >>> path > >>> gets passed to the server and gets resolved differently there. > >>> But I > >>> think that's an ok semantic. > >>> > >>> /host=*/interface=* > >>> > >>> Same as path. > >>> > >>> /host=*/server-config=*/system-property=* > >>> /host=*/server-config=*/interface=* > >>> /host=*/server-config=*/path=* > >>> > >>> None of these resources are relevant on the HC process; they > >>> drive > >>> the > >>> config of the server. So --resolve-expressions cannot be > >>> supported > >>> here. > >>> It can be supported on /host=*/server-config=* itself though. > >>> > >>>> Joe Wertz > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> > >>>>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: > >>>>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: > >>>>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: > >>>>>>>> Thanks, Joe, for looking into this. > >>>>>>>> > >>>>>>>> I'm curious what you've done so far with your 'ls > >>>>>>>> --resolve-expressions' > >>>>>>>> work. Did you use the existing > >>>>>>>> ':resolve-expression(expression=___)' low > >>>>>>>> level operation to process any expressions found in the > >>>>>>>> :read-resource > >>>>>>>> response? > >>>>>>>> > >>>>>>>> There are a few aspects of this I'd like to explore. > >>>>>>>> > >>>>>>>> One is the UX one. Is allowing 'resolve-expressions' in some > >>>>>>>> contexts > >>>>>>>> and not others a good UX? Will users understand that? I'm > >>>>>>>> ambivalent > >>>>>>>> about that, and am interested in others' opinions. > >>>>>>>> > >>>>>>>> If it can work for a server and for anything under /host=*, > >>>>>>>> then > >>>>>>>> I'm > >>>>>>>> ambivalent. Any restriction at all is unintuitive, but once > >>>>>>>> the > >>>>>>>> user > >>>>>>>> learns that there is a restriction, that's a pretty > >>>>>>>> understandable one. > >>>>>>>> If it only works for a patchwork of stuff under /host=* then > >>>>>>>> I'm > >>>>>>>> real > >>>>>>>> negative about it. An area of concern is > >>>>>>>> /host=*/server-config=*, > >>>>>>>> where > >>>>>>>> an expression might be irrelevant to the host, only > >>>>>>>> resolving > >>>>>>>> correctly > >>>>>>>> on the server that is created using that server-config. That > >>>>>>>> will > >>>>>>>> need > >>>>>>>> careful examination. > >>>>>>>> > >>>>>>>> A second one is how this data would be displayed with 'ls'. > >>>>>>>> A > >>>>>>>> separate > >>>>>>>> additional column? Or replacing the current data? The answer > >>>>>>>> to > >>>>>>>> this > >>>>>>>> might impact how it would be implemented server side. > >>>>>>> > >>>>>>> Keep in mind that ls is an example. There are other commands > >>>>>>> that > >>>>>>> will > >>>>>>> have to support this feature once it's implemented in one > >>>>>>> place. > >>>>>>> Another > >>>>>>> example is read-attribute command. The ability to resolve > >>>>>>> expressions > >>>>>>> elsewhere will be a natural expectation then. > >>>>>>> So, it has to be thought of as a general features that can be > >>>>>>> applied to > >>>>>>> various cli commands. > >>>>>>> > >>>>>> > >>>>>> Good point. Joe, we'd need a clear understanding of all the > >>>>>> commands > >>>>>> that would be affected. > >>>>> > >>>>> At this point, it's ls, read-attribute and commands handled by > >>>>> GenericTypeOperationHandler (which means [xa-]data-source, > >>>>> jms-topic, > >>>>> -queue, -connection-factory, etc). > >>>>> > >>>>> The generic handler includes action read-resource (e.g. w/o > >>>>> other > >>>>> optional arguments 'data-source read-resource > >>>>> --name=ExampleDS'), > >>>>> which > >>>>> is basically a formatted result of :read-resource. > >>>>> > >>>>> In general, it could be applied to any command displaying an > >>>>> attribute > >>>>> value to the user. > >>>>> > >>>>> Alexey > >>>>> > >>>>>> > >>>>>>> IMO, the values returned should just be replaced with the > >>>>>>> resolved > >>>>>>> ones > >>>>>>> for display. Some commands support --verbose argument, in > >>>>>>> which > >>>>>>> case > >>>>>>> additional info is displayed in columns, there we could > >>>>>>> include > >>>>>>> the > >>>>>>> original value. > >>>>>>> The output of the cli commands in some cases is parsed by > >>>>>>> scripts > >>>>>>> or > >>>>>>> other code, so keeping it simple will help there too. > >>>>>>> > >>>>>>>> The third aspect is the technical issue of how to make any > >>>>>>>> 'resolve-expressions' param or CLI argument available in > >>>>>>>> certain > >>>>>>>> contexts and not in others. That's very likely solvable on > >>>>>>>> the > >>>>>>>> server > >>>>>>>> side; not sure how difficult it would be in the CLI > >>>>>>>> high-level > >>>>>>>> command. > >>>>>>> > >>>>>>> Current tab-completion supports dependencies of command > >>>>>>> arguments > >>>>>>> and > >>>>>>> their values on the current context (connection to the > >>>>>>> controller, > >>>>>>> standalone/domain mode, the presence of other arguments on > >>>>>>> the > >>>>>>> line and > >>>>>>> the values specified for them, etc). Technically, there > >>>>>>> shouldn't > >>>>>>> be an > >>>>>>> issue. > >>>>>> > >>>>>> Ok, good. > >>>>>> > >>>>>>> I am more concerned about how intuitive that will look like > >>>>>>> for > >>>>>>> the user > >>>>>>> in various contexts. > >>>>>>> > >>>>>> > >>>>>> Yes, I think the UX aspects are the more significant ones. > >>>>>> > >>>>>>> Alexey > >>>>>>> > >>>>>>>> FYI, for others reading this, offline Joe pointed out > >>>>>>>> there's a > >>>>>>>> related > >>>>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. > >>>>>>>> > >>>>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: > >>>>>>>>> I'm looking into whether it's possible to automatically > >>>>>>>>> resolve > >>>>>>>>> expressions when executing operations and commands in the > >>>>>>>>> CLI. > >>>>>>>>> > >>>>>>>>> >From my understanding, there are two variations of the > >>>>>>>>>> problem. > >>>>>>>>> > >>>>>>>>> * Operations are server-side processes that are > >>>>>>>>> accessed > >>>>>>>>> via ':' in the CLI and, currently, the CLI presents > >>>>>>>>> the > >>>>>>>>> results returned as-is to the users. ex: > >>>>>>>>> ':read-resource' > >>>>>>>>> > >>>>>>>>> * Commands are processes that get manipulated by > >>>>>>>>> the CLI > >>>>>>>>> before getting presented to users. ex: 'ls' > >>>>>>>>> > >>>>>>>>> I've been experimenting with adding arguments to the CLI > >>>>>>>>> commands, like 'ls --resolve-expressions', and gotten it > >>>>>>>>> working for the standalone and domain side of things. > >>>>>>>>> However, > >>>>>>>>> I can't control the scope of the argument, so it's > >>>>>>>>> available > >>>>>>>>> in > >>>>>>>>> situations that cannot accurately resolve expressions like > >>>>>>>>> the > >>>>>>>>> 'profile=full' section of the domain tree. The results > >>>>>>>>> wouldn't > >>>>>>>>> be reliable. > >>>>>>>>> > >>>>>>>>> The same problem would apply to adding parameters to the > >>>>>>>>> server-side operations. The scope of the operations > >>>>>>>>> themselves > >>>>>>>>> can be controlled, but not their parameters. An execution > >>>>>>>>> like > >>>>>>>>> ':read-resource(recursive=true resolve-expressions=true)' > >>>>>>>>> can't > >>>>>>>>> resolve expressions unless it's used against an actual > >>>>>>>>> server > >>>>>>>>> or host, but the operation is available almost everywhere. > >>>>>>>>> Again, the results wouldn't be reliable. > >>>>>>>>> > >>>>>>>>> I'm wondering if anyone can suggest a way to attack this > >>>>>>>>> problem? There is already a > >>>>>>>>> ':resolve-expression(expression=___)' operation, so users > >>>>>>>>> can > >>>>>>>>> somewhat laboriously get the runtime values they want, but > >>>>>>>>> I > >>>>>>>>> can't figure out a way to integrate the values into the > >>>>>>>>> existing framework successfully. Other than creating > >>>>>>>>> entirely > >>>>>>>>> new operations and commands, like 'ls-resolve' and > >>>>>>>>> ':read-resource-resolve', which seems like an unsustainable > >>>>>>>>> way > >>>>>>>>> to solve the problem. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Joe Wertz > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Wed Jul 16 06:21:29 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 16 Jul 2014 12:21:29 +0200 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> <53BC028D.7050904@redhat.com> <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> Message-ID: On Wed, Jul 16, 2014 at 5:40 AM, Edward Wertz wrote: > However, the issue is how to limit it within the configuration tree. Why would you want to limit it? read-resource/read-attribute operation will be executed in right context anyway and .resolve() will work properly. (at least i think so) anyhow you can get what you are looking for with context.getRunningMode() -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140716/89753771/attachment.html From ewertz at redhat.com Wed Jul 16 09:23:49 2014 From: ewertz at redhat.com (Edward Wertz) Date: Wed, 16 Jul 2014 09:23:49 -0400 (EDT) Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> <53BC028D.7050904@redhat.com> <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> Message-ID: <27283700.509.1405517023593.JavaMail.joe@dhcp-17-61.nay.redhat.com> The issue from a UX perspective is that resolving values against the host controller leads to uninformative failures or meaningless information. There's no sense in resolving an expression in a profile against the HC, if the expression is even in that JVM to be resolved, since the values on the servers aren't dependent on that at all. A user could leave that experience thinking they have accurate information about their servers when they actually don't. I'd prefer the functionality to be disabled with an informative error message. Joe ----- Original Message ----- > > > > > On Wed, Jul 16, 2014 at 5:40 AM, Edward Wertz < ewertz at redhat.com > > wrote: > > > However, the issue is how to limit it within the configuration tree. > > > Why would you want to limit it? > > > read-resource/read-attribute operation will be executed in right > context anyway and .resolve() will work properly. (at least i think > so) > > > anyhow you can get what you are looking for with > context.getRunningMode() > > > -- > > tomaz > From brian.stansberry at redhat.com Wed Jul 16 14:21:13 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 16 Jul 2014 13:21:13 -0500 Subject: [wildfly-dev] Automatically resolving expressions in the CLI In-Reply-To: <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> References: <924955857.34071548.1403779269224.JavaMail.zimbra@redhat.com> <53AD83A4.10004@redhat.com> <53AD8D3D.1020301@redhat.com> <9465014.839.1404711377103.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BADC94.8060705@redhat.com> <17231034.1110.1404819425495.JavaMail.joe@dhcp-17-61.nay.redhat.com> <53BBF1BB.5040704@redhat.com> <53BC028D.7050904@redhat.com> <18410210.421.1405482037565.JavaMail.joe@dhcp-17-61.nay.redhat.com> Message-ID: <53C6C299.3000102@redhat.com> On 7/15/14, 10:40 PM, Edward Wertz wrote: > I've got a better broad solution to this now, but I'm having some trouble figuring out how to create limitations on the functionality. > > I added a 'resolve-expressions' parameter to ':read-attribute', which can enable the handler to simply call ModelNode.resolve() on the return value and replace all the expressions with their runtime values from that server. I assume you're referring to server-side handler, org.jboss.as.controller.operations.global.ReadAttributeHandler? You can't resolve expressions by calling ModelNode.resolve(), as that doesn't account for all the resolution sources available in a WildFly process, e.g. the security vault. An OperationStepHandler would do it via OperationContext.resolveExpressions(). > That parameter can simply be passed down the command chain from the 'ls' and ':read-resource' commands to get the functionality. A lot cleaner than executing resolve-expression operations for each expression returned to the CLI I think. > > However, the issue is how to limit it within the configuration tree. > > I've been trying to figure out how to add something to the description that identifies locations where a resolve would be valid, but the problem with this idea seems to be that the ':read-resource-description' on the '/profile=*' areas resolves all that information against the HC by treating it like any normal server. There doesn't seem to be a way to tell the difference between values returned from a HC and values returned from a 'live' server simply from the description. > There would need to be a separate instance of ReadAttributeHandler registered for the resources that support it, e.g. a new constant ReadAttributeHandler.RESOLVING_INSTANCE. The ReadAttributeHandler class should have a flag that determines whether an instance accepts this parameter, and it should fail if the client requests resolution and the flag is false. The existing ReadAttributeHandler.DEFINITION would not include this new param and the existing INSTANCE would set the flag to false. A separate OperationDefinition that includes the param would be used for the resources where resolution is supported, e.g. a ReadAttributeHandler.RESOLVING_DEFINITION. This new RESOLVING_DEFINITION and RESOLVING_INSTANCE can be registered at the root of any part of the resource tree that supports this. That registration will override the registration inherited from the root of the tree. Use the ManagementResourceRegistration.registerOperationHandler() variant that takes the "inherited" param to register it for an entire branch of the tree. The CLI knows if the resolution is supported by seeing if the :read-operation-description metadata for 'read-attribute' includes the parameter. I expect you'll want to do something similar with :read-resource (ReadResourceHandler) since calling :read-attribute for every attribute will kind of suck. > Is there some way to identify that a command is getting executed on a HC within the actual HC? Or to get that information back out of the HC? I don't think there's a place on a live server where this functionality needs to be restricted, so if it can somehow be identified that the execution is on a HC it could be easier to restrict the functionality to things that are valid on *both* the HC and live server. However, this is sounding more like a server-side error-handling pattern, which isn't what we wanted originally. > For *reads*, only addresses under /host=*/server=* execute on a server; all other reads in a domain execute on HCs. Writes are more complicated, but I don't believe that's relevant here. > Thoughts? > > Joe Wertz > > > ----- Original Message ----- >> On 07/08/2014 03:27 PM, Brian Stansberry wrote: >>> On 7/8/14, 6:37 AM, Edward Wertz wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> On 7/7/14, 12:36 AM, Edward Wertz wrote: >>>>>> I've been thinking about the UX considerations over the last >>>>>> week. >>>>>> Generally there seem to be 3 basic situations involved. >>>>>> >>>>>> 1) There can be expressions in the result and the CLI can, in >>>>>> some >>>>>> manner, successfully resolve those expressions. This is >>>>>> dependent >>>>>> on the context that the command/operation is executed in, >>>>>> domain/standalone mode and the location in the configuration >>>>>> tree, >>>>>> but seems solvable. >>>>>> >>>>>> 2) There can be expressions in the result and the CLI can't >>>>>> resolve >>>>>> those expressions. For example if they're looking at a domain >>>>>> profile there's nothing to resolve against. >>>>>> >>>>>> 3) There won't be expressions in the result. There are lots of >>>>>> places in the CLI that would never return an expression. Which >>>>>> means the user would never need the argument/param. >>>>>> >>>>>> I think it's ok to hide the argument/param in situation 3. If >>>>>> expressions won't show up in the results there's no reason to >>>>>> have >>>>>> an option to resolve them really. It seems confusing to include >>>>>> it >>>>>> here. >>>>>> >>>>> >>>>> I don't really follow this. For sure we won't include any >>>>> --resolve-expressions param on commands where it isn't relevant, >>>>> like >>>>> 'cd' or something. If that's what you mean, that's fine. >>>>> Otherwise I >>>>> don't see what situation you're referring to. >>>>> >>>> >>>> I'm thinking about this as it applies to the 'ls' command mostly, >>>> since it seems to be the broadest command and is available >>>> basically everywhere in the system tree. However, there are lots >>>> of locations in that tree where expressions simply would never >>>> exist aren't there? Would 'ls' on the root ever return an >>>> expression? That information is all version numbers and names >>>> and, I suspect, it's impossible to see an expression at that >>>> location. Thus no reason to have the ability to resolve one. I'm >>>> thinking it's ok to hide the argument in that situation. I'm not >>>> sure how widely this problem exists with other operations and >>>> commands though. ls might be somewhat unique in this regard since >>>> it's available throughout the entire CLI. >>>> >>> >>> Ok, I don't think we should worry about this. IMHO it would be >>> confusing, since it would cause the --resolve-expressions param to >>> not >>> appear in locations where the user would have no intuitive >>> understanding >>> as to why not. >>> >>> My assumption here is if --resolve-expressions were set, attributes >>> that >>> didn't have expressions would be displayed as they are now. So if a >>> user >>> set the param where there were no actual expressions, there's no >>> harm. >> >> Right. Joe, keep in mind that hiding arguments as not exposing them >> through the tab-completion is one thing, any argument and any rubbish >> may still appear on the command line just because the user is able >> type >> in whatever the keyboard is capable of. We'll still have to recognize >> the context of the input and decide what to do. >> So, don't overcomplicate the tab-completion logic. >> >> Alexey >> >>> >>>>>> The main question is what to do in situation 2, where there will >>>>>> be >>>>>> expressions in a result but it's impossible to resolve. Hiding >>>>>> the >>>>>> argument there seems like it could be confusing for people. >>>>>> They'll see an expression and if they know the argument is >>>>>> available elsewhere they'll wonder why they can't use it here. >>>>>> Frustration ensues. I think it would be better to have some type >>>>>> of error message explaining, somehow, that their location within >>>>>> the configuration tree doesn't allow for expressions to be >>>>>> resolved. I'm not sure what it should say though or how many of >>>>>> these situations exist. Any suggestions? >>>>>> >>>>> >>>>> There are actually 2 variants of 2). One is the expression can't >>>>> be >>>>> resolved at all, and the other is it can be resolved, but the >>>>> resolution >>>>> is not meaningful because the resolutions is not occurring in a >>>>> meaningful process. >>>>> >>>>> For example, in a managed domain, /profile=x/subsystem=y: >>>>> >>>>> max-size="${com.user.thingy.max-size:10} >>>>> >>>>> That can always be resolved, but the resolution is meaningless >>>>> except >>>>> on >>>>> a server at /host=a/server=1/subsystem=y. >>>>> >>>>> A another example would be: >>>>> >>>>> enabled="${java.net.preferIPv4Stack}" >>>>> >>>>> where the system property might be set on a Host Controller, so >>>>> it >>>>> resolves, but again the value is meaningless because a server >>>>> might >>>>> have >>>>> a different value for the system property. >>>>> >>>>> Because of this, simply trying to resolve the expression and >>>>> handling >>>>> a >>>>> failure will not work. (Sounds like a bad approach anyway.) The >>>>> tool >>>>> is >>>>> going to have to know in advance whether the resolution can be >>>>> performed. That would either have to be statically built into the >>>>> tool >>>>> (bad) or the management API is going to have to indicate this for >>>>> each >>>>> resource. I see the latter being done by either adding a param to >>>>> the >>>>> API of read-resource-description for resources where it is >>>>> allowed, >>>>> or >>>>> by creating a separate op registered only where allowed. >>>>> >>>>> Any error handling I want done client side, i.e. if you and >>>>> Alexey >>>>> decide to add --resolve-expressions everywhere and then put out a >>>>> failure if it's not supported, I want the CLI to decide to fail >>>>> based >>>>> on >>>>> the management metadata, not to count on the server side >>>>> providing >>>>> some >>>>> expected failure if it's not supported. >>>>> >>>> >>>> I definitely agree. I didn't make that clear, but it was always my >>>> intention for it to be a pre-determined failure message. I lumped >>>> the 'meaningless' resolve in with 'no resolve', and thought the >>>> CLI should be able to determine based on the location in the tree >>>> whether a resolve makes any sense. If it doesn't, an error >>>> message would stop the command from executing and tell the user >>>> it's not possible to resolve expressions at this location. >>>> >>> >>> Ok, good. For the CLI to determine if the command is present it >>> will >>> need to do a :read-resource-description call against the current >>> resource address. >>> >>>>>> The other question is whether there are situations where 1 and 2 >>>>>> actually overlap. Where some expressions are resolvable, but >>>>>> others are not. I haven't been able to figure out if that's an >>>>>> actual problem yet. >>>>>> >>>>>> I'm going to implement the ability to hide the argument for the >>>>>> 'ls' command this week, which Alexey pointed me towards on >>>>>> Friday, >>>>>> and look into how to add a param to the server-side operations. >>>>>> Once I have both working successfully I'll try to create a >>>>>> comprehensive list of all the applicable situations I can figure >>>>>> out. No sense in doing that before I can get it actually working >>>>>> for both the CLI commands and server-side operations first. >>>>>> >>>>> >>>>> What's tricky is the subtree under host=*, excluding >>>>> host=*/server=*. >>>>> Everything in a domain not under host=* is cannot support >>>>> resolution, >>>>> and everything under host=*/server=* can. >>>>> >>>>> Places where this is an issue are: >>>>> >>>>> /host=*/system-property=* >>>>> >>>>> This resource is not relevant on the HC process; it drives the >>>>> config >>>>> of >>>>> the server. So --resolve-expressions cannot be supported here. >>>>> >>>>> /host=*/path=* >>>>> >>>>> This one is a bit tricky, as the expression must be resolvable on >>>>> the >>>>> HC, so --resolve-expressions could work, but it's possible that >>>>> the >>>>> path >>>>> gets passed to the server and gets resolved differently there. >>>>> But I >>>>> think that's an ok semantic. >>>>> >>>>> /host=*/interface=* >>>>> >>>>> Same as path. >>>>> >>>>> /host=*/server-config=*/system-property=* >>>>> /host=*/server-config=*/interface=* >>>>> /host=*/server-config=*/path=* >>>>> >>>>> None of these resources are relevant on the HC process; they >>>>> drive >>>>> the >>>>> config of the server. So --resolve-expressions cannot be >>>>> supported >>>>> here. >>>>> It can be supported on /host=*/server-config=* itself though. >>>>> >>>>>> Joe Wertz >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> >>>>>>> On 06/27/2014 04:45 PM, Brian Stansberry wrote: >>>>>>>> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote: >>>>>>>>> On 06/26/2014 05:31 PM, Brian Stansberry wrote: >>>>>>>>>> Thanks, Joe, for looking into this. >>>>>>>>>> >>>>>>>>>> I'm curious what you've done so far with your 'ls >>>>>>>>>> --resolve-expressions' >>>>>>>>>> work. Did you use the existing >>>>>>>>>> ':resolve-expression(expression=___)' low >>>>>>>>>> level operation to process any expressions found in the >>>>>>>>>> :read-resource >>>>>>>>>> response? >>>>>>>>>> >>>>>>>>>> There are a few aspects of this I'd like to explore. >>>>>>>>>> >>>>>>>>>> One is the UX one. Is allowing 'resolve-expressions' in some >>>>>>>>>> contexts >>>>>>>>>> and not others a good UX? Will users understand that? I'm >>>>>>>>>> ambivalent >>>>>>>>>> about that, and am interested in others' opinions. >>>>>>>>>> >>>>>>>>>> If it can work for a server and for anything under /host=*, >>>>>>>>>> then >>>>>>>>>> I'm >>>>>>>>>> ambivalent. Any restriction at all is unintuitive, but once >>>>>>>>>> the >>>>>>>>>> user >>>>>>>>>> learns that there is a restriction, that's a pretty >>>>>>>>>> understandable one. >>>>>>>>>> If it only works for a patchwork of stuff under /host=* then >>>>>>>>>> I'm >>>>>>>>>> real >>>>>>>>>> negative about it. An area of concern is >>>>>>>>>> /host=*/server-config=*, >>>>>>>>>> where >>>>>>>>>> an expression might be irrelevant to the host, only >>>>>>>>>> resolving >>>>>>>>>> correctly >>>>>>>>>> on the server that is created using that server-config. That >>>>>>>>>> will >>>>>>>>>> need >>>>>>>>>> careful examination. >>>>>>>>>> >>>>>>>>>> A second one is how this data would be displayed with 'ls'. >>>>>>>>>> A >>>>>>>>>> separate >>>>>>>>>> additional column? Or replacing the current data? The answer >>>>>>>>>> to >>>>>>>>>> this >>>>>>>>>> might impact how it would be implemented server side. >>>>>>>>> >>>>>>>>> Keep in mind that ls is an example. There are other commands >>>>>>>>> that >>>>>>>>> will >>>>>>>>> have to support this feature once it's implemented in one >>>>>>>>> place. >>>>>>>>> Another >>>>>>>>> example is read-attribute command. The ability to resolve >>>>>>>>> expressions >>>>>>>>> elsewhere will be a natural expectation then. >>>>>>>>> So, it has to be thought of as a general features that can be >>>>>>>>> applied to >>>>>>>>> various cli commands. >>>>>>>>> >>>>>>>> >>>>>>>> Good point. Joe, we'd need a clear understanding of all the >>>>>>>> commands >>>>>>>> that would be affected. >>>>>>> >>>>>>> At this point, it's ls, read-attribute and commands handled by >>>>>>> GenericTypeOperationHandler (which means [xa-]data-source, >>>>>>> jms-topic, >>>>>>> -queue, -connection-factory, etc). >>>>>>> >>>>>>> The generic handler includes action read-resource (e.g. w/o >>>>>>> other >>>>>>> optional arguments 'data-source read-resource >>>>>>> --name=ExampleDS'), >>>>>>> which >>>>>>> is basically a formatted result of :read-resource. >>>>>>> >>>>>>> In general, it could be applied to any command displaying an >>>>>>> attribute >>>>>>> value to the user. >>>>>>> >>>>>>> Alexey >>>>>>> >>>>>>>> >>>>>>>>> IMO, the values returned should just be replaced with the >>>>>>>>> resolved >>>>>>>>> ones >>>>>>>>> for display. Some commands support --verbose argument, in >>>>>>>>> which >>>>>>>>> case >>>>>>>>> additional info is displayed in columns, there we could >>>>>>>>> include >>>>>>>>> the >>>>>>>>> original value. >>>>>>>>> The output of the cli commands in some cases is parsed by >>>>>>>>> scripts >>>>>>>>> or >>>>>>>>> other code, so keeping it simple will help there too. >>>>>>>>> >>>>>>>>>> The third aspect is the technical issue of how to make any >>>>>>>>>> 'resolve-expressions' param or CLI argument available in >>>>>>>>>> certain >>>>>>>>>> contexts and not in others. That's very likely solvable on >>>>>>>>>> the >>>>>>>>>> server >>>>>>>>>> side; not sure how difficult it would be in the CLI >>>>>>>>>> high-level >>>>>>>>>> command. >>>>>>>>> >>>>>>>>> Current tab-completion supports dependencies of command >>>>>>>>> arguments >>>>>>>>> and >>>>>>>>> their values on the current context (connection to the >>>>>>>>> controller, >>>>>>>>> standalone/domain mode, the presence of other arguments on >>>>>>>>> the >>>>>>>>> line and >>>>>>>>> the values specified for them, etc). Technically, there >>>>>>>>> shouldn't >>>>>>>>> be an >>>>>>>>> issue. >>>>>>>> >>>>>>>> Ok, good. >>>>>>>> >>>>>>>>> I am more concerned about how intuitive that will look like >>>>>>>>> for >>>>>>>>> the user >>>>>>>>> in various contexts. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, I think the UX aspects are the more significant ones. >>>>>>>> >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>>> FYI, for others reading this, offline Joe pointed out >>>>>>>>>> there's a >>>>>>>>>> related >>>>>>>>>> JIRA for this: https://issues.jboss.org/browse/WFLY-1069. >>>>>>>>>> >>>>>>>>>> On 6/26/14, 5:41 AM, Edward Wertz wrote: >>>>>>>>>>> I'm looking into whether it's possible to automatically >>>>>>>>>>> resolve >>>>>>>>>>> expressions when executing operations and commands in the >>>>>>>>>>> CLI. >>>>>>>>>>> >>>>>>>>>>> >From my understanding, there are two variations of the >>>>>>>>>>>> problem. >>>>>>>>>>> >>>>>>>>>>> * Operations are server-side processes that are >>>>>>>>>>> accessed >>>>>>>>>>> via ':' in the CLI and, currently, the CLI presents >>>>>>>>>>> the >>>>>>>>>>> results returned as-is to the users. ex: >>>>>>>>>>> ':read-resource' >>>>>>>>>>> >>>>>>>>>>> * Commands are processes that get manipulated by >>>>>>>>>>> the CLI >>>>>>>>>>> before getting presented to users. ex: 'ls' >>>>>>>>>>> >>>>>>>>>>> I've been experimenting with adding arguments to the CLI >>>>>>>>>>> commands, like 'ls --resolve-expressions', and gotten it >>>>>>>>>>> working for the standalone and domain side of things. >>>>>>>>>>> However, >>>>>>>>>>> I can't control the scope of the argument, so it's >>>>>>>>>>> available >>>>>>>>>>> in >>>>>>>>>>> situations that cannot accurately resolve expressions like >>>>>>>>>>> the >>>>>>>>>>> 'profile=full' section of the domain tree. The results >>>>>>>>>>> wouldn't >>>>>>>>>>> be reliable. >>>>>>>>>>> >>>>>>>>>>> The same problem would apply to adding parameters to the >>>>>>>>>>> server-side operations. The scope of the operations >>>>>>>>>>> themselves >>>>>>>>>>> can be controlled, but not their parameters. An execution >>>>>>>>>>> like >>>>>>>>>>> ':read-resource(recursive=true resolve-expressions=true)' >>>>>>>>>>> can't >>>>>>>>>>> resolve expressions unless it's used against an actual >>>>>>>>>>> server >>>>>>>>>>> or host, but the operation is available almost everywhere. >>>>>>>>>>> Again, the results wouldn't be reliable. >>>>>>>>>>> >>>>>>>>>>> I'm wondering if anyone can suggest a way to attack this >>>>>>>>>>> problem? There is already a >>>>>>>>>>> ':resolve-expression(expression=___)' operation, so users >>>>>>>>>>> can >>>>>>>>>>> somewhat laboriously get the runtime values they want, but >>>>>>>>>>> I >>>>>>>>>>> can't figure out a way to integrate the values into the >>>>>>>>>>> existing framework successfully. Other than creating >>>>>>>>>>> entirely >>>>>>>>>>> new operations and commands, like 'ls-resolve' and >>>>>>>>>>> ':read-resource-resolve', which seems like an unsustainable >>>>>>>>>>> way >>>>>>>>>>> to solve the problem. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Joe Wertz >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Thu Jul 17 06:28:20 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 17 Jul 2014 12:28:20 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C47482.1040808@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53C47482.1040808@redhat.com> Message-ID: <53C7A544.3000203@redhat.com> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example. Emmanuel Le 15/07/2014 02:23, James R. Perkins a ?crit : > I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or > possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. > > On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: >> # Ability to read boot errors via WildFly Management APIs >> >> Tracked by https://issues.jboss.org/browse/WFLY-543 >> >> Use Cases >> --------- >> >> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >> searching the logs. >> This information needs to be captured and stored for later reporting. >> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >> the service. >> >> Implementation >> -------------- >> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >> errors and missing dependencies near seems like a good place. >> thus we would have : >> core-service => service-container { >> boot-errors => { >> failures => { >> service-name => stackTrace; >> .... >> } >> missing-deps => { >> ... list of missing dependencies as String >> } >> } >> } >> >> This structure is based on the structure of the failure description returned during verification when starting a service. >> All these informations should be collected in the ModelControllerImpl. >> This resource would have restricted access of course. >> >> What do you think? >> >> Emmanuel >> >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140717/e3b39781/attachment.bin From ssilvert at redhat.com Thu Jul 17 08:44:25 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 17 Jul 2014 08:44:25 -0400 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C7A544.3000203@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53C47482.1040808@redhat.com> <53C7A544.3000203@redhat.com> Message-ID: <53C7C529.9000900@redhat.com> On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote: > Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example. > Emmanuel "some service might log errors"? Do we have a solid use case? I'd like to understand what this is for. > > Le 15/07/2014 02:23, James R. Perkins a ?crit : >> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or >> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. >> >> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: >>> # Ability to read boot errors via WildFly Management APIs >>> >>> Tracked by https://issues.jboss.org/browse/WFLY-543 >>> >>> Use Cases >>> --------- >>> >>> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >>> searching the logs. >>> This information needs to be captured and stored for later reporting. >>> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >>> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >>> the service. >>> >>> Implementation >>> -------------- >>> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >>> errors and missing dependencies near seems like a good place. >>> thus we would have : >>> core-service => service-container { >>> boot-errors => { >>> failures => { >>> service-name => stackTrace; >>> .... >>> } >>> missing-deps => { >>> ... list of missing dependencies as String >>> } >>> } >>> } >>> >>> This structure is based on the structure of the failure description returned during verification when starting a service. >>> All these informations should be collected in the ModelControllerImpl. >>> This resource would have restricted access of course. >>> >>> What do you think? >>> >>> Emmanuel >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- >> James R. Perkins >> JBoss by Red Hat >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140717/309012a9/attachment.html From ssilvert at redhat.com Thu Jul 17 09:01:41 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 17 Jul 2014 09:01:41 -0400 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C7C529.9000900@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53C47482.1040808@redhat.com> <53C7A544.3000203@redhat.com> <53C7C529.9000900@redhat.com> Message-ID: <53C7C935.9090309@redhat.com> On 7/17/2014 8:44 AM, Stan Silvert wrote: > On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote: >> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example. >> Emmanuel > "some service might log errors"? > > Do we have a solid use case? I'd like to understand what this is for. I guess I should be more clear about what I don't understand. I take it that this proposal wants to gather the boot errors so they can be accessed by some other process? What would the process be able to do with the information? If the purpose is to let users see the errors then that is already achieved by reading the log. So I take it that the use cases are not user-centric? > >> Le 15/07/2014 02:23, James R. Perkins a ?crit : >>> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or >>> possibly the same ashttp://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. >>> >>> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: >>>> # Ability to read boot errors via WildFly Management APIs >>>> >>>> Tracked byhttps://issues.jboss.org/browse/WFLY-543 >>>> >>>> Use Cases >>>> --------- >>>> >>>> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >>>> searching the logs. >>>> This information needs to be captured and stored for later reporting. >>>> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >>>> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >>>> the service. >>>> >>>> Implementation >>>> -------------- >>>> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >>>> errors and missing dependencies near seems like a good place. >>>> thus we would have : >>>> core-service => service-container { >>>> boot-errors => { >>>> failures => { >>>> service-name => stackTrace; >>>> .... >>>> } >>>> missing-deps => { >>>> ... list of missing dependencies as String >>>> } >>>> } >>>> } >>>> >>>> This structure is based on the structure of the failure description returned during verification when starting a service. >>>> All these informations should be collected in the ModelControllerImpl. >>>> This resource would have restricted access of course. >>>> >>>> What do you think? >>>> >>>> Emmanuel >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing 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/20140717/05218b96/attachment.html From jperkins at redhat.com Thu Jul 17 11:35:01 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 17 Jul 2014 08:35:01 -0700 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C7A544.3000203@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53C47482.1040808@redhat.com> <53C7A544.3000203@redhat.com> Message-ID: <53C7ED25.5060402@redhat.com> On 07/17/2014 03:28 AM, Emmanuel Hugonnet wrote: > Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example. > Emmanuel Excellent. Just wanted to make sure we weren't going to duplicate work :) > > Le 15/07/2014 02:23, James R. Perkins a ?crit : >> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or >> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. >> >> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: >>> # Ability to read boot errors via WildFly Management APIs >>> >>> Tracked by https://issues.jboss.org/browse/WFLY-543 >>> >>> Use Cases >>> --------- >>> >>> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >>> searching the logs. >>> This information needs to be captured and stored for later reporting. >>> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >>> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >>> the service. >>> >>> Implementation >>> -------------- >>> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >>> errors and missing dependencies near seems like a good place. >>> thus we would have : >>> core-service => service-container { >>> boot-errors => { >>> failures => { >>> service-name => stackTrace; >>> .... >>> } >>> missing-deps => { >>> ... list of missing dependencies as String >>> } >>> } >>> } >>> >>> This structure is based on the structure of the failure description returned during verification when starting a service. >>> All these informations should be collected in the ModelControllerImpl. >>> This resource would have restricted access of course. >>> >>> What do you think? >>> >>> Emmanuel >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- >> James R. Perkins >> JBoss by Red Hat >> -- James R. Perkins JBoss by Red Hat From ehugonne at redhat.com Thu Jul 17 11:43:21 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 17 Jul 2014 17:43:21 +0200 Subject: [wildfly-dev] Proposal to read boot errors via WildFly Management APIs In-Reply-To: <53C7C935.9090309@redhat.com> References: <53BEA1FB.2070408@redhat.com> <53C47482.1040808@redhat.com> <53C7A544.3000203@redhat.com> <53C7C529.9000900@redhat.com> <53C7C935.9090309@redhat.com> Message-ID: <53C7EF19.4070803@redhat.com> Well, the users could quickly check the errors with a script instead of searching through the logs or even looking 'manually' in the log viewer. Of course they could already be doing something with the logs, this aims to be easier to access / use. Le 17/07/2014 15:01, Stan Silvert a ?crit : > On 7/17/2014 8:44 AM, Stan Silvert wrote: >> On 7/17/2014 6:28 AM, Emmanuel Hugonnet wrote: >>> Well the idea was to avoid log parsing as some service might log errors which are not preventing it to start for example. >>> Emmanuel >> "some service might log errors"? >> >> Do we have a solid use case? I'd like to understand what this is for. > > I guess I should be more clear about what I don't understand. I take it that this proposal wants to gather the boot errors so they can be > accessed by some other process? What would the process be able to do with the information? > > If the purpose is to let users see the errors then that is already achieved by reading the log. So I take it that the use cases are not > user-centric? > >> >>> Le 15/07/2014 02:23, James R. Perkins a ?crit : >>>> I don't see a JIRA for this, but there has been some discussions around log viewing in general. This looks like it might be similar to or >>>> possibly the same as http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002336.html. >>>> >>>> On 07/10/2014 07:23 AM, Emmanuel Hugonnet wrote: >>>>> # Ability to read boot errors via WildFly Management APIs >>>>> >>>>> Tracked by https://issues.jboss.org/browse/WFLY-543 >>>>> >>>>> Use Cases >>>>> --------- >>>>> >>>>> If a server starts but reported errors during boot, there is no way to access the error data via the Management API and users are reduced to >>>>> searching the logs. >>>>> This information needs to be captured and stored for later reporting. >>>>> If some problem happens that gets logged at boot but somehow doesn't become visible to the management layer, that's out of scope. A problem >>>>> getting logged but not becoming visible would basically mean some runtime service logged an error but the error didn't prevent the start of >>>>> the service. >>>>> >>>>> Implementation >>>>> -------------- >>>>> Create a new sub resource of core-service=service-container because it has the ability to dump services, thus having all the services boot >>>>> errors and missing dependencies near seems like a good place. >>>>> thus we would have : >>>>> core-service => service-container { >>>>> boot-errors => { >>>>> failures => { >>>>> service-name => stackTrace; >>>>> .... >>>>> } >>>>> missing-deps => { >>>>> ... list of missing dependencies as String >>>>> } >>>>> } >>>>> } >>>>> >>>>> This structure is based on the structure of the failure description returned during verification when starting a service. >>>>> All these informations should be collected in the ModelControllerImpl. >>>>> This resource would have restricted access of course. >>>>> >>>>> What do you think? >>>>> >>>>> Emmanuel >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> -- >>>> James R. Perkins >>>> JBoss by Red Hat >>>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> _______________________________________________ >> wildfly-dev mailing 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: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140717/b95daece/attachment-0001.bin From mlittle at redhat.com Fri Jul 18 07:28:59 2014 From: mlittle at redhat.com (Mark Little) Date: Fri, 18 Jul 2014 12:28:59 +0100 Subject: [wildfly-dev] Design Proposal: Server suspend/resume (AKA Graceful Shutdown) In-Reply-To: <53BB74E0.1000502@gmail.com> References: <5396377F.80003@redhat.com> <22131731.5850.1402355055126.JavaMail.andrig@worklaptop.miller.org> <786BAC10-7BCE-47B8-BD87-968FE3FA4830@gmail.com> <5396D506.1030402@redhat.com> <31464906.7003.1402404649117.JavaMail.andrig@worklaptop.miller.org> <53970460.1070900@redhat.com> <31CC2816-8C5C-42CC-93C9-D16A11F83E96@redhat.com> <53BB74E0.1000502@gmail.com> Message-ID: Apologise for the delay in replying, but I forgot to check this folder (ping me directly in future too) ;) On 8 Jul 2014, at 05:34, Stuart Douglas wrote: > > Mark Little wrote: >> Are we talking about really shutting down the app server or just suspending it, with a view to resuming activity later? The answer is different for these two scenarios. >> > > It could be either. > >> If we just consider the former, then since the transaction system can cope with a crash failure and ensure consistency, technically we could just SIGKILL (or equivalent) and let it tidy up later. Of course we don't want to do that because we could end up with heuristics etc. So I assume what we're trying to achieve is as graceful a shutdown as possible, reducing the number of log recoveries and amount of tidying up we need to do. > > In the case of a fully graceful shutdown the transaction subsystem should not have to do anything, new requests will be rejected at the connector (or entry point) level, and existing requests will continue to run as normal. The question is what to do if the requests don't finish within some timeout, in this case from a transactions point of view I think recovery is inevitable. The transaction system should be able to treat this just as a crash failure. Though of course a graceful shutdown should be attempted first. > >> >> We should wait for the transaction to terminate and prevent any new transactions from starting. There's a mechanism in Narayana which allows it to be started/stopped (or suspended/resumed) so that no new transactions can be created once the switch is flicked. Those inflight transactions that haven't been prepared *could* have setRollbackOnly called on them to force them to end quicker (potentially add a JBoss specific option to change the timeout value as well - speed up time, but that would be risky). Those transactions which get past prepare need to be waited upon, but obviously there's a possibility they could block. We have some interrupt code in the transaction reaper to help there and that should be sufficient. >> >> Using a combination of the above would help to shorten the time to wait in the case there are a lot of inflight transactions. > > The problem is that this should only happen after the initial timeout has been hit. Before that the server has to work as normal for all currently running requests. > > You could potentially do this after the initial timeout has been hit, but then you would need a second timeout to see if it has worked. This makes me think it is worth the extra complexity, especially given that it is not going to be very graceful anyway. In HP-AS (HP Application Server) "back in the day", we simply prevented the creation of further transactions immediately the app server was going down, ran through termination of other services such as CORBA etc. and then allowed the process to terminate. Any inflight transactions were tidied up by recovery. The other stuff I mentioned, such as setRollbackOnly, would only be applicable if we wanted to provide a more graceful way for applications to terminate or to prevent heuristics, which could happen if there's a failure after the prepare phase. The former is a nice-to-have, whereas the latter is definitely something we should be worried about. Mark. > > Stuart > >> >> Mark. >> >> >> On 10 Jun 2014, at 14:13, Stuart Douglas wrote: >> >>>> If the transaction will never abort, can we force a rollback? This could lead to a never ending "graceful" shutdown. >>>> >>> That is why we have a timeout, once the timeout is done the server will >>> shutdown anyway. We should probably have some kind of post-timeout >>> callback that gets invoked, so the TX subsystem could potentially take >>> some action. >>> >>> I'm not sure what the best action would be, the subsystem specific >>> details will be up to the team that maintains the subsystem. >>> >>> Stuart >>> >>>> Andy >>>> >>>>> Note also that suspending before an in-flight transaction has >>>>> prepared is probably safe since the resource will either: >>>>> >>>>> - rollback the branch if all connections to the db are closed (when >>>>> the system suspends); or >>>>> - rollback the branch if the XAResource timeout (set via the >>>>> XAResource.setTransactionTimeout()) value is reached >>>>> >>>>> [And since it was never prepared we have no log record for it so we >>>>> would not do anything on resume] >>>>> >>>>> Mike >>>>> >>>>>> IIRC the behavior for a tx timeout is a rollback, but we should >>>>>> check that. >>>>>> >>>>>>> On Jun 9, 2014, at 6:50 PM, Stuart Douglas >>>>>>> wrote: >>>>>>> >>>>>>> Something I forgot to mention is that we will need a switch to >>>>>>> turn this off, as there is a small but noticeable cost with >>>>>>> tracking in flight requests. >>>>>>> >>>>>>> >>>>>>>> On 9 Jun 2014, at 18:04, Andrig Miller >>>>>>>> wrote: >>>>>>>> >>>>>>>> What I am bringing up is more subsystem specific, but it might be >>>>>>>> valuable to think about. In case of the time out of the >>>>>>>> graceful shutdown, what behavior would we consider correct in >>>>>>>> terms of an inflight transaction? >>>>>>> It waits for the transaction to finish before shutting down. >>>>>>> >>>>>>> Stuart >>>>>>> >>>>>>>> Should it be a forced rollback, so that when the server is >>>>>>>> started back up, the transaction manager will not find in the >>>>>>>> log a transaction to be recovered? >>>>>>>> >>>>>>>> Or, should it be considered the same as a crashed state, where >>>>>>>> transactions should be recoverable, and the recover manager >>>>>>>> wouuld try to recover the transaction? >>>>>>>> >>>>>>>> I would lean towards the first, as this would be considered >>>>>>>> graceful by the administrator, and having a transaction be in a >>>>>>>> state where it would be recovered on a restart, doesn't seem >>>>>>>> graceful to me. >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Stuart Douglas" >>>>>>>>> To: "Wildfly Dev mailing list" >>>>>>>>> Sent: Monday, June 9, 2014 4:38:55 PM >>>>>>>>> Subject: [wildfly-dev] Design Proposal: Server suspend/resume >>>>>>>>> (AKA Graceful Shutdown) >>>>>>>>> >>>>>>>>> Server suspend and resume is a feature that allows a running >>>>>>>>> server >>>>>>>>> to >>>>>>>>> gracefully finish of all running requests. The most common use >>>>>>>>> case >>>>>>>>> for >>>>>>>>> this is graceful shutdown, where you would like a server to >>>>>>>>> complete >>>>>>>>> all >>>>>>>>> running requests, reject any new ones, and then shut down, >>>>>>>>> however >>>>>>>>> there >>>>>>>>> are also plenty of other valid use cases (e.g. suspend the >>>>>>>>> server, >>>>>>>>> modify a data source or some other config, then resume). >>>>>>>>> >>>>>>>>> User View: >>>>>>>>> >>>>>>>>> For the users point of view two new operations will be added to >>>>>>>>> the >>>>>>>>> server: >>>>>>>>> >>>>>>>>> suspend(timeout) >>>>>>>>> resume() >>>>>>>>> >>>>>>>>> A runtime only attribute suspend-state (is this a good name?) >>>>>>>>> will >>>>>>>>> also >>>>>>>>> be added, that can take one of three possible values, RUNNING, >>>>>>>>> SUSPENDING, SUSPENDED. >>>>>>>>> >>>>>>>>> A timeout attribute will also be added to the shutdown >>>>>>>>> operation. If >>>>>>>>> this is present then the server will first be suspended, and the >>>>>>>>> server >>>>>>>>> will not shut down until either the suspend is successful or the >>>>>>>>> timeout >>>>>>>>> occurs. If no timeout parameter is passed to the operation then >>>>>>>>> a >>>>>>>>> normal >>>>>>>>> non-graceful shutdown will take place. >>>>>>>>> >>>>>>>>> In domain mode these operations will be added to both individual >>>>>>>>> server >>>>>>>>> and a complete server group. >>>>>>>>> >>>>>>>>> Implementation Details >>>>>>>>> >>>>>>>>> Suspend/resume operates on entry points to the server. Any >>>>>>>>> request >>>>>>>>> that >>>>>>>>> is currently running must not be affected by the suspend state, >>>>>>>>> however >>>>>>>>> any new request should be rejected. In general subsystems will >>>>>>>>> track >>>>>>>>> the >>>>>>>>> number of outstanding requests, and when this hits zero they are >>>>>>>>> considered suspended. >>>>>>>>> >>>>>>>>> We will introduce the notion of a global SuspendController, that >>>>>>>>> manages >>>>>>>>> the servers suspend state. All subsystems that wish to do a >>>>>>>>> graceful >>>>>>>>> shutdown register callback handlers with this controller. >>>>>>>>> >>>>>>>>> When the suspend() operation is invoked the controller will >>>>>>>>> invoke >>>>>>>>> all >>>>>>>>> these callbacks, letting the subsystem know that the server is >>>>>>>>> suspend, >>>>>>>>> and providing the subsystem with a SuspendContext object that >>>>>>>>> the >>>>>>>>> subsystem can then use to notify the controller that the suspend >>>>>>>>> is >>>>>>>>> complete. >>>>>>>>> >>>>>>>>> What the subsystem does when it receives a suspend command, and >>>>>>>>> when >>>>>>>>> it >>>>>>>>> considers itself suspended will vary, but in the common case it >>>>>>>>> will >>>>>>>>> immediatly start rejecting external requests (e.g. Undertow will >>>>>>>>> start >>>>>>>>> responding with a 503 to all new requests). The subsystem will >>>>>>>>> also >>>>>>>>> track the number of outstanding requests, and when this hits >>>>>>>>> zero >>>>>>>>> then >>>>>>>>> the subsystem will notify the controller that is has >>>>>>>>> successfully >>>>>>>>> suspended. >>>>>>>>> Some subsystems will obviously want to do other actions on >>>>>>>>> suspend, >>>>>>>>> e.g. >>>>>>>>> clustering will likely want to fail over, mod_cluster will >>>>>>>>> notify the >>>>>>>>> load balancer that the node is no longer available etc. In some >>>>>>>>> cases >>>>>>>>> we >>>>>>>>> may want to make this configurable to an extent (e.g. Undertow >>>>>>>>> could >>>>>>>>> be >>>>>>>>> configured to allow requests with an existing session, and not >>>>>>>>> consider >>>>>>>>> itself timed out until all sessions have either timed out or >>>>>>>>> been >>>>>>>>> invalidated, although this will obviously take a while). >>>>>>>>> >>>>>>>>> If anyone has any feedback let me know. In terms of >>>>>>>>> implementation my >>>>>>>>> basic plan is to get the core functionality and the Undertow >>>>>>>>> implementation into Wildfly, and then work with subsystem >>>>>>>>> authors to >>>>>>>>> implement subsystem specific functionality once the core is in >>>>>>>>> place. >>>>>>>>> >>>>>>>>> Stuart >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The >>>>>>>>> >>>>>>>>> A timeout attribute will also be added to the shutdown command, >>>>>>>>> _______________________________________________ >>>>>>>>> wildfly-dev mailing list >>>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> -- >>>>> Michael Musgrove >>>>> Transactions Team >>>>> e: mmusgrov at redhat.com >>>>> t: +44 191 243 0870 >>>>> >>>>> Registered in England and Wales under Company Registration No. >>>>> 03798903 >>>>> Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson >>>>> (US), Michael O'Neill(Ireland) >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> --- >> Mark Little >> mlittle at redhat.com >> >> JBoss, by Red Hat >> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. >> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). >> >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev --- Mark Little mlittle at redhat.com JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). From ralph.soika at imixs.com Mon Jul 21 12:16:14 2014 From: ralph.soika at imixs.com (Ralph Soika) Date: Mon, 21 Jul 2014 18:16:14 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default Message-ID: <53CD3CCE.2030902@imixs.com> Hi, I want to discuss the topic of Session Bean Pooling in WildFly. I know that there was a discussion in the past to disable pooling of EJB Session Beans per default in WildFly. I understand when you argue that pooling a session bean is not faster than creating the bean from scratch each time a method is called. From the perspective of a application server developer this is a clear and easy decision. But from the view of an application developer this breaks one of the main concepts of session beans - the pooling. As a application developer I suppose my bean is pooled and I can use one of the life-cycle annotations to control my bean. This is a basic concept for all kind of beans. First I thought it could be a compromise to pool only these beans which have a life-cycle annotation. But this isn't a solution. Knowing that my bean will be pooled allows me - as a component developer - to use this as a caching mechanism. For example time intensive routines can also cache results in a local variable to be used next time a method is called. This isn't a bad practice and can increase performance of my component depending on the pool settings. So my suggestion is to pool also stateless session ejbs in the future. I guess form the specification there is no duty to pool beans. So there is nothing wrong when not pooling beans. And again I don't want to criticize. But at the end not pooling will decrease the performance of WildFly. Not the container itself but the applications running in WildFly. It takes me a long time to figure out why my application was a little bit slower in WildFly than in GlassFish until I recognized the missing pooling. I can activate pooling and everything is cool. But I guess some other application developers will only see that there application is slower in WildFly than on other application servers. And this will effect their decision. That is the argument to activate the pool per default. best regards Ralph -- *Imixs*...extends the way people work together We are an open source company, read more at: www.imixs.org ------------------------------------------------------------------------ Imixs Software Solutions GmbH Agnes-Pockels-Bogen 1, 80992 M?nchen *Web:* www.imixs.com *Office:* +49 (0)89-452136 16 *Mobil:* +49-177-4128245 Registergericht: Amtsgericht Muenchen, HRB 136045 Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140721/4bfac6c5/attachment.html From wfink at redhat.com Mon Jul 21 13:39:12 2014 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Mon, 21 Jul 2014 19:39:12 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53CD3CCE.2030902@imixs.com> References: <53CD3CCE.2030902@imixs.com> Message-ID: <53CD5040.5070409@redhat.com> Hi Ralph, as I said in your community thread (https://community.jboss.org/thread/242999) it is not only the problem to add a pool for it. At the moment there is only the strict-max-pool which limit the total number of beans pooled - and also the total number of beans which can be used in parallel. So that means adding the pool is a performance issue, which can make the situation better or worse depend on the application. So you need to adjust it depend on your needs. If there is another implementation of a pool, i.e. which allow to have x pooled instances and more if needed, the pool might be back as default. For the moment it is makes no difference or is faster (in most cases) without pooling. - Wolf On 21/07/14 18:16, Ralph Soika wrote: > Hi, > > I want to discuss the topic of Session Bean Pooling in WildFly. I know > that there was a discussion in the past to disable pooling of EJB > Session Beans per default in WildFly. > I understand when you argue that pooling a session bean is not faster > than creating the bean from scratch each time a method is called. From > the perspective of a application server developer this is a clear and > easy decision. But from the view of an application developer this > breaks one of the main concepts of session beans - the pooling. > As a application developer I suppose my bean is pooled and I can use > one of the life-cycle annotations to control my bean. This is a basic > concept for all kind of beans. First I thought it could be a > compromise to pool only these beans which have a life-cycle > annotation. But this isn't a solution. > Knowing that my bean will be pooled allows me - as a component > developer - to use this as a caching mechanism. For example time > intensive routines can also cache results in a local variable to be > used next time a method is called. This isn't a bad practice and can > increase performance of my component depending on the pool settings. > > So my suggestion is to pool also stateless session ejbs in the future. > I guess form the specification there is no duty to pool beans. So > there is nothing wrong when not pooling beans. And again I don't want > to criticize. But at the end not pooling will decrease the performance > of WildFly. Not the container itself but the applications running in > WildFly. > It takes me a long time to figure out why my application was a little > bit slower in WildFly than in GlassFish until I recognized the missing > pooling. I can activate pooling and everything is cool. But I guess > some other application developers will only see that there application > is slower in WildFly than on other application servers. > And this will effect their decision. That is the argument to activate > the pool per default. > > best regards > Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140721/31f37f97/attachment-0001.html From ralph.soika at imixs.com Tue Jul 22 04:23:00 2014 From: ralph.soika at imixs.com (Ralph Soika) Date: Tue, 22 Jul 2014 10:23:00 +0200 Subject: [wildfly-dev] Pooling EJB Session Beans per default In-Reply-To: <53CD5040.5070409@redhat.com> References: <53CD3CCE.2030902@imixs.com> <53CD5040.5070409@redhat.com> Message-ID: <53CE1F64.8090708@imixs.com> Hi Wolf, thanks for your answer. Ok I will no longer ask for this default setting ;-) As long as it is possible to configure the pool according to the requirements of a deployed application there is not problem. WildFly now works great and really fast in my case. Thanks again. === Ralph On 21.07.2014 19:39, Wolf-Dieter Fink wrote: > Hi Ralph, > > as I said in your community thread > (https://community.jboss.org/thread/242999) it is not only the problem > to add a pool for it. > At the moment there is only the strict-max-pool which limit the total > number of beans pooled - and also the total number of beans which can > be used in parallel. > So that means adding the pool is a performance issue, which can make > the situation better or worse depend on the application. > So you need to adjust it depend on your needs. > > If there is another implementation of a pool, i.e. which allow to > have x pooled instances and more if needed, the pool might be back as > default. > For the moment it is makes no difference or is faster (in most cases) > without pooling. > > - Wolf > > On 21/07/14 18:16, Ralph Soika wrote: >> Hi, >> >> I want to discuss the topic of Session Bean Pooling in WildFly. I >> know that there was a discussion in the past to disable pooling of >> EJB Session Beans per default in WildFly. >> I understand when you argue that pooling a session bean is not faster >> than creating the bean from scratch each time a method is called. >> From the perspective of a application server developer this is a >> clear and easy decision. But from the view of an application >> developer this breaks one of the main concepts of session beans - the >> pooling. >> As a application developer I suppose my bean is pooled and I can use >> one of the life-cycle annotations to control my bean. This is a basic >> concept for all kind of beans. First I thought it could be a >> compromise to pool only these beans which have a life-cycle >> annotation. But this isn't a solution. >> Knowing that my bean will be pooled allows me - as a component >> developer - to use this as a caching mechanism. For example time >> intensive routines can also cache results in a local variable to be >> used next time a method is called. This isn't a bad practice and can >> increase performance of my component depending on the pool settings. >> >> So my suggestion is to pool also stateless session ejbs in the >> future. I guess form the specification there is no duty to pool >> beans. So there is nothing wrong when not pooling beans. And again I >> don't want to criticize. But at the end not pooling will decrease the >> performance of WildFly. Not the container itself but the applications >> running in WildFly. >> It takes me a long time to figure out why my application was a little >> bit slower in WildFly than in GlassFish until I recognized the >> missing pooling. I can activate pooling and everything is cool. But I >> guess some other application developers will only see that there >> application is slower in WildFly than on other application servers. >> And this will effect their decision. That is the argument to activate >> the pool per default. >> >> best regards >> Ralph > -- *Imixs*...extends the way people work together We are an open source company, read more at: www.imixs.org ------------------------------------------------------------------------ Imixs Software Solutions GmbH Agnes-Pockels-Bogen 1, 80992 M?nchen *Web:* www.imixs.com *Office:* +49 (0)89-452136 16 *Mobil:* +49-177-4128245 Registergericht: Amtsgericht Muenchen, HRB 136045 Geschaeftsfuehrer: Gaby Heinle u. Ralph Soika -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140722/049fd69c/attachment.html From jason.greene at redhat.com Tue Jul 22 16:04:29 2014 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 22 Jul 2014 15:04:29 -0500 Subject: [wildfly-dev] WildFly Schedule & Goals Update Message-ID: <1D463807-4E8F-403B-B7C1-4A964FB0DE81@redhat.com> Hello Everyone, I just wanted to relay some updated timeline and goals information: - 8.2.0 is still waiting on an EE7 TCK update which includes CDI 1.2. Last we heard we should be getting this in the summer, so expect it sometime in August. - 9.0.0.Beta1 is slated for September 9, 2014 - 9.0.0.CR1 is slated for October 10, 2014 - 9.0.0.Final is slated for November 11, 2014 Note that WildFly Core is now versioned separately and is currently at 1.0.0.Alpha5. Once we are happy with the split it will be released Final. The core releases will move at a faster pace. More info on that to come. WildFly 9 will focus on the following major features: - Core/Servlet/Full Split - Graceful shutdown - Elytron (Security improvments) - Switching to the JDK ORB from JacORB - Undertow as a mod_cluster frontend - Subsystem Capabilities and Requirements - EAP 6.4 RFEs (TBA) If you have any questions or concerns, let me know! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jperkins at redhat.com Tue Jul 22 23:02:33 2014 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 22 Jul 2014 20:02:33 -0700 Subject: [wildfly-dev] Start Up Scripts Message-ID: <53CF25C9.4050007@redhat.com> While taking a look at a change to the start up scripts I'm reminded on what a PITA it is to get consistent behavior across platforms. There are 4 scripts, not including daemon style scripts, to launch WildFly. In addition to the 4 scripts there are 4 I guess extension scripts. Any change needed is likely needed in 4 of the files. I've created an API to launch WildFly [1]. I'm proposing we could use the API to launch WildFly. We could nix the *.conf and *.conf.bat files and go to two properties files; a standalone.properties and a domain.properties. The normal start up scripts would remain, but be reduced to only setup essential environment variables and invoke a main class in the launcher API[2]. Note this is by no means complete, just an example of how it could be done. If has any opinions on this let me know. It would allow making changes a lot easier. [1]: https://github.com/wildfly/wildfly-core/pull/28 [2]: https://gist.github.com/jamezp/2033be603da4737ac571 -- James R. Perkins JBoss by Red Hat From tomaz.cerar at gmail.com Wed Jul 23 07:50:02 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 23 Jul 2014 13:50:02 +0200 Subject: [wildfly-dev] Start Up Scripts In-Reply-To: <53CF25C9.4050007@redhat.com> References: <53CF25C9.4050007@redhat.com> Message-ID: What would that mean in practice? Extra jvm launcher process that will start wildfly. or will this be in run in same process? On Wed, Jul 23, 2014 at 5:02 AM, James R. Perkins wrote: > While taking a look at a change to the start up scripts I'm reminded on > what a PITA it is to get consistent behavior across platforms. There are > 4 scripts, not including daemon style scripts, to launch WildFly. In > addition to the 4 scripts there are 4 I guess extension scripts. Any > change needed is likely needed in 4 of the files. > > I've created an API to launch WildFly [1]. I'm proposing we could use > the API to launch WildFly. We could nix the *.conf and *.conf.bat files > and go to two properties files; a standalone.properties and a > domain.properties. The normal start up scripts would remain, but be > reduced to only setup essential environment variables and invoke a main > class in the launcher API[2]. Note this is by no means complete, just an > example of how it could be done. > > If has any opinions on this let me know. It would allow making changes a > lot easier. > > [1]: https://github.com/wildfly/wildfly-core/pull/28 > [2]: https://gist.github.com/jamezp/2033be603da4737ac571 > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140723/b21dc61b/attachment.html From hrupp at redhat.com Wed Jul 23 08:10:10 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Wed, 23 Jul 2014 14:10:10 +0200 Subject: [wildfly-dev] Start Up Scripts In-Reply-To: References: <53CF25C9.4050007@redhat.com> Message-ID: <6819E25E-A0BE-43C0-A815-74D5AA3B33F3@redhat.com> I like the idea in general, as there are currently too many knobs to operate. I think though that users and tools (like RHQ/JON) have already added a lot of functionality to twiddle those .conf and what not files. So at least make sure it gets right the first time and does not need too many iterations :) Heiko From jperkins at redhat.com Wed Jul 23 10:16:36 2014 From: jperkins at redhat.com (James R. Perkins) Date: Wed, 23 Jul 2014 10:16:36 -0400 (EDT) Subject: [wildfly-dev] Start Up Scripts In-Reply-To: References: <53CF25C9.4050007@redhat.com> Message-ID: <452980287.570725.1406124996619.JavaMail.zimbra@zmail16.collab.prod.int.phx2.redhat.com> If we were to do it this way it would be another process. I also experimented with just echoing the command back and running it that way. The issue there is a JVM is started to get the command. There could be a better way too. If anyone has suggestions, I'm open to them. -- James R. Perkins JBoss by Red Hat On Jul 23, 2014 4:50 AM, Toma? Cerar wrote: What would that mean in practice? Extra jvm launcher process that will start wildfly. or will this be in run in same process? On Wed, Jul 23, 2014 at 5:02 AM, James R. Perkins wrote: > While taking a look at a change to the start up scripts I'm reminded on > what a PITA it is to get consistent behavior across platforms. There are > 4 scripts, not including daemon style scripts, to launch WildFly. In > addition to the 4 scripts there are 4 I guess extension scripts. Any > change needed is likely needed in 4 of the files. > > I've created an API to launch WildFly [1]. I'm proposing we could use > the API to launch WildFly. We could nix the *.conf and *.conf.bat files > and go to two properties files; a standalone.properties and a > domain.properties. The normal start up scripts would remain, but be > reduced to only setup essential environment variables and invoke a main > class in the launcher API[2]. Note this is by no means complete, just an > example of how it could be done. > > If has any opinions on this let me know. It would allow making changes a > lot easier. > > [1]: https://github.com/wildfly/wildfly-core/pull/28 > [2]: https://gist.github.com/jamezp/2033be603da4737ac571 > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140723/7a5c2f7d/attachment-0001.html From kabir.khan at jboss.com Wed Jul 23 13:05:57 2014 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 23 Jul 2014 18:05:57 +0100 Subject: [wildfly-dev] Chained transformers and 7.1.x tests In-Reply-To: <53BAEDF5.3080507@redhat.com> References: <38971EB5-3FBD-4F2E-92A8-4804B165609E@jboss.com> <285A1BB4-D4F4-4AF0-AB5A-19BAA1530114@jboss.com> <8127B9EE-BC70-4CCD-A4B4-3706778DA950@jboss.com> <53BAD7E2.8070203@redhat.com> <53BAEDF5.3080507@redhat.com> Message-ID: <487BFDD5-BC16-4C49-B127-A2307DBEC887@jboss.com> Chained transformers are now working and have been merged to wildfly-core. So they should be usable from the next wildfly-core release. I have documented the changes to chained transformers and the test framework in the Domain Mode Subsystem Transformers document: * You no longer need to generate the .dmr files for new subsystem versions: [Testing a configuration that works] (The last paragraph or so) * Chained transformers Then I have updated the [Evolving transformers with subsystem ModelVersions] section to document the chained transformers at: [Chained transformers]. This section also contains the system properties needed to run the ?legacy? tests which do not get run by default. [Testing a configuration that works] - https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers#DomainModeSubsystemTransformers-Testingaconfigurationthatworks [Evolving transformers with subsystem ModelVersions] - https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers#DomainModeSubsystemTransformers-EvolvingtransformerswithsubsystemModelVersions [Chained transformers] - https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers#DomainModeSubsystemTransformers-Chainedtransformers On 7 Jul 2014, at 19:59, Brian Stansberry wrote: > On 7/7/14, 1:25 PM, Kabir Khan wrote: >> I am looking at adding chained transformers to the core model transformers, i.e. DomainTransformers and the classes it uses. However, I?d like to get an extra eye on the sequence of versions in the chains used. >> >> https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/domain/controller/transformers/DomainTransformers.java#L57 contains the following versions and comments: >> >> //AS 7.1.2.Final / EAP 6.0.0 >> private static final ModelVersion VERSION_1_2 = ModelVersion.create(1, 2, 0); >> //AS 7.1.3.Final / EAP 6.0.1 >> private static final ModelVersion VERSION_1_3 = ModelVersion.create(1, 3, 0); >> //AS 7.2.0.Final / EAP 6.1.0 / EAP 6.1.1 >> private static final ModelVersion VERSION_1_4 = ModelVersion.create(1, 4, 0); >> // EAP 6.2.0 >> private static final ModelVersion VERSION_1_5 = ModelVersion.create(1, 5, 0); >> // EAP 6.3.0 >> private static final ModelVersion VERSION_1_6 = ModelVersion.create(1, 6, 0); >> //WF 8.0.0.Final >> private static final ModelVersion VERSION_2_0 = ModelVersion.create(2, 0, 0); >> //WF 8.1.0.Final >> private static final ModelVersion VERSION_2_1 = ModelVersion.create(2, 1, 0); >> >> Since some features were introduced in 1.6.0 and 1.5.0 for EAP which also exist in 2.0.0 (and probably 2.1.0) I guess that the chains should be: >> * For WildFly: 3.0.0->2.1.0->2.0.0 >> * For JBoss EAP and AS 7 releases: 3.0.0->1.6.0->1.5.0->1.4.0->1.3.0->1.2.0 >> > > Yes. > >> To get good coverage of my refactoring, and of the chained transformers themselves, I am also reintroducing the core-model-test 7.1.2 test controller again. Once I am done with the chained transformers, I will look at pulling the legacy test controllers for both core-model-test and subsystem-test out into their own repository. That way they can be kept around without polluting the codebase. This should end the days of having 3 versions of WildFly/AS7 classes appear in the IDE classpath, which is annoying when you want to look up a class by name. >> > > :) > >> On 7 Jul 2014, at 18:24, Brian Stansberry wrote: >> >>> Thanks for all this, Kabir. >>> >>> On 7/7/14, 5:43 AM, Kabir Khan wrote: >>>> This has been merged to wildfly-core. >>>> To test the transformers against 7.1.x and EAP 6.0.x use -Djboss.test.transformers.subsystem.old. >>>> To get the EAP ones you will also need -Djboss.test.transformers.eap, as usual. >>>> >>>> On 6 Jul 2014, at 12:22, Kabir Khan wrote: >>>> >>>>> On 6 Jul 2014, at 11:45, Kabir Khan wrote: >>>>> >>>>>> https://github.com/wildfly/wildfly-core/pull/10 enables this and also gets rid of all the .dmr files used by the subsystem tests. The tests will now simply generate these on demand. >>>>>> >>>>>> All tests in core pass with this (also for 7.1.x when enabled). In wildfly everything passes when running the tests, although there are some issues in the following subsystems when running against 7.1.x >>>>>> * jgroups - needs a touched up .dmr file for 7.1.x, I have s commit >>>>> s/s commit/a commit >>>>>> * infinispan - something goes wrong in the >>>>> ? 7.1.x tests, I?ve not looked into it >>>>>> * messaging - although not a 7.1.x issue, the PR enables testing against WF 8 as well. However, the messaging extension uses some methods which are no longer available in WF 9. This could be fixed by adding a test-controller-8_0_0. >>>>>> >>>>>> These problems are probably not too important to spend a lot of time on at this stage, since they do not occur when running against the versions enabled by default. The point of allowing the 7.1.x testing again is to get better coverage while converting the chained transformer stuff so that I can work through problems while I remember how this works, rather than in many month?s time. >>>>>> >>>>>> On 5 Jul 2014, at 10:57, Kabir Khan wrote: >>>>>> >>>>>>> I?ve got the chained transformers mostly working in its own tests, but have some issues to iron out when using them for real, which is not picked up by the tests I wrote. Currently I am trying to convert the jmx subsystem, and think I will also do the other ones in wildfly-core (remoting and logging). >>>>>>> >>>>>>> Since we have disabled transformer testing against WildFly 8, and AS 7.1.x, there isn?t actually much of a chain to test at the moment. To get better coverage of what I have done in real subsystem scenarios, I would like to temporarily reinstate the test controller for 7.1.x, and to use a system property to enable running of tests against 7.1.x and WildFly 8 unless someone has some strong objections. If people start converting to use chained transformers, since the 7.1.x tests already exist, I think this will be valuable validation of what they are doing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> -- >>> Brian Stansberry >>> 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 > 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 tomaz.cerar at gmail.com Thu Jul 24 11:43:36 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 24 Jul 2014 17:43:36 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <53BE9D38.4020607@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <53BD8ABE.1060907@redhat.com> <53BD912F.1010504@gmail.com> <53BD9971.2020904@redhat.com> <53BE9D38.4020607@redhat.com> Message-ID: I have send PR removing jmx subsystem from core https://github.com/wildfly/wildfly-core/pull/57 but to send PR for inclusion to full WildFly repo new release of core is needed as jmx subsystem is using new transformers API we have in core. -- tomaz On Thu, Jul 10, 2014 at 4:03 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 7/9/14, 6:00 PM, Toma? Cerar wrote: > >> >> On Wed, Jul 9, 2014 at 9:35 PM, Brian Stansberry >> > wrote: >> >> >> Does logging belong in web then then? Still seems like something that >> even the uber-minimalists would want. I ask because it bugs me that we >> have two meanings now for "core" -- the old "core" notion that was the >> true core with zero subsystems, and now this new wildfly-core dist, >> which has subsystems. >> >> >> Core *current* comes with following subsystems: >> - logging >> - jmx (on the way out) >> - deployment-scanner >> - remoting >> - io (because of remoting) >> >> I agree that jmx needs to go out, >> deployment scanner needs to stay. >> And remoting is needed to make cli & alike work... >> >> > Remoting and io libs are needed, but not the subsystems themselves. > > But, we've discussed some having the current stuff becoming > subsystems once we have proper HC extensions/subsystems, so at that point > there *will be* subsystems needed for core. > > Seems my concern about two meanings of "core" won't matter at that point > anyway. > > Thanks. > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140724/25d42958/attachment.html From brian.stansberry at redhat.com Thu Jul 24 11:50:34 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 10:50:34 -0500 Subject: [wildfly-dev] Support for legacy xml parsers Message-ID: <53D12B4A.8080408@redhat.com> For WildFly 9 (not 8.2) I propose that we change our policy regarding support for legacy WildFly configuration documents.[1] Currently we support being able to parse content from any of our namespaces (core or subsystem) shipped in a final release going back to AS 7.0.0. I want to change this to limit support to namespaces shipped in AS 7.2.0 or later and EAP 6.1.0 or later. This cutoff is consistent with what we are doing with mixed-version support in managed domains. The goal of this is to reduce the maintenance burden related to legacy xml parsers. The goal is *not* to reduce the size of the codebase etc. So, if this proposal carries, please do not go off and delete old stuff that works just because you can. But, if you find yourself having to expend energy maintaining one of these old parsers, the policy change means just dropping it is a valid alternative. Comments? [1] Configuration documents meaning standalone/domain/host.xml, not stuff like deployment descriptors. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Thu Jul 24 12:11:55 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 24 Jul 2014 09:11:55 -0700 Subject: [wildfly-dev] Support for legacy xml parsers In-Reply-To: <53D12B4A.8080408@redhat.com> References: <53D12B4A.8080408@redhat.com> Message-ID: <53D1304B.4060401@redhat.com> Ha, I just saw this email after having a conversion with Tomaz and David on IRC. Since WildFly there was such a long time between 7.1.1.Final and WildFly 8 I think it might be better to wait until WildFly 10. I still see quite a few questions regarding JBoss AS 7.x. If we could encourage those users to switch to WildFly I think it would make all of us happier :) If we cut support for WildFly 9 of their configuration files I could see them less likely to move if 9 is the current release. On 07/24/2014 08:50 AM, Brian Stansberry wrote: > For WildFly 9 (not 8.2) I propose that we change our policy regarding > support for legacy WildFly configuration documents.[1] > > Currently we support being able to parse content from any of our > namespaces (core or subsystem) shipped in a final release going back to > AS 7.0.0. > > I want to change this to limit support to namespaces shipped in AS 7.2.0 > or later and EAP 6.1.0 or later. > > This cutoff is consistent with what we are doing with mixed-version > support in managed domains. > > The goal of this is to reduce the maintenance burden related to legacy > xml parsers. The goal is *not* to reduce the size of the codebase etc. > So, if this proposal carries, please do not go off and delete old stuff > that works just because you can. But, if you find yourself having to > expend energy maintaining one of these old parsers, the policy change > means just dropping it is a valid alternative. > > Comments? > > > [1] Configuration documents meaning standalone/domain/host.xml, not > stuff like deployment descriptors. > -- James R. Perkins JBoss by Red Hat From lclayton at redhat.com Thu Jul 24 12:22:05 2014 From: lclayton at redhat.com (Liz Clayton) Date: Thu, 24 Jul 2014 12:22:05 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: <1180430621.18811771.1406218306721.JavaMail.zimbra@redhat.com> Message-ID: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> Hi, I'm sketching out some ideas for the Domain Overview screen. I'd like to find a visualization that make it easier to scan the page to determine server availability, and possibly alerts. Given that the domain could be large, the visualization needs to scale. I started by looking at heatmap visualizations, which worked pretty well. Although I didn't feel like they helped in describing the overall relationships of servers, server groups and hosts... So I decided to break the heat maps into individual (stacked) heatmaps, ordered by server group. My hope is that this helps to define groupings and such. I posted the current design proposal at: https://community.jboss.org/wiki/DomainOverview070114pdf It would be great to get feedback on the designs. Some questions I have are: - Is it difficult/easy to understand that the boxes, in the server groupings, are intended to represent servers? - Should the servers be laid out in the visualization by level of availability/status (as illustrated), or by some other ordering (A-Z, Z-A...)? - Is it difficult/easy to understand that when a box is a different color, that it is indicating its availability status? - What do you expect to be the relationship between (Availability) Status and Alerts? Would ?x? alerts equate to a change in availability status, or can they function independently? For example: Could you have an error on a server and it still be ?available?? Thanks, Liz From jason.greene at redhat.com Thu Jul 24 12:45:38 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 24 Jul 2014 11:45:38 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> Message-ID: <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: > Hi, > > I'm sketching out some ideas for the Domain Overview screen. I'd like to find a visualization that make it easier to scan the page to determine server availability, and possibly alerts. > > Given that the domain could be large, the visualization needs to scale. I started by looking at heatmap visualizations, which worked pretty well. Although I didn't feel like they helped in describing the overall relationships of servers, server groups and hosts... So I decided to break the heat maps into individual (stacked) heatmaps, ordered by server group. My hope is that this helps to define groupings and such. > > I posted the current design proposal at: > https://community.jboss.org/wiki/DomainOverview070114pdf > > It would be great to get feedback on the designs. Some questions I have are: > - Is it difficult/easy to understand that the boxes, in the server groupings, are intended to represent servers? > - Should the servers be laid out in the visualization by level of availability/status (as illustrated), or by some other ordering (A-Z, Z-A...)? > - Is it difficult/easy to understand that when a box is a different color, that it is indicating its availability status? > - What do you expect to be the relationship between (Availability) Status and Alerts? Would ?x? alerts equate to a change in availability status, or can they function independently? For example: Could you have an error on a server and it still be ?available?? Thanks for forwarding this proposal Liz! While I chew on this, I have posted this on the user forums and twitter as well: https://community.jboss.org/message/882227#882227 https://twitter.com/jtgreene/status/492347878254182401 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Thu Jul 24 13:05:24 2014 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 24 Jul 2014 12:05:24 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> Message-ID: <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> On Jul 24, 2014, at 11:45 AM, Jason Greene wrote: > > On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: > >> Hi, >> >> I'm sketching out some ideas for the Domain Overview screen. I'd like to find a visualization that make it easier to scan the page to determine server availability, and possibly alerts. >> >> Given that the domain could be large, the visualization needs to scale. I started by looking at heatmap visualizations, which worked pretty well. Although I didn't feel like they helped in describing the overall relationships of servers, server groups and hosts... So I decided to break the heat maps into individual (stacked) heatmaps, ordered by server group. My hope is that this helps to define groupings and such. >> >> I posted the current design proposal at: >> https://community.jboss.org/wiki/DomainOverview070114pdf >> >> It would be great to get feedback on the designs. Some questions I have are: >> - Is it difficult/easy to understand that the boxes, in the server groupings, are intended to represent servers? >> - Should the servers be laid out in the visualization by level of availability/status (as illustrated), or by some other ordering (A-Z, Z-A...)? >> - Is it difficult/easy to understand that when a box is a different color, that it is indicating its availability status? >> - What do you expect to be the relationship between (Availability) Status and Alerts? Would ?x? alerts equate to a change in availability status, or can they function independently? For example: Could you have an error on a server and it still be ?available?? > > Thanks for forwarding this proposal Liz! > > While I chew on this, I have posted this on the user forums and twitter as well: > > https://community.jboss.org/message/882227#882227 > https://twitter.com/jtgreene/status/492347878254182401 https://twitter.com/jtgreene/status/492354174432993280 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From lclayton at redhat.com Thu Jul 24 13:11:12 2014 From: lclayton at redhat.com (Liz Clayton) Date: Thu, 24 Jul 2014 13:11:12 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> Message-ID: <651395953.18833884.1406221872021.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: "Jason Greene" > To: "Liz Clayton" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, July 24, 2014 12:45:38 PM > Subject: Re: [wildfly-dev] Domain Overview design > > > On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: > > > Hi, > > > > I'm sketching out some ideas for the Domain Overview screen. I'd like to > > find a visualization that make it easier to scan the page to determine > > server availability, and possibly alerts. > > > > Given that the domain could be large, the visualization needs to scale. I > > started by looking at heatmap visualizations, which worked pretty well. > > Although I didn't feel like they helped in describing the overall > > relationships of servers, server groups and hosts... So I decided to break > > the heat maps into individual (stacked) heatmaps, ordered by server group. > > My hope is that this helps to define groupings and such. > > > > I posted the current design proposal at: > > https://community.jboss.org/wiki/DomainOverview070114pdf > > > > It would be great to get feedback on the designs. Some questions I have > > are: > > - Is it difficult/easy to understand that the boxes, in the server > > groupings, are intended to represent servers? > > - Should the servers be laid out in the visualization by level of > > availability/status (as illustrated), or by some other ordering (A-Z, > > Z-A...)? > > - Is it difficult/easy to understand that when a box is a different color, > > that it is indicating its availability status? > > - What do you expect to be the relationship between (Availability) Status > > and Alerts? Would ?x? alerts equate to a change in availability status, or > > can they function independently? For example: Could you have an error on a > > server and it still be ?available?? > > Thanks for forwarding this proposal Liz! > > While I chew on this, I have posted this on the user forums and twitter as > well: > > https://community.jboss.org/message/882227#882227 > https://twitter.com/jtgreene/status/492347878254182401 Thanks for checking it out, and for getting it out there! -Liz > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From brian.stansberry at redhat.com Thu Jul 24 15:58:15 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 14:58:15 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> Message-ID: <53D16557.1070405@redhat.com> +100 on Jason's comment thanking you for posting this. On 7/24/14, 12:05 PM, Jason Greene wrote: > > On Jul 24, 2014, at 11:45 AM, Jason Greene wrote: > >> >> On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: >> >>> Hi, >>> >>> I'm sketching out some ideas for the Domain Overview screen. I'd like to find a visualization that make it easier to scan the page to determine server availability, and possibly alerts. >>> >>> Given that the domain could be large, the visualization needs to scale. I started by looking at heatmap visualizations, which worked pretty well. Although I didn't feel like they helped in describing the overall relationships of servers, server groups and hosts... So I decided to break the heat maps into individual (stacked) heatmaps, ordered by server group. My hope is that this helps to define groupings and such. >>> >>> I posted the current design proposal at: >>> https://community.jboss.org/wiki/DomainOverview070114pdf >>> >>> It would be great to get feedback on the designs. Some questions I have are: >>> - Is it difficult/easy to understand that the boxes, in the server groupings, are intended to represent servers? That seemed intuitive to me. I don't get though why some boxes are different sizes from others on "Second Iteration: Stacked heatmap". On "First draft heatmap ? Server Group view for 'availability'" I could somewhat get that, as different server groups can vary in size based on # of servers. >>> - Should the servers be laid out in the visualization by level of availability/status (as illustrated), or by some other ordering (A-Z, Z-A...)? My instinct is something like alphabetical is better. The color already lets me easily find and identify things where availability/status is relevant to what I want to do. But when it's not relevant to what I want (say I want to work with server-X for reasons completely unrelated to availability) then I need to rely on location to find what I want quickly. Note that multiple servers in a domain can have the same name; it's the host (as in Host Controller) + server name combination that must be unique. >>> - Is it difficult/easy to understand that when a box is a different color, that it is indicating its availability status? If the colors are green and grey, maybe not. But in a number of examples you use green<->red, with grey too, and I think that's pretty intuitive. Red = bad, green = good, yellowish = in between, grey = the good/bad aspect is out-of-scope. >>> - What do you expect to be the relationship between (Availability) Status and Alerts? Would ?x? alerts equate to a change in availability status, or can they function independently? For example: Could you have an error on a server and it still be ?available?? I think we need a better understanding of what alerts are. In general, I like the idea of the occurrence of some kind of negative event tends to shift the color away from green and toward red. But what constitutes a negative event? How much control does the user have over that definition? How much control does the user have over how much different events shift the color? Please be cautious about the Alerts notion in your design. WildFly doesn't actually have the kind of altering system that many might be thinking of when they imagine this kind of thing. So it would have to be developed. That's something we want to do, and Jeff Mesnil is doing some of the foundational work, but it's not there yet and it's a big job competing with lots of other big tasks. So, we want it, but the more a UI design depends on a complex alerting system, the riskier it is that a needed feature won't be there. Re: some of the questions, on the "Questions" page: "What are the states for server availability?" On "Not available" and "Failed" we have no notion of why a server was taken down; i.e. the admin takes it down, but whether they did so due to issues or for some other reason, we have no idea. We can distinguish a crash from an administrative shutdown. Also, there are other aspect of a server's running state that complicate things. We are adding the ability to put a server in "suspending" and "suspended" states where it moves to not accepting normal end user requests but is still running. This isn't an "error" state; the admin has chosen to put the server in that state. There's also a similar notion regarding how consistent the server's running state is with its persistent configuration. Admins can make configuration changes that will not take effect until the server is reloaded or restarted. I'm not sure if those things are well represented on a green-yellow-red color continuum because they are somewhat different from server health. But they are important pieces of data to visualize. "How does the Alerts tab fit in with the *current* Notification message queue?" Heiko Braun knows better, but I don't see a close fit. The current queue isn't really based on any sort of server-push of events. The console makes administrative requests and gets responses; if relevant that request/response results in stuff in the queue. But anything that happens outside of those requests/responses is unknown to the console. Cheers, -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ssilvert at redhat.com Thu Jul 24 16:05:15 2014 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 24 Jul 2014 16:05:15 -0400 Subject: [wildfly-dev] Status: Keycloak-secured Web Console in WildFly 9 In-Reply-To: <53D16052.9070500@redhat.com> References: <53D16052.9070500@redhat.com> Message-ID: <53D166FB.2020202@redhat.com> I sent below preview to TheCore. But I'd like to give status and get development feedback from wildfly-dev. https://community.jboss.org/wiki/PreviewKeycloak-securedManagementInWildFly9 Status: * The current implementation only pulls Keycloak modules into WildFly Full. WildFly Core only needs Keycloak at compile time. * You can still use Keycloak with wf-core, but you need to install the modules yourself. * The current implementation may change a great deal based on Elytron. I'd like to discuss with someone from that team. * Thanks to Juca Krohling, who has been preparing integration tests for this. * If you follow the setup directions in the preview, you see that the last step is to unzip some stuff into WildFly. The zip file contains the Keycloak auth server, a standalone-keycloak.xml file, and an initial Keycloak database configured for Web Console. I'm wondering if one or more of these items should ship with WildFly Full? If not, how do we make it as easy as possible to get Keycloak up and running? Waiting issue: To merge this, we have to wait on two releases. First is a new Keycloak release, which should be in the next two weeks. After that, I can do a PR against WildFly Core. After waiting for a WildFly Core release, I can do a PR against WildFly Full. The waiting is OK as long as it doesn't drag out too much. I'm hoping the WildFly Core releases are indeed very frequent. Stan -------- Original Message -------- Subject: Preview: Keycloak-secured Web Console in WildFly 9 Date: Thu, 24 Jul 2014 15:36:50 -0400 From: Stan Silvert To: thecore at redhat.com If you want to see the Web Console secured by Keycloak, follow these quick and easy instructions. Setup takes about 5 minutes. https://community.jboss.org/wiki/PreviewKeycloak-securedManagementInWildFly9 Once you are done, you can see * Web Console using Keycloak login. * Single Signon between Web Console and Keycloak Admin * Single Log Out * Add/Remove Web Console users from Keycloak * Manage RBAC roles for Web Console users from Keycloak * Lots of other cool Keycloak features Stan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140724/4a62dbeb/attachment.html From brian.stansberry at redhat.com Thu Jul 24 16:12:50 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 15:12:50 -0500 Subject: [wildfly-dev] Support for legacy xml parsers In-Reply-To: <53D1304B.4060401@redhat.com> References: <53D12B4A.8080408@redhat.com> <53D1304B.4060401@redhat.com> Message-ID: <53D168C2.60900@redhat.com> Is a 7.1.1 config file likely to be useful in WF 9? On a server we no longer support the old web subsystem, cmp and jaxr. By the time we're done with Elytron integration, the security subsystem may be completely revamped as well, with the current config relegated to HC-only support for use in a mixed domain. On 7/24/14, 11:11 AM, James R. Perkins wrote: > Ha, I just saw this email after having a conversion with Tomaz and David > on IRC. > > Since WildFly there was such a long time between 7.1.1.Final and WildFly > 8 I think it might be better to wait until WildFly 10. I still see quite > a few questions regarding JBoss AS 7.x. If we could encourage those > users to switch to WildFly I think it would make all of us happier :) If > we cut support for WildFly 9 of their configuration files I could see > them less likely to move if 9 is the current release. > > On 07/24/2014 08:50 AM, Brian Stansberry wrote: >> For WildFly 9 (not 8.2) I propose that we change our policy regarding >> support for legacy WildFly configuration documents.[1] >> >> Currently we support being able to parse content from any of our >> namespaces (core or subsystem) shipped in a final release going back to >> AS 7.0.0. >> >> I want to change this to limit support to namespaces shipped in AS 7.2.0 >> or later and EAP 6.1.0 or later. >> >> This cutoff is consistent with what we are doing with mixed-version >> support in managed domains. >> >> The goal of this is to reduce the maintenance burden related to legacy >> xml parsers. The goal is *not* to reduce the size of the codebase etc. >> So, if this proposal carries, please do not go off and delete old stuff >> that works just because you can. But, if you find yourself having to >> expend energy maintaining one of these old parsers, the policy change >> means just dropping it is a valid alternative. >> >> Comments? >> >> >> [1] Configuration documents meaning standalone/domain/host.xml, not >> stuff like deployment descriptors. >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Thu Jul 24 16:33:55 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 24 Jul 2014 13:33:55 -0700 Subject: [wildfly-dev] Support for legacy xml parsers In-Reply-To: <53D168C2.60900@redhat.com> References: <53D12B4A.8080408@redhat.com> <53D1304B.4060401@redhat.com> <53D168C2.60900@redhat.com> Message-ID: <53D16DB3.7090508@redhat.com> That's actually a good point I hadn't considered. I can't speak for other subsystems, but logging would still be useful. There are more resources now and probably better ways to do things, but the old operations and resources are still there. For me they're not all that hard to maintain. On 07/24/2014 01:12 PM, Brian Stansberry wrote: > Is a 7.1.1 config file likely to be useful in WF 9? On a server we no > longer support the old web subsystem, cmp and jaxr. By the time we're > done with Elytron integration, the security subsystem may be completely > revamped as well, with the current config relegated to HC-only support > for use in a mixed domain. > > On 7/24/14, 11:11 AM, James R. Perkins wrote: >> Ha, I just saw this email after having a conversion with Tomaz and David >> on IRC. >> >> Since WildFly there was such a long time between 7.1.1.Final and WildFly >> 8 I think it might be better to wait until WildFly 10. I still see quite >> a few questions regarding JBoss AS 7.x. If we could encourage those >> users to switch to WildFly I think it would make all of us happier :) If >> we cut support for WildFly 9 of their configuration files I could see >> them less likely to move if 9 is the current release. >> >> On 07/24/2014 08:50 AM, Brian Stansberry wrote: >>> For WildFly 9 (not 8.2) I propose that we change our policy regarding >>> support for legacy WildFly configuration documents.[1] >>> >>> Currently we support being able to parse content from any of our >>> namespaces (core or subsystem) shipped in a final release going back to >>> AS 7.0.0. >>> >>> I want to change this to limit support to namespaces shipped in AS 7.2.0 >>> or later and EAP 6.1.0 or later. >>> >>> This cutoff is consistent with what we are doing with mixed-version >>> support in managed domains. >>> >>> The goal of this is to reduce the maintenance burden related to legacy >>> xml parsers. The goal is *not* to reduce the size of the codebase etc. >>> So, if this proposal carries, please do not go off and delete old stuff >>> that works just because you can. But, if you find yourself having to >>> expend energy maintaining one of these old parsers, the policy change >>> means just dropping it is a valid alternative. >>> >>> Comments? >>> >>> >>> [1] Configuration documents meaning standalone/domain/host.xml, not >>> stuff like deployment descriptors. >>> > -- James R. Perkins JBoss by Red Hat From bburke at redhat.com Thu Jul 24 16:42:08 2014 From: bburke at redhat.com (Bill Burke) Date: Thu, 24 Jul 2014 16:42:08 -0400 Subject: [wildfly-dev] Status: Keycloak-secured Web Console in WildFly 9 In-Reply-To: <53D166FB.2020202@redhat.com> References: <53D16052.9070500@redhat.com> <53D166FB.2020202@redhat.com> Message-ID: <53D16FA0.3010106@redhat.com> Thanks Stan. You are the man. On 7/24/2014 4:05 PM, Stan Silvert wrote: > I sent below preview to TheCore. But I'd like to give status and get > development feedback from wildfly-dev. > https://community.jboss.org/wiki/PreviewKeycloak-securedManagementInWildFly9 > > Status: > * The current implementation only pulls Keycloak modules into WildFly > Full. WildFly Core only needs Keycloak at compile time. > * You can still use Keycloak with wf-core, but you need to install the > modules yourself. > * The current implementation may change a great deal based on Elytron. > I'd like to discuss with someone from that team. > * Thanks to Juca Krohling, who has been preparing integration tests for > this. > * If you follow the setup directions in the preview, you see that the > last step is to unzip some stuff into WildFly. The zip file contains > the Keycloak auth server, a standalone-keycloak.xml file, and an initial > Keycloak database configured for Web Console. I'm wondering if one or > more of these items should ship with WildFly Full? If not, how do we > make it as easy as possible to get Keycloak up and running? > > Waiting issue: > To merge this, we have to wait on two releases. First is a new Keycloak > release, which should be in the next two weeks. After that, I can do a > PR against WildFly Core. After waiting for a WildFly Core release, I > can do a PR against WildFly Full. > > The waiting is OK as long as it doesn't drag out too much. I'm hoping > the WildFly Core releases are indeed very frequent. > > Stan > > -------- Original Message -------- > Subject: Preview: Keycloak-secured Web Console in WildFly 9 > Date: Thu, 24 Jul 2014 15:36:50 -0400 > From: Stan Silvert > To: thecore at redhat.com > > > > If you want to see the Web Console secured by Keycloak, follow these > quick and easy instructions. Setup takes about 5 minutes. > https://community.jboss.org/wiki/PreviewKeycloak-securedManagementInWildFly9 > > Once you are done, you can see > * Web Console using Keycloak login. > * Single Signon between Web Console and Keycloak Admin > * Single Log Out > * Add/Remove Web Console users from Keycloak > * Manage RBAC roles for Web Console users from Keycloak > * Lots of other cool Keycloak features > > Stan > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From frank.langelage at osnanet.de Thu Jul 24 18:03:54 2014 From: frank.langelage at osnanet.de (Frank Langelage) Date: Fri, 25 Jul 2014 00:03:54 +0200 Subject: [wildfly-dev] WFLY 9.0 startup message Message-ID: <53D182CA.3090301@osnanet.de> When using current WildFly build from sources I see this message after startup is complete: 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services (179 services are lazy, passive or on-demand) Two things I suppose to be changed: 1. version is now the version of the underlying core, but version of the server should also be shown, or not? May be something like "WildFly 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? 2. the nickname "Kenny" already was used for WildFly 8.x. Time to create a new one for 9.0.x, or? From brian.stansberry at redhat.com Thu Jul 24 18:15:23 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 17:15:23 -0500 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D182CA.3090301@osnanet.de> References: <53D182CA.3090301@osnanet.de> Message-ID: <53D1857B.2090804@redhat.com> On 7/24/14, 5:03 PM, Frank Langelage wrote: > When using current WildFly build from sources I see this message after > startup is complete: > 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly > 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services > (179 services are lazy, passive or on-demand) > > Two things I suppose to be changed: > 1. version is now the version of the underlying core, but version of the > server should also be shown, or not? May be something like "WildFly > 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? IMHO it should just be the version of the full dist, with the core version only shown if whatever mechanism we add for letting a dist-based on core control this isn't implemented by a particular dist. Right now I assume we have no mechanism to let dists based on the core control this. > 2. the nickname "Kenny" already was used for WildFly 8.x. Time to create > a new one for 9.0.x, or? Please, let's drop code names!!! It's just another thing to screw up. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jorsol at gmail.com Thu Jul 24 18:43:52 2014 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Thu, 24 Jul 2014 16:43:52 -0600 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D1857B.2090804@redhat.com> References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> Message-ID: I'm not following very close the development of WF9, but I have a simple question, the log shows now WFLYSRV0025 instead of JBAS015874 ? Jorge Sol?rzano On Thu, Jul 24, 2014 at 4:15 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 7/24/14, 5:03 PM, Frank Langelage wrote: > > When using current WildFly build from sources I see this message after > > startup is complete: > > 24.07. 21:12:26,131 INFO [org.jboss.as#done] > WFLYSRV0025: WildFly > > 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services > > (179 services are lazy, passive or on-demand) > > > > Two things I suppose to be changed: > > 1. version is now the version of the underlying core, but version of the > > server should also be shown, or not? May be something like "WildFly > > 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? > > IMHO it should just be the version of the full dist, with the core > version only shown if whatever mechanism we add for letting a dist-based > on core control this isn't implemented by a particular dist. > > Right now I assume we have no mechanism to let dists based on the core > control this. > > > 2. the nickname "Kenny" already was used for WildFly 8.x. Time to create > > a new one for 9.0.x, or? > > Please, let's drop code names!!! It's just another thing to screw up. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140724/1c6bb29e/attachment.html From jperkins at redhat.com Thu Jul 24 19:54:17 2014 From: jperkins at redhat.com (James R. Perkins) Date: Thu, 24 Jul 2014 16:54:17 -0700 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D1857B.2090804@redhat.com> References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> Message-ID: <53D19CA9.4080601@redhat.com> On 07/24/2014 03:15 PM, Brian Stansberry wrote: > On 7/24/14, 5:03 PM, Frank Langelage wrote: >> When using current WildFly build from sources I see this message after >> startup is complete: >> 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly >> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services >> (179 services are lazy, passive or on-demand) >> >> Two things I suppose to be changed: >> 1. version is now the version of the underlying core, but version of the >> server should also be shown, or not? May be something like "WildFly >> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? > IMHO it should just be the version of the full dist, with the core > version only shown if whatever mechanism we add for letting a dist-based > on core control this isn't implemented by a particular dist. Probably not ideal, but something like this almost kind of works https://github.com/jamezp/wildfly/compare/name-test. We could clean the Version API up though and probably do it a little different. > > Right now I assume we have no mechanism to let dists based on the core > control this. > >> 2. the nickname "Kenny" already was used for WildFly 8.x. Time to create >> a new one for 9.0.x, or? > Please, let's drop code names!!! It's just another thing to screw up. +1 > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -- James R. Perkins JBoss by Red Hat From brian.stansberry at redhat.com Thu Jul 24 21:03:41 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 20:03:41 -0500 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> Message-ID: <53D1ACED.1050209@redhat.com> Yes, see https://issues.jboss.org/browse/WFLY-2864 and http://lists.jboss.org/pipermail/wildfly-dev/2014-February/001727.html On 7/24/14, 5:43 PM, Jorge Sol?rzano wrote: > I'm not following very close the development of WF9, but I have a simple > question, the log shows now WFLYSRV0025 instead of JBAS015874 ? > > > Jorge Sol?rzano > > > On Thu, Jul 24, 2014 at 4:15 PM, Brian Stansberry > > wrote: > > On 7/24/14, 5:03 PM, Frank Langelage wrote: > > When using current WildFly build from sources I see this message > after > > startup is complete: > > 24.07. 21:12:26,131 INFO [org.jboss.as#done > ] > WFLYSRV0025: WildFly > > 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services > > (179 services are lazy, passive or on-demand) > > > > Two things I suppose to be changed: > > 1. version is now the version of the underlying core, but version > of the > > server should also be shown, or not? May be something like "WildFly > > 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? > > IMHO it should just be the version of the full dist, with the core > version only shown if whatever mechanism we add for letting a dist-based > on core control this isn't implemented by a particular dist. > > Right now I assume we have no mechanism to let dists based on the core > control this. > > > 2. the nickname "Kenny" already was used for WildFly 8.x. Time to > create > > a new one for 9.0.x, or? > > Please, let's drop code names!!! It's just another thing to screw up. > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > 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 Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Thu Jul 24 21:24:16 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 24 Jul 2014 20:24:16 -0500 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D19CA9.4080601@redhat.com> References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> <53D19CA9.4080601@redhat.com> Message-ID: <53D1B1C0.40500@redhat.com> On 7/24/14, 6:54 PM, James R. Perkins wrote: > > On 07/24/2014 03:15 PM, Brian Stansberry wrote: >> On 7/24/14, 5:03 PM, Frank Langelage wrote: >>> When using current WildFly build from sources I see this message after >>> startup is complete: >>> 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly >>> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services >>> (179 services are lazy, passive or on-demand) >>> >>> Two things I suppose to be changed: >>> 1. version is now the version of the underlying core, but version of the >>> server should also be shown, or not? May be something like "WildFly >>> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? >> IMHO it should just be the version of the full dist, with the core >> version only shown if whatever mechanism we add for letting a dist-based >> on core control this isn't implemented by a particular dist. > Probably not ideal, but something like this almost kind of works > https://github.com/jamezp/wildfly/compare/name-test. Yeah, IIRC (which is chancy) in an IRC chat a few weeks back something like that looked like the likely solution. Some things to think about: 1) This is the EAP mechanism, so we'll need to think about how it will relate to EAP once that becomes relevant (i.e. don't steal its thing and then get stuck when it wants it back.) I think that's mostly just thinking about the log message we'll want to write adn ensuring ProductConfig can support that with the needed data. 2) product.conf as a file name kind of sucks for something that isn't a product 3) How this relates to the process of building a server when each of the pieces that make up that server (e.g. web-build) try to write that file, unless it's just trivial to have the final build win. > We could clean the > Version API up though and probably do it a little different. >> >> Right now I assume we have no mechanism to let dists based on the core >> control this. >> >>> 2. the nickname "Kenny" already was used for WildFly 8.x. Time to create >>> a new one for 9.0.x, or? >> Please, let's drop code names!!! It's just another thing to screw up. > +1 >> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From hrupp at redhat.com Fri Jul 25 04:16:04 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 25 Jul 2014 10:16:04 +0200 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <53D16557.1070405@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> Message-ID: <7C4643F8-9A80-4BD3-8F6B-4D06EB82F547@redhat.com> Am 24.07.2014 um 21:58 schrieb Brian Stansberry : > Please be cautious about the Alerts notion in your design. WildFly > doesn't actually have the kind of altering system that many might be > thinking of when they imagine this kind of thing. So it would have to be > developed. That's something we want to do, and Jeff Mesnil is doing some > of the foundational work, but it's not there yet and it's a big job > competing with lots of other big tasks. So, we want it, but the more a > UI design depends on a complex alerting system, the riskier it is that a > needed feature won't be there. Please be aware that RHQ / JBoss ON a) has complex alerting as of today b) will improve that and make it available to other project just like we are making rhq-metrics available to others. Creating an alerting (sub)system is no trivial task as we have learned the painful way. If you have resources available for this, then please contribute to the rhq effort so that we have a joint (customer) experience. Heiko From lclayton at redhat.com Fri Jul 25 08:49:10 2014 From: lclayton at redhat.com (Liz Clayton) Date: Fri, 25 Jul 2014 08:49:10 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: <53D16557.1070405@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> Message-ID: <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > From: "Brian Stansberry" > To: "Liz Clayton" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, July 24, 2014 3:58:15 PM > Subject: Re: [wildfly-dev] Domain Overview design > > +100 on Jason's comment thanking you for posting this. Thanks for looking it over, and for the great feedback! I have some follow-up questions inline. > On 7/24/14, 12:05 PM, Jason Greene wrote: > > > > On Jul 24, 2014, at 11:45 AM, Jason Greene wrote: > > > >> > >> On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: > >> > >>> Hi, > >>> > >>> I'm sketching out some ideas for the Domain Overview screen. I'd like to > >>> find a visualization that make it easier to scan the page to determine > >>> server availability, and possibly alerts. > >>> > >>> Given that the domain could be large, the visualization needs to scale. I > >>> started by looking at heatmap visualizations, which worked pretty well. > >>> Although I didn't feel like they helped in describing the overall > >>> relationships of servers, server groups and hosts... So I decided to > >>> break the heat maps into individual (stacked) heatmaps, ordered by > >>> server group. My hope is that this helps to define groupings and such. > >>> > >>> I posted the current design proposal at: > >>> https://community.jboss.org/wiki/DomainOverview070114pdf > >>> > >>> It would be great to get feedback on the designs. Some questions I have > >>> are: > >>> - Is it difficult/easy to understand that the boxes, in the server > >>> groupings, are intended to represent servers? > > That seemed intuitive to me. I don't get though why some boxes are > different sizes from others on "Second Iteration: Stacked heatmap". On > "First draft heatmap ? Server Group view for 'availability'" I could > somewhat get that, as different server groups can vary in size based on > # of servers. So it sounds like the uniformly sized boxes (pg 5) are working better for you? Followed by the standard heatmap (pg15), and then not so much for the irregular ones on pg 16? The boxes are irregular on 16 because they were intended to display mini heatmaps, stacked. And unlike the domain-view version (pg15) where the size of the box would be driven by # of servers - the mini ones could be scaled by some other metric (throughput or etc.). But I didn't really have that information, so I made the boxes uniformly sized. > >>> - Should the servers be laid out in the visualization by level of > >>> availability/status (as illustrated), or by some other ordering (A-Z, > >>> Z-A...)? > > My instinct is something like alphabetical is better. The color already > lets me easily find and identify things where availability/status is > relevant to what I want to do. But when it's not relevant to what I want > (say I want to work with server-X for reasons completely unrelated to > availability) then I need to rely on location to find what I want quickly. That makes sense. For the everything is OK scenario - maybe there could be some kind of search to help locate/highlight a specific server in the display. > Note that multiple servers in a domain can have the same name; it's the > host (as in Host Controller) + server name combination that must be unique. Good to know. > >>> - Is it difficult/easy to understand that when a box is a different > >>> color, that it is indicating its availability status? > > If the colors are green and grey, maybe not. But in a number of examples > you use green<->red, with grey too, and I think that's pretty intuitive. > Red = bad, green = good, yellowish = in between, grey = the good/bad > aspect is out-of-scope. Is there info to help figure out those bands - when something changes from yellow to red...? > >>> - What do you expect to be the relationship between (Availability) Status > >>> and Alerts? Would ?x? alerts equate to a change in availability status, > >>> or can they function independently? For example: Could you have an error > >>> on a server and it still be ?available?? > > I think we need a better understanding of what alerts are. In general, I > like the idea of the occurrence of some kind of negative event tends to > shift the color away from green and toward red. But what constitutes a > negative event? How much control does the user have over that > definition? How much control does the user have over how much different > events shift the color? Yes exactly. I was hoping that there could be some type of relationship (events=shifting), and that the user could drill-down to learn more about the event(s). But lots of hand-waving in the design, because I'm not sure how do-able that is? > Please be cautious about the Alerts notion in your design. WildFly > doesn't actually have the kind of altering system that many might be > thinking of when they imagine this kind of thing. So it would have to be > developed. That's something we want to do, and Jeff Mesnil is doing some > of the foundational work, but it's not there yet and it's a big job > competing with lots of other big tasks. So, we want it, but the more a > UI design depends on a complex alerting system, the riskier it is that a > needed feature won't be there. Great to know, thanks! I'm principally trying to find a way for users to drill-down to get more information about an availability issue. Perhaps there are other ways that steer clear of alerts. > Re: some of the questions, on the "Questions" page: > > "What are the states for server availability?" > > On "Not available" and "Failed" we have no notion of why a server was > taken down; i.e. the admin takes it down, but whether they did so due to > issues or for some other reason, we have no idea. We can distinguish a > crash from an administrative shutdown. So it sounds like there is shutdown ("N/A") and "failed." > Also, there are other aspect of a server's running state that complicate > things. > > We are adding the ability to put a server in "suspending" and > "suspended" states where it moves to not accepting normal end user > requests but is still running. This isn't an "error" state; the admin > has chosen to put the server in that state. So it sounds like there is: shutdown ("N/A"), "suspended", and "failed." > There's also a similar notion regarding how consistent the server's > running state is with its persistent configuration. Admins can make > configuration changes that will not take effect until the server is > reloaded or restarted. Would that directly affect its availability status? > I'm not sure if those things are well represented on a green-yellow-red > color continuum because they are somewhat different from server health. > But they are important pieces of data to visualize. yes, great to know about. > "How does the Alerts tab fit in with the *current* Notification message > queue?" > > Heiko Braun knows better, but I don't see a close fit. The current queue > isn't really based on any sort of server-push of events. The console > makes administrative requests and gets responses; if relevant that > request/response results in stuff in the queue. But anything that > happens outside of those requests/responses is unknown to the console. So there are events happening on the system, that could affect availability, which will not show up in the message queue? Thanks! Liz > Cheers, > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > From brian.stansberry at redhat.com Fri Jul 25 10:21:52 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 25 Jul 2014 09:21:52 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <7C4643F8-9A80-4BD3-8F6B-4D06EB82F547@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <7C4643F8-9A80-4BD3-8F6B-4D06EB82F547@redhat.com> Message-ID: <53D26800.1080307@redhat.com> On 7/25/14, 3:16 AM, Heiko W.Rupp wrote: > > Am 24.07.2014 um 21:58 schrieb Brian Stansberry : >> Please be cautious about the Alerts notion in your design. WildFly >> doesn't actually have the kind of altering system that many might be >> thinking of when they imagine this kind of thing. So it would have to be >> developed. That's something we want to do, and Jeff Mesnil is doing some >> of the foundational work, but it's not there yet and it's a big job >> competing with lots of other big tasks. So, we want it, but the more a >> UI design depends on a complex alerting system, the riskier it is that a >> needed feature won't be there. > > Please be aware that RHQ / JBoss ON > > a) has complex alerting as of today > b) will improve that and make it available to other project just like > we are making rhq-metrics available to others. > Good to know. I figured that would happen, a la the rhq-metrics work; I'm glad to hear that's the plan. > Creating an alerting (sub)system is no trivial task as we have > learned the painful way. If you have resources available for this, > then please contribute to the rhq effort so that we have a joint > (customer) experience. > Yes, absolutely. We've done very little in this area, and have very little in the way of resources, so anything we do we'd very much want to do as part of a broader effort. The work I mentioned that Jeff is doing truly is foundational; it's not an alerts management system, it's the fundamental support for receiving notifications from the management API. Anything not based on polling would need that. See http://lists.jboss.org/pipermail/wildfly-dev/2014-July/002533.html > Heiko > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Fri Jul 25 13:09:56 2014 From: jperkins at redhat.com (James R. Perkins) Date: Fri, 25 Jul 2014 10:09:56 -0700 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D1B1C0.40500@redhat.com> References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> <53D19CA9.4080601@redhat.com> <53D1B1C0.40500@redhat.com> Message-ID: <53D28F64.8030301@redhat.com> On 07/24/2014 06:24 PM, Brian Stansberry wrote: > On 7/24/14, 6:54 PM, James R. Perkins wrote: >> >> On 07/24/2014 03:15 PM, Brian Stansberry wrote: >>> On 7/24/14, 5:03 PM, Frank Langelage wrote: >>>> When using current WildFly build from sources I see this message after >>>> startup is complete: >>>> 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly >>>> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services >>>> (179 services are lazy, passive or on-demand) >>>> >>>> Two things I suppose to be changed: >>>> 1. version is now the version of the underlying core, but version >>>> of the >>>> server should also be shown, or not? May be something like "WildFly >>>> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? >>> IMHO it should just be the version of the full dist, with the core >>> version only shown if whatever mechanism we add for letting a >>> dist-based >>> on core control this isn't implemented by a particular dist. >> Probably not ideal, but something like this almost kind of works >> https://github.com/jamezp/wildfly/compare/name-test. > > Yeah, IIRC (which is chancy) in an IRC chat a few weeks back something > like that looked like the likely solution. Some things to think about: > > 1) This is the EAP mechanism, so we'll need to think about how it will > relate to EAP once that becomes relevant (i.e. don't steal its thing > and then get stuck when it wants it back.) I think that's mostly just > thinking about the log message we'll want to write adn ensuring > ProductConfig can support that with the needed data. Agreed. > > 2) product.conf as a file name kind of sucks for something that isn't > a product Again agreed. > > 3) How this relates to the process of building a server when each of > the pieces that make up that server (e.g. web-build) try to write that > file, unless it's just trivial to have the final build win. Maybe it's something we can enhance the build plugin to do now. Seems there should be a reasonable solution. Maybe a simple properties file lookup or something like that. Anyway I don't want to jump in the middle if someone is already looking at it. > >> We could clean the >> Version API up though and probably do it a little different. >>> >>> Right now I assume we have no mechanism to let dists based on the core >>> control this. >>> >>>> 2. the nickname "Kenny" already was used for WildFly 8.x. Time to >>>> create >>>> a new one for 9.0.x, or? >>> Please, let's drop code names!!! It's just another thing to screw up. >> +1 >>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >> > > -- James R. Perkins JBoss by Red Hat From brian.stansberry at redhat.com Fri Jul 25 13:23:08 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 25 Jul 2014 12:23:08 -0500 Subject: [wildfly-dev] WFLY 9.0 startup message In-Reply-To: <53D28F64.8030301@redhat.com> References: <53D182CA.3090301@osnanet.de> <53D1857B.2090804@redhat.com> <53D19CA9.4080601@redhat.com> <53D1B1C0.40500@redhat.com> <53D28F64.8030301@redhat.com> Message-ID: <53D2927C.8090809@redhat.com> On 7/25/14, 12:09 PM, James R. Perkins wrote: > > On 07/24/2014 06:24 PM, Brian Stansberry wrote: >> On 7/24/14, 6:54 PM, James R. Perkins wrote: >>> >>> On 07/24/2014 03:15 PM, Brian Stansberry wrote: >>>> On 7/24/14, 5:03 PM, Frank Langelage wrote: >>>>> When using current WildFly build from sources I see this message after >>>>> startup is complete: >>>>> 24.07. 21:12:26,131 INFO [org.jboss.as#done] WFLYSRV0025: WildFly >>>>> 1.0.0.Alpha3 "Kenny" started in 28469ms - Started 374 of 500 services >>>>> (179 services are lazy, passive or on-demand) >>>>> >>>>> Two things I suppose to be changed: >>>>> 1. version is now the version of the underlying core, but version >>>>> of the >>>>> server should also be shown, or not? May be something like "WildFly >>>>> 9.0.0-Alpha-SNAPSHOT based on WildFly Core 1.0.0.Alpha3" ? >>>> IMHO it should just be the version of the full dist, with the core >>>> version only shown if whatever mechanism we add for letting a >>>> dist-based >>>> on core control this isn't implemented by a particular dist. >>> Probably not ideal, but something like this almost kind of works >>> https://github.com/jamezp/wildfly/compare/name-test. >> >> Yeah, IIRC (which is chancy) in an IRC chat a few weeks back something >> like that looked like the likely solution. Some things to think about: >> >> 1) This is the EAP mechanism, so we'll need to think about how it will >> relate to EAP once that becomes relevant (i.e. don't steal its thing >> and then get stuck when it wants it back.) I think that's mostly just >> thinking about the log message we'll want to write adn ensuring >> ProductConfig can support that with the needed data. > Agreed. >> >> 2) product.conf as a file name kind of sucks for something that isn't >> a product > Again agreed. EAP will probably want to keep it though, so perhaps ProductConfig can check for 2 things, giving precedence to product.conf. >> >> 3) How this relates to the process of building a server when each of >> the pieces that make up that server (e.g. web-build) try to write that >> file, unless it's just trivial to have the final build win. > Maybe it's something we can enhance the build plugin to do now. Seems > there should be a reasonable solution. Maybe a simple properties file > lookup or something like that. Anyway I don't want to jump in the middle > if someone is already looking at it. I doubt anyone is looking into this; IIRC it was just something that was chatted about a bit. Ping Stuart if no one responds; if anyone is doing anything it's likely him. It's possible the provisioning stuff already handles all this just fine; I am far from an expert on the current status. >> >>> We could clean the >>> Version API up though and probably do it a little different. >>>> >>>> Right now I assume we have no mechanism to let dists based on the core >>>> control this. >>>> >>>>> 2. the nickname "Kenny" already was used for WildFly 8.x. Time to >>>>> create >>>>> a new one for 9.0.x, or? >>>> Please, let's drop code names!!! It's just another thing to screw up. >>> +1 >>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>> >> >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Fri Jul 25 17:40:30 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 25 Jul 2014 16:40:30 -0500 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> Message-ID: <53D2CECE.8000400@redhat.com> On 7/25/14, 7:49 AM, Liz Clayton wrote: > Hi, > > ----- Original Message ----- >> From: "Brian Stansberry" >> To: "Liz Clayton" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Thursday, July 24, 2014 3:58:15 PM >> Subject: Re: [wildfly-dev] Domain Overview design >> >> +100 on Jason's comment thanking you for posting this. > > Thanks for looking it over, and for the great feedback! I have some follow-up questions inline. > >> On 7/24/14, 12:05 PM, Jason Greene wrote: >>> >>> On Jul 24, 2014, at 11:45 AM, Jason Greene wrote: >>> >>>> >>>> On Jul 24, 2014, at 11:22 AM, Liz Clayton wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm sketching out some ideas for the Domain Overview screen. I'd like to >>>>> find a visualization that make it easier to scan the page to determine >>>>> server availability, and possibly alerts. >>>>> >>>>> Given that the domain could be large, the visualization needs to scale. I >>>>> started by looking at heatmap visualizations, which worked pretty well. >>>>> Although I didn't feel like they helped in describing the overall >>>>> relationships of servers, server groups and hosts... So I decided to >>>>> break the heat maps into individual (stacked) heatmaps, ordered by >>>>> server group. My hope is that this helps to define groupings and such. >>>>> >>>>> I posted the current design proposal at: >>>>> https://community.jboss.org/wiki/DomainOverview070114pdf >>>>> >>>>> It would be great to get feedback on the designs. Some questions I have >>>>> are: >>>>> - Is it difficult/easy to understand that the boxes, in the server >>>>> groupings, are intended to represent servers? >> >> That seemed intuitive to me. I don't get though why some boxes are >> different sizes from others on "Second Iteration: Stacked heatmap". On >> "First draft heatmap ? Server Group view for 'availability'" I could >> somewhat get that, as different server groups can vary in size based on >> # of servers. > > So it sounds like the uniformly sized boxes (pg 5) are working better for you? Followed by the standard heatmap (pg15), and then not so much for the irregular ones on pg 16? > Yes. Aesthetically I like the pg16 approach, but once I asked myself what the size meant, I had no answer. :) BTW, I just realized that pg 5 is the more critical page vs pg 16. :) > The boxes are irregular on 16 because they were intended to display mini heatmaps, stacked. And unlike the domain-view version (pg15) where the size of the box would be driven by # of servers - the mini ones could be scaled by some other metric (throughput or etc.). But I didn't really have that information, so I made the boxes uniformly sized. > I see; so the thought was perhaps the user could choose a scaling factor or something? >>>>> - Should the servers be laid out in the visualization by level of >>>>> availability/status (as illustrated), or by some other ordering (A-Z, >>>>> Z-A...)? >> >> My instinct is something like alphabetical is better. The color already >> lets me easily find and identify things where availability/status is >> relevant to what I want to do. But when it's not relevant to what I want >> (say I want to work with server-X for reasons completely unrelated to >> availability) then I need to rely on location to find what I want quickly. > > That makes sense. For the everything is OK scenario - maybe there could be some kind of search to help locate/highlight a specific server in the display. > >> Note that multiple servers in a domain can have the same name; it's the >> host (as in Host Controller) + server name combination that must be unique. > > Good to know. > >>>>> - Is it difficult/easy to understand that when a box is a different >>>>> color, that it is indicating its availability status? >> >> If the colors are green and grey, maybe not. But in a number of examples >> you use green<->red, with grey too, and I think that's pretty intuitive. >> Red = bad, green = good, yellowish = in between, grey = the good/bad >> aspect is out-of-scope. > > Is there info to help figure out those bands - when something changes from yellow to red...? > Not really, no. Having that gets into the "alerts" discussion. Some of the other notions I mentioned -- suspended, reload-required, restart-required -- could possibly be 'yellow', but as we discuss below those things are not quite the same as server "health". The "suspended" state could logically be yellow, but if later we want to treat some sort of alert-based error criteria as triggering yellow, then we'd be mixing two different things into the "yellow" concept. >>>>> - What do you expect to be the relationship between (Availability) Status >>>>> and Alerts? Would ?x? alerts equate to a change in availability status, >>>>> or can they function independently? For example: Could you have an error >>>>> on a server and it still be ?available?? >> >> I think we need a better understanding of what alerts are. In general, I >> like the idea of the occurrence of some kind of negative event tends to >> shift the color away from green and toward red. But what constitutes a >> negative event? How much control does the user have over that >> definition? How much control does the user have over how much different >> events shift the color? > > Yes exactly. I was hoping that there could be some type of relationship (events=shifting), and that the user could drill-down to learn more about the event(s). But lots of hand-waving in the design, because I'm not sure how do-able that is? > It's a very big task. >> Please be cautious about the Alerts notion in your design. WildFly >> doesn't actually have the kind of altering system that many might be >> thinking of when they imagine this kind of thing. So it would have to be >> developed. That's something we want to do, and Jeff Mesnil is doing some >> of the foundational work, but it's not there yet and it's a big job >> competing with lots of other big tasks. So, we want it, but the more a >> UI design depends on a complex alerting system, the riskier it is that a >> needed feature won't be there. > > Great to know, thanks! I'm principally trying to find a way for users to drill-down to get more information about an availability issue. Perhaps there are other ways that steer clear of alerts. > >> Re: some of the questions, on the "Questions" page: >> >> "What are the states for server availability?" >> >> On "Not available" and "Failed" we have no notion of why a server was >> taken down; i.e. the admin takes it down, but whether they did so due to >> issues or for some other reason, we have no idea. We can distinguish a >> crash from an administrative shutdown. > > So it sounds like there is shutdown ("N/A") and "failed." > >> Also, there are other aspect of a server's running state that complicate >> things. >> >> We are adding the ability to put a server in "suspending" and >> "suspended" states where it moves to not accepting normal end user >> requests but is still running. This isn't an "error" state; the admin >> has chosen to put the server in that state. > > So it sounds like there is: shutdown ("N/A"), "suspended", and "failed." > >> There's also a similar notion regarding how consistent the server's >> running state is with its persistent configuration. Admins can make >> configuration changes that will not take effect until the server is >> reloaded or restarted. > > Would that directly affect its availability status? > No, it wouldn't. The server goes into this state when the admin makes a config change that the server can't apply to its running services without affecting their ability to handle end-user requests. The server doesn't "just do it", it goes into this state which lets the admin know they need to take an action that *will* temporarily affect availability. >> I'm not sure if those things are well represented on a green-yellow-red >> color continuum because they are somewhat different from server health. >> But they are important pieces of data to visualize. > > yes, great to know about. > >> "How does the Alerts tab fit in with the *current* Notification message >> queue?" >> >> Heiko Braun knows better, but I don't see a close fit. The current queue >> isn't really based on any sort of server-push of events. The console >> makes administrative requests and gets responses; if relevant that >> request/response results in stuff in the queue. But anything that >> happens outside of those requests/responses is unknown to the console. > > So there are events happening on the system, that could affect availability, which will not show up in the message queue? > Absolutely. The console only knows what it specifically asks or the effect of changes it makes, plus a small bit of status information that gets piggy-backed in the response to requests (i.e. that the server is in reload/restart-required state.) But the user's app could be throwing errors all over the place, resources like memory or thread pools could be overtaxed, etc, and the console would have no clue unless it check those specific things. > Thanks! > Liz > > >> Cheers, >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From william at witt-family.net Sat Jul 26 19:12:16 2014 From: william at witt-family.net (William Witt) Date: Sat, 26 Jul 2014 18:12:16 -0500 Subject: [wildfly-dev] I'm looking to contribute Message-ID: <56F69141-256B-4030-9036-A0840330651B@witt-family.net> I?m looking to contribute to WildFly in some way. I?d appreciate any assistance getting started or tossing simple bugs my way to assist in learning the project?s architecture. What I?ve done so far: - Cloned and pulled down the source from GitHub - Built via the command line (which worked like a charm) - Attempted to import the project into Eclipse, but there are a 33k+ build errors due to unresolved dependencies. I?d appreciate assistance configuring Eclipse correctly. A little bit about me: - At my day job I develop Java web applications, integrating with other C# and Java apps via SOAP web services and an AQ based ESB. (Unfortunately, we?re locked in to Weblogic through an enterprise buy). - I?m on a Mac with both Windows and Linux VMs available, and don?t mind working on Mac specific issues. - I have 10-15 hours a week to help, mostly on nights and weekends. William Witt From tomaz.cerar at gmail.com Mon Jul 28 07:46:00 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 28 Jul 2014 13:46:00 +0200 Subject: [wildfly-dev] Build / distro in new build system Message-ID: Hi guys, there have been lots of questions about end results of new build, mostly all related to missing "jar" files in build distribution. New build plugin now enables us to produce "slim" distribution of WildFly which does not include jar files in module directory but rather user jboss-modules feature to load resources from maven. This slim/full distribution can be controlled in server-build.xml, which is config file for build plugin, by *copy-module-artifacts* flag. By default in current build we have different settings for different modules / builds by directories: - build - produces slim distribution of whole server, which is used for integration testing - web-build - produces "web" slim distribution - dist - produces full inflated distribution with all jars in modules and in wildfly-core, we have - core-build - which produces inflated distribution, but will be switched back to slim after MODULES-194 is fixed So in short, if you need full distribution with all jars or slim distro doesn't work for you (WFLY-3596 ) either use build that you can find in "dist/target" or change config flag (just don't commit it back) Also in similar spirit if you need zip/tar.gz distribution, then just run build with -Drelease and you will get zip/tar.gz in dist/target -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140728/477abc18/attachment-0001.html From rory.odonnell at oracle.com Tue Jul 29 05:08:28 2014 From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland) Date: Tue, 29 Jul 2014 10:08:28 +0100 Subject: [wildfly-dev] Early Access builds for JDK 9 b24, JDK 8u20 b23 are available on java.net Message-ID: <53D7648C.9010900@oracle.com> Hi Guys, Early Access builds for JDK 9 b24 and JDK 8u20 b23 are available on java.net. As we enter the later phases of development for JDK 8u20 , please log any show stoppers as soon as possible. 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/20140729/1603464e/attachment.html From tomaz.cerar at gmail.com Tue Jul 29 09:12:33 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 29 Jul 2014 15:12:33 +0200 Subject: [wildfly-dev] I'm looking to contribute In-Reply-To: <56F69141-256B-4030-9036-A0840330651B@witt-family.net> References: <56F69141-256B-4030-9036-A0840330651B@witt-family.net> Message-ID: Hi William, always great to see people interested in contributing :) For your eclipse problem I am not sure what is wrong, but all you should do is import it as maven project. If you don't see that option anywhere install https://www.eclipse.org/m2e/ plugin which will help you resolve your build problems. As for simple issues to start with go, I think just going trough jira and find something that maybe bothers you or you think it wont should be simple to fix just grab it, there are plenty issues just waiting to be grabbed https://issues.jboss.org/browse/WFLY In short it is easiest to start with something that has immediate effect on you, probably some small bug that is irritating you and we forgot to address it. If you have any more questions just ask away. -- tomaz On Sun, Jul 27, 2014 at 1:12 AM, William Witt wrote: > I?m looking to contribute to WildFly in some way. I?d appreciate any > assistance getting started or tossing simple bugs my way to assist in > learning the project?s architecture. > > What I?ve done so far: > - Cloned and pulled down the source from GitHub > - Built via the command line (which worked like a charm) > - Attempted to import the project into Eclipse, but there are a 33k+ build > errors due to unresolved dependencies. I?d appreciate assistance > configuring Eclipse correctly. > > A little bit about me: > - At my day job I develop Java web applications, integrating with other C# > and Java apps via SOAP web services and an AQ based ESB. (Unfortunately, > we?re locked in to Weblogic through an enterprise buy). > - I?m on a Mac with both Windows and Linux VMs available, and don?t mind > working on Mac specific issues. > - I have 10-15 hours a week to help, mostly on nights and weekends. > > William Witt > _______________________________________________ > 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/20140729/1d113cca/attachment.html From wfink at redhat.com Tue Jul 29 09:25:23 2014 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Tue, 29 Jul 2014 15:25:23 +0200 Subject: [wildfly-dev] I'm looking to contribute In-Reply-To: <56F69141-256B-4030-9036-A0840330651B@witt-family.net> References: <56F69141-256B-4030-9036-A0840330651B@witt-family.net> Message-ID: <53D7A0C3.8070504@redhat.com> Great that you are interested, any helping hand will improve WildFly :) You might have a look to https://community.jboss.org/wiki/HackingOnWildFly as well. For Eclipse, I use the maven import, you need the maven plugin anyway. it happen to me that I need to use "Maven -> refresh" after import - I don't understand the reason why that happen sometimes That works for me Wolf On 27/07/14 01:12, William Witt wrote: > I?m looking to contribute to WildFly in some way. I?d appreciate any assistance getting started or tossing simple bugs my way to assist in learning the project?s architecture. > > What I?ve done so far: > - Cloned and pulled down the source from GitHub > - Built via the command line (which worked like a charm) > - Attempted to import the project into Eclipse, but there are a 33k+ build errors due to unresolved dependencies. I?d appreciate assistance configuring Eclipse correctly. > > A little bit about me: > - At my day job I develop Java web applications, integrating with other C# and Java apps via SOAP web services and an AQ based ESB. (Unfortunately, we?re locked in to Weblogic through an enterprise buy). > - I?m on a Mac with both Windows and Linux VMs available, and don?t mind working on Mac specific issues. > - I have 10-15 hours a week to help, mostly on nights and weekends. > > William Witt > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hrupp at redhat.com Tue Jul 29 11:52:39 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 29 Jul 2014 17:52:39 +0200 Subject: [wildfly-dev] Domain Overview design In-Reply-To: <53D26800.1080307@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <7C4643F8-9A80-4BD3-8F6B-4D06EB82F547@redhat.com> <53D26800.1080307@redhat.com> Message-ID: <5D578F0D-E3D3-43E8-8713-718118F4540E@redhat.com> Hey Brian, thanks for you reply. > Good to know. I figured that would happen, a la the rhq-metrics work; > I'm glad to hear that's the plan. Absolutely. > The work I mentioned that Jeff is doing truly is foundational; it's not > an alerts management system, it's the fundamental support for receiving > notifications from the management API. Anything not based on polling > would need that. Ah, so the analogy of jmx notifications - a long awaited feature. Definitively makes sense. We should see how we can pick that data up in RHQ and make use of it. Thanks Heiko From hrupp at redhat.com Tue Jul 29 12:01:44 2014 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 29 Jul 2014 18:01:44 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> Message-ID: <1973EA0E-BAED-4235-AC4E-B1461BEE1B7A@redhat.com> Am 09.07.2014 um 20:55 schrieb Patton, John : > We rely on JMX for accessing specific monitoring metrics and it's > difficult to get at some of the metrics that used to be easily available > in prior versions for some metrics. We've had to jump through some hoops I second this from the experiences we have in RHQ -- Heiko Rupp Project lead RHQ projects http://jboss.org/rhq From tomaz.cerar at gmail.com Tue Jul 29 12:25:59 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 29 Jul 2014 18:25:59 +0200 Subject: [wildfly-dev] Is JMX Needed in Core? In-Reply-To: <1973EA0E-BAED-4235-AC4E-B1461BEE1B7A@redhat.com> References: <53BD1DB4.7050908@jboss.com> <53BD89A3.10600@redhat.com> <1973EA0E-BAED-4235-AC4E-B1461BEE1B7A@redhat.com> Message-ID: On Tue, Jul 29, 2014 at 6:01 PM, Heiko W.Rupp wrote: > I second this from the experiences we have in RHQ And i will second question you, why is this something that needs to be in barebones wildfly core? It will stay part of all normal distributions out there. Noting really changes for RHQ and alike. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140729/eff99928/attachment.html From lclayton at redhat.com Tue Jul 29 14:44:07 2014 From: lclayton at redhat.com (Liz Clayton) Date: Tue, 29 Jul 2014 14:44:07 -0400 (EDT) Subject: [wildfly-dev] Domain Overview design In-Reply-To: <53D2CECE.8000400@redhat.com> References: <1058582827.18816481.1406218925294.JavaMail.zimbra@redhat.com> <29D9D528-0ACE-448A-BECF-7188ADE5837A@redhat.com> <3F3B9B31-D534-468A-A0DB-69883E62BD15@redhat.com> <53D16557.1070405@redhat.com> <660940694.19299854.1406292550805.JavaMail.zimbra@redhat.com> <53D2CECE.8000400@redhat.com> Message-ID: <874726742.21577492.1406659447392.JavaMail.zimbra@redhat.com> Hi, Thanks for answering my questions! ----- Original Message ----- > From: "Brian Stansberry" > To: "Liz Clayton" > Cc: wildfly-dev at lists.jboss.org > Sent: Friday, July 25, 2014 5:40:30 PM > Subject: Re: [wildfly-dev] Domain Overview design > ... > > The boxes are irregular on 16 because they were intended to display mini > > heatmaps, stacked. And unlike the domain-view version (pg15) where the > > size of the box would be driven by # of servers - the mini ones could be > > scaled by some other metric (throughput or etc.). But I didn't really have > > that information, so I made the boxes uniformly sized. > > > > I see; so the thought was perhaps the user could choose a scaling factor > or something? I hadn't thought about it being a user selection, but that's an interesting idea. ... > >> There's also a similar notion regarding how consistent the server's > >> running state is with its persistent configuration. Admins can make > >> configuration changes that will not take effect until the server is > >> reloaded or restarted. > > > > Would that directly affect its availability status? > > > > No, it wouldn't. The server goes into this state when the admin makes a > config change that the server can't apply to its running services > without affecting their ability to handle end-user requests. The server > doesn't "just do it", it goes into this state which lets the admin know > they need to take an action that *will* temporarily affect availability. > > >> I'm not sure if those things are well represented on a green-yellow-red > >> color continuum because they are somewhat different from server health. > >> But they are important pieces of data to visualize. So there's server health (availability), & server "state", and they are both useful bits of high-level info. > > yes, great to know about. > > > >> "How does the Alerts tab fit in with the *current* Notification message > >> queue?" > >> > >> Heiko Braun knows better, but I don't see a close fit. The current queue > >> isn't really based on any sort of server-push of events. The console > >> makes administrative requests and gets responses; if relevant that > >> request/response results in stuff in the queue. But anything that > >> happens outside of those requests/responses is unknown to the console. > > > > So there are events happening on the system, that could affect > > availability, which will not show up in the message queue? > > > > Absolutely. The console only knows what it specifically asks or the > effect of changes it makes, plus a small bit of status information that > gets piggy-backed in the response to requests (i.e. that the server is > in reload/restart-required state.) But the user's app could be throwing > errors all over the place, resources like memory or thread pools could > be overtaxed, etc, and the console would have no clue unless it check > those specific things. OK, thanks! -Liz From claudio at claudius.com.br Tue Jul 29 16:48:25 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 29 Jul 2014 17:48:25 -0300 Subject: [wildfly-dev] HAL - filter for environment properties is gone Message-ID: HI, I noticed the input text to filter properties in "Runtime - Server Status - Environment" is gone from wildfly 8.1 and latest 9 alpha3. Is there any reason to remove it ? It was of great help to filter custom properties. As it is today user must navigate and visually search for the property. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Tue Jul 29 19:16:24 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 29 Jul 2014 20:16:24 -0300 Subject: [wildfly-dev] HAL - filter for environment properties is gone In-Reply-To: References: Message-ID: Looks like a regression of https://issues.jboss.org/browse/HAL-266 On Tue, Jul 29, 2014 at 5:48 PM, Claudio Miranda wrote: > HI, I noticed the input text to filter properties in "Runtime - Server > Status - Environment" is gone from wildfly 8.1 and latest 9 alpha3. > > Is there any reason to remove it ? > > It was of great help to filter custom properties. > > As it is today user must navigate and visually search for the property. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Tue Jul 29 21:11:03 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 29 Jul 2014 22:11:03 -0300 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found Message-ID: Hi, have updated hal and run mvn -Pdev clean install, it cannot find the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact repository.jboss.org doesn't contain this artifact. [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom [WARNING] The POM for org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no dependency information available Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar ... [ERROR] Failed to execute goal on project console-spi: Could not resolve dependencies for project org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] [ERROR] -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From claudio at claudius.com.br Tue Jul 29 22:27:26 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Tue, 29 Jul 2014 23:27:26 -0300 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: References: Message-ID: I needed to download and mvn install the following projects https://github.com/hal/jgrapht https://github.com/hal/circuit But building hal/core (mvn -Pdev clean install) throws [INFO] [ERROR] Errors in 'jar:file:/home/claudio/.m2/repository/org/jgrapht/jgrapht-core/0.9.1-hal/jgrapht-core-0.9.1-hal-sources.jar!/org/jgrapht/traverse/DepthFirstIterator.java' [INFO] [ERROR] Line 81: No source code is available for type java.util.Deque; did you forget to inherit a required module? [INFO] [ERROR] Line 81: No source code is available for type java.util.ArrayDeque; did you forget to inherit a required module? Any ideas ? On Tue, Jul 29, 2014 at 10:11 PM, Claudio Miranda wrote: > Hi, have updated hal and run mvn -Pdev clean install, it cannot find > the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact > > repository.jboss.org doesn't contain this artifact. > > > [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom > Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom > [WARNING] The POM for > org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no > dependency information available > Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar > Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar > > ... > > [ERROR] Failed to execute goal on project console-spi: Could not > resolve dependencies for project > org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact > org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in > jboss-public-repository-group > (https://repository.jboss.org/nexus/content/groups/public/) -> [Help > 1] > [ERROR] -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From hpehl at redhat.com Wed Jul 30 03:57:54 2014 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 30 Jul 2014 09:57:54 +0200 Subject: [wildfly-dev] HAL - filter for environment properties is gone In-Reply-To: References: Message-ID: <38121194-BE09-459E-9BEB-062051EBA11F@redhat.com> Yes you're right. Somehow this fix got lost. But it's here again [1]! It's in Ballroom 2.1.0-SNAPSHOT which is a dependency of HAL 2.4.0-SNAPSHOT. [1] https://github.com/hal/ballroom/commit/19932bd1bc56da6199f68651c5a38bd8d8a2e2b3 Am 30.07.2014 um 01:16 schrieb Claudio Miranda : > Looks like a regression of https://issues.jboss.org/browse/HAL-266 > > On Tue, Jul 29, 2014 at 5:48 PM, Claudio Miranda > wrote: >> HI, I noticed the input text to filter properties in "Runtime - Server >> Status - Environment" is gone from wildfly 8.1 and latest 9 alpha3. >> >> Is there any reason to remove it ? >> >> It was of great help to filter custom properties. >> >> As it is today user must navigate and visually search for the property. > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > 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 From hbraun at redhat.com Wed Jul 30 04:07:45 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 30 Jul 2014 10:07:45 +0200 Subject: [wildfly-dev] HAL - filter for environment properties is gone In-Reply-To: References: Message-ID: Yes, thats certainly regression. I'll look into it. Thanks, Claudio > Am 30.07.2014 um 01:16 schrieb Claudio Miranda : > > Looks like a regression of https://issues.jboss.org/browse/HAL-266 > > On Tue, Jul 29, 2014 at 5:48 PM, Claudio Miranda > wrote: >> HI, I noticed the input text to filter properties in "Runtime - Server >> Status - Environment" is gone from wildfly 8.1 and latest 9 alpha3. >> >> Is there any reason to remove it ? >> >> It was of great help to filter custom properties. >> >> As it is today user must navigate and visually search for the property. > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From hbraun at redhat.com Wed Jul 30 04:10:33 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 30 Jul 2014 10:10:33 +0200 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: References: Message-ID: <794C21ED-96FC-4539-8015-BBC40E34A3CC@redhat.com> I published circuit 0.0.5 last night. But i'll look into the build problem anyway. Regards, heiko > Am 30.07.2014 um 04:27 schrieb Claudio Miranda : > > I needed to download and mvn install the following projects > https://github.com/hal/jgrapht > https://github.com/hal/circuit > > But building hal/core (mvn -Pdev clean install) throws > > [INFO] [ERROR] Errors in > 'jar:file:/home/claudio/.m2/repository/org/jgrapht/jgrapht-core/0.9.1-hal/jgrapht-core-0.9.1-hal-sources.jar!/org/jgrapht/traverse/DepthFirstIterator.java' > [INFO] [ERROR] Line 81: No source code is available for type > java.util.Deque; did you forget to inherit a required module? > [INFO] [ERROR] Line 81: No source code is available for type > java.util.ArrayDeque; did you forget to inherit a required module? > > Any ideas ? > > On Tue, Jul 29, 2014 at 10:11 PM, Claudio Miranda > wrote: >> Hi, have updated hal and run mvn -Pdev clean install, it cannot find >> the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact >> >> repository.jboss.org doesn't contain this artifact. >> >> >> [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT >> [INFO] ------------------------------------------------------------------------ >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> [WARNING] The POM for >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no >> dependency information available >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> >> ... >> >> [ERROR] Failed to execute goal on project console-spi: Could not >> resolve dependencies for project >> org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in >> jboss-public-repository-group >> (https://repository.jboss.org/nexus/content/groups/public/) -> [Help >> 1] >> [ERROR] > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ehugonne at redhat.com Wed Jul 30 04:24:36 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Wed, 30 Jul 2014 10:24:36 +0200 Subject: [wildfly-dev] Upgradting wildfly-core/threads Message-ID: <53D8ABC4.9090608@redhat.com> Hi, I'm upgrading wildfly-core/threads subsystem to 1.2 for WFLY-1878 (https://issues.jboss.org/browse/WFLY-1878). This will impact connectors (jca), ejb3 and batch subsystems. Since ejb3 and jca 3.0 are not released I'm just updating their schemas to use the 1.2 from threads. I propose also to upgrade batch from 1.0 to 1.1. What do you think ? Cheers, Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140730/9bcd2cd6/attachment.bin From hbraun at redhat.com Wed Jul 30 04:26:30 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 30 Jul 2014 10:26:30 +0200 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: References: Message-ID: <8E80A447-6388-4ECF-9632-12C58E98AE90@redhat.com> Do you have the latest master of the jgrapht repo? The Dequeue has been replaced a while ago: https://github.com/hal/jgrapht/commit/8979f64d8b83e99be9f898b57ffb5dbc09e8a199 On 30 Jul 2014, at 04:27, Claudio Miranda wrote: > I needed to download and mvn install the following projects > https://github.com/hal/jgrapht > https://github.com/hal/circuit > > But building hal/core (mvn -Pdev clean install) throws > > [INFO] [ERROR] Errors in > 'jar:file:/home/claudio/.m2/repository/org/jgrapht/jgrapht-core/0.9.1-hal/jgrapht-core-0.9.1-hal-sources.jar!/org/jgrapht/traverse/DepthFirstIterator.java' > [INFO] [ERROR] Line 81: No source code is available for type > java.util.Deque; did you forget to inherit a required module? > [INFO] [ERROR] Line 81: No source code is available for type > java.util.ArrayDeque; did you forget to inherit a required module? > > Any ideas ? > > On Tue, Jul 29, 2014 at 10:11 PM, Claudio Miranda > wrote: >> Hi, have updated hal and run mvn -Pdev clean install, it cannot find >> the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact >> >> repository.jboss.org doesn't contain this artifact. >> >> >> [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT >> [INFO] ------------------------------------------------------------------------ >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> [WARNING] The POM for >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no >> dependency information available >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> >> ... >> >> [ERROR] Failed to execute goal on project console-spi: Could not >> resolve dependencies for project >> org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in >> jboss-public-repository-group >> (https://repository.jboss.org/nexus/content/groups/public/) -> [Help >> 1] >> [ERROR] > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > 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/20140730/4e0e61f1/attachment-0001.html From hbraun at redhat.com Wed Jul 30 04:30:08 2014 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 30 Jul 2014 10:30:08 +0200 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: References: Message-ID: <99AA8204-032E-4AFD-AE2C-D666CB7F7715@redhat.com> It has been released yesterday: https://repository.jboss.org/nexus/index.html#nexus-search;quick~circuit On 30 Jul 2014, at 03:11, Claudio Miranda wrote: > Hi, have updated hal and run mvn -Pdev clean install, it cannot find > the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact > > repository.jboss.org doesn't contain this artifact. > > > [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom > Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom > [WARNING] The POM for > org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no > dependency information available > Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar > Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar > > ... > > [ERROR] Failed to execute goal on project console-spi: Could not > resolve dependencies for project > org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact > org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in > jboss-public-repository-group > (https://repository.jboss.org/nexus/content/groups/public/) -> [Help > 1] > [ERROR] > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > 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/20140730/5a139fc5/attachment.html From tomaz.cerar at gmail.com Wed Jul 30 06:00:04 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 30 Jul 2014 12:00:04 +0200 Subject: [wildfly-dev] Upgradting wildfly-core/threads In-Reply-To: <53D8ABC4.9090608@redhat.com> References: <53D8ABC4.9090608@redhat.com> Message-ID: First of, threads subsystem upgrade should be to 2.0 as this change is part of next major WildFly release. For new, not yet released schemas referencing it, change to use new xsd is not just fine but also required. On Wed, Jul 30, 2014 at 10:24 AM, Emmanuel Hugonnet wrote: > Hi, > I'm upgrading wildfly-core/threads subsystem to 1.2 for WFLY-1878 ( > https://issues.jboss.org/browse/WFLY-1878). > This will impact connectors (jca), ejb3 and batch subsystems. > Since ejb3 and jca 3.0 are not released I'm just updating their schemas to > use the 1.2 from threads. > I propose also to upgrade batch from 1.0 to 1.1. > What do you think ? > Cheers, > Emmanuel > > > _______________________________________________ > 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/20140730/1c695937/attachment.html From hpehl at redhat.com Wed Jul 30 06:23:36 2014 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 30 Jul 2014 12:23:36 +0200 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: <99AA8204-032E-4AFD-AE2C-D666CB7F7715@redhat.com> References: <99AA8204-032E-4AFD-AE2C-D666CB7F7715@redhat.com> Message-ID: I fixed the HAL build for master [1]. There were some dependencies missing. All of them are now available in the JBoss repository. Please let me know if this works for you. [1] https://github.com/hal/core/commit/a8f51e380fb862fd6b5bd5da72435c1716acb2bf .: Harald Am 30.07.2014 um 10:30 schrieb Heiko Braun : > > > It has been released yesterday: > https://repository.jboss.org/nexus/index.html#nexus-search;quick~circuit > > > > On 30 Jul 2014, at 03:11, Claudio Miranda wrote: > >> Hi, have updated hal and run mvn -Pdev clean install, it cannot find >> the org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 artifact >> >> repository.jboss.org doesn't contain this artifact. >> >> >> [INFO] Building HAL Core Console :: SPI 2.4.0-SNAPSHOT >> [INFO] ------------------------------------------------------------------------ >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.pom >> [WARNING] The POM for >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 is missing, no >> dependency information available >> Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> Downloading: http://repo.maven.apache.org/maven2/org/jboss/gwt/circuit/circuit-processor/0.0.5/circuit-processor-0.0.5.jar >> >> ... >> >> [ERROR] Failed to execute goal on project console-spi: Could not >> resolve dependencies for project >> org.jboss.as:console-spi:jar:2.4.0-SNAPSHOT: Could not find artifact >> org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 in >> jboss-public-repository-group >> (https://repository.jboss.org/nexus/content/groups/public/) -> [Help >> 1] >> [ERROR] >> >> >> -- >> Claudio Miranda >> >> claudio at claudius.com.br >> http://www.claudius.com.br >> _______________________________________________ >> 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/20140730/b821a478/attachment.html From claudio at claudius.com.br Wed Jul 30 08:14:21 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 30 Jul 2014 09:14:21 -0300 Subject: [wildfly-dev] error building hal-core, org.jboss.gwt.circuit:circuit-processor:jar:0.0.5 not found In-Reply-To: References: <99AA8204-032E-4AFD-AE2C-D666CB7F7715@redhat.com> Message-ID: On Wed, Jul 30, 2014 at 7:23 AM, Harald Pehl wrote: > I fixed the HAL build for master [1]. There were some dependencies missing. > All of them are now available in the JBoss repository. Please let me know if > this works for you. Thanks, it is working now. -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From darran.lofthouse at jboss.com Wed Jul 30 15:46:47 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 30 Jul 2014 20:46:47 +0100 Subject: [wildfly-dev] TODO Comments Message-ID: <53D94BA7.5040508@jboss.com> Just a random idea. Can we block merging pull requests if they contain a TODO comment that don't reference a Jira issue? The views in GitHub are easy to see if a TODO is involved so quite simple to double check - and if no Jira is justified maybe the TODO isn't either. Regards, Darran Lofthouse. From Anil.Saldhana at redhat.com Wed Jul 30 16:03:23 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Wed, 30 Jul 2014 15:03:23 -0500 Subject: [wildfly-dev] TODO Comments In-Reply-To: <53D94BA7.5040508@jboss.com> References: <53D94BA7.5040508@jboss.com> Message-ID: <53D94F8B.3040601@redhat.com> Darran - very good suggestion. Also, don't merge if there is no javadoc on public methods and classes. :-) On 07/30/2014 02:46 PM, Darran Lofthouse wrote: > Just a random idea. > > Can we block merging pull requests if they contain a TODO comment that > don't reference a Jira issue? > > The views in GitHub are easy to see if a TODO is involved so quite > simple to double check - and if no Jira is justified maybe the TODO > isn't either. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From sebastian.laskawiec at gmail.com Wed Jul 30 16:19:22 2014 From: sebastian.laskawiec at gmail.com (=?UTF-8?Q?Sebastian_=C5=81askawiec?=) Date: Wed, 30 Jul 2014 22:19:22 +0200 Subject: [wildfly-dev] TODO Comments In-Reply-To: <53D94F8B.3040601@redhat.com> References: <53D94BA7.5040508@jboss.com> <53D94F8B.3040601@redhat.com> Message-ID: I'm just thinking out laud - perhaps it would be better to add some rules to checkstyle plugin? This way all commits would have to obey this kind of coding standards. Of course there are some drawbacks... we'd need to fix all violations in existing code base. But this also may be considered as a something good :) Best regards Sebastian 2014-07-30 22:03 GMT+02:00 Anil Saldhana : > Darran - very good suggestion. > > Also, don't merge if there is no javadoc on public methods and classes. :-) > > On 07/30/2014 02:46 PM, Darran Lofthouse wrote: > > Just a random idea. > > > > Can we block merging pull requests if they contain a TODO comment that > > don't reference a Jira issue? > > > > The views in GitHub are easy to see if a TODO is involved so quite > > simple to double check - and if no Jira is justified maybe the TODO > > isn't either. > > > > 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 > -- Sebastian ?askawiec -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140730/3f4b499e/attachment-0001.html From smarlow at redhat.com Wed Jul 30 22:18:09 2014 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 30 Jul 2014 22:18:09 -0400 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... Message-ID: <53D9A761.9000504@redhat.com> We started to see what looks like a JPA extended persistence context related error. [1] is the server.log that shows the exception (see the last one near the bottom) that shouldn't be happening on WildFly master. Also, there are some marshalling errors that I didn't see on brontes (I'm wondering if there is a concurrency error between the bean invocation and passivation/activation when Hibernate throws the "java.lang.IllegalStateException: Cannot serialize a session while connected" error during marshalling as if bean is active). I am able to recreate the failure locally with a modification to the PassivationTestCase.testPassivationMaxSize() [2] to repeatedly alternative between calls to remote1 + remote2 beans. I don't have this nailed down to the actual cause but it seems like a race condition between passivation/activation and bean invocation (imo). Scott [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the results from more than one test run. If you look at the server.log, you probably should go to the end and see the last "javax.ejb.EJBException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used" error [2] unit test change to loop repeatedly until failure occurs https://github.com/scottmarlow/wildfly/tree/passivationxpcissue From claudio at claudius.com.br Wed Jul 30 22:49:03 2014 From: claudio at claudius.com.br (Claudio Miranda) Date: Wed, 30 Jul 2014 23:49:03 -0300 Subject: [wildfly-dev] deployment information Message-ID: Hi, for any jar deployed, deployment shows /deployment=mysql-connector-java-5.1.26-bin.jar:read-resource(include-runtime=true,include-aliases=true,include-defaults=true,recursive=true) { "outcome" => "success", "result" => { "content" => [{"hash" => bytes { 0x22, 0x53, 0xb6, 0xad, 0x12, 0x0d, 0x95, 0x46, 0xe4, 0x84, 0xe3, 0x3b, 0x54, 0x66, 0xb4, 0xdd, 0xa9, 0x02, 0xa8, 0xfd }}], "enabled" => true, "name" => "mysql-connector-java-5.1.26-bin.jar", "persistent" => true, "runtime-name" => "mysql-connector-java-5.1.26-bin.jar", "status" => "OK", "subdeployment" => undefined, "subsystem" => undefined } } I would like to add more information, the timestamp of deployment (probably the timestamp of content file on the filesystem), size and the hash as in data/content directory. Tried to look into wildfly-core projects (host-controller, deployment-scanner, deployment-repository, wildfly-controller), but was unable to find the code that outputs the information to jboss-cli. I know it uses the instruction below, to request deployment information, but what is the project/class invoked for the "deployment" command ? final ModelNode op = Util.getEmptyOperation(READ_CHILDREN_RESOURCES_OPERATION, new ModelNode()); op.get(CHILD_TYPE).set(DEPLOYMENT); ModelNode response; try { response = controllerClient.execute(op); Kind regards -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From ehugonne at redhat.com Thu Jul 31 04:20:31 2014 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 31 Jul 2014 10:20:31 +0200 Subject: [wildfly-dev] deployment information In-Reply-To: References: Message-ID: <53D9FC4F.1080204@redhat.com> Hi, You would have to register new runtime attributes to the DeploymentResourceDefinition that would read the informations from the ContentRepository / file depending on how the jar was deployed and if it is exploded or not. Cheers, Emmanuel Le 31/07/2014 04:49, Claudio Miranda a ?crit : > Hi, for any jar deployed, deployment shows > > > /deployment=mysql-connector-java-5.1.26-bin.jar:read-resource(include-runtime=true,include-aliases=true,include-defaults=true,recursive=true) > { > "outcome" => "success", > "result" => { > "content" => [{"hash" => bytes { > 0x22, 0x53, 0xb6, 0xad, 0x12, 0x0d, 0x95, 0x46, > 0xe4, 0x84, 0xe3, 0x3b, 0x54, 0x66, 0xb4, 0xdd, > 0xa9, 0x02, 0xa8, 0xfd > }}], > "enabled" => true, > "name" => "mysql-connector-java-5.1.26-bin.jar", > "persistent" => true, > "runtime-name" => "mysql-connector-java-5.1.26-bin.jar", > "status" => "OK", > "subdeployment" => undefined, > "subsystem" => undefined > } > } > > I would like to add more information, the timestamp of deployment > (probably the timestamp of content file on the filesystem), size and > the hash as in data/content directory. > > Tried to look into wildfly-core projects (host-controller, > deployment-scanner, deployment-repository, wildfly-controller), but > was unable to find the code that outputs the information to jboss-cli. > > I know it uses the instruction below, to request deployment > information, but what is the project/class invoked for the > "deployment" command ? > > final ModelNode op = > Util.getEmptyOperation(READ_CHILDREN_RESOURCES_OPERATION, new > ModelNode()); > op.get(CHILD_TYPE).set(DEPLOYMENT); > ModelNode response; > try { > response = controllerClient.execute(op); > > > Kind regards > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140731/929f1cdd/attachment.bin From tomaz.cerar at gmail.com Thu Jul 31 05:52:31 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 31 Jul 2014 11:52:31 +0200 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: <53D9A761.9000504@redhat.com> References: <53D9A761.9000504@redhat.com> Message-ID: For time beeing I have muted and assigned this test failure on brontes to you Scott. This way people wont get bogus PR test failures while you are working on a fix. -- tomaz On Thu, Jul 31, 2014 at 4:18 AM, Scott Marlow wrote: > We started to see what looks like a JPA extended persistence context > related error. [1] is the server.log that shows the exception (see the > last one near the bottom) that shouldn't be happening on WildFly master. > Also, there are some marshalling errors that I didn't see on brontes > (I'm wondering if there is a concurrency error between the bean > invocation and passivation/activation when Hibernate throws the > "java.lang.IllegalStateException: Cannot serialize a session while > connected" error during marshalling as if bean is active). > > I am able to recreate the failure locally with a modification to the > PassivationTestCase.testPassivationMaxSize() [2] to repeatedly > alternative between calls to remote1 + remote2 beans. > > I don't have this nailed down to the actual cause but it seems like a > race condition between passivation/activation and bean invocation (imo). > > Scott > > [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the > results from more than one test run. If you look at the server.log, you > probably should go to the end and see the last "javax.ejb.EJBException: > WFLYJPA0030: Found extended persistence context in SFSB invocation call > stack but that cannot be used" error > > [2] unit test change to loop repeatedly until failure occurs > https://github.com/scottmarlow/wildfly/tree/passivationxpcissue > _______________________________________________ > 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/20140731/b805f828/attachment.html From darran.lofthouse at jboss.com Thu Jul 31 07:31:30 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 31 Jul 2014 12:31:30 +0100 Subject: [wildfly-dev] TODO Comments In-Reply-To: References: <53D94BA7.5040508@jboss.com> <53D94F8B.3040601@redhat.com> Message-ID: <53DA2912.2060600@jboss.com> On 30/07/14 21:19, Sebastian ?askawiec wrote: > I'm just thinking out laud - perhaps it would be better to add some > rules to checkstyle plugin? This way all commits would have to obey this > kind of coding standards. > > Of course there are some drawbacks... we'd need to fix all violations in > existing code base. But this also may be considered as a something good :) A quick search and I believe we have over 400 files in WildFly and 400 in WildFly Core containing TODO comments. > Best regards > Sebastian > > > 2014-07-30 22:03 GMT+02:00 Anil Saldhana >: > > Darran - very good suggestion. > > Also, don't merge if there is no javadoc on public methods and > classes. :-) > > On 07/30/2014 02:46 PM, Darran Lofthouse wrote: > > Just a random idea. > > > > Can we block merging pull requests if they contain a TODO comment > that > > don't reference a Jira issue? > > > > The views in GitHub are easy to see if a TODO is involved so quite > > simple to double check - and if no Jira is justified maybe the TODO > > isn't either. > > > > 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 > > > > > -- > Sebastian ?askawiec > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From smarlow at redhat.com Thu Jul 31 11:22:12 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 31 Jul 2014 11:22:12 -0400 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: References: <53D9A761.9000504@redhat.com> Message-ID: <53DA5F24.8020108@redhat.com> Just to keep everyone in the loop, it seems like configuring the passivation max-size to be less than "one + number of nested beans", could be the cause. We are currently configuring the passivation cache max-size to be one, which may lead to passivation of the nested bean. In the PassivationTestCase test, each top level session bean has a nested bean. The top level bean shares the extended persistence context with the nested bean. If users hit this same failure, they should ensure that max-size is at least equal to "1 + number of nested beans referenced from top level bean". We will continue to discuss this case on IRC or email and keep you all posted. Scott On 07/31/2014 05:52 AM, Toma? Cerar wrote: > For time beeing I have muted and assigned this test failure on brontes > to you Scott. > > This way people wont get bogus PR test failures while you are working on > a fix. > > -- > tomaz > > > On Thu, Jul 31, 2014 at 4:18 AM, Scott Marlow > wrote: > > We started to see what looks like a JPA extended persistence context > related error. [1] is the server.log that shows the exception (see the > last one near the bottom) that shouldn't be happening on WildFly master. > Also, there are some marshalling errors that I didn't see on brontes > (I'm wondering if there is a concurrency error between the bean > invocation and passivation/activation when Hibernate throws the > "java.lang.IllegalStateException: Cannot serialize a session while > connected" error during marshalling as if bean is active). > > I am able to recreate the failure locally with a modification to the > PassivationTestCase.testPassivationMaxSize() [2] to repeatedly > alternative between calls to remote1 + remote2 beans. > > I don't have this nailed down to the actual cause but it seems like a > race condition between passivation/activation and bean invocation (imo). > > Scott > > [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the > results from more than one test run. If you look at the server.log, you > probably should go to the end and see the last "javax.ejb.EJBException: > WFLYJPA0030: Found extended persistence context in SFSB invocation call > stack but that cannot be used" error > > [2] unit test change to loop repeatedly until failure occurs > https://github.com/scottmarlow/wildfly/tree/passivationxpcissue > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From smarlow at redhat.com Thu Jul 31 16:06:24 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 31 Jul 2014 16:06:24 -0400 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: <53DA5F24.8020108@redhat.com> References: <53D9A761.9000504@redhat.com> <53DA5F24.8020108@redhat.com> Message-ID: <53DAA1C0.9080802@redhat.com> From talking with Paul about this situation, it sounds like we currently do allow direct passivation of the nested stateful beans, without passivating the top level bean that might reference it. Up to now, I thought that we always passivated the top level stateful bean and all referenced beans, as a group. We actually do passivate the entire group (top level + nested beans), when the top level bean is passivated but we also allow the nested beans to passivated in an isolated fashion. My question at this point is, could we switch to only passivating top level beans? I'm not sure if we know the difference between top-level and nested beans, which might make this difficult or impossible. On 07/31/2014 11:22 AM, Scott Marlow wrote: > Just to keep everyone in the loop, it seems like configuring the > passivation max-size to be less than "one + number of nested beans", > could be the cause. We are currently configuring the passivation cache > max-size to be one, which may lead to passivation of the nested bean. > > In the PassivationTestCase test, each top level session bean has a > nested bean. The top level bean shares the extended persistence context > with the nested bean. > > If users hit this same failure, they should ensure that max-size is at > least equal to "1 + number of nested beans referenced from top level bean". > > We will continue to discuss this case on IRC or email and keep you all > posted. > > Scott > > On 07/31/2014 05:52 AM, Toma? Cerar wrote: >> For time beeing I have muted and assigned this test failure on brontes >> to you Scott. >> >> This way people wont get bogus PR test failures while you are working on >> a fix. >> >> -- >> tomaz >> >> >> On Thu, Jul 31, 2014 at 4:18 AM, Scott Marlow > > wrote: >> >> We started to see what looks like a JPA extended persistence context >> related error. [1] is the server.log that shows the exception (see the >> last one near the bottom) that shouldn't be happening on WildFly master. >> Also, there are some marshalling errors that I didn't see on brontes >> (I'm wondering if there is a concurrency error between the bean >> invocation and passivation/activation when Hibernate throws the >> "java.lang.IllegalStateException: Cannot serialize a session while >> connected" error during marshalling as if bean is active). >> >> I am able to recreate the failure locally with a modification to the >> PassivationTestCase.testPassivationMaxSize() [2] to repeatedly >> alternative between calls to remote1 + remote2 beans. >> >> I don't have this nailed down to the actual cause but it seems like a >> race condition between passivation/activation and bean invocation (imo). >> >> Scott >> >> [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the >> results from more than one test run. If you look at the server.log, you >> probably should go to the end and see the last "javax.ejb.EJBException: >> WFLYJPA0030: Found extended persistence context in SFSB invocation call >> stack but that cannot be used" error >> >> [2] unit test change to loop repeatedly until failure occurs >> https://github.com/scottmarlow/wildfly/tree/passivationxpcissue >> _______________________________________________ >> 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 paul.ferraro at redhat.com Thu Jul 31 17:02:08 2014 From: paul.ferraro at redhat.com (Paul Ferraro) Date: Thu, 31 Jul 2014 17:02:08 -0400 (EDT) Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: <53DAA1C0.9080802@redhat.com> References: <53D9A761.9000504@redhat.com> <53DA5F24.8020108@redhat.com> <53DAA1C0.9080802@redhat.com> Message-ID: <2140080491.227800.1406840528252.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Scott Marlow" > To: wildfly-dev at lists.jboss.org > Sent: Thursday, July 31, 2014 4:06:24 PM > Subject: Re: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has > passivation max-size=1 and repeated called to two separate beans... > > From talking with Paul about this situation, it sounds like we > currently do allow direct passivation of the nested stateful beans, > without passivating the top level bean that might reference it. Sorry if I wasn't clear, but that's not the case. All nested beans are always passivated together - they have to be to preserve references to the same objects (e.g. the XPC). > Up to now, I thought that we always passivated the top level stateful > bean and all referenced beans, as a group. We actually do passivate the > entire group (top level + nested beans), when the top level bean is > passivated but we also allow the nested beans to passivated in an > isolated fashion. That's not quite true either. A bean forever belongs to the group into which it was 1st created. So, even if a nested bean is invoked directly (rather than via the parent bean) - it would still passivate as a group along with its other associated beans. > My question at this point is, could we switch to only passivating top > level beans? I'm not sure if we know the difference between top-level > and nested beans, which might make this difficult or impossible. The issue, I think, is when passivation of the group is triggered within the context of the invocation that uses the bean. The reason this is happening in this test is because the passivation threshold is lower than the depth of your nested beans. When did this test start failing? I suspect it might be related to this commit: https://github.com/wildfly/wildfly/commit/555b8a42249527674448b880b95b334bbdc6ef23 If so, I should have a fix for this shortly. Let's also keep in mind that this isn't really a real-world scenario, as nobody in their right mind would ever set their max-size of the SFSB cache to be so small. So, this is more about getting the test to pass than to fix a functional issue. > On 07/31/2014 11:22 AM, Scott Marlow wrote: > > Just to keep everyone in the loop, it seems like configuring the > > passivation max-size to be less than "one + number of nested beans", > > could be the cause. We are currently configuring the passivation cache > > max-size to be one, which may lead to passivation of the nested bean. > > > > In the PassivationTestCase test, each top level session bean has a > > nested bean. The top level bean shares the extended persistence context > > with the nested bean. > > > > If users hit this same failure, they should ensure that max-size is at > > least equal to "1 + number of nested beans referenced from top level bean". > > > > We will continue to discuss this case on IRC or email and keep you all > > posted. > > > > Scott > > > > On 07/31/2014 05:52 AM, Toma? Cerar wrote: > >> For time beeing I have muted and assigned this test failure on brontes > >> to you Scott. > >> > >> This way people wont get bogus PR test failures while you are working on > >> a fix. > >> > >> -- > >> tomaz > >> > >> > >> On Thu, Jul 31, 2014 at 4:18 AM, Scott Marlow >> > wrote: > >> > >> We started to see what looks like a JPA extended persistence context > >> related error. [1] is the server.log that shows the exception (see > >> the > >> last one near the bottom) that shouldn't be happening on WildFly > >> master. > >> Also, there are some marshalling errors that I didn't see on > >> brontes > >> (I'm wondering if there is a concurrency error between the bean > >> invocation and passivation/activation when Hibernate throws the > >> "java.lang.IllegalStateException: Cannot serialize a session while > >> connected" error during marshalling as if bean is active). > >> > >> I am able to recreate the failure locally with a modification to the > >> PassivationTestCase.testPassivationMaxSize() [2] to repeatedly > >> alternative between calls to remote1 + remote2 beans. > >> > >> I don't have this nailed down to the actual cause but it seems like a > >> race condition between passivation/activation and bean invocation > >> (imo). > >> > >> Scott > >> > >> [1] https://www.dropbox.com/s/277pwvxv53dp8vk/server.zip contains the > >> results from more than one test run. If you look at the server.log, > >> you > >> probably should go to the end and see the last > >> "javax.ejb.EJBException: > >> WFLYJPA0030: Found extended persistence context in SFSB invocation > >> call > >> stack but that cannot be used" error > >> > >> [2] unit test change to loop repeatedly until failure occurs > >> https://github.com/scottmarlow/wildfly/tree/passivationxpcissue > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Thu Jul 31 19:13:16 2014 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 31 Jul 2014 19:13:16 -0400 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: <2140080491.227800.1406840528252.JavaMail.zimbra@redhat.com> References: <53D9A761.9000504@redhat.com> <53DA5F24.8020108@redhat.com> <53DAA1C0.9080802@redhat.com> <2140080491.227800.1406840528252.JavaMail.zimbra@redhat.com> Message-ID: <53DACD8C.3050109@redhat.com> On 07/31/2014 05:02 PM, Paul Ferraro wrote: > When did this test start failing? I suspect it might be related to this commit: > https://github.com/wildfly/wildfly/commit/555b8a42249527674448b880b95b334bbdc6ef23 > If so, I should have a fix for this shortly. The first failure on brontes was at 07/30/2014 02:03 AM (Brno time?). It looks like the above commit was merged around 07/29/2014 11:18 PM (EST timezone). It could be the above commit, I'm not sure. I tried running the same test against 4a765b5d7dee4d28950805c113b0e623fdb017b2 ( WFLY-3486 Make default session timeout configurable in the Undertow subsystem) but got a "Unable to acquire lock after [15 seconds] on key [5f1c2614-2ed8-4b70-951e-f30c9699c8d8] for requestor [GlobalTransaction::105:local]! Lock held by [GlobalTransaction::106:local] " error and other exceptions as well. Not sure why. > > Let's also keep in mind that this isn't really a real-world scenario, as nobody in their right mind would ever set their max-size of the SFSB cache to be so small. > > So, this is more about getting the test to pass than to fix a functional issue. From brian.stansberry at redhat.com Thu Jul 31 19:40:20 2014 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 31 Jul 2014 18:40:20 -0500 Subject: [wildfly-dev] We started seeing test failure in PassivationTestCase.testPassivationMaxSize() which has passivation max-size=1 and repeated called to two separate beans... In-Reply-To: <53DACD8C.3050109@redhat.com> References: <53D9A761.9000504@redhat.com> <53DA5F24.8020108@redhat.com> <53DAA1C0.9080802@redhat.com> <2140080491.227800.1406840528252.JavaMail.zimbra@redhat.com> <53DACD8C.3050109@redhat.com> Message-ID: <53DAD3E4.8090503@redhat.com> On 7/31/14, 6:13 PM, Scott Marlow wrote: > On 07/31/2014 05:02 PM, Paul Ferraro wrote: >> When did this test start failing? I suspect it might be related to this commit: >> https://github.com/wildfly/wildfly/commit/555b8a42249527674448b880b95b334bbdc6ef23 >> If so, I should have a fix for this shortly. > > The first failure on brontes was at 07/30/2014 02:03 AM (Brno time?). > It looks like the above commit was merged around 07/29/2014 11:18 PM > (EST timezone). > > It could be the above commit, I'm not sure. > For any test run, click on the "Changes" link and you can often see a lot of the recent history of the branch. In this 2:03 AM run, the commit in question is at the top: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=18974&buildTypeId=WF_8xIgnoreLinux&tab=buildChangesDiv Seems I shouldn't have merged it. Some story about a boy shepherd and a wolf comes to mind... > I tried running the same test against > 4a765b5d7dee4d28950805c113b0e623fdb017b2 ( WFLY-3486 Make default > session timeout configurable in the Undertow subsystem) but got a > "Unable to acquire lock after [15 seconds] on key > [5f1c2614-2ed8-4b70-951e-f30c9699c8d8] for requestor > [GlobalTransaction::105:local]! Lock held by > [GlobalTransaction::106:local] > " error and other exceptions as well. Not sure why. > >> >> Let's also keep in mind that this isn't really a real-world scenario, as nobody in their right mind would ever set their max-size of the SFSB cache to be so small. >> >> So, this is more about getting the test to pass than to fix a functional issue. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat