From jason.greene at redhat.com Thu Mar 1 02:51:21 2018 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 1 Mar 2018 01:51:21 -0600 Subject: [wildfly-dev] 12.0.0.CR1 released! In-Reply-To: <98bef8dd-9e9d-67a2-2ebb-edb793706710@gmail.com> References: <8E8FB3D2-54E2-4B96-A48E-70FCC090DAF7@redhat.com> <98bef8dd-9e9d-67a2-2ebb-edb793706710@gmail.com> Message-ID: <62DBAFEF-610F-40F7-9E2B-82BA4890ECB0@redhat.com> Hi Jaikiran, Thanks for the feedback! In our new release model, we are trying to be as close to timeboxed as we can, so the only thing that holds back a Final is a blocker level issue. Since the issues you reference occur in specific circumstances and have workarounds, they did not appear to meet that level of severity. Unfortunately this means that some issues like this will miss the train, but luckily the wait with our timeboxed model isn?t too long, and if something heavily affects the community in a way that really can?t wait we could always do an interim release. Thanks, -Jason > On Feb 28, 2018, at 10:52 PM, Jaikiran Pai wrote: > > Hi Jason, > > The past few weeks, there have been multiple reports in the forums and in the JIRA related to remote EJB invocations (especially over HTTP) that seems to be failing due to some of the bugs in our remote EJB libraries. From what I see, most of them should be resolved in 12.0.0.CR1 that's released. However, I think there's at least one or two issues (still being discussed in the forums and JIRA[1] [2]) which I suspect are bugs in either WildFly itself or one of our libraries. > > Related to those, I believe, the fix in this PR https://github.com/wildfly/wildfly/pull/10929 which is currently open, is an important one in context of 12.0 Final release. I haven't had the chance to check if this PR would solve the rest of the issues, but at least from the looks of it, it's an important fix in itself. > > I think we should include that fix in 12.0.0.Final. > > [1] https://issues.jboss.org/browse/WFLY-9896 > > [2] https://developer.jboss.org/message/980718#980718 > > -Jaikiran > > On 27/02/18 9:02 AM, Jason Greene wrote: >> Hi Everyone, >> >> In preparation for WildFly 12 Final, CR1 is now available for build testing: >> http://wildfly.org/downloads/ >> >> Provided no blocking issues are discovered we will be releasing Final shortly. >> >> WildFly 12 is the first release in our new quarterly delivery model. The most significant feature is delivery of new EE8 capabilities. As mentioned during the original 12 announcement, we are delivering EE8 functionality incrementally, as opposed to waiting for a big bang. WildFly 12 includes Servlet 4, JAX-RS 2.1, CDI 2.0, Bean Validation 2.0, JSF 2.3, JSON-B, JSON-P 1.1, and Javamail 1.6. >> >> By default WildFly 12 runs in EE7 mode, but you can enable EE8 variants of the standard by starting the server with the special parameter ?-Dee8.preview.mode=true?. >> >> Thanks! >> >> -Jason >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jai.forums2013 at gmail.com Thu Mar 1 07:03:22 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 1 Mar 2018 17:33:22 +0530 Subject: [wildfly-dev] 12.0.0.CR1 released! In-Reply-To: <62DBAFEF-610F-40F7-9E2B-82BA4890ECB0@redhat.com> References: <8E8FB3D2-54E2-4B96-A48E-70FCC090DAF7@redhat.com> <98bef8dd-9e9d-67a2-2ebb-edb793706710@gmail.com> <62DBAFEF-610F-40F7-9E2B-82BA4890ECB0@redhat.com> Message-ID: Fair enough! Congratulations on the 12.0.0.Final release :) -Jaikiran On 01/03/18 1:21 PM, Jason Greene wrote: > Hi Jaikiran, > > Thanks for the feedback! In our new release model, we are trying to be as close to timeboxed as we can, so the only thing that holds back a Final is a blocker level issue. Since the issues you reference occur in specific circumstances and have workarounds, they did not appear to meet that level of severity. Unfortunately this means that some issues like this will miss the train, but luckily the wait with our timeboxed model isn?t too long, and if something heavily affects the community in a way that really can?t wait we could always do an interim release. > > Thanks, > > -Jason > >> On Feb 28, 2018, at 10:52 PM, Jaikiran Pai wrote: >> >> Hi Jason, >> >> The past few weeks, there have been multiple reports in the forums and in the JIRA related to remote EJB invocations (especially over HTTP) that seems to be failing due to some of the bugs in our remote EJB libraries. From what I see, most of them should be resolved in 12.0.0.CR1 that's released. However, I think there's at least one or two issues (still being discussed in the forums and JIRA[1] [2]) which I suspect are bugs in either WildFly itself or one of our libraries. >> >> Related to those, I believe, the fix in this PR https://github.com/wildfly/wildfly/pull/10929 which is currently open, is an important one in context of 12.0 Final release. I haven't had the chance to check if this PR would solve the rest of the issues, but at least from the looks of it, it's an important fix in itself. >> >> I think we should include that fix in 12.0.0.Final. >> >> [1] https://issues.jboss.org/browse/WFLY-9896 >> >> [2] https://developer.jboss.org/message/980718#980718 >> >> -Jaikiran >> >> On 27/02/18 9:02 AM, Jason Greene wrote: >>> Hi Everyone, >>> >>> In preparation for WildFly 12 Final, CR1 is now available for build testing: >>> http://wildfly.org/downloads/ >>> >>> Provided no blocking issues are discovered we will be releasing Final shortly. >>> >>> WildFly 12 is the first release in our new quarterly delivery model. The most significant feature is delivery of new EE8 capabilities. As mentioned during the original 12 announcement, we are delivering EE8 functionality incrementally, as opposed to waiting for a big bang. WildFly 12 includes Servlet 4, JAX-RS 2.1, CDI 2.0, Bean Validation 2.0, JSF 2.3, JSON-B, JSON-P 1.1, and Javamail 1.6. >>> >>> By default WildFly 12 runs in EE7 mode, but you can enable EE8 variants of the standard by starting the server with the special parameter ?-Dee8.preview.mode=true?. >>> >>> Thanks! >>> >>> -Jason >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev From hpehl at redhat.com Fri Mar 2 04:29:44 2018 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 2 Mar 2018 10:29:44 +0100 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 Message-ID: The development of HAL.next [1] has reached a point where we can replace the existing console with HAL.next. We'd like to make this transition for WildFly 13. HAL.next ships with everything which is available in the current console. In addition there are plenty new and enhanced features. I'm currently preparing a website which will include basic user documentation and a list of new and enhanced features. Although we believe the new console is stable enough, we could add an additional endpoint in WildFly 13 for the old console. This would enable users to switch back and forth between the new and old console. What do you think? .: Harald [1] https://github.com/hal/hal.next From rory.odonnell at oracle.com Fri Mar 2 05:58:50 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 2 Mar 2018 10:58:50 +0000 Subject: [wildfly-dev] JDK 10: Release Candidate & JDK 11 Early Access builds available Message-ID: <679a2cb6-2af7-3494-477d-9d7324510ed0@oracle.com> Hi Jason/Tomaz, *JDK 10 build 45 is our JDK 10 Release Candidate and now available at http://jdk.java.net/10/* * Schedule, status & features o http://openjdk.java.net/projects/jdk/10/ * Release Notes o http://jdk.java.net/10/release-notes * Summary of changes in b45: o JDK-8198658 - Docs still point to JDK 9 docs *JDK 11 EA build 3, under both the GPL and Oracle EA licenses, are now available at **http://jdk.java.net/11**.* * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/2/jdk-11+2.html * JEPs targeted to JDK 11, so far o 309: Dynamic Class-File Constants o 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector o *320: **Remove the Java EE and CORBA Modules * ** + ** *This build includes JEP 320, so build is significantly smaller (nine fewer modules, 22 fewer megabyteson Linux/x64).* o 323: Local-Variable Syntax for Lambda Parameters * Open Source Project fixes in JDK 11 build 1 o JDK-8195096 - Apache Tomcat + Exception with custom LogManager on starting Apache Tomcat o JDK-8193802 - Apache Maven + NullPointerException from JarFileSystem.getVersionMap() o JDK-8191842 - jOOQ + JShell: Inferred type information is lost when assigning types to a "var" Finally, the Crypto roadmap was updated - 23-Feb-2018** ** * Add support for AEAD TLS Cipher Suites o Target date changed from 2018-04-17 to 2018-07-17 Regards, 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/20180302/2eb15114/attachment-0001.html From tomaz.cerar at gmail.com Fri Mar 2 18:21:51 2018 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Sat, 3 Mar 2018 00:21:51 +0100 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: <5a99dc8c.88d31c0a.66954.51dd@mx.google.com> > Although we believe the new console is stable enough, we could add an > additional endpoint in WildFly 13 for the old console. This would enable > users to switch back and forth between the new and old console. How much extra fat would that bring to the server distribution? -- tomaz From: Harald Pehl Sent: petek, 02. marec 2018 10:30 To: WildFly Dev Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 The development of HAL.next [1] has reached a point where we can replace the existing console with HAL.next. We'd like to make this transition for WildFly 13. HAL.next ships with everything which is available in the current console. In addition there are plenty new and enhanced features. I'm currently preparing a website which will include basic user documentation and a list of new and enhanced features. Although we believe the new console is stable enough, we could add an additional endpoint in WildFly 13 for the old console. This would enable users to switch back and forth between the new and old console. What do you think? .: Harald [1] https://github.com/hal/hal.next _______________________________________________ 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/20180303/e79596ee/attachment.html From hpehl at redhat.com Sat Mar 3 01:52:00 2018 From: hpehl at redhat.com (Harald Pehl) Date: Sat, 3 Mar 2018 07:52:00 +0100 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: <5a99dc8c.88d31c0a.66954.51dd@mx.google.com> References: <5a99dc8c.88d31c0a.66954.51dd@mx.google.com> Message-ID: <0DB56B66-B20E-4C82-BDE2-1505491CF493@redhat.com> > On 3. Mar 2018, at 00:21, Toma? Cerar wrote: > > How much extra fat would that bring to the server distribution? The current console is about 10 MB, HAL.next is something around 7 MB. So if we replace the console we would save 3 MB, if we keep both that would add 7 MB. // Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180303/e59bd558/attachment.html From jason.greene at redhat.com Sat Mar 3 03:20:09 2018 From: jason.greene at redhat.com (Jason Greene) Date: Sat, 3 Mar 2018 00:20:09 -0800 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: <0DB56B66-B20E-4C82-BDE2-1505491CF493@redhat.com> References: <5a99dc8c.88d31c0a.66954.51dd@mx.google.com> <0DB56B66-B20E-4C82-BDE2-1505491CF493@redhat.com> Message-ID: This is great news. As long as they are functionally equivalent and you feel the new one is stable, I don?t think we have to worry about keeping the old console. Since we have a CLI and API I doubt people are scripting web ui clients. Web UIs in general are expected to change / evolve over time. On Mar 3, 2018, at 6:52 AM, Harald Pehl wrote: On 3. Mar 2018, at 00:21, Toma? Cerar wrote: How much extra fat would that bring to the server distribution? The current console is about 10 MB, HAL.next is something around 7 MB. So if we replace the console we would save 3 MB, if we keep both that would add 7 MB. // Harald _______________________________________________ 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/20180303/f5d9ed1f/attachment.html From mchoma at redhat.com Mon Mar 5 03:44:14 2018 From: mchoma at redhat.com (Martin Choma) Date: Mon, 5 Mar 2018 09:44:14 +0100 Subject: [wildfly-dev] Wildfly multi domains with one certificate In-Reply-To: References: Message-ID: Hi, wildfly forum [1] is probably more suitable for this kind of questions. I think that should be fine with WildFly. Still I would recommend try it with some testing certificate before buying production one. Martin [1] https://developer.jboss.org/en/wildfly On Mon, Feb 19, 2018 at 3:25 AM, Noah Wu wrote: > Suppose I have a few websites with different domain names, domainA.com, > domainB.jp, etc. > > I have setup the correct virtual hosts configuration for these sites in > wildfly 11. > > And I am planning on buying mutlti domain SSL certificate from GoDaddy. > > A Multi-domain SSL Certificate can secure your main domain + several SAN ( > Subject Alternative Name) domain names in one Certificate. > > My question is that can wildfly recognize this kind of multi domain SSL > certificate. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jai.forums2013 at gmail.com Wed Mar 7 00:10:21 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 7 Mar 2018 10:40:21 +0530 Subject: [wildfly-dev] WildFly Java 9 support & CI job Message-ID: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> It appears that the recent release of WildFly 12.0.0.Final has a major issue with Java 9 support for deployments. More specifically, if the application being deployed is compiled using Java 9 JDK then the annotation processing (through Jandex) causes such classes to skip the annotation indexing, effectively missing any annotation information present on them. There's a JIRA for it here[1] and I /think/ another user here in the forum thread[2] is affected by the same issue. I see that Stuart is already upgrading Jandex which includes a fix, so this mail isn't really about fixing this issue. Given the ease with which this got reproduced and the fact that we missed it in our regular integration job for Java 9 [3], I looked around to see why we couldn't catch this earlier. It looks like the WildFly pom.xml uses org.jboss:jboss-parent:25 [4] which fixes the target class version of the compilation to 1.8. As a result, even though the CI job uses Java 9 to compile the application sources (in test cases) it ends up with a class version to Java 8 and that explains why these issues weren't caught earlier. So would it be possible to have another variant of this CI job which passes Java 9 as the target version for compiled sources, as a system property value (the pom.xml of jboss-parent allows the value to be configured through properties)? [1] https://issues.jboss.org/browse/WFLY-9961 [2] https://developer.jboss.org/thread/277401 [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branch_WF=__all_branches__ [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180307/034f27e8/attachment-0001.html From tomaz.cerar at gmail.com Wed Mar 7 04:35:12 2018 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Wed, 7 Mar 2018 10:35:12 +0100 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> Message-ID: <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Hey Jaikiran, yes there are known issues with Jandex and also with few proposed fixes but we didn?t manage to get them merged and/or released. When it comes to -source / -target 9 compiling there is a reason why we do not use it. Yet! When one switches to compile for -target 9, whole behavior of compiler changes as result we can no longer access non public classes or modules. Unless we add module-info.java for problematic maven modules. But adding module-info.java means all (maven) compile dependencies of said maven module need to be jigsaw compatible, which at this point is not really there yet. Currently we have to problematic modules that cause issues with this. ?cli? in wildfly-core, and ?security? in wildfly repository. Both of them have quite big dependency tree where many of its jars are not jigsaw compatible. I do have working branch that has quite some work done on this subject, but until we get dependencies fixed to not violate jigsaw rules, it cannot be completed. Here is non complete list of Jira issues that track jigsaw problems in our dependencies that prevent cli and security to be compiled with target = 9 https://issues.jboss.org/browse/SECURITY-986 https://issues.jboss.org/browse/SECURITY-985 https://issues.jboss.org/browse/ISPN-8844 https://issues.jboss.org/browse/AESH-458 https://issues.jboss.org/browse/AESH-457 So in short our support of JDK9/10 is currently scoped only to using it as runtime JDK of the server. None of the jigsaw related features will work in deployments. Said all that, jandex problem is real, we will fix it. -- tomaz From: Jaikiran Pai Sent: sreda, 07. marec 2018 06:11 To: wildfly-dev at lists.jboss.org Subject: [wildfly-dev] WildFly Java 9 support & CI job It appears that the recent release of WildFly 12.0.0.Final has a major issue with Java 9 support for deployments. More specifically, if the application being deployed is compiled using Java 9 JDK then the annotation processing (through Jandex) causes such classes to skip the annotation indexing, effectively missing any annotation information present on them. There's a JIRA for it here[1] and I think another user here in the forum thread[2] is affected by the same issue. I see that Stuart is already upgrading Jandex which includes a fix, so this mail isn't really about fixing this issue. Given the ease with which this got reproduced and the fact that we missed it in our regular integration job for Java 9 [3], I looked around to see why we couldn't catch this earlier. It looks like the WildFly pom.xml uses org.jboss:jboss-parent:25 [4] which fixes the target class version of the compilation to 1.8. As a result, even though the CI job uses Java 9 to compile the application sources (in test cases) it ends up with a class version to Java 8 and that explains why these issues weren't caught earlier. So would it be possible to have another variant of this CI job which passes Java 9 as the target version for compiled sources, as a system property value (the pom.xml of jboss-parent allows the value to be configured through properties)? [1] https://issues.jboss.org/browse/WFLY-9961 [2] https://developer.jboss.org/thread/277401 [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branch_WF=__all_branches__ [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180307/b5c3c7e2/attachment.html From jai.forums2013 at gmail.com Wed Mar 7 06:55:19 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 7 Mar 2018 17:25:19 +0530 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: <5a9fb24e.01da1c0a.97901.e866@mx.google.com> References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: Hi Tomaz, Thank you for the detailed explanation. I wasn't aware that it's this much more involved with switching to -target 9. I certainly need to catch up with these more frequent Java releases soon :) -Jaikiran On 07/03/18 3:05 PM, Toma? Cerar wrote: > Hey Jaikiran, > > yes there are known issues with Jandex and also with few proposed > fixes but we didn?t manage to get them merged and/or released. > > When it comes to -source / -target 9 compiling there is a reason why > we do not use it. Yet! > When one switches to compile for -target 9, whole behavior of compiler > changes as result we can no longer access non public classes or modules. > Unless we add module-info.java for problematic maven modules. > But adding module-info.java means all (maven) compile dependencies of > said maven module need to be jigsaw compatible, which at this point is > not really there yet. > > Currently we have to problematic modules that cause issues with this. > ?cli? in wildfly-core, and ?security? in wildfly repository. > > Both of them have quite big dependency tree where many of its jars are > not jigsaw compatible. > > I do have working branch that has quite some work done on this > subject, but until we get dependencies fixed to not violate jigsaw > rules, it cannot be completed. > > Here is non complete list of Jira issues that track jigsaw problems in > our dependencies that prevent cli and security to be compiled with > target = 9 > https://issues.jboss.org/browse/SECURITY-986 > https://issues.jboss.org/browse/SECURITY-985 > https://issues.jboss.org/browse/ISPN-8844 > https://issues.jboss.org/browse/AESH-458 > https://issues.jboss.org/browse/AESH-457 > > So in short our support of JDK9/10 is currently scoped only to using > it as runtime JDK of the server. None of the jigsaw related features > will work in deployments. > Said all that, jandex problem is real, we will fix it. > > -- > tomaz > > *From: *Jaikiran Pai > *Sent: *sreda, 07. marec 2018 06:11 > *To: *wildfly-dev at lists.jboss.org > *Subject: *[wildfly-dev] WildFly Java 9 support & CI job > > It appears that the recent release of WildFly 12.0.0.Final has a major > issue with Java 9 support for deployments. More specifically, if the > application being deployed is compiled using Java 9 JDK then the > annotation processing (through Jandex) causes such classes to skip the > annotation indexing, effectively missing any annotation information > present on them. There's a JIRA for it here[1] and I /think/ another > user here in the forum thread[2] is affected by the same issue. I see > that Stuart is already upgrading Jandex which includes a fix, so this > mail isn't really about fixing this issue. > Given the ease with which this got reproduced and the fact that we > missed it in our regular integration job for Java 9 [3], I looked > around to see why we couldn't catch this earlier. It looks like the > WildFly pom.xml uses org.jboss:jboss-parent:25 [4] which fixes the > target class version of the compilation to 1.8. As a result, even > though the CI job uses Java 9 to compile the application sources (in > test cases) it ends up with a class version to Java 8 and that > explains why these issues weren't caught earlier. > So would it be possible to have another variant of this CI job which > passes Java 9 as the target version for compiled sources, as a system > property value (the pom.xml of jboss-parent allows the value to be > configured through properties)? > [1] https://issues.jboss.org/browse/WFLY-9961 > [2] https://developer.jboss.org/thread/277401 > [3] > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branch_WF=__all_branches__ > [4] > http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom > -Jaikiran -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180307/ff924c4f/attachment-0001.html From jdenise at redhat.com Wed Mar 7 08:09:31 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Wed, 7 Mar 2018 14:09:31 +0100 Subject: [wildfly-dev] Authentication commands for CLI Message-ID: Hi, after having introduced SSL commands in CLI in WF12, we plan to add authentication related commands. Here is a proposal[1] (that is the result of discussions between Farah Juma, Martin Choma and myself). Feedbacks welcome. Thank-you. JF [1] https://github.com/wildfly/wildfly-proposals/pull/32 From stuart.w.douglas at gmail.com Thu Mar 8 18:13:49 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 9 Mar 2018 10:13:49 +1100 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: <5a9fb24e.01da1c0a.97901.e866@mx.google.com> References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: Could we look at making one or all of the test suite modules compile using -target 9 ? This was the server is still built the same way, but it should pick up issues like this in testing. Stuart On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar wrote: > Hey Jaikiran, > > > > yes there are known issues with Jandex and also with few proposed fixes > but we didn?t manage to get them merged and/or released. > > > > When it comes to -source / -target 9 compiling there is a reason why we do > not use it. Yet! > > When one switches to compile for -target 9, whole behavior of compiler > changes as result we can no longer access non public classes or modules. > > Unless we add module-info.java for problematic maven modules. > > But adding module-info.java means all (maven) compile dependencies of said > maven module need to be jigsaw compatible, which at this point is not > really there yet. > > > > Currently we have to problematic modules that cause issues with this. > > ?cli? in wildfly-core, and ?security? in wildfly repository. > > > > Both of them have quite big dependency tree where many of its jars are not > jigsaw compatible. > > > > I do have working branch that has quite some work done on this subject, > but until we get dependencies fixed to not violate jigsaw rules, it cannot > be completed. > > > > Here is non complete list of Jira issues that track jigsaw problems in our > dependencies that prevent cli and security to be compiled with target = 9 > > https://issues.jboss.org/browse/SECURITY-986 > > https://issues.jboss.org/browse/SECURITY-985 > > https://issues.jboss.org/browse/ISPN-8844 > > https://issues.jboss.org/browse/AESH-458 > > https://issues.jboss.org/browse/AESH-457 > > > > So in short our support of JDK9/10 is currently scoped only to using it as > runtime JDK of the server. None of the jigsaw related features will work in > deployments. > > Said all that, jandex problem is real, we will fix it. > > > > -- > > tomaz > > > > > > *From: *Jaikiran Pai > *Sent: *sreda, 07. marec 2018 06:11 > *To: *wildfly-dev at lists.jboss.org > *Subject: *[wildfly-dev] WildFly Java 9 support & CI job > > > > It appears that the recent release of WildFly 12.0.0.Final has a major > issue with Java 9 support for deployments. More specifically, if the > application being deployed is compiled using Java 9 JDK then the annotation > processing (through Jandex) causes such classes to skip the annotation > indexing, effectively missing any annotation information present on them. > There's a JIRA for it here[1] and I *think* another user here in the > forum thread[2] is affected by the same issue. I see that Stuart is already > upgrading Jandex which includes a fix, so this mail isn't really about > fixing this issue. > > Given the ease with which this got reproduced and the fact that we missed > it in our regular integration job for Java 9 [3], I looked around to see > why we couldn't catch this earlier. It looks like the WildFly pom.xml uses > org.jboss:jboss-parent:25 [4] which fixes the target class version of the > compilation to 1.8. As a result, even though the CI job uses Java 9 to > compile the application sources (in test cases) it ends up with a class > version to Java 8 and that explains why these issues weren't caught earlier. > > So would it be possible to have another variant of this CI job which > passes Java 9 as the target version for compiled sources, as a system > property value (the pom.xml of jboss-parent allows the value to be > configured through properties)? > > [1] https://issues.jboss.org/browse/WFLY-9961 > > [2] https://developer.jboss.org/thread/277401 > > [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_ > MasterLinuxJdk9&branch_WF=__all_branches__ > > [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/ > jboss-parent-25.pom > > -Jaikiran > > > > _______________________________________________ > 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/20180309/9c2bc813/attachment.html From tomaz.cerar at gmail.com Thu Mar 8 18:46:03 2018 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 08 Mar 2018 23:46:03 +0000 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: I can take a look at it. As long as we don't use any non public app in tests suite, it should work. But this still wouldn't catch issues like this, as we wouldn't not have deployments with module-info.class present. But it would certainly have its benefits. -- Toma? On Fri, 9 Mar 2018 at 00:13, Stuart Douglas wrote: > Could we look at making one or all of the test suite modules compile using -target > 9 ? This was the server is still built the same way, but it should pick up > issues like this in testing. > > Stuart > On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar wrote: > >> Hey Jaikiran, >> >> >> >> yes there are known issues with Jandex and also with few proposed fixes >> but we didn?t manage to get them merged and/or released. >> >> >> >> When it comes to -source / -target 9 compiling there is a reason why we >> do not use it. Yet! >> >> When one switches to compile for -target 9, whole behavior of compiler >> changes as result we can no longer access non public classes or modules. >> >> Unless we add module-info.java for problematic maven modules. >> >> But adding module-info.java means all (maven) compile dependencies of >> said maven module need to be jigsaw compatible, which at this point is not >> really there yet. >> >> >> >> Currently we have to problematic modules that cause issues with this. >> >> ?cli? in wildfly-core, and ?security? in wildfly repository. >> >> >> >> Both of them have quite big dependency tree where many of its jars are >> not jigsaw compatible. >> >> >> >> I do have working branch that has quite some work done on this subject, >> but until we get dependencies fixed to not violate jigsaw rules, it cannot >> be completed. >> >> >> >> Here is non complete list of Jira issues that track jigsaw problems in >> our dependencies that prevent cli and security to be compiled with target = >> 9 >> >> https://issues.jboss.org/browse/SECURITY-986 >> >> https://issues.jboss.org/browse/SECURITY-985 >> >> https://issues.jboss.org/browse/ISPN-8844 >> >> https://issues.jboss.org/browse/AESH-458 >> >> https://issues.jboss.org/browse/AESH-457 >> >> >> >> So in short our support of JDK9/10 is currently scoped only to using it >> as runtime JDK of the server. None of the jigsaw related features will work >> in deployments. >> >> Said all that, jandex problem is real, we will fix it. >> >> >> >> -- >> >> tomaz >> >> >> >> >> >> *From: *Jaikiran Pai >> *Sent: *sreda, 07. marec 2018 06:11 >> *To: *wildfly-dev at lists.jboss.org >> *Subject: *[wildfly-dev] WildFly Java 9 support & CI job >> >> >> >> It appears that the recent release of WildFly 12.0.0.Final has a major >> issue with Java 9 support for deployments. More specifically, if the >> application being deployed is compiled using Java 9 JDK then the annotation >> processing (through Jandex) causes such classes to skip the annotation >> indexing, effectively missing any annotation information present on them. >> There's a JIRA for it here[1] and I *think* another user here in the >> forum thread[2] is affected by the same issue. I see that Stuart is already >> upgrading Jandex which includes a fix, so this mail isn't really about >> fixing this issue. >> >> Given the ease with which this got reproduced and the fact that we missed >> it in our regular integration job for Java 9 [3], I looked around to see >> why we couldn't catch this earlier. It looks like the WildFly pom.xml uses >> org.jboss:jboss-parent:25 [4] which fixes the target class version of the >> compilation to 1.8. As a result, even though the CI job uses Java 9 to >> compile the application sources (in test cases) it ends up with a class >> version to Java 8 and that explains why these issues weren't caught earlier. >> >> So would it be possible to have another variant of this CI job which >> passes Java 9 as the target version for compiled sources, as a system >> property value (the pom.xml of jboss-parent allows the value to be >> configured through properties)? >> >> [1] https://issues.jboss.org/browse/WFLY-9961 >> >> [2] https://developer.jboss.org/thread/277401 >> >> [3] >> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branch_WF=__all_branches__ >> >> [4] >> http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom >> >> -Jaikiran >> >> >> >> _______________________________________________ >> 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/20180308/ce1b25b7/attachment-0001.html From rsvoboda at redhat.com Fri Mar 9 03:10:55 2018 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Fri, 9 Mar 2018 03:10:55 -0500 (EST) Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: <2063396773.6286848.1520583055258.JavaMail.zimbra@redhat.com> +1 for some coverage on this. I think running Quickstarts with -target 9 is good option too. I'm looking into preparing matrix job to run it in our Jenkins. Probably daily job for latest wf master + qs master. and we need https://github.com/wildfly/wildfly-core/pull/3157 before we move on Rostislav ----- Original Message ----- > I can take a look at it. > As long as we don't use any non public app in tests suite, it should work. > > But this still wouldn't catch issues like this, as we wouldn't not have > deployments with module-info.class present. > > But it would certainly have its benefits. > > -- > Toma? > > On Fri, 9 Mar 2018 at 00:13, Stuart Douglas < stuart.w.douglas at gmail.com > > wrote: > > > > Could we look at making one or all of the test suite modules compile using > -target 9 ? This was the server is still built the same way, but it should > pick up issues like this in testing. > > Stuart > On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar < tomaz.cerar at gmail.com > wrote: > > > > > > Hey Jaikiran, > > > > yes there are known issues with Jandex and also with few proposed fixes but > we didn?t manage to get them merged and/or released. > > > > When it comes to -source / -target 9 compiling there is a reason why we do > not use it. Yet! > > When one switches to compile for -target 9, whole behavior of compiler > changes as result we can no longer access non public classes or modules. > > Unless we add module-info.java for problematic maven modules. > > But adding module-info.java means all (maven) compile dependencies of said > maven module need to be jigsaw compatible, which at this point is not really > there yet. > > > > Currently we have to problematic modules that cause issues with this. > > ?cli? in wildfly-core, and ?security? in wildfly repository. > > > > Both of them have quite big dependency tree where many of its jars are not > jigsaw compatible. > > > > I do have working branch that has quite some work done on this subject, but > until we get dependencies fixed to not violate jigsaw rules, it cannot be > completed. > > > > Here is non complete list of Jira issues that track jigsaw problems in our > dependencies that prevent cli and security to be compiled with target = 9 > > https://issues.jboss.org/browse/SECURITY-986 > > https://issues.jboss.org/browse/SECURITY-985 > > https://issues.jboss.org/browse/ISPN-8844 > > https://issues.jboss.org/browse/AESH-458 > > https://issues.jboss.org/browse/AESH-457 > > > > So in short our support of JDK9/10 is currently scoped only to using it as > runtime JDK of the server. None of the jigsaw related features will work in > deployments. > > Said all that, jandex problem is real, we will fix it. > > > > -- > > tomaz > > > > > > > From: Jaikiran Pai > Sent: sreda, 07. marec 2018 06:11 > To: wildfly-dev at lists.jboss.org > Subject: [wildfly-dev] WildFly Java 9 support & CI job > > > > > It appears that the recent release of WildFly 12.0.0.Final has a major issue > with Java 9 support for deployments. More specifically, if the application > being deployed is compiled using Java 9 JDK then the annotation processing > (through Jandex) causes such classes to skip the annotation indexing, > effectively missing any annotation information present on them. There's a > JIRA for it here[1] and I think another user here in the forum thread[2] is > affected by the same issue. I see that Stuart is already upgrading Jandex > which includes a fix, so this mail isn't really about fixing this issue. > > Given the ease with which this got reproduced and the fact that we missed it > in our regular integration job for Java 9 [3], I looked around to see why we > couldn't catch this earlier. It looks like the WildFly pom.xml uses > org.jboss:jboss-parent:25 [4] which fixes the target class version of the > compilation to 1.8. As a result, even though the CI job uses Java 9 to > compile the application sources (in test cases) it ends up with a class > version to Java 8 and that explains why these issues weren't caught earlier. > > So would it be possible to have another variant of this CI job which passes > Java 9 as the target version for compiled sources, as a system property > value (the pom.xml of jboss-parent allows the value to be configured through > properties)? > > [1] https://issues.jboss.org/browse/WFLY-9961 > > [2] https://developer.jboss.org/thread/277401 > > [3] > https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9&branch_WF=__all_branches__ > > [4] > http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jboss-parent-25.pom > > -Jaikiran > > > > > > _______________________________________________ > 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 Sun Mar 11 17:37:04 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 12 Mar 2018 08:37:04 +1100 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: On Fri, Mar 9, 2018 at 10:46 AM, Toma? Cerar wrote: > I can take a look at it. > As long as we don't use any non public app in tests suite, it should work. > > But this still wouldn't catch issues like this, as we wouldn't not have > deployments with module-info.class present. > This issue is not about module-info.class, the issue is that all JDK9 classes have their annotations ignored, which would be caught. Stuart > > But it would certainly have its benefits. > > -- > Toma? > > On Fri, 9 Mar 2018 at 00:13, Stuart Douglas > wrote: > >> Could we look at making one or all of the test suite modules compile >> using -target 9 ? This was the server is still built the same way, but >> it should pick up issues like this in testing. >> >> Stuart >> On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar >> wrote: >> >>> Hey Jaikiran, >>> >>> >>> >>> yes there are known issues with Jandex and also with few proposed fixes >>> but we didn?t manage to get them merged and/or released. >>> >>> >>> >>> When it comes to -source / -target 9 compiling there is a reason why we >>> do not use it. Yet! >>> >>> When one switches to compile for -target 9, whole behavior of compiler >>> changes as result we can no longer access non public classes or modules. >>> >>> Unless we add module-info.java for problematic maven modules. >>> >>> But adding module-info.java means all (maven) compile dependencies of >>> said maven module need to be jigsaw compatible, which at this point is not >>> really there yet. >>> >>> >>> >>> Currently we have to problematic modules that cause issues with this. >>> >>> ?cli? in wildfly-core, and ?security? in wildfly repository. >>> >>> >>> >>> Both of them have quite big dependency tree where many of its jars are >>> not jigsaw compatible. >>> >>> >>> >>> I do have working branch that has quite some work done on this subject, >>> but until we get dependencies fixed to not violate jigsaw rules, it cannot >>> be completed. >>> >>> >>> >>> Here is non complete list of Jira issues that track jigsaw problems in >>> our dependencies that prevent cli and security to be compiled with target = >>> 9 >>> >>> https://issues.jboss.org/browse/SECURITY-986 >>> >>> https://issues.jboss.org/browse/SECURITY-985 >>> >>> https://issues.jboss.org/browse/ISPN-8844 >>> >>> https://issues.jboss.org/browse/AESH-458 >>> >>> https://issues.jboss.org/browse/AESH-457 >>> >>> >>> >>> So in short our support of JDK9/10 is currently scoped only to using it >>> as runtime JDK of the server. None of the jigsaw related features will work >>> in deployments. >>> >>> Said all that, jandex problem is real, we will fix it. >>> >>> >>> >>> -- >>> >>> tomaz >>> >>> >>> >>> >>> >>> *From: *Jaikiran Pai >>> *Sent: *sreda, 07. marec 2018 06:11 >>> *To: *wildfly-dev at lists.jboss.org >>> *Subject: *[wildfly-dev] WildFly Java 9 support & CI job >>> >>> >>> >>> It appears that the recent release of WildFly 12.0.0.Final has a major >>> issue with Java 9 support for deployments. More specifically, if the >>> application being deployed is compiled using Java 9 JDK then the annotation >>> processing (through Jandex) causes such classes to skip the annotation >>> indexing, effectively missing any annotation information present on them. >>> There's a JIRA for it here[1] and I *think* another user here in the >>> forum thread[2] is affected by the same issue. I see that Stuart is already >>> upgrading Jandex which includes a fix, so this mail isn't really about >>> fixing this issue. >>> >>> Given the ease with which this got reproduced and the fact that we >>> missed it in our regular integration job for Java 9 [3], I looked around to >>> see why we couldn't catch this earlier. It looks like the WildFly pom.xml >>> uses org.jboss:jboss-parent:25 [4] which fixes the target class version of >>> the compilation to 1.8. As a result, even though the CI job uses Java 9 to >>> compile the application sources (in test cases) it ends up with a class >>> version to Java 8 and that explains why these issues weren't caught earlier. >>> >>> So would it be possible to have another variant of this CI job which >>> passes Java 9 as the target version for compiled sources, as a system >>> property value (the pom.xml of jboss-parent allows the value to be >>> configured through properties)? >>> >>> [1] https://issues.jboss.org/browse/WFLY-9961 >>> >>> [2] https://developer.jboss.org/thread/277401 >>> >>> [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_ >>> MasterLinuxJdk9&branch_WF=__all_branches__ >>> >>> [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/ >>> jboss-parent-25.pom >>> >>> -Jaikiran >>> >>> >>> >>> _______________________________________________ >>> 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/20180312/aa200dc6/attachment.html From tomaz.cerar at gmail.com Mon Mar 12 09:09:23 2018 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 12 Mar 2018 14:09:23 +0100 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: Hey, I got it working locally, it needed only 2 testsuite classes changes to not use sun.* internal api. Change is part of my JDK10/11 PR https://github.com/wildfly/wildfly/pull/10982 To enable it, just run on JDK9/10/11 and pass -Djdk-release=9/10/11 which will compile testsuite classes to selected release. I've added it as optionally enabled profile as when you use it, pretty much everything fails ATM. This way we can only have it on CI for time being. -- tomaz On Sun, Mar 11, 2018 at 10:37 PM, Stuart Douglas wrote: > > > On Fri, Mar 9, 2018 at 10:46 AM, Toma? Cerar > wrote: > >> I can take a look at it. >> As long as we don't use any non public app in tests suite, it should work. >> >> But this still wouldn't catch issues like this, as we wouldn't not have >> deployments with module-info.class present. >> > > This issue is not about module-info.class, the issue is that all JDK9 > classes have their annotations ignored, which would be caught. > > Stuart > > >> >> But it would certainly have its benefits. >> >> -- >> Toma? >> >> On Fri, 9 Mar 2018 at 00:13, Stuart Douglas >> wrote: >> >>> Could we look at making one or all of the test suite modules compile >>> using -target 9 ? This was the server is still built the same way, but >>> it should pick up issues like this in testing. >>> >>> Stuart >>> On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar >>> wrote: >>> >>>> Hey Jaikiran, >>>> >>>> >>>> >>>> yes there are known issues with Jandex and also with few proposed fixes >>>> but we didn?t manage to get them merged and/or released. >>>> >>>> >>>> >>>> When it comes to -source / -target 9 compiling there is a reason why we >>>> do not use it. Yet! >>>> >>>> When one switches to compile for -target 9, whole behavior of compiler >>>> changes as result we can no longer access non public classes or modules. >>>> >>>> Unless we add module-info.java for problematic maven modules. >>>> >>>> But adding module-info.java means all (maven) compile dependencies of >>>> said maven module need to be jigsaw compatible, which at this point is not >>>> really there yet. >>>> >>>> >>>> >>>> Currently we have to problematic modules that cause issues with this. >>>> >>>> ?cli? in wildfly-core, and ?security? in wildfly repository. >>>> >>>> >>>> >>>> Both of them have quite big dependency tree where many of its jars are >>>> not jigsaw compatible. >>>> >>>> >>>> >>>> I do have working branch that has quite some work done on this subject, >>>> but until we get dependencies fixed to not violate jigsaw rules, it cannot >>>> be completed. >>>> >>>> >>>> >>>> Here is non complete list of Jira issues that track jigsaw problems in >>>> our dependencies that prevent cli and security to be compiled with target = >>>> 9 >>>> >>>> https://issues.jboss.org/browse/SECURITY-986 >>>> >>>> https://issues.jboss.org/browse/SECURITY-985 >>>> >>>> https://issues.jboss.org/browse/ISPN-8844 >>>> >>>> https://issues.jboss.org/browse/AESH-458 >>>> >>>> https://issues.jboss.org/browse/AESH-457 >>>> >>>> >>>> >>>> So in short our support of JDK9/10 is currently scoped only to using it >>>> as runtime JDK of the server. None of the jigsaw related features will work >>>> in deployments. >>>> >>>> Said all that, jandex problem is real, we will fix it. >>>> >>>> >>>> >>>> -- >>>> >>>> tomaz >>>> >>>> >>>> >>>> >>>> >>>> *From: *Jaikiran Pai >>>> *Sent: *sreda, 07. marec 2018 06:11 >>>> *To: *wildfly-dev at lists.jboss.org >>>> *Subject: *[wildfly-dev] WildFly Java 9 support & CI job >>>> >>>> >>>> >>>> It appears that the recent release of WildFly 12.0.0.Final has a major >>>> issue with Java 9 support for deployments. More specifically, if the >>>> application being deployed is compiled using Java 9 JDK then the annotation >>>> processing (through Jandex) causes such classes to skip the annotation >>>> indexing, effectively missing any annotation information present on them. >>>> There's a JIRA for it here[1] and I *think* another user here in the >>>> forum thread[2] is affected by the same issue. I see that Stuart is already >>>> upgrading Jandex which includes a fix, so this mail isn't really about >>>> fixing this issue. >>>> >>>> Given the ease with which this got reproduced and the fact that we >>>> missed it in our regular integration job for Java 9 [3], I looked around to >>>> see why we couldn't catch this earlier. It looks like the WildFly pom.xml >>>> uses org.jboss:jboss-parent:25 [4] which fixes the target class version of >>>> the compilation to 1.8. As a result, even though the CI job uses Java 9 to >>>> compile the application sources (in test cases) it ends up with a class >>>> version to Java 8 and that explains why these issues weren't caught earlier. >>>> >>>> So would it be possible to have another variant of this CI job which >>>> passes Java 9 as the target version for compiled sources, as a system >>>> property value (the pom.xml of jboss-parent allows the value to be >>>> configured through properties)? >>>> >>>> [1] https://issues.jboss.org/browse/WFLY-9961 >>>> >>>> [2] https://developer.jboss.org/thread/277401 >>>> >>>> [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLi >>>> nuxJdk9&branch_WF=__all_branches__ >>>> >>>> [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jbos >>>> s-parent-25.pom >>>> >>>> -Jaikiran >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20180312/ec13227c/attachment-0001.html From tomaz.cerar at gmail.com Tue Mar 13 10:46:11 2018 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 13 Mar 2018 15:46:11 +0100 Subject: [wildfly-dev] WildFly Java 9 support & CI job In-Reply-To: References: <90bf13ad-8d62-8701-458b-3abfc42df6cc@gmail.com> <5a9fb24e.01da1c0a.97901.e866@mx.google.com> Message-ID: Just an update, JDK10 job on CI https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk10 is now running with -Djdk-release=10 which will compile testsuite with release=10 and should show up problems like this. -- tomaz On Mon, Mar 12, 2018 at 2:09 PM, Toma? Cerar wrote: > Hey, > > I got it working locally, it needed only 2 testsuite classes changes to > not use sun.* internal api. > > Change is part of my JDK10/11 PR https://github.com/wildfly/ > wildfly/pull/10982 > > To enable it, just run on JDK9/10/11 and pass -Djdk-release=9/10/11 > which will compile testsuite classes to selected release. > > I've added it as optionally enabled profile as when you use it, pretty > much everything fails ATM. > This way we can only have it on CI for time being. > > -- > tomaz > > > On Sun, Mar 11, 2018 at 10:37 PM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> >> >> On Fri, Mar 9, 2018 at 10:46 AM, Toma? Cerar >> wrote: >> >>> I can take a look at it. >>> As long as we don't use any non public app in tests suite, it should >>> work. >>> >>> But this still wouldn't catch issues like this, as we wouldn't not have >>> deployments with module-info.class present. >>> >> >> This issue is not about module-info.class, the issue is that all JDK9 >> classes have their annotations ignored, which would be caught. >> >> Stuart >> >> >>> >>> But it would certainly have its benefits. >>> >>> -- >>> Toma? >>> >>> On Fri, 9 Mar 2018 at 00:13, Stuart Douglas >>> wrote: >>> >>>> Could we look at making one or all of the test suite modules compile >>>> using -target 9 ? This was the server is still built the same way, but >>>> it should pick up issues like this in testing. >>>> >>>> Stuart >>>> On Wed, Mar 7, 2018 at 8:35 PM, Toma? Cerar >>>> wrote: >>>> >>>>> Hey Jaikiran, >>>>> >>>>> >>>>> >>>>> yes there are known issues with Jandex and also with few proposed >>>>> fixes but we didn?t manage to get them merged and/or released. >>>>> >>>>> >>>>> >>>>> When it comes to -source / -target 9 compiling there is a reason why >>>>> we do not use it. Yet! >>>>> >>>>> When one switches to compile for -target 9, whole behavior of compiler >>>>> changes as result we can no longer access non public classes or modules. >>>>> >>>>> Unless we add module-info.java for problematic maven modules. >>>>> >>>>> But adding module-info.java means all (maven) compile dependencies of >>>>> said maven module need to be jigsaw compatible, which at this point is not >>>>> really there yet. >>>>> >>>>> >>>>> >>>>> Currently we have to problematic modules that cause issues with this. >>>>> >>>>> ?cli? in wildfly-core, and ?security? in wildfly repository. >>>>> >>>>> >>>>> >>>>> Both of them have quite big dependency tree where many of its jars are >>>>> not jigsaw compatible. >>>>> >>>>> >>>>> >>>>> I do have working branch that has quite some work done on this >>>>> subject, but until we get dependencies fixed to not violate jigsaw rules, >>>>> it cannot be completed. >>>>> >>>>> >>>>> >>>>> Here is non complete list of Jira issues that track jigsaw problems in >>>>> our dependencies that prevent cli and security to be compiled with target = >>>>> 9 >>>>> >>>>> https://issues.jboss.org/browse/SECURITY-986 >>>>> >>>>> https://issues.jboss.org/browse/SECURITY-985 >>>>> >>>>> https://issues.jboss.org/browse/ISPN-8844 >>>>> >>>>> https://issues.jboss.org/browse/AESH-458 >>>>> >>>>> https://issues.jboss.org/browse/AESH-457 >>>>> >>>>> >>>>> >>>>> So in short our support of JDK9/10 is currently scoped only to using >>>>> it as runtime JDK of the server. None of the jigsaw related features will >>>>> work in deployments. >>>>> >>>>> Said all that, jandex problem is real, we will fix it. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> tomaz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *Jaikiran Pai >>>>> *Sent: *sreda, 07. marec 2018 06:11 >>>>> *To: *wildfly-dev at lists.jboss.org >>>>> *Subject: *[wildfly-dev] WildFly Java 9 support & CI job >>>>> >>>>> >>>>> >>>>> It appears that the recent release of WildFly 12.0.0.Final has a major >>>>> issue with Java 9 support for deployments. More specifically, if the >>>>> application being deployed is compiled using Java 9 JDK then the annotation >>>>> processing (through Jandex) causes such classes to skip the annotation >>>>> indexing, effectively missing any annotation information present on them. >>>>> There's a JIRA for it here[1] and I *think* another user here in the >>>>> forum thread[2] is affected by the same issue. I see that Stuart is already >>>>> upgrading Jandex which includes a fix, so this mail isn't really about >>>>> fixing this issue. >>>>> >>>>> Given the ease with which this got reproduced and the fact that we >>>>> missed it in our regular integration job for Java 9 [3], I looked around to >>>>> see why we couldn't catch this earlier. It looks like the WildFly pom.xml >>>>> uses org.jboss:jboss-parent:25 [4] which fixes the target class version of >>>>> the compilation to 1.8. As a result, even though the CI job uses Java 9 to >>>>> compile the application sources (in test cases) it ends up with a class >>>>> version to Java 8 and that explains why these issues weren't caught earlier. >>>>> >>>>> So would it be possible to have another variant of this CI job which >>>>> passes Java 9 as the target version for compiled sources, as a system >>>>> property value (the pom.xml of jboss-parent allows the value to be >>>>> configured through properties)? >>>>> >>>>> [1] https://issues.jboss.org/browse/WFLY-9961 >>>>> >>>>> [2] https://developer.jboss.org/thread/277401 >>>>> >>>>> [3] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLi >>>>> nuxJdk9&branch_WF=__all_branches__ >>>>> >>>>> [4] http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/jbos >>>>> s-parent-25.pom >>>>> >>>>> -Jaikiran >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20180313/4ef4de9a/attachment.html From rory.odonnell at oracle.com Wed Mar 21 07:09:32 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 21 Mar 2018 11:09:32 +0000 Subject: [wildfly-dev] Release Announcement: General Availability of JDK 10 Message-ID: Hi Jason/Tomaz, A number of items to share with you today : *1) JDK 10 General Availability * JDK 10, the first release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. We've identified no P1 bugs since we promoted build 46 almost two weeks ago, so that is the official GA release, ready for production use. GPL'd binaries from Oracle are available here: http://jdk.java.net/10 This release includes twelve features: * 286: Local-Variable Type Inference * 296: Consolidate the JDK Forest into a Single Repository * 304: Garbage-Collector Interface * 307: Parallel Full GC for G1 * 310: Application Class-Data Sharing * 312: Thread-Local Handshakes * 313: Remove the Native-Header Generation Tool (javah) * 314: Additional Unicode Language-Tag Extensions * 316: Heap Allocation on Alternative Memory Devices * 317: Experimental Java-Based JIT Compiler * 319: Root Certificates * 322: Time-Based Release Versioning *2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are now available at **http://jdk.java.net/11**.* * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html *3) The Z Garbage Collector Project, early access builds available : * The first EA binary from from The Z Garbage Collector Project, also known as ZGC, is now available. ZGC is a scalable low latency garbage collector. For information on how to enable and use ZGC, please see the project wiki. * Project page: http://openjdk.java.net/projects/zgc/ * Wiki: https://wiki.openjdk.java.net/display/zgc/Main *4) Quality Outreach Report for **March 2018 **is available * * https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2018 *5) **Java Client Roadmap Update * * We posted a blog [3] and related white paper [4] detailing our plans for the Java Client. Rgds,Rory [1] https://mreinhold.org/blog/forward-faster [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3] Blog: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates [4] Whitepaper: http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf -- 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/20180321/5b29d311/attachment-0001.html From alexey.loubyansky at redhat.com Fri Mar 23 11:55:11 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 23 Mar 2018 16:55:11 +0100 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model Message-ID: While this is addressed mainly to the Elytron team, it seems like we would appreciate opinions from other colleagues since we are basically stuck discussing possible ways to resolve https://issues.jboss.org/browse/WFCORE-3596 The description in the jira is pretty brief assuming people know what that is about, since it's been raised before multiple times. Here is what it is about fundamentally. If a configuration model (of a subsystem or any other component) includes a list of configurable units (let's assume XML elements for simplicity) that don't have any identity (unique id/name/path/etc) this is a big problem for supporting patching and version updates preserving user configuration changes. Or simply customizing the default config model using a tool. By a big problem I mean it's simply not going to work reliably. As a simple exercise that demonstrates the issue, imagine you have two configs each of which includes a list of these configurable units that have no identity. Now try to identify the difference between the two lists. Or merge them with one overwriting the other. Basically components w/o an identity can not be manipulated. You can only add them but not modify or even remove (unless their index in the list is a constant value of course). I don't think I've seen any issue of this kind in our (WF/EAP) configs except for the Elytron's permission-mapping's. (If somebody knows such components please let me know). If I misunderstand the Elytron config model or approaching this from a wrong angle, please let me know. Question for the Elytron team: is the problem I am describing clear? Do you admit it as a problem? Thanks, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/1fd66f86/attachment.html From darran.lofthouse at jboss.com Fri Mar 23 12:15:49 2018 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 23 Mar 2018 16:15:49 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: I think at the moment it is fair to say the issue manipulating the default configuration is understood and agreed, a very minor change from an administrator can prevent further automated modifications and the modifications that are made need to duplicated as the current default configuration. We do have a proposal to move the default permissions into a new resource permission-set which will be referenced by the mapper, this will be a resource that is addressable by name. As subsystems are added to the server this will be the single place to add the permissions, as subsystems are removed this will be the single resource to remove the permission from. If an administrator has chosen to use their own permission mappings instead of this permission set then they will not be affected by any automated updates. The change we have proposed will also be compatible with previous versions using transformers as we can just in-line these permission sets in the transformed model. We have been at this stage a couple of times but although we have an option to provide a single named resource that can be manipulated by patching this does not seem to be sufficient - I think that is where the sticking point is in achieving a solution for this. Regards, Darran Lofthouse. On Fri, 23 Mar 2018 at 15:55 Alexey Loubyansky wrote: > While this is addressed mainly to the Elytron team, it seems like we would > appreciate opinions from other colleagues since we are basically stuck > discussing possible ways to resolve > https://issues.jboss.org/browse/WFCORE-3596 > > The description in the jira is pretty brief assuming people know what that > is about, since it's been raised before multiple times. Here is what it is > about fundamentally. > > If a configuration model (of a subsystem or any other component) includes > a list of configurable units (let's assume XML elements for simplicity) > that don't have any identity (unique id/name/path/etc) this is a big > problem for supporting patching and version updates preserving user > configuration changes. Or simply customizing the default config model using > a tool. By a big problem I mean it's simply not going to work reliably. > > As a simple exercise that demonstrates the issue, imagine you have two > configs each of which includes a list of these configurable units that have > no identity. Now try to identify the difference between the two lists. Or > merge them with one overwriting the other. Basically components w/o an > identity can not be manipulated. You can only add them but not modify or > even remove (unless their index in the list is a constant value of course). > > I don't think I've seen any issue of this kind in our (WF/EAP) configs > except for the Elytron's permission-mapping's. (If somebody knows such > components please let me know). > If I misunderstand the Elytron config model or approaching this from a > wrong angle, please let me know. > > Question for the Elytron team: is the problem I am describing clear? Do > you admit it as a problem? > > Thanks, > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/a91f78cf/attachment.html From fjuma at redhat.com Fri Mar 23 13:20:58 2018 From: fjuma at redhat.com (Farah Juma) Date: Fri, 23 Mar 2018 13:20:58 -0400 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: A solution to part of the problem mentioned in WFCORE-3596 that was discussed is to introduce the concept of named permission sets. In particular, instead of having a permission-mapping reference permissions, it would instead reference named permission-sets. This would allow the provisioning tool to be able to add/remove permissions to/from a default permission-set based on the presence/absence of a specific subsystem when generating the default configuration. However, as Alexey pointed out, this doesn't solve the problem of knowing which permission-mapping a permission-set should be added to when attempting to preserve user configuration changes for patching, version updates, etc. Thanks, Farah On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < alexey.loubyansky at redhat.com> wrote: > While this is addressed mainly to the Elytron team, it seems like we would > appreciate opinions from other colleagues since we are basically stuck > discussing possible ways to resolve https://issues.jboss.org/ > browse/WFCORE-3596 > > The description in the jira is pretty brief assuming people know what that > is about, since it's been raised before multiple times. Here is what it is > about fundamentally. > > If a configuration model (of a subsystem or any other component) includes > a list of configurable units (let's assume XML elements for simplicity) > that don't have any identity (unique id/name/path/etc) this is a big > problem for supporting patching and version updates preserving user > configuration changes. Or simply customizing the default config model using > a tool. By a big problem I mean it's simply not going to work reliably. > > As a simple exercise that demonstrates the issue, imagine you have two > configs each of which includes a list of these configurable units that have > no identity. Now try to identify the difference between the two lists. Or > merge them with one overwriting the other. Basically components w/o an > identity can not be manipulated. You can only add them but not modify or > even remove (unless their index in the list is a constant value of course). > > I don't think I've seen any issue of this kind in our (WF/EAP) configs > except for the Elytron's permission-mapping's. (If somebody knows such > components please let me know). > If I misunderstand the Elytron config model or approaching this from a > wrong angle, please let me know. > > Question for the Elytron team: is the problem I am describing clear? Do > you admit it as a problem? > > Thanks, > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/357d96a7/attachment.html From darran.lofthouse at jboss.com Fri Mar 23 13:28:00 2018 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 23 Mar 2018 17:28:00 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: Why would the permission-mapping resource need to be modified by tooling? The purpose of the named permission-set is that that becomes the resource automatically manipulated, the permission mappings should not need to be manipulated as they either will or will not already reference the permission-set and that should be automatically changed. Regards, Darran Lofthouse. On Fri, 23 Mar 2018 at 17:21 Farah Juma wrote: > A solution to part of the problem mentioned in WFCORE-3596 that was > discussed is to introduce the concept of named permission sets. In > particular, instead of having a permission-mapping reference permissions, > it would instead reference named permission-sets. This would allow the > provisioning tool to be able to add/remove permissions to/from a default > permission-set based on the presence/absence of a specific subsystem when > generating the default configuration. However, as Alexey pointed out, this > doesn't solve the problem of knowing which permission-mapping a > permission-set should be added to when attempting to preserve user > configuration changes for patching, version updates, etc. > > Thanks, > Farah > > On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> While this is addressed mainly to the Elytron team, it seems like we >> would appreciate opinions from other colleagues since we are basically >> stuck discussing possible ways to resolve >> https://issues.jboss.org/browse/WFCORE-3596 >> >> The description in the jira is pretty brief assuming people know what >> that is about, since it's been raised before multiple times. Here is what >> it is about fundamentally. >> >> If a configuration model (of a subsystem or any other component) includes >> a list of configurable units (let's assume XML elements for simplicity) >> that don't have any identity (unique id/name/path/etc) this is a big >> problem for supporting patching and version updates preserving user >> configuration changes. Or simply customizing the default config model using >> a tool. By a big problem I mean it's simply not going to work reliably. >> >> As a simple exercise that demonstrates the issue, imagine you have two >> configs each of which includes a list of these configurable units that have >> no identity. Now try to identify the difference between the two lists. Or >> merge them with one overwriting the other. Basically components w/o an >> identity can not be manipulated. You can only add them but not modify or >> even remove (unless their index in the list is a constant value of course). >> >> I don't think I've seen any issue of this kind in our (WF/EAP) configs >> except for the Elytron's permission-mapping's. (If somebody knows such >> components please let me know). >> If I misunderstand the Elytron config model or approaching this from a >> wrong angle, please let me know. >> >> Question for the Elytron team: is the problem I am describing clear? Do >> you admit it as a problem? >> >> Thanks, >> Alexey >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/5ee2f289/attachment-0001.html From alexey.loubyansky at redhat.com Fri Mar 23 13:49:46 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 23 Mar 2018 18:49:46 +0100 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: > A solution to part of the problem mentioned in WFCORE-3596 that was > discussed is to introduce the concept of named permission sets. In > particular, instead of having a permission-mapping reference permissions, > it would instead reference named permission-sets. This would allow the > provisioning tool to be able to add/remove permissions to/from a default > permission-set based on the presence/absence of a specific subsystem when > generating the default configuration. However, as Alexey pointed out, this > doesn't solve the problem of knowing which permission-mapping a > permission-set should be added to when attempting to preserve user > configuration changes for patching, version updates, etc. > Right. It does not change the permission-mappings, they remain to be a list of items with no identity. Which is the fundamental problem. Thanks, Alexey Thanks, > Farah > > On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> While this is addressed mainly to the Elytron team, it seems like we >> would appreciate opinions from other colleagues since we are basically >> stuck discussing possible ways to resolve https://issues.jboss.org/brows >> e/WFCORE-3596 >> >> The description in the jira is pretty brief assuming people know what >> that is about, since it's been raised before multiple times. Here is what >> it is about fundamentally. >> >> If a configuration model (of a subsystem or any other component) includes >> a list of configurable units (let's assume XML elements for simplicity) >> that don't have any identity (unique id/name/path/etc) this is a big >> problem for supporting patching and version updates preserving user >> configuration changes. Or simply customizing the default config model using >> a tool. By a big problem I mean it's simply not going to work reliably. >> >> As a simple exercise that demonstrates the issue, imagine you have two >> configs each of which includes a list of these configurable units that have >> no identity. Now try to identify the difference between the two lists. Or >> merge them with one overwriting the other. Basically components w/o an >> identity can not be manipulated. You can only add them but not modify or >> even remove (unless their index in the list is a constant value of course). >> >> I don't think I've seen any issue of this kind in our (WF/EAP) configs >> except for the Elytron's permission-mapping's. (If somebody knows such >> components please let me know). >> If I misunderstand the Elytron config model or approaching this from a >> wrong angle, please let me know. >> >> Question for the Elytron team: is the problem I am describing clear? Do >> you admit it as a problem? >> >> Thanks, >> Alexey >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/22563fd8/attachment.html From alexey.loubyansky at redhat.com Fri Mar 23 13:55:30 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 23 Mar 2018 18:55:30 +0100 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: BTW, I want to highlight an important point here. I don't care about how it will look like in the XML. It may remain this list in the XML. What I care about is how it appears in the domain management model and its description. Thanks, Alexey On Fri, Mar 23, 2018 at 6:49 PM, Alexey Loubyansky < alexey.loubyansky at redhat.com> wrote: > On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: > >> A solution to part of the problem mentioned in WFCORE-3596 that was >> discussed is to introduce the concept of named permission sets. In >> particular, instead of having a permission-mapping reference permissions, >> it would instead reference named permission-sets. This would allow the >> provisioning tool to be able to add/remove permissions to/from a default >> permission-set based on the presence/absence of a specific subsystem when >> generating the default configuration. However, as Alexey pointed out, this >> doesn't solve the problem of knowing which permission-mapping a >> permission-set should be added to when attempting to preserve user >> configuration changes for patching, version updates, etc. >> > > Right. It does not change the permission-mappings, they remain to be a > list of items with no identity. Which is the fundamental problem. > > Thanks, > Alexey > > Thanks, >> Farah >> >> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> While this is addressed mainly to the Elytron team, it seems like we >>> would appreciate opinions from other colleagues since we are basically >>> stuck discussing possible ways to resolve https://issues.jboss.org/brows >>> e/WFCORE-3596 >>> >>> The description in the jira is pretty brief assuming people know what >>> that is about, since it's been raised before multiple times. Here is what >>> it is about fundamentally. >>> >>> If a configuration model (of a subsystem or any other component) >>> includes a list of configurable units (let's assume XML elements for >>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>> a big problem for supporting patching and version updates preserving user >>> configuration changes. Or simply customizing the default config model using >>> a tool. By a big problem I mean it's simply not going to work reliably. >>> >>> As a simple exercise that demonstrates the issue, imagine you have two >>> configs each of which includes a list of these configurable units that have >>> no identity. Now try to identify the difference between the two lists. Or >>> merge them with one overwriting the other. Basically components w/o an >>> identity can not be manipulated. You can only add them but not modify or >>> even remove (unless their index in the list is a constant value of course). >>> >>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>> except for the Elytron's permission-mapping's. (If somebody knows such >>> components please let me know). >>> If I misunderstand the Elytron config model or approaching this from a >>> wrong angle, please let me know. >>> >>> Question for the Elytron team: is the problem I am describing clear? Do >>> you admit it as a problem? >>> >>> Thanks, >>> Alexey >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/11ca7887/attachment.html From darran.lofthouse at jboss.com Fri Mar 23 13:56:33 2018 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 23 Mar 2018 17:56:33 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky wrote: > On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: > >> A solution to part of the problem mentioned in WFCORE-3596 that was >> discussed is to introduce the concept of named permission sets. In >> particular, instead of having a permission-mapping reference permissions, >> it would instead reference named permission-sets. This would allow the >> provisioning tool to be able to add/remove permissions to/from a default >> permission-set based on the presence/absence of a specific subsystem when >> generating the default configuration. However, as Alexey pointed out, this >> doesn't solve the problem of knowing which permission-mapping a >> permission-set should be added to when attempting to preserve user >> configuration changes for patching, version updates, etc. >> > > Right. It does not change the permission-mappings, they remain to be a > list of items with no identity. Which is the fundamental problem. > But why is that a problem? I think that is the piece still missing. By moving the list of the permissions into a single named resource the tooling no longer has a need to be performing the manipulation within the simple permission mapper so that can be left to the administrator to look after independently. > > Thanks, > Alexey > > Thanks, >> Farah >> >> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> While this is addressed mainly to the Elytron team, it seems like we >>> would appreciate opinions from other colleagues since we are basically >>> stuck discussing possible ways to resolve >>> https://issues.jboss.org/browse/WFCORE-3596 >>> >>> The description in the jira is pretty brief assuming people know what >>> that is about, since it's been raised before multiple times. Here is what >>> it is about fundamentally. >>> >>> If a configuration model (of a subsystem or any other component) >>> includes a list of configurable units (let's assume XML elements for >>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>> a big problem for supporting patching and version updates preserving user >>> configuration changes. Or simply customizing the default config model using >>> a tool. By a big problem I mean it's simply not going to work reliably. >>> >>> As a simple exercise that demonstrates the issue, imagine you have two >>> configs each of which includes a list of these configurable units that have >>> no identity. Now try to identify the difference between the two lists. Or >>> merge them with one overwriting the other. Basically components w/o an >>> identity can not be manipulated. You can only add them but not modify or >>> even remove (unless their index in the list is a constant value of course). >>> >>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>> except for the Elytron's permission-mapping's. (If somebody knows such >>> components please let me know). >>> If I misunderstand the Elytron config model or approaching this from a >>> wrong angle, please let me know. >>> >>> Question for the Elytron team: is the problem I am describing clear? Do >>> you admit it as a problem? >>> >>> Thanks, >>> Alexey >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/4b49e290/attachment-0001.html From brian.stansberry at redhat.com Fri Mar 23 16:52:07 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 23 Mar 2018 15:52:07 -0500 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: >> >>> A solution to part of the problem mentioned in WFCORE-3596 that was >>> discussed is to introduce the concept of named permission sets. In >>> particular, instead of having a permission-mapping reference permissions, >>> it would instead reference named permission-sets. This would allow the >>> provisioning tool to be able to add/remove permissions to/from a default >>> permission-set based on the presence/absence of a specific subsystem when >>> generating the default configuration. However, as Alexey pointed out, this >>> doesn't solve the problem of knowing which permission-mapping a >>> permission-set should be added to when attempting to preserve user >>> configuration changes for patching, version updates, etc. >>> >> >> Right. It does not change the permission-mappings, they remain to be a >> list of items with no identity. Which is the fundamental problem. >> > > But why is that a problem? I think that is the piece still missing. > > By moving the list of the permissions into a single named resource the > tooling no longer has a need to be performing the manipulation within the > simple permission mapper so that can be left to the administrator to look > after independently. > Is your question why is it a problem to give these things an identity? If so, I have the same question, although I don't think Alexey's the one to come up with the identity. Or is your question why is not having an identity a problem? If so, is it correct to say that getting rid of this bit of wrongness is the problem: https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125 Basically right there elytron is speculatively providing configuration rightly owned by other subsystems. To do this correctly, each of those permissions should be part of the config established by other parts of the system. The provisioning tool is expected to do it correctly. And doing that requires some sort of identity for each item in the set. . Installing a feature should involve adding independent, identifiable chunks of config, not manipulating an attribute of some chunk of config owned by a different feature. Manipulating an attribute is not feasible and isn't correct. > >> >> Thanks, >> Alexey >> >> Thanks, >>> Farah >>> >>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>> alexey.loubyansky at redhat.com> wrote: >>> >>>> While this is addressed mainly to the Elytron team, it seems like we >>>> would appreciate opinions from other colleagues since we are basically >>>> stuck discussing possible ways to resolve https://issues.jboss.org/ >>>> browse/WFCORE-3596 >>>> >>>> The description in the jira is pretty brief assuming people know what >>>> that is about, since it's been raised before multiple times. Here is what >>>> it is about fundamentally. >>>> >>>> If a configuration model (of a subsystem or any other component) >>>> includes a list of configurable units (let's assume XML elements for >>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>> a big problem for supporting patching and version updates preserving user >>>> configuration changes. Or simply customizing the default config model using >>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>> >>>> As a simple exercise that demonstrates the issue, imagine you have two >>>> configs each of which includes a list of these configurable units that have >>>> no identity. Now try to identify the difference between the two lists. Or >>>> merge them with one overwriting the other. Basically components w/o an >>>> identity can not be manipulated. You can only add them but not modify or >>>> even remove (unless their index in the list is a constant value of course). >>>> >>>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>>> except for the Elytron's permission-mapping's. (If somebody knows such >>>> components please let me know). >>>> If I misunderstand the Elytron config model or approaching this from a >>>> wrong angle, please let me know. >>>> >>>> Question for the Elytron team: is the problem I am describing clear? Do >>>> you admit it as a problem? >>>> >>>> Thanks, >>>> Alexey >>>> >>> >>> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/ec7e2a57/attachment.html From alexey.loubyansky at redhat.com Fri Mar 23 17:39:01 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Fri, 23 Mar 2018 22:39:01 +0100 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: Apparently all your responses to this thread Darran didn't show up in my view of the thread. No idea why. If not Brian's response to your email I wouldn't have found out that. Copying your email from the list archive: "But why is that a problem? I think that is the piece still missing. By moving the list of the permissions into a single named resource the tooling no longer has a need to be performing the manipulation within the simple permission mapper so that can be left to the administrator to look after independently." It doesn't work like that. It's not like "you can manage this part of the config and this part should be left out". About the permission-mappings and why this list is a problem. We need to be able to compute a diff between two Elytron subsystem configs. They may match, may be slightly different, may be completely different. To do that we need to be able to identify comparable pieces the config consists of. Named permission-sets are no problem. Now I get to the list of permission-mappings, as it is a part of the Elytron's subsystem config. How can I compare these lists? Well, naturally a list is a collection of items in a specific order. So what I am going to do is assume that I should be comparing the items in the order they appear in two lists. And generate the diff based on that order. Which in some cases will be useless. The thing is that, I will not only be calculating the diff I will also be applying it to the config. In some cases the result will be pretty much unexpected. Does it make any sense to you? Thanks, Alexey On Fri, Mar 23, 2018 at 6:49 PM, Alexey Loubyansky < alexey.loubyansky at redhat.com> wrote: > On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: > >> A solution to part of the problem mentioned in WFCORE-3596 that was >> discussed is to introduce the concept of named permission sets. In >> particular, instead of having a permission-mapping reference permissions, >> it would instead reference named permission-sets. This would allow the >> provisioning tool to be able to add/remove permissions to/from a default >> permission-set based on the presence/absence of a specific subsystem when >> generating the default configuration. However, as Alexey pointed out, this >> doesn't solve the problem of knowing which permission-mapping a >> permission-set should be added to when attempting to preserve user >> configuration changes for patching, version updates, etc. >> > > Right. It does not change the permission-mappings, they remain to be a > list of items with no identity. Which is the fundamental problem. > > Thanks, > Alexey > > Thanks, >> Farah >> >> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> While this is addressed mainly to the Elytron team, it seems like we >>> would appreciate opinions from other colleagues since we are basically >>> stuck discussing possible ways to resolve https://issues.jboss.org/brows >>> e/WFCORE-3596 >>> >>> The description in the jira is pretty brief assuming people know what >>> that is about, since it's been raised before multiple times. Here is what >>> it is about fundamentally. >>> >>> If a configuration model (of a subsystem or any other component) >>> includes a list of configurable units (let's assume XML elements for >>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>> a big problem for supporting patching and version updates preserving user >>> configuration changes. Or simply customizing the default config model using >>> a tool. By a big problem I mean it's simply not going to work reliably. >>> >>> As a simple exercise that demonstrates the issue, imagine you have two >>> configs each of which includes a list of these configurable units that have >>> no identity. Now try to identify the difference between the two lists. Or >>> merge them with one overwriting the other. Basically components w/o an >>> identity can not be manipulated. You can only add them but not modify or >>> even remove (unless their index in the list is a constant value of course). >>> >>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>> except for the Elytron's permission-mapping's. (If somebody knows such >>> components please let me know). >>> If I misunderstand the Elytron config model or approaching this from a >>> wrong angle, please let me know. >>> >>> Question for the Elytron team: is the problem I am describing clear? Do >>> you admit it as a problem? >>> >>> Thanks, >>> Alexey >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/7fd76cc9/attachment-0001.html From zoltan.kukk at gmail.com Mon Mar 26 04:07:56 2018 From: zoltan.kukk at gmail.com (=?UTF-8?B?Wm9sdMOhbiBLdWtr?=) Date: Mon, 26 Mar 2018 10:07:56 +0200 Subject: [wildfly-dev] Elytron role mapping Message-ID: Hi all, I'd like to create a role mapping to convert role received from a realm to another role eg. role name is SOME_ROLE and I'd like to convert it to SOMETHING_ELSE. Is it possible with Elytron? From mchoma at redhat.com Mon Mar 26 05:26:19 2018 From: mchoma at redhat.com (Martin Choma) Date: Mon, 26 Mar 2018 11:26:19 +0200 Subject: [wildfly-dev] Elytron role mapping In-Reply-To: References: Message-ID: Hi, this is developers forum. This kind of questions should be asked in https://developer.jboss.org/en/wildfly Elytron provides role mappers, but it has some limitations currently (WFCORE-3666). But really lets discuss details on wildfly forum. Martin On Mon, Mar 26, 2018 at 10:07 AM, Zolt?n Kukk wrote: > Hi all, > > I'd like to create a role mapping to convert role received from a > realm to another role > eg. role name is SOME_ROLE and I'd like to convert it to SOMETHING_ELSE. > Is it possible with Elytron? > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mchoma at redhat.com Mon Mar 26 08:40:29 2018 From: mchoma at redhat.com (Martin Choma) Date: Mon, 26 Mar 2018 14:40:29 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: I run through Elytron subsystem and there are other "suspicious" resources [1]. How it is guaranteed name/id/path attributes of collections are unique identifiers? On subsystem code level? Because this information is not in the model, as far as I know. Is it possible to declare compound unique-key? I mean for example to say that for permission resource (class-name,module) tuple is unique key. [1] configurable-sasl-server-factory/filters configurable-http-server-mechanism-factory/filters sasl-authentication-factory/mechanism-configurations sasl-authentication-factory/mechanism-configurations/mechanism-realm-configurations http-authentication-factory/mechanism-configurations http-authentication-factory/mechanism-configurations/mechanism-realm-configurations mechanism-provider-filtering-sasl-server-factory/filters ldap-realm/identity-mapping/attribute-mapping jdbc-realm/principal-query jdbc-realm/principal-query/attribute-mapping security-domain/realms On Fri, Mar 23, 2018 at 4:55 PM, Alexey Loubyansky wrote: > While this is addressed mainly to the Elytron team, it seems like we would > appreciate opinions from other colleagues since we are basically stuck > discussing possible ways to resolve > https://issues.jboss.org/browse/WFCORE-3596 > > The description in the jira is pretty brief assuming people know what that > is about, since it's been raised before multiple times. Here is what it is > about fundamentally. > > If a configuration model (of a subsystem or any other component) includes a > list of configurable units (let's assume XML elements for simplicity) that > don't have any identity (unique id/name/path/etc) this is a big problem for > supporting patching and version updates preserving user configuration > changes. Or simply customizing the default config model using a tool. By a > big problem I mean it's simply not going to work reliably. > > As a simple exercise that demonstrates the issue, imagine you have two > configs each of which includes a list of these configurable units that have > no identity. Now try to identify the difference between the two lists. Or > merge them with one overwriting the other. Basically components w/o an > identity can not be manipulated. You can only add them but not modify or > even remove (unless their index in the list is a constant value of course). > > I don't think I've seen any issue of this kind in our (WF/EAP) configs > except for the Elytron's permission-mapping's. (If somebody knows such > components please let me know). > If I misunderstand the Elytron config model or approaching this from a wrong > angle, please let me know. > > Question for the Elytron team: is the problem I am describing clear? Do you > admit it as a problem? > > Thanks, > Alexey > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From alexey.loubyansky at redhat.com Mon Mar 26 12:17:50 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Mon, 26 Mar 2018 18:17:50 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: Hi Martin, thanks for the list. Right, some of those suffer from the same problem and some seem to have an identity (not explicitly expressed since we don't have a way to do that for a member of a complex type yet but once we do it won't be a problem). Ok, I had a hope we were going to address these relatively quick (given that the issue was raised back in autumn). I don't see it happening next month neither. So for now I am going to handle these kind of config structures (i.e. lists of complex types) as atomic pieces (although potentially big). They won't be mergeable during updates but one will be replacing completely the other with the one coming in last winning. In perspective though, I think this is going to remain a critical issue. Thanks, Alexey On Mon, Mar 26, 2018 at 2:40 PM, Martin Choma wrote: > I run through Elytron subsystem and there are other "suspicious" > resources [1]. How it is guaranteed name/id/path attributes of > collections are unique identifiers? On subsystem code level? Because > this information is not in the model, as far as I know. > > Is it possible to declare compound unique-key? I mean for example to > say that for permission resource (class-name,module) tuple is unique > key. > > [1] > configurable-sasl-server-factory/filters > configurable-http-server-mechanism-factory/filters > > sasl-authentication-factory/mechanism-configurations > sasl-authentication-factory/mechanism-configurations/mechani > sm-realm-configurations > http-authentication-factory/mechanism-configurations > http-authentication-factory/mechanism-configurations/mechani > sm-realm-configurations > > mechanism-provider-filtering-sasl-server-factory/filters > > ldap-realm/identity-mapping/attribute-mapping > jdbc-realm/principal-query > jdbc-realm/principal-query/attribute-mapping > > security-domain/realms > > On Fri, Mar 23, 2018 at 4:55 PM, Alexey Loubyansky > wrote: > > While this is addressed mainly to the Elytron team, it seems like we > would > > appreciate opinions from other colleagues since we are basically stuck > > discussing possible ways to resolve > > https://issues.jboss.org/browse/WFCORE-3596 > > > > The description in the jira is pretty brief assuming people know what > that > > is about, since it's been raised before multiple times. Here is what it > is > > about fundamentally. > > > > If a configuration model (of a subsystem or any other component) > includes a > > list of configurable units (let's assume XML elements for simplicity) > that > > don't have any identity (unique id/name/path/etc) this is a big problem > for > > supporting patching and version updates preserving user configuration > > changes. Or simply customizing the default config model using a tool. By > a > > big problem I mean it's simply not going to work reliably. > > > > As a simple exercise that demonstrates the issue, imagine you have two > > configs each of which includes a list of these configurable units that > have > > no identity. Now try to identify the difference between the two lists. Or > > merge them with one overwriting the other. Basically components w/o an > > identity can not be manipulated. You can only add them but not modify or > > even remove (unless their index in the list is a constant value of > course). > > > > I don't think I've seen any issue of this kind in our (WF/EAP) configs > > except for the Elytron's permission-mapping's. (If somebody knows such > > components please let me know). > > If I misunderstand the Elytron config model or approaching this from a > wrong > > angle, please let me know. > > > > Question for the Elytron team: is the problem I am describing clear? Do > you > > admit it as a problem? > > > > Thanks, > > Alexey > > > > _______________________________________________ > > 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/20180326/b152be02/attachment.html From darran.lofthouse at redhat.com Tue Mar 27 06:40:07 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Tue, 27 Mar 2018 10:40:07 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: Ok so lets switch this another way. If the addition from other subsystems was to be eliminated is there still a provisioning issue? On Fri, 23 Mar 2018 at 20:52 Brian Stansberry wrote: > On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: >>> >>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>> discussed is to introduce the concept of named permission sets. In >>>> particular, instead of having a permission-mapping reference permissions, >>>> it would instead reference named permission-sets. This would allow the >>>> provisioning tool to be able to add/remove permissions to/from a default >>>> permission-set based on the presence/absence of a specific subsystem when >>>> generating the default configuration. However, as Alexey pointed out, this >>>> doesn't solve the problem of knowing which permission-mapping a >>>> permission-set should be added to when attempting to preserve user >>>> configuration changes for patching, version updates, etc. >>>> >>> >>> Right. It does not change the permission-mappings, they remain to be a >>> list of items with no identity. Which is the fundamental problem. >>> >> >> But why is that a problem? I think that is the piece still missing. >> >> By moving the list of the permissions into a single named resource the >> tooling no longer has a need to be performing the manipulation within the >> simple permission mapper so that can be left to the administrator to look >> after independently. >> > > Is your question why is it a problem to give these things an identity? If > so, I have the same question, although I don't think Alexey's the one to > come up with the identity. > > Or is your question why is not having an identity a problem? If so, is it > correct to say that getting rid of this bit of wrongness is the problem: > > > https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125 > > Basically right there elytron is speculatively providing configuration > rightly owned by other subsystems. To do this correctly, each of those > permissions should be part of the config established by other parts of the > system. The provisioning tool is expected to do it correctly. And doing > that requires some sort of identity for each item in the set. . Installing > a feature should involve adding independent, identifiable chunks of config, > not manipulating an attribute of some chunk of config owned by a different > feature. Manipulating an attribute is not feasible and isn't correct. > > >> >>> >>> Thanks, >>> Alexey >>> >>> Thanks, >>>> Farah >>>> >>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>> alexey.loubyansky at redhat.com> wrote: >>>> >>>>> While this is addressed mainly to the Elytron team, it seems like we >>>>> would appreciate opinions from other colleagues since we are basically >>>>> stuck discussing possible ways to resolve >>>>> https://issues.jboss.org/browse/WFCORE-3596 >>>>> >>>>> The description in the jira is pretty brief assuming people know what >>>>> that is about, since it's been raised before multiple times. Here is what >>>>> it is about fundamentally. >>>>> >>>>> If a configuration model (of a subsystem or any other component) >>>>> includes a list of configurable units (let's assume XML elements for >>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>> a big problem for supporting patching and version updates preserving user >>>>> configuration changes. Or simply customizing the default config model using >>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>> >>>>> As a simple exercise that demonstrates the issue, imagine you have two >>>>> configs each of which includes a list of these configurable units that have >>>>> no identity. Now try to identify the difference between the two lists. Or >>>>> merge them with one overwriting the other. Basically components w/o an >>>>> identity can not be manipulated. You can only add them but not modify or >>>>> even remove (unless their index in the list is a constant value of course). >>>>> >>>>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>>>> except for the Elytron's permission-mapping's. (If somebody knows such >>>>> components please let me know). >>>>> If I misunderstand the Elytron config model or approaching this from a >>>>> wrong angle, please let me know. >>>>> >>>>> Question for the Elytron team: is the problem I am describing clear? >>>>> Do you admit it as a problem? >>>>> >>>>> Thanks, >>>>> Alexey >>>>> >>>> >>>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/d897f6b8/attachment-0001.html From alexey.loubyansky at redhat.com Tue Mar 27 07:15:14 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 27 Mar 2018 13:15:14 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > Ok so lets switch this another way. > > If the addition from other subsystems was to be eliminated is there still > a provisioning issue? > The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added. Thanks, Alexey > > On Fri, 23 Mar 2018 at 20:52 Brian Stansberry > wrote: > >> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >> darran.lofthouse at jboss.com> wrote: >> >>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>> alexey.loubyansky at redhat.com> wrote: >>> >>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: >>>> >>>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>>> discussed is to introduce the concept of named permission sets. In >>>>> particular, instead of having a permission-mapping reference permissions, >>>>> it would instead reference named permission-sets. This would allow the >>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>> permission-set based on the presence/absence of a specific subsystem when >>>>> generating the default configuration. However, as Alexey pointed out, this >>>>> doesn't solve the problem of knowing which permission-mapping a >>>>> permission-set should be added to when attempting to preserve user >>>>> configuration changes for patching, version updates, etc. >>>>> >>>> >>>> Right. It does not change the permission-mappings, they remain to be a >>>> list of items with no identity. Which is the fundamental problem. >>>> >>> >>> But why is that a problem? I think that is the piece still missing. >>> >>> By moving the list of the permissions into a single named resource the >>> tooling no longer has a need to be performing the manipulation within the >>> simple permission mapper so that can be left to the administrator to look >>> after independently. >>> >> >> Is your question why is it a problem to give these things an identity? If >> so, I have the same question, although I don't think Alexey's the one to >> come up with the identity. >> >> Or is your question why is not having an identity a problem? If so, is it >> correct to say that getting rid of this bit of wrongness is the problem: >> >> https://github.com/wildfly/wildfly-core/blob/master/ >> elytron/src/main/resources/subsystem-templates/elytron.xml#L125 >> >> Basically right there elytron is speculatively providing configuration >> rightly owned by other subsystems. To do this correctly, each of those >> permissions should be part of the config established by other parts of the >> system. The provisioning tool is expected to do it correctly. And doing >> that requires some sort of identity for each item in the set. . Installing >> a feature should involve adding independent, identifiable chunks of config, >> not manipulating an attribute of some chunk of config owned by a different >> feature. Manipulating an attribute is not feasible and isn't correct. >> >> >>> >>>> >>>> Thanks, >>>> Alexey >>>> >>>> Thanks, >>>>> Farah >>>>> >>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>> alexey.loubyansky at redhat.com> wrote: >>>>> >>>>>> While this is addressed mainly to the Elytron team, it seems like we >>>>>> would appreciate opinions from other colleagues since we are basically >>>>>> stuck discussing possible ways to resolve https://issues.jboss.org/ >>>>>> browse/WFCORE-3596 >>>>>> >>>>>> The description in the jira is pretty brief assuming people know what >>>>>> that is about, since it's been raised before multiple times. Here is what >>>>>> it is about fundamentally. >>>>>> >>>>>> If a configuration model (of a subsystem or any other component) >>>>>> includes a list of configurable units (let's assume XML elements for >>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>> a big problem for supporting patching and version updates preserving user >>>>>> configuration changes. Or simply customizing the default config model using >>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>> >>>>>> As a simple exercise that demonstrates the issue, imagine you have >>>>>> two configs each of which includes a list of these configurable units that >>>>>> have no identity. Now try to identify the difference between the two lists. >>>>>> Or merge them with one overwriting the other. Basically components w/o an >>>>>> identity can not be manipulated. You can only add them but not modify or >>>>>> even remove (unless their index in the list is a constant value of course). >>>>>> >>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>> such components please let me know). >>>>>> If I misunderstand the Elytron config model or approaching this from >>>>>> a wrong angle, please let me know. >>>>>> >>>>>> Question for the Elytron team: is the problem I am describing clear? >>>>>> Do you admit it as a problem? >>>>>> >>>>>> Thanks, >>>>>> Alexey >>>>>> >>>>> >>>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> >> -- >> Brian Stansberry >> Manager, Senior Principal Software Engineer >> Red Hat >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/e197d523/attachment.html From guillaume at hibernate.org Tue Mar 27 07:16:55 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Tue, 27 Mar 2018 13:16:55 +0200 Subject: [wildfly-dev] Hibernate Validator/Bean Validation status Message-ID: Hi, The Apache BVal folks are working on their Bean Validation 2.0 implementation and, by doing so, they opened a few TCK appeals against the Bean Validation TCK - including for tests already present in the 1.1 TCK. We fixed a few tests in the TCK and we had to also make changes to the reference implementation as it was conforming to incorrect tests. So, basically, we will have to release a new version of the TCK and a conforming version of Hibernate Validator and upgrade them in WildFly at some point. These versions will be respectively 2.0.3.Final and 6.0.10.Final. This is still a work in progress and I'm not really sure of when the Apache BVal folks will be done with the appeals. Thus I will push an upgrade to 6.0.9.Final to WildFly today as we recently discovered a 5.x -> 6.0.x regression and I think it's better to be sure the fix is in WildFly 13. If we get to finish the TCK work before the WF 13 freeze, I'll push the updated version and we will also have to upgrade the TCK we use for testing the EE8 conformance. -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/2f955cd0/attachment.html From darran.lofthouse at redhat.com Tue Mar 27 07:23:06 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Tue, 27 Mar 2018 11:23:06 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue? I am sure we have other examples of ordered lists out there. Darran. On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky wrote: > On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> Ok so lets switch this another way. >> >> If the addition from other subsystems was to be eliminated is there still >> a provisioning issue? >> > > The provisioning issue is related to the structure of the configuration > model (to be more precise the representation of the resource in the domain > management model since this is what is being manipulated). There are other > examples of subsystems requiring configuration of other features, e.g. some > subsystems may require specific socket-bindings. There is no problem with > that from the provisioning perspective because the model allows to check > whether the required socket-binding is already present in the config, > whether its parameters need any adjustments and if the socket-binding is > missing from the config it can be added. > > Thanks, > Alexey > > >> >> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry < >> brian.stansberry at redhat.com> wrote: >> >>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >>> darran.lofthouse at jboss.com> wrote: >>> >>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>>> alexey.loubyansky at redhat.com> wrote: >>>> >>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: >>>>> >>>>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>>>> discussed is to introduce the concept of named permission sets. In >>>>>> particular, instead of having a permission-mapping reference permissions, >>>>>> it would instead reference named permission-sets. This would allow the >>>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>>> permission-set based on the presence/absence of a specific subsystem when >>>>>> generating the default configuration. However, as Alexey pointed out, this >>>>>> doesn't solve the problem of knowing which permission-mapping a >>>>>> permission-set should be added to when attempting to preserve user >>>>>> configuration changes for patching, version updates, etc. >>>>>> >>>>> >>>>> Right. It does not change the permission-mappings, they remain to be a >>>>> list of items with no identity. Which is the fundamental problem. >>>>> >>>> >>>> But why is that a problem? I think that is the piece still missing. >>>> >>>> By moving the list of the permissions into a single named resource the >>>> tooling no longer has a need to be performing the manipulation within the >>>> simple permission mapper so that can be left to the administrator to look >>>> after independently. >>>> >>> >>> Is your question why is it a problem to give these things an identity? >>> If so, I have the same question, although I don't think Alexey's the one to >>> come up with the identity. >>> >>> Or is your question why is not having an identity a problem? If so, is >>> it correct to say that getting rid of this bit of wrongness is the problem: >>> >>> >>> https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125 >>> >>> Basically right there elytron is speculatively providing configuration >>> rightly owned by other subsystems. To do this correctly, each of those >>> permissions should be part of the config established by other parts of the >>> system. The provisioning tool is expected to do it correctly. And doing >>> that requires some sort of identity for each item in the set. . Installing >>> a feature should involve adding independent, identifiable chunks of config, >>> not manipulating an attribute of some chunk of config owned by a different >>> feature. Manipulating an attribute is not feasible and isn't correct. >>> >>> >>>> >>>>> >>>>> Thanks, >>>>> Alexey >>>>> >>>>> Thanks, >>>>>> Farah >>>>>> >>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>> >>>>>>> While this is addressed mainly to the Elytron team, it seems like we >>>>>>> would appreciate opinions from other colleagues since we are basically >>>>>>> stuck discussing possible ways to resolve >>>>>>> https://issues.jboss.org/browse/WFCORE-3596 >>>>>>> >>>>>>> The description in the jira is pretty brief assuming people know >>>>>>> what that is about, since it's been raised before multiple times. Here is >>>>>>> what it is about fundamentally. >>>>>>> >>>>>>> If a configuration model (of a subsystem or any other component) >>>>>>> includes a list of configurable units (let's assume XML elements for >>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>>> a big problem for supporting patching and version updates preserving user >>>>>>> configuration changes. Or simply customizing the default config model using >>>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>>> >>>>>>> As a simple exercise that demonstrates the issue, imagine you have >>>>>>> two configs each of which includes a list of these configurable units that >>>>>>> have no identity. Now try to identify the difference between the two lists. >>>>>>> Or merge them with one overwriting the other. Basically components w/o an >>>>>>> identity can not be manipulated. You can only add them but not modify or >>>>>>> even remove (unless their index in the list is a constant value of course). >>>>>>> >>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>>> such components please let me know). >>>>>>> If I misunderstand the Elytron config model or approaching this from >>>>>>> a wrong angle, please let me know. >>>>>>> >>>>>>> Question for the Elytron team: is the problem I am describing clear? >>>>>>> Do you admit it as a problem? >>>>>>> >>>>>>> Thanks, >>>>>>> Alexey >>>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> >>> -- >>> Brian Stansberry >>> Manager, Senior Principal Software Engineer >>> Red Hat >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/7f6f8114/attachment-0001.html From alexey.loubyansky at redhat.com Tue Mar 27 07:45:26 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 27 Mar 2018 13:45:26 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > The part that I am still missing is if we remove the need to manipulate an > ordered list as other subsystems are added and removed how is the presence > of the ordered list still an issue? I am sure we have other examples of > ordered lists out there. > Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. Identifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well. Alexey > Darran. > > > On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < >> darran.lofthouse at redhat.com> wrote: >> >>> Ok so lets switch this another way. >>> >>> If the addition from other subsystems was to be eliminated is there >>> still a provisioning issue? >>> >> >> The provisioning issue is related to the structure of the configuration >> model (to be more precise the representation of the resource in the domain >> management model since this is what is being manipulated). There are other >> examples of subsystems requiring configuration of other features, e.g. some >> subsystems may require specific socket-bindings. There is no problem with >> that from the provisioning perspective because the model allows to check >> whether the required socket-binding is already present in the config, >> whether its parameters need any adjustments and if the socket-binding is >> missing from the config it can be added. >> >> Thanks, >> Alexey >> >> >>> >>> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry < >>> brian.stansberry at redhat.com> wrote: >>> >>>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >>>> darran.lofthouse at jboss.com> wrote: >>>> >>>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>>>> alexey.loubyansky at redhat.com> wrote: >>>>> >>>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma wrote: >>>>>> >>>>>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>>>>> discussed is to introduce the concept of named permission sets. In >>>>>>> particular, instead of having a permission-mapping reference permissions, >>>>>>> it would instead reference named permission-sets. This would allow the >>>>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>>>> permission-set based on the presence/absence of a specific subsystem when >>>>>>> generating the default configuration. However, as Alexey pointed out, this >>>>>>> doesn't solve the problem of knowing which permission-mapping a >>>>>>> permission-set should be added to when attempting to preserve user >>>>>>> configuration changes for patching, version updates, etc. >>>>>>> >>>>>> >>>>>> Right. It does not change the permission-mappings, they remain to be >>>>>> a list of items with no identity. Which is the fundamental problem. >>>>>> >>>>> >>>>> But why is that a problem? I think that is the piece still missing. >>>>> >>>>> By moving the list of the permissions into a single named resource the >>>>> tooling no longer has a need to be performing the manipulation within the >>>>> simple permission mapper so that can be left to the administrator to look >>>>> after independently. >>>>> >>>> >>>> Is your question why is it a problem to give these things an identity? >>>> If so, I have the same question, although I don't think Alexey's the one to >>>> come up with the identity. >>>> >>>> Or is your question why is not having an identity a problem? If so, is >>>> it correct to say that getting rid of this bit of wrongness is the problem: >>>> >>>> https://github.com/wildfly/wildfly-core/blob/master/ >>>> elytron/src/main/resources/subsystem-templates/elytron.xml#L125 >>>> >>>> Basically right there elytron is speculatively providing configuration >>>> rightly owned by other subsystems. To do this correctly, each of those >>>> permissions should be part of the config established by other parts of the >>>> system. The provisioning tool is expected to do it correctly. And doing >>>> that requires some sort of identity for each item in the set. . Installing >>>> a feature should involve adding independent, identifiable chunks of config, >>>> not manipulating an attribute of some chunk of config owned by a different >>>> feature. Manipulating an attribute is not feasible and isn't correct. >>>> >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexey >>>>>> >>>>>> Thanks, >>>>>>> Farah >>>>>>> >>>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>> >>>>>>>> While this is addressed mainly to the Elytron team, it seems like >>>>>>>> we would appreciate opinions from other colleagues since we are basically >>>>>>>> stuck discussing possible ways to resolve https://issues.jboss.org/ >>>>>>>> browse/WFCORE-3596 >>>>>>>> >>>>>>>> The description in the jira is pretty brief assuming people know >>>>>>>> what that is about, since it's been raised before multiple times. Here is >>>>>>>> what it is about fundamentally. >>>>>>>> >>>>>>>> If a configuration model (of a subsystem or any other component) >>>>>>>> includes a list of configurable units (let's assume XML elements for >>>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>>>> a big problem for supporting patching and version updates preserving user >>>>>>>> configuration changes. Or simply customizing the default config model using >>>>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>>>> >>>>>>>> As a simple exercise that demonstrates the issue, imagine you have >>>>>>>> two configs each of which includes a list of these configurable units that >>>>>>>> have no identity. Now try to identify the difference between the two lists. >>>>>>>> Or merge them with one overwriting the other. Basically components w/o an >>>>>>>> identity can not be manipulated. You can only add them but not modify or >>>>>>>> even remove (unless their index in the list is a constant value of course). >>>>>>>> >>>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>>>> such components please let me know). >>>>>>>> If I misunderstand the Elytron config model or approaching this >>>>>>>> from a wrong angle, please let me know. >>>>>>>> >>>>>>>> Question for the Elytron team: is the problem I am describing >>>>>>>> clear? Do you admit it as a problem? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexey >>>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Manager, Senior Principal Software Engineer >>>> Red Hat >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/ecb3843f/attachment.html From darran.lofthouse at redhat.com Tue Mar 27 08:06:51 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Tue, 27 Mar 2018 12:06:51 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: How do you cope with things like a login module stack in the security subsystem? That is also ordered where the order has a very specific meaning. I haven't checked the configuration recently but doesn't configuration for jgroups also handle the configuration in an ordered way that an administrator could choose to modify? The proposal we have so far is to remove the need for the manipulation of permissions in the ordered list as other subsystems are added / removed - at this point the remaining config in the permission mapper should either match the default we ship or if it is modified this should be as a result of administrator action so should be preserved as is. The problem we have with the resource now is it must be preserved for backwards compatibility. Broadly this means we have the following two requirements: - 1 - Any changes we make must be transformable to the prior version of the resource. 2 - XML configuration for a prior version of the resource must be convertible to the new version. Alternatively we could redesign a new resource from scratch to provide model based permission mapping but a redesign from scratch is unlikely to completely cover #1 and #2 so we could end up with a deprecated resource which is not immediately removable although if we can achieve #1 removal possibly could be faster. But is all this necessary at the moment? Especially as at the moment we do have a proposal that moves the permissions we know need to be updated to an identifiable resource. Darran. On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky wrote: > On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> The part that I am still missing is if we remove the need to manipulate >> an ordered list as other subsystems are added and removed how is the >> presence of the ordered list still an issue? I am sure we have other >> examples of ordered lists out there. >> > > Actually, mainly in Elytron. The list in itself is not an issue, the > identity of the items is. If there is a list that can be modified by > various parties (end user, as a consequence of integration of other > components, etc) there is a problem of merging these modifications or even > identifying them in terms which items changed and how. Identifying user > changes since the last official update (with the goal to preserve them > after the next update) becomes a problem as well. > > Alexey > > >> Darran. >> >> >> On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < >>> darran.lofthouse at redhat.com> wrote: >>> >>>> Ok so lets switch this another way. >>>> >>>> If the addition from other subsystems was to be eliminated is there >>>> still a provisioning issue? >>>> >>> >>> The provisioning issue is related to the structure of the configuration >>> model (to be more precise the representation of the resource in the domain >>> management model since this is what is being manipulated). There are other >>> examples of subsystems requiring configuration of other features, e.g. some >>> subsystems may require specific socket-bindings. There is no problem with >>> that from the provisioning perspective because the model allows to check >>> whether the required socket-binding is already present in the config, >>> whether its parameters need any adjustments and if the socket-binding is >>> missing from the config it can be added. >>> >>> Thanks, >>> Alexey >>> >>> >>>> >>>> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry < >>>> brian.stansberry at redhat.com> wrote: >>>> >>>>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >>>>> darran.lofthouse at jboss.com> wrote: >>>>> >>>>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>> >>>>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma >>>>>>> wrote: >>>>>>> >>>>>>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>>>>>> discussed is to introduce the concept of named permission sets. In >>>>>>>> particular, instead of having a permission-mapping reference permissions, >>>>>>>> it would instead reference named permission-sets. This would allow the >>>>>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>>>>> permission-set based on the presence/absence of a specific subsystem when >>>>>>>> generating the default configuration. However, as Alexey pointed out, this >>>>>>>> doesn't solve the problem of knowing which permission-mapping a >>>>>>>> permission-set should be added to when attempting to preserve user >>>>>>>> configuration changes for patching, version updates, etc. >>>>>>>> >>>>>>> >>>>>>> Right. It does not change the permission-mappings, they remain to be >>>>>>> a list of items with no identity. Which is the fundamental problem. >>>>>>> >>>>>> >>>>>> But why is that a problem? I think that is the piece still missing. >>>>>> >>>>>> By moving the list of the permissions into a single named resource >>>>>> the tooling no longer has a need to be performing the manipulation within >>>>>> the simple permission mapper so that can be left to the administrator to >>>>>> look after independently. >>>>>> >>>>> >>>>> Is your question why is it a problem to give these things an identity? >>>>> If so, I have the same question, although I don't think Alexey's the one to >>>>> come up with the identity. >>>>> >>>>> Or is your question why is not having an identity a problem? If so, is >>>>> it correct to say that getting rid of this bit of wrongness is the problem: >>>>> >>>>> >>>>> https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125 >>>>> >>>>> Basically right there elytron is speculatively providing configuration >>>>> rightly owned by other subsystems. To do this correctly, each of those >>>>> permissions should be part of the config established by other parts of the >>>>> system. The provisioning tool is expected to do it correctly. And doing >>>>> that requires some sort of identity for each item in the set. . Installing >>>>> a feature should involve adding independent, identifiable chunks of config, >>>>> not manipulating an attribute of some chunk of config owned by a different >>>>> feature. Manipulating an attribute is not feasible and isn't correct. >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexey >>>>>>> >>>>>>> Thanks, >>>>>>>> Farah >>>>>>>> >>>>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>>> >>>>>>>>> While this is addressed mainly to the Elytron team, it seems like >>>>>>>>> we would appreciate opinions from other colleagues since we are basically >>>>>>>>> stuck discussing possible ways to resolve >>>>>>>>> https://issues.jboss.org/browse/WFCORE-3596 >>>>>>>>> >>>>>>>>> The description in the jira is pretty brief assuming people know >>>>>>>>> what that is about, since it's been raised before multiple times. Here is >>>>>>>>> what it is about fundamentally. >>>>>>>>> >>>>>>>>> If a configuration model (of a subsystem or any other component) >>>>>>>>> includes a list of configurable units (let's assume XML elements for >>>>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>>>>> a big problem for supporting patching and version updates preserving user >>>>>>>>> configuration changes. Or simply customizing the default config model using >>>>>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>>>>> >>>>>>>>> As a simple exercise that demonstrates the issue, imagine you have >>>>>>>>> two configs each of which includes a list of these configurable units that >>>>>>>>> have no identity. Now try to identify the difference between the two lists. >>>>>>>>> Or merge them with one overwriting the other. Basically components w/o an >>>>>>>>> identity can not be manipulated. You can only add them but not modify or >>>>>>>>> even remove (unless their index in the list is a constant value of course). >>>>>>>>> >>>>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>>>>> such components please let me know). >>>>>>>>> If I misunderstand the Elytron config model or approaching this >>>>>>>>> from a wrong angle, please let me know. >>>>>>>>> >>>>>>>>> Question for the Elytron team: is the problem I am describing >>>>>>>>> clear? Do you admit it as a problem? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Manager, Senior Principal Software Engineer >>>>> Red Hat >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/54f6f0b5/attachment-0001.html From alexey.loubyansky at redhat.com Tue Mar 27 11:35:06 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 27 Mar 2018 17:35:06 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Tue, Mar 27, 2018 at 2:06 PM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > How do you cope with things like a login module stack in the security > subsystem? That is also ordered where the order has a very specific > meaning. I haven't checked the configuration recently but doesn't > configuration for jgroups also handle the configuration in an ordered way > that an administrator could choose to modify? > They (login module stack and jgroup's protocol stack) are different in that every item on the stack has an identity. So I can see whether an item has been removed, modified or a new one added. I can't see how I can do that with the permission-mapping. This is my main problem at the moment. About the ordered collections in general, yes, there is an issue. Like you mentioned, for a start the order can be pre-defined (it can later be re-defined although that appears to be not as easy as it should be). This is actually how it currently works. The proposal we have so far is to remove the need for the manipulation of > permissions in the ordered list as other subsystems are added / removed - > at this point the remaining config in the permission mapper should either > match the default we ship or if it is modified this should be as a result > of administrator action so should be preserved as is. > Right, I get that. The thing is that if it is modified, it has to be fully re-defined, meaning it's not a fine-grained adjustment. Because if you want to add another permission (or the named permission-set) how to can the target permission-mapping be determined? > The problem we have with the resource now is it must be preserved for > backwards compatibility. Broadly this means we have the following two > requirements: - > 1 - Any changes we make must be transformable to the prior version of the > resource. > 2 - XML configuration for a prior version of the resource must be > convertible to the new version. > The good thing is that XML is not what is being manipulated, the representation of the resource in the domain management model is. Not meaning it gives a complete freedom but it's a good thing. > Alternatively we could redesign a new resource from scratch to provide > model based permission mapping but a redesign from scratch is unlikely to > completely cover #1 and #2 so we could end up with a deprecated resource > which is not immediately removable although if we can achieve #1 removal > possibly could be faster. > > But is all this necessary at the moment? Especially as at the moment we > do have a proposal that moves the permissions we know need to be updated to > an identifiable resource. > What about the permission-mapping? Are there plans to do anything with them? To me, it depends on what you mean by "at the moment". If you mean whether the changes need to be implemented and usable in a few weeks, no. But I think not giving it a priority now is a bad thing, because as you wrote above then we have to support the structure which limits the ability to customize the default configs, perform integration, updates and preserving user changes. Thanks, Alexey > > Darran. > > > On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky < > alexey.loubyansky at redhat.com> wrote: > >> On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse < >> darran.lofthouse at redhat.com> wrote: >> >>> The part that I am still missing is if we remove the need to manipulate >>> an ordered list as other subsystems are added and removed how is the >>> presence of the ordered list still an issue? I am sure we have other >>> examples of ordered lists out there. >>> >> >> Actually, mainly in Elytron. The list in itself is not an issue, the >> identity of the items is. If there is a list that can be modified by >> various parties (end user, as a consequence of integration of other >> components, etc) there is a problem of merging these modifications or even >> identifying them in terms which items changed and how. Identifying user >> changes since the last official update (with the goal to preserve them >> after the next update) becomes a problem as well. >> >> Alexey >> >> >>> Darran. >>> >>> >>> On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky < >>> alexey.loubyansky at redhat.com> wrote: >>> >>>> On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < >>>> darran.lofthouse at redhat.com> wrote: >>>> >>>>> Ok so lets switch this another way. >>>>> >>>>> If the addition from other subsystems was to be eliminated is there >>>>> still a provisioning issue? >>>>> >>>> >>>> The provisioning issue is related to the structure of the configuration >>>> model (to be more precise the representation of the resource in the domain >>>> management model since this is what is being manipulated). There are other >>>> examples of subsystems requiring configuration of other features, e.g. some >>>> subsystems may require specific socket-bindings. There is no problem with >>>> that from the provisioning perspective because the model allows to check >>>> whether the required socket-binding is already present in the config, >>>> whether its parameters need any adjustments and if the socket-binding is >>>> missing from the config it can be added. >>>> >>>> Thanks, >>>> Alexey >>>> >>>> >>>>> >>>>> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry < >>>>> brian.stansberry at redhat.com> wrote: >>>>> >>>>>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >>>>>> darran.lofthouse at jboss.com> wrote: >>>>>> >>>>>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>> >>>>>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma >>>>>>>> wrote: >>>>>>>> >>>>>>>>> A solution to part of the problem mentioned in WFCORE-3596 that >>>>>>>>> was discussed is to introduce the concept of named permission sets. In >>>>>>>>> particular, instead of having a permission-mapping reference permissions, >>>>>>>>> it would instead reference named permission-sets. This would allow the >>>>>>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>>>>>> permission-set based on the presence/absence of a specific subsystem when >>>>>>>>> generating the default configuration. However, as Alexey pointed out, this >>>>>>>>> doesn't solve the problem of knowing which permission-mapping a >>>>>>>>> permission-set should be added to when attempting to preserve user >>>>>>>>> configuration changes for patching, version updates, etc. >>>>>>>>> >>>>>>>> >>>>>>>> Right. It does not change the permission-mappings, they remain to >>>>>>>> be a list of items with no identity. Which is the fundamental problem. >>>>>>>> >>>>>>> >>>>>>> But why is that a problem? I think that is the piece still missing. >>>>>>> >>>>>>> By moving the list of the permissions into a single named resource >>>>>>> the tooling no longer has a need to be performing the manipulation within >>>>>>> the simple permission mapper so that can be left to the administrator to >>>>>>> look after independently. >>>>>>> >>>>>> >>>>>> Is your question why is it a problem to give these things an >>>>>> identity? If so, I have the same question, although I don't think Alexey's >>>>>> the one to come up with the identity. >>>>>> >>>>>> Or is your question why is not having an identity a problem? If so, >>>>>> is it correct to say that getting rid of this bit of wrongness is the >>>>>> problem: >>>>>> >>>>>> https://github.com/wildfly/wildfly-core/blob/master/elytron/ >>>>>> src/main/resources/subsystem-templates/elytron.xml#L125 >>>>>> >>>>>> Basically right there elytron is speculatively providing >>>>>> configuration rightly owned by other subsystems. To do this correctly, each >>>>>> of those permissions should be part of the config established by other >>>>>> parts of the system. The provisioning tool is expected to do it correctly. >>>>>> And doing that requires some sort of identity for each item in the set. . >>>>>> Installing a feature should involve adding independent, identifiable chunks >>>>>> of config, not manipulating an attribute of some chunk of config owned by a >>>>>> different feature. Manipulating an attribute is not feasible and >>>>>> isn't correct. >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexey >>>>>>>> >>>>>>>> Thanks, >>>>>>>>> Farah >>>>>>>>> >>>>>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>>>> >>>>>>>>>> While this is addressed mainly to the Elytron team, it seems like >>>>>>>>>> we would appreciate opinions from other colleagues since we are basically >>>>>>>>>> stuck discussing possible ways to resolve >>>>>>>>>> https://issues.jboss.org/browse/WFCORE-3596 >>>>>>>>>> >>>>>>>>>> The description in the jira is pretty brief assuming people know >>>>>>>>>> what that is about, since it's been raised before multiple times. Here is >>>>>>>>>> what it is about fundamentally. >>>>>>>>>> >>>>>>>>>> If a configuration model (of a subsystem or any other component) >>>>>>>>>> includes a list of configurable units (let's assume XML elements for >>>>>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>>>>>> a big problem for supporting patching and version updates preserving user >>>>>>>>>> configuration changes. Or simply customizing the default config model using >>>>>>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>>>>>> >>>>>>>>>> As a simple exercise that demonstrates the issue, imagine you >>>>>>>>>> have two configs each of which includes a list of these configurable units >>>>>>>>>> that have no identity. Now try to identify the difference between the two >>>>>>>>>> lists. Or merge them with one overwriting the other. Basically components >>>>>>>>>> w/o an identity can not be manipulated. You can only add them but not >>>>>>>>>> modify or even remove (unless their index in the list is a constant value >>>>>>>>>> of course). >>>>>>>>>> >>>>>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>>>>>> such components please let me know). >>>>>>>>>> If I misunderstand the Elytron config model or approaching this >>>>>>>>>> from a wrong angle, please let me know. >>>>>>>>>> >>>>>>>>>> Question for the Elytron team: is the problem I am describing >>>>>>>>>> clear? Do you admit it as a problem? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list >>>>>>> wildfly-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Manager, Senior Principal Software Engineer >>>>>> Red Hat >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/dac54386/attachment-0001.html From darran.lofthouse at redhat.com Tue Mar 27 12:01:48 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Tue, 27 Mar 2018 16:01:48 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: I think this takes us all back to the start. Why do you need to be modifying the simple-permission-mapper resource. The proposed changes are to give you a named resource that can be safely manipulated without the simple-permission-mapper needing to be touched at all. On Tue, 27 Mar 2018 at 16:37 Alexey Loubyansky wrote: > On Tue, Mar 27, 2018 at 2:06 PM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> How do you cope with things like a login module stack in the security >> subsystem? That is also ordered where the order has a very specific >> meaning. I haven't checked the configuration recently but doesn't >> configuration for jgroups also handle the configuration in an ordered way >> that an administrator could choose to modify? >> > > They (login module stack and jgroup's protocol stack) are different in > that every item on the stack has an identity. So I can see whether an item > has been removed, modified or a new one added. I can't see how I can do > that with the permission-mapping. This is my main problem at the moment. > Isn't there a way for an equality check to be performed? In the case of the login module stacks once modules have been added or removed it is no longer safe for you to make changes to that stack - this resource is no different. > > About the ordered collections in general, yes, there is an issue. Like you > mentioned, for a start the order can be pre-defined (it can later be > re-defined although that appears to be not as easy as it should be). This > is actually how it currently works. > > The proposal we have so far is to remove the need for the manipulation of >> permissions in the ordered list as other subsystems are added / removed - >> at this point the remaining config in the permission mapper should either >> match the default we ship or if it is modified this should be as a result >> of administrator action so should be preserved as is. >> > > Right, I get that. The thing is that if it is modified, it has to be fully > re-defined, meaning it's not a fine-grained adjustment. Because if you want > to add another permission (or the named permission-set) how to can the > target permission-mapping be determined? > Why do you need to know this? The proposed change is so you can just modify the permission-set - once the administrator updates the simple-permission-mapper they have taken ownership of that resource and we should not be automating any further changes to it. > > >> The problem we have with the resource now is it must be preserved for >> backwards compatibility. Broadly this means we have the following two >> requirements: - >> 1 - Any changes we make must be transformable to the prior version of >> the resource. >> 2 - XML configuration for a prior version of the resource must be >> convertible to the new version. >> > > The good thing is that XML is not what is being manipulated, the > representation of the resource in the domain management model is. Not > meaning it gives a complete freedom but it's a good thing. > Yes but my point is we can not choose to simplify the resource as we still have to support the various permutations that could have been represented in XML against the previous version. > > >> Alternatively we could redesign a new resource from scratch to provide >> model based permission mapping but a redesign from scratch is unlikely to >> completely cover #1 and #2 so we could end up with a deprecated resource >> which is not immediately removable although if we can achieve #1 removal >> possibly could be faster. >> >> But is all this necessary at the moment? Especially as at the moment we >> do have a proposal that moves the permissions we know need to be updated to >> an identifiable resource. >> > > What about the permission-mapping? Are there plans to do anything with > them? > The plan is to update the simple-permission-mapper so the permission-mapping can map to a permission-set instead of containing the permission names directly. To me, it depends on what you mean by "at the moment". If you mean whether > the changes need to be implemented and usable in a few weeks, no. But I > think not giving it a priority now is a bad thing, because as you wrote > above then we have to support the structure which limits the ability to > customize the default configs, perform integration, updates and preserving > user changes. > I would propose we go ahead and add the new permission-set resource and update the simple-permission-mapper so these can be referenced instead of listing the permission classes. Based on the default configuration we ship we can then restructure the configuration so you have a single named resource to add and remove the permissions as appropriate where order is not relevant. We can then look as a separate RFE at redefining permission mapping, which could mean tweaks to the existing resource or could even consider some clean designs and deprecate the current resource if we think that makes sense. > > Thanks, > Alexey > > >> >> Darran. >> >> >> On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky < >> alexey.loubyansky at redhat.com> wrote: >> >>> On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse < >>> darran.lofthouse at redhat.com> wrote: >>> >>>> The part that I am still missing is if we remove the need to manipulate >>>> an ordered list as other subsystems are added and removed how is the >>>> presence of the ordered list still an issue? I am sure we have other >>>> examples of ordered lists out there. >>>> >>> >>> Actually, mainly in Elytron. The list in itself is not an issue, the >>> identity of the items is. If there is a list that can be modified by >>> various parties (end user, as a consequence of integration of other >>> components, etc) there is a problem of merging these modifications or even >>> identifying them in terms which items changed and how. Identifying user >>> changes since the last official update (with the goal to preserve them >>> after the next update) becomes a problem as well. >>> >>> Alexey >>> >>> >>>> Darran. >>>> >>>> >>>> On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky < >>>> alexey.loubyansky at redhat.com> wrote: >>>> >>>>> On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse < >>>>> darran.lofthouse at redhat.com> wrote: >>>>> >>>>>> Ok so lets switch this another way. >>>>>> >>>>>> If the addition from other subsystems was to be eliminated is there >>>>>> still a provisioning issue? >>>>>> >>>>> >>>>> The provisioning issue is related to the structure of the >>>>> configuration model (to be more precise the representation of the resource >>>>> in the domain management model since this is what is being manipulated). >>>>> There are other examples of subsystems requiring configuration of other >>>>> features, e.g. some subsystems may require specific socket-bindings. There >>>>> is no problem with that from the provisioning perspective because the model >>>>> allows to check whether the required socket-binding is already present in >>>>> the config, whether its parameters need any adjustments and if the >>>>> socket-binding is missing from the config it can be added. >>>>> >>>>> Thanks, >>>>> Alexey >>>>> >>>>> >>>>>> >>>>>> On Fri, 23 Mar 2018 at 20:52 Brian Stansberry < >>>>>> brian.stansberry at redhat.com> wrote: >>>>>> >>>>>>> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < >>>>>>> darran.lofthouse at jboss.com> wrote: >>>>>>> >>>>>>>> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >>>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>>> >>>>>>>>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> A solution to part of the problem mentioned in WFCORE-3596 that >>>>>>>>>> was discussed is to introduce the concept of named permission sets. In >>>>>>>>>> particular, instead of having a permission-mapping reference permissions, >>>>>>>>>> it would instead reference named permission-sets. This would allow the >>>>>>>>>> provisioning tool to be able to add/remove permissions to/from a default >>>>>>>>>> permission-set based on the presence/absence of a specific subsystem when >>>>>>>>>> generating the default configuration. However, as Alexey pointed out, this >>>>>>>>>> doesn't solve the problem of knowing which permission-mapping a >>>>>>>>>> permission-set should be added to when attempting to preserve user >>>>>>>>>> configuration changes for patching, version updates, etc. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Right. It does not change the permission-mappings, they remain to >>>>>>>>> be a list of items with no identity. Which is the fundamental problem. >>>>>>>>> >>>>>>>> >>>>>>>> But why is that a problem? I think that is the piece still missing. >>>>>>>> >>>>>>>> By moving the list of the permissions into a single named resource >>>>>>>> the tooling no longer has a need to be performing the manipulation within >>>>>>>> the simple permission mapper so that can be left to the administrator to >>>>>>>> look after independently. >>>>>>>> >>>>>>> >>>>>>> Is your question why is it a problem to give these things an >>>>>>> identity? If so, I have the same question, although I don't think Alexey's >>>>>>> the one to come up with the identity. >>>>>>> >>>>>>> Or is your question why is not having an identity a problem? If so, >>>>>>> is it correct to say that getting rid of this bit of wrongness is the >>>>>>> problem: >>>>>>> >>>>>>> >>>>>>> https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125 >>>>>>> >>>>>>> Basically right there elytron is speculatively providing >>>>>>> configuration rightly owned by other subsystems. To do this correctly, each >>>>>>> of those permissions should be part of the config established by other >>>>>>> parts of the system. The provisioning tool is expected to do it correctly. >>>>>>> And doing that requires some sort of identity for each item in the set. . >>>>>>> Installing a feature should involve adding independent, identifiable chunks >>>>>>> of config, not manipulating an attribute of some chunk of config owned by a >>>>>>> different feature. Manipulating an attribute is not feasible and >>>>>>> isn't correct. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>>> Farah >>>>>>>>>> >>>>>>>>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>>>>>>>> alexey.loubyansky at redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> While this is addressed mainly to the Elytron team, it seems >>>>>>>>>>> like we would appreciate opinions from other colleagues since we are >>>>>>>>>>> basically stuck discussing possible ways to resolve >>>>>>>>>>> https://issues.jboss.org/browse/WFCORE-3596 >>>>>>>>>>> >>>>>>>>>>> The description in the jira is pretty brief assuming people know >>>>>>>>>>> what that is about, since it's been raised before multiple times. Here is >>>>>>>>>>> what it is about fundamentally. >>>>>>>>>>> >>>>>>>>>>> If a configuration model (of a subsystem or any other component) >>>>>>>>>>> includes a list of configurable units (let's assume XML elements for >>>>>>>>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>>>>>>>> a big problem for supporting patching and version updates preserving user >>>>>>>>>>> configuration changes. Or simply customizing the default config model using >>>>>>>>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>>>>>>>> >>>>>>>>>>> As a simple exercise that demonstrates the issue, imagine you >>>>>>>>>>> have two configs each of which includes a list of these configurable units >>>>>>>>>>> that have no identity. Now try to identify the difference between the two >>>>>>>>>>> lists. Or merge them with one overwriting the other. Basically components >>>>>>>>>>> w/o an identity can not be manipulated. You can only add them but not >>>>>>>>>>> modify or even remove (unless their index in the list is a constant value >>>>>>>>>>> of course). >>>>>>>>>>> >>>>>>>>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>>>>>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>>>>>>>> such components please let me know). >>>>>>>>>>> If I misunderstand the Elytron config model or approaching this >>>>>>>>>>> from a wrong angle, please let me know. >>>>>>>>>>> >>>>>>>>>>> Question for the Elytron team: is the problem I am describing >>>>>>>>>>> clear? Do you admit it as a problem? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> wildfly-dev mailing list >>>>>>>> wildfly-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Manager, Senior Principal Software Engineer >>>>>>> Red Hat >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/53116dc6/attachment-0001.html From alexey.loubyansky at redhat.com Tue Mar 27 13:49:00 2018 From: alexey.loubyansky at redhat.com (Alexey Loubyansky) Date: Tue, 27 Mar 2018 19:49:00 +0200 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: On Tue, Mar 27, 2018 at 6:01 PM, Darran Lofthouse < darran.lofthouse at redhat.com> wrote: > I think this takes us all back to the start. > > Why do you need to be modifying the simple-permission-mapper resource. > Because users will probably need to. Two use-cases. 1) I don't want to install the default distribution with its configs and then start customizing it (given the complexity, in general, that is not a trivial and safe exercise especially if you are doing it manually). I want to install the already customized version (which is validated by the tool). Hopefully, I won't need to modify the simple-permission-mapper but what if I do want to? 2) I have my customized installation, there is a new compatible version available. I want to upgrade but don't want to do the config-customizing exercise again, i.e. i want my existing customizations to be preserved after the update. For that the tool needs to be able to identify my customizations that can be (re-)applied to the new version (assuming it is a compatible release). Now if I added a permission-set to one of the permission-mappings in the previous version, the tool won't be able to do a fine-grained diff that can be re-applied. The answer to both, and this is what you imply by saying that once an administrator touched it it shouldn't be changed by anything else, this part of the config is an atomic unit which has to be configured in its entirety whenever you want any change in it. Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/55ab450f/attachment.html From darran.lofthouse at redhat.com Tue Mar 27 13:57:16 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Tue, 27 Mar 2018 17:57:16 +0000 Subject: [wildfly-dev] problems with the Elytron permission-mapping config model In-Reply-To: References: Message-ID: Yes, once the administrator has modified the value for that single attribute the entire value for that attribute should be transferred over - the tooling should not be attempting to merge two attribute values into one. On Tue, 27 Mar 2018 at 18:49 Alexey Loubyansky wrote: > On Tue, Mar 27, 2018 at 6:01 PM, Darran Lofthouse < > darran.lofthouse at redhat.com> wrote: > >> I think this takes us all back to the start. >> >> Why do you need to be modifying the simple-permission-mapper resource. >> > > Because users will probably need to. Two use-cases. > > 1) I don't want to install the default distribution with its configs and > then start customizing it (given the complexity, in general, that is not a > trivial and safe exercise especially if you are doing it manually). I want > to install the already customized version (which is validated by the tool). > Hopefully, I won't need to modify the simple-permission-mapper but what if > I do want to? > > 2) I have my customized installation, there is a new compatible version > available. I want to upgrade but don't want to do the config-customizing > exercise again, i.e. i want my existing customizations to be preserved > after the update. For that the tool needs to be able to identify my > customizations that can be (re-)applied to the new version (assuming it is > a compatible release). Now if I added a permission-set to one of the > permission-mappings in the previous version, the tool won't be able to do a > fine-grained diff that can be re-applied. > > The answer to both, and this is what you imply by saying that once an > administrator touched it it shouldn't be changed by anything else, this > part of the config is an atomic unit which has to be configured in its > entirety whenever you want any change in it. > > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/15919a4b/attachment.html From hpehl at redhat.com Wed Mar 28 05:06:16 2018 From: hpehl at redhat.com (Harald Pehl) Date: Wed, 28 Mar 2018 11:06:16 +0200 Subject: [wildfly-dev] Rename HAL.next codebase Message-ID: Hi, as part of the transition from the current console to HAL.next, I renamed its GitHub repository today: https://github.com/hal/hal.next --> https://github.com/hal/console This is now the official codebase for the management console. I adjusted CI jobs, documentation, links and other references. If you come across broken links or find anything else that doesn't work anymore, please let me know. Thanks Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180328/8fb05bf8/attachment.html From david.lloyd at redhat.com Thu Mar 29 10:20:48 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 29 Mar 2018 09:20:48 -0500 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas Message-ID: This is something we've talked about before. I think we should move forward on this for the WFLY and WFCORE projects. Ideally we'd also have a "responsible person" field which would be populated by the component lead by default. But I don't think this is necessary as long as our component leads are triaging issues in their areas (which they should be). I think we should just do it. WDYT? -- - DML From anmiller at redhat.com Thu Mar 29 10:28:05 2018 From: anmiller at redhat.com (Andrig Miller) Date: Thu, 29 Mar 2018 08:28:05 -0600 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: This is the way it was a long time ago, and then we moved to default to the component lead because so many issues were being left in the unassigned state. Perhaps the default assignment just makes thing "look" better, and doesn't force triage to occur, or perhaps it does? I think we just think about this a little more, since we made the change because of such a mountain of issues being in the unassigned state. Andy On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd wrote: > This is something we've talked about before. I think we should move > forward on this for the WFLY and WFCORE projects. > > Ideally we'd also have a "responsible person" field which would be > populated by the component lead by default. But I don't think this is > necessary as long as our component leads are triaging issues in their > areas (which they should be). > > I think we should just do it. WDYT? > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180329/864356ac/attachment.html From david.lloyd at redhat.com Thu Mar 29 10:39:39 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 29 Mar 2018 09:39:39 -0500 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: Speaking for myself, I'd rather have issues unassigned because having it assigned means "do not work on this; someone else is going to". Then they just sit like that, maybe for years. I think having a default assignee is hiding the symptom while at the same time discouraging volunteers from taking issues. It's even worse now that we have multiple teams within Red Hat itself who want to work issues. I often get emails like "I see that WFLY-xxx is assigned to you; is it OK if I take it?" For every one of these, there may be several (internal or external) where they just give up because the issue is "assigned", and they just wait forever for someone to deliver the fix/feature for them. We see every issue as they are created. If we don't take an issue at that time, being honest, are we really ever going to do it? On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller wrote: > This is the way it was a long time ago, and then we moved to default to the > component lead because so many issues were being left in the unassigned > state. > > Perhaps the default assignment just makes thing "look" better, and doesn't > force triage to occur, or perhaps it does? > > I think we just think about this a little more, since we made the change > because of such a mountain of issues being in the unassigned state. > > Andy > > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd wrote: >> >> This is something we've talked about before. I think we should move >> forward on this for the WFLY and WFCORE projects. >> >> Ideally we'd also have a "responsible person" field which would be >> populated by the component lead by default. But I don't think this is >> necessary as long as our component leads are triaging issues in their >> areas (which they should be). >> >> I think we should just do it. WDYT? >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Andrig (Andy) T. Miller > Global Platform Director, Middleware > Red Hat, Inc. -- - DML From anmiller at redhat.com Thu Mar 29 10:41:55 2018 From: anmiller at redhat.com (Andrig Miller) Date: Thu, 29 Mar 2018 08:41:55 -0600 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: Good points. The issue has always been getting component leads to triage their issues on a regular enough basis. If this is just hiding that problem, and causing issues with community involvement, I am all for going back to unassigned. Andy On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd wrote: > Speaking for myself, I'd rather have issues unassigned because having > it assigned means "do not work on this; someone else is going to". > Then they just sit like that, maybe for years. > > I think having a default assignee is hiding the symptom while at the > same time discouraging volunteers from taking issues. It's even worse > now that we have multiple teams within Red Hat itself who want to work > issues. I often get emails like "I see that WFLY-xxx is assigned to > you; is it OK if I take it?" For every one of these, there may be > several (internal or external) where they just give up because the > issue is "assigned", and they just wait forever for someone to deliver > the fix/feature for them. > > We see every issue as they are created. If we don't take an issue at > that time, being honest, are we really ever going to do it? > > On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller > wrote: > > This is the way it was a long time ago, and then we moved to default to > the > > component lead because so many issues were being left in the unassigned > > state. > > > > Perhaps the default assignment just makes thing "look" better, and > doesn't > > force triage to occur, or perhaps it does? > > > > I think we just think about this a little more, since we made the change > > because of such a mountain of issues being in the unassigned state. > > > > Andy > > > > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd > wrote: > >> > >> This is something we've talked about before. I think we should move > >> forward on this for the WFLY and WFCORE projects. > >> > >> Ideally we'd also have a "responsible person" field which would be > >> populated by the component lead by default. But I don't think this is > >> necessary as long as our component leads are triaging issues in their > >> areas (which they should be). > >> > >> I think we should just do it. WDYT? > >> > >> -- > >> - DML > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > Andrig (Andy) T. Miller > > Global Platform Director, Middleware > > Red Hat, Inc. > > > > -- > - DML > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180329/1e350fcc/attachment.html From brian.stansberry at redhat.com Thu Mar 29 10:58:09 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 29 Mar 2018 09:58:09 -0500 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: I'm in favor of this change. I think in most cases it's important for people to communicate with component leads before they start doing much on an issue. But having the issued assigned to the lead hasn't AFAICT help ensure that kind of communication. On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller wrote: > Good points. The issue has always been getting component leads to triage > their issues on a regular enough basis. > > If this is just hiding that problem, and causing issues with community > involvement, I am all for going back to unassigned. > > Andy > > On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd > wrote: > >> Speaking for myself, I'd rather have issues unassigned because having >> it assigned means "do not work on this; someone else is going to". >> Then they just sit like that, maybe for years. >> >> I think having a default assignee is hiding the symptom while at the >> same time discouraging volunteers from taking issues. It's even worse >> now that we have multiple teams within Red Hat itself who want to work >> issues. I often get emails like "I see that WFLY-xxx is assigned to >> you; is it OK if I take it?" For every one of these, there may be >> several (internal or external) where they just give up because the >> issue is "assigned", and they just wait forever for someone to deliver >> the fix/feature for them. >> >> We see every issue as they are created. If we don't take an issue at >> that time, being honest, are we really ever going to do it? >> >> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller >> wrote: >> > This is the way it was a long time ago, and then we moved to default to >> the >> > component lead because so many issues were being left in the unassigned >> > state. >> > >> > Perhaps the default assignment just makes thing "look" better, and >> doesn't >> > force triage to occur, or perhaps it does? >> > >> > I think we just think about this a little more, since we made the change >> > because of such a mountain of issues being in the unassigned state. >> > >> > Andy >> > >> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd >> wrote: >> >> >> >> This is something we've talked about before. I think we should move >> >> forward on this for the WFLY and WFCORE projects. >> >> >> >> Ideally we'd also have a "responsible person" field which would be >> >> populated by the component lead by default. But I don't think this is >> >> necessary as long as our component leads are triaging issues in their >> >> areas (which they should be). >> >> >> >> I think we should just do it. WDYT? >> >> >> >> -- >> >> - DML >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> > >> > -- >> > Andrig (Andy) T. Miller >> > Global Platform Director, Middleware >> > Red Hat, Inc. >> >> >> >> -- >> - DML >> > > > > -- > Andrig (Andy) T. Miller > Global Platform Director, Middleware > Red Hat, Inc. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180329/78c33cd1/attachment.html From david.lloyd at redhat.com Thu Mar 29 11:15:27 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 29 Mar 2018 10:15:27 -0500 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: There's nothing stopping leads (or others) from commenting on issues with questions and/or more information, also. I'm more inclined to do that when I look at an issue and think "this isn't assigned to me, so I better make a note for whoever works the issue instead of just writing it on a forgotten notepad somewhere". Even if it ends up being me, it's helpful. On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry wrote: > I'm in favor of this change. > > I think in most cases it's important for people to communicate with > component leads before they start doing much on an issue. But having the > issued assigned to the lead hasn't AFAICT help ensure that kind of > communication. > > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller wrote: >> >> Good points. The issue has always been getting component leads to triage >> their issues on a regular enough basis. >> >> If this is just hiding that problem, and causing issues with community >> involvement, I am all for going back to unassigned. >> >> Andy >> >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd >> wrote: >>> >>> Speaking for myself, I'd rather have issues unassigned because having >>> it assigned means "do not work on this; someone else is going to". >>> Then they just sit like that, maybe for years. >>> >>> I think having a default assignee is hiding the symptom while at the >>> same time discouraging volunteers from taking issues. It's even worse >>> now that we have multiple teams within Red Hat itself who want to work >>> issues. I often get emails like "I see that WFLY-xxx is assigned to >>> you; is it OK if I take it?" For every one of these, there may be >>> several (internal or external) where they just give up because the >>> issue is "assigned", and they just wait forever for someone to deliver >>> the fix/feature for them. >>> >>> We see every issue as they are created. If we don't take an issue at >>> that time, being honest, are we really ever going to do it? >>> >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller >>> wrote: >>> > This is the way it was a long time ago, and then we moved to default to >>> > the >>> > component lead because so many issues were being left in the unassigned >>> > state. >>> > >>> > Perhaps the default assignment just makes thing "look" better, and >>> > doesn't >>> > force triage to occur, or perhaps it does? >>> > >>> > I think we just think about this a little more, since we made the >>> > change >>> > because of such a mountain of issues being in the unassigned state. >>> > >>> > Andy >>> > >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd >>> > wrote: >>> >> >>> >> This is something we've talked about before. I think we should move >>> >> forward on this for the WFLY and WFCORE projects. >>> >> >>> >> Ideally we'd also have a "responsible person" field which would be >>> >> populated by the component lead by default. But I don't think this is >>> >> necessary as long as our component leads are triaging issues in their >>> >> areas (which they should be). >>> >> >>> >> I think we should just do it. WDYT? >>> >> >>> >> -- >>> >> - DML >>> >> _______________________________________________ >>> >> wildfly-dev mailing list >>> >> wildfly-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > >>> > >>> > >>> > >>> > -- >>> > Andrig (Andy) T. Miller >>> > Global Platform Director, Middleware >>> > Red Hat, Inc. >>> >>> >>> >>> -- >>> - DML >> >> >> >> >> -- >> Andrig (Andy) T. Miller >> Global Platform Director, Middleware >> Red Hat, Inc. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -- - DML From belaran at redhat.com Thu Mar 29 13:04:22 2018 From: belaran at redhat.com (Romain Pelisse) Date: Thu, 29 Mar 2018 19:04:22 +0200 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: IMHO, having an issue assigned by default by somebody is missing leading. It give the feeling the issue is being worked on or at least acknowledge while often the assignee, in fact, never looked at it. If the issue is not assigned, at least you know it's not assigned. If there many issues not assigned, it's not (to me) a problem and it is a better state than having hundred of issue supposedly assigned to somebody who never looked at it. On Thu, Mar 29, 2018 at 5:15 PM, David Lloyd wrote: > There's nothing stopping leads (or others) from commenting on issues > with questions and/or more information, also. I'm more inclined to do > that when I look at an issue and think "this isn't assigned to me, so > I better make a note for whoever works the issue instead of just > writing it on a forgotten notepad somewhere". Even if it ends up > being me, it's helpful. > > On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry > wrote: > > I'm in favor of this change. > > > > I think in most cases it's important for people to communicate with > > component leads before they start doing much on an issue. But having the > > issued assigned to the lead hasn't AFAICT help ensure that kind of > > communication. > > > > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller > wrote: > >> > >> Good points. The issue has always been getting component leads to > triage > >> their issues on a regular enough basis. > >> > >> If this is just hiding that problem, and causing issues with community > >> involvement, I am all for going back to unassigned. > >> > >> Andy > >> > >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd > >> wrote: > >>> > >>> Speaking for myself, I'd rather have issues unassigned because having > >>> it assigned means "do not work on this; someone else is going to". > >>> Then they just sit like that, maybe for years. > >>> > >>> I think having a default assignee is hiding the symptom while at the > >>> same time discouraging volunteers from taking issues. It's even worse > >>> now that we have multiple teams within Red Hat itself who want to work > >>> issues. I often get emails like "I see that WFLY-xxx is assigned to > >>> you; is it OK if I take it?" For every one of these, there may be > >>> several (internal or external) where they just give up because the > >>> issue is "assigned", and they just wait forever for someone to deliver > >>> the fix/feature for them. > >>> > >>> We see every issue as they are created. If we don't take an issue at > >>> that time, being honest, are we really ever going to do it? > >>> > >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller > >>> wrote: > >>> > This is the way it was a long time ago, and then we moved to default > to > >>> > the > >>> > component lead because so many issues were being left in the > unassigned > >>> > state. > >>> > > >>> > Perhaps the default assignment just makes thing "look" better, and > >>> > doesn't > >>> > force triage to occur, or perhaps it does? > >>> > > >>> > I think we just think about this a little more, since we made the > >>> > change > >>> > because of such a mountain of issues being in the unassigned state. > >>> > > >>> > Andy > >>> > > >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd > > >>> > wrote: > >>> >> > >>> >> This is something we've talked about before. I think we should move > >>> >> forward on this for the WFLY and WFCORE projects. > >>> >> > >>> >> Ideally we'd also have a "responsible person" field which would be > >>> >> populated by the component lead by default. But I don't think this > is > >>> >> necessary as long as our component leads are triaging issues in > their > >>> >> areas (which they should be). > >>> >> > >>> >> I think we should just do it. WDYT? > >>> >> > >>> >> -- > >>> >> - DML > >>> >> _______________________________________________ > >>> >> wildfly-dev mailing list > >>> >> wildfly-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Andrig (Andy) T. Miller > >>> > Global Platform Director, Middleware > >>> > Red Hat, Inc. > >>> > >>> > >>> > >>> -- > >>> - DML > >> > >> > >> > >> > >> -- > >> Andrig (Andy) T. Miller > >> Global Platform Director, Middleware > >> Red Hat, Inc. > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > > > -- > - DML > _______________________________________________ > 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/20180329/853fb825/attachment-0001.html From rsvoboda at redhat.com Thu Mar 29 13:28:18 2018 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Thu, 29 Mar 2018 19:28:18 +0200 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: When the default is gonna be unassigned for WFLY and WFCORE, following pages should get better visibility: - https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page - https://issues.jboss.org/projects/WFCORE?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Reason is to have easy way how to identify component owner when there is lack of activity on the issue. Rostislav On Thu, Mar 29, 2018 at 5:15 PM, David Lloyd wrote: > There's nothing stopping leads (or others) from commenting on issues > with questions and/or more information, also. I'm more inclined to do > that when I look at an issue and think "this isn't assigned to me, so > I better make a note for whoever works the issue instead of just > writing it on a forgotten notepad somewhere". Even if it ends up > being me, it's helpful. > > On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry > wrote: > > I'm in favor of this change. > > > > I think in most cases it's important for people to communicate with > > component leads before they start doing much on an issue. But having the > > issued assigned to the lead hasn't AFAICT help ensure that kind of > > communication. > > > > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller > wrote: > >> > >> Good points. The issue has always been getting component leads to > triage > >> their issues on a regular enough basis. > >> > >> If this is just hiding that problem, and causing issues with community > >> involvement, I am all for going back to unassigned. > >> > >> Andy > >> > >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd > >> wrote: > >>> > >>> Speaking for myself, I'd rather have issues unassigned because having > >>> it assigned means "do not work on this; someone else is going to". > >>> Then they just sit like that, maybe for years. > >>> > >>> I think having a default assignee is hiding the symptom while at the > >>> same time discouraging volunteers from taking issues. It's even worse > >>> now that we have multiple teams within Red Hat itself who want to work > >>> issues. I often get emails like "I see that WFLY-xxx is assigned to > >>> you; is it OK if I take it?" For every one of these, there may be > >>> several (internal or external) where they just give up because the > >>> issue is "assigned", and they just wait forever for someone to deliver > >>> the fix/feature for them. > >>> > >>> We see every issue as they are created. If we don't take an issue at > >>> that time, being honest, are we really ever going to do it? > >>> > >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller > >>> wrote: > >>> > This is the way it was a long time ago, and then we moved to default > to > >>> > the > >>> > component lead because so many issues were being left in the > unassigned > >>> > state. > >>> > > >>> > Perhaps the default assignment just makes thing "look" better, and > >>> > doesn't > >>> > force triage to occur, or perhaps it does? > >>> > > >>> > I think we just think about this a little more, since we made the > >>> > change > >>> > because of such a mountain of issues being in the unassigned state. > >>> > > >>> > Andy > >>> > > >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd > > >>> > wrote: > >>> >> > >>> >> This is something we've talked about before. I think we should move > >>> >> forward on this for the WFLY and WFCORE projects. > >>> >> > >>> >> Ideally we'd also have a "responsible person" field which would be > >>> >> populated by the component lead by default. But I don't think this > is > >>> >> necessary as long as our component leads are triaging issues in > their > >>> >> areas (which they should be). > >>> >> > >>> >> I think we should just do it. WDYT? > >>> >> > >>> >> -- > >>> >> - DML > >>> >> _______________________________________________ > >>> >> wildfly-dev mailing list > >>> >> wildfly-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Andrig (Andy) T. Miller > >>> > Global Platform Director, Middleware > >>> > Red Hat, Inc. > >>> > >>> > >>> > >>> -- > >>> - DML > >> > >> > >> > >> > >> -- > >> Andrig (Andy) T. Miller > >> Global Platform Director, Middleware > >> Red Hat, Inc. > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > > > -- > - DML > _______________________________________________ > 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/20180329/bfcf1fe7/attachment.html From steve at hibernate.org Thu Mar 29 13:54:31 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 29 Mar 2018 17:54:31 +0000 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: If triaging is a big concern, keeping the default assignee is one way to help make sure the triage happens (supposing it does now). Just because something is default assigned to you does not mean it has to stay that way - triage it and re-assign, un-assign, reject, etc On Thu, Mar 29, 2018 at 12:35 PM Rostislav Svoboda wrote: > When the default is gonna be unassigned for WFLY and WFCORE, following > pages should get better visibility: > > - > https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > - > https://issues.jboss.org/projects/WFCORE?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > > Reason is to have easy way how to identify component owner when there is > lack of activity on the issue. > > Rostislav > On Thu, Mar 29, 2018 at 5:15 PM, David Lloyd > wrote: > >> There's nothing stopping leads (or others) from commenting on issues >> with questions and/or more information, also. I'm more inclined to do >> that when I look at an issue and think "this isn't assigned to me, so >> I better make a note for whoever works the issue instead of just >> writing it on a forgotten notepad somewhere". Even if it ends up >> being me, it's helpful. >> >> On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry >> wrote: >> > I'm in favor of this change. >> > >> > I think in most cases it's important for people to communicate with >> > component leads before they start doing much on an issue. But having the >> > issued assigned to the lead hasn't AFAICT help ensure that kind of >> > communication. >> > >> > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller >> wrote: >> >> >> >> Good points. The issue has always been getting component leads to >> triage >> >> their issues on a regular enough basis. >> >> >> >> If this is just hiding that problem, and causing issues with community >> >> involvement, I am all for going back to unassigned. >> >> >> >> Andy >> >> >> >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd >> >> wrote: >> >>> >> >>> Speaking for myself, I'd rather have issues unassigned because having >> >>> it assigned means "do not work on this; someone else is going to". >> >>> Then they just sit like that, maybe for years. >> >>> >> >>> I think having a default assignee is hiding the symptom while at the >> >>> same time discouraging volunteers from taking issues. It's even worse >> >>> now that we have multiple teams within Red Hat itself who want to work >> >>> issues. I often get emails like "I see that WFLY-xxx is assigned to >> >>> you; is it OK if I take it?" For every one of these, there may be >> >>> several (internal or external) where they just give up because the >> >>> issue is "assigned", and they just wait forever for someone to deliver >> >>> the fix/feature for them. >> >>> >> >>> We see every issue as they are created. If we don't take an issue at >> >>> that time, being honest, are we really ever going to do it? >> >>> >> >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller >> >>> wrote: >> >>> > This is the way it was a long time ago, and then we moved to >> default to >> >>> > the >> >>> > component lead because so many issues were being left in the >> unassigned >> >>> > state. >> >>> > >> >>> > Perhaps the default assignment just makes thing "look" better, and >> >>> > doesn't >> >>> > force triage to occur, or perhaps it does? >> >>> > >> >>> > I think we just think about this a little more, since we made the >> >>> > change >> >>> > because of such a mountain of issues being in the unassigned state. >> >>> > >> >>> > Andy >> >>> > >> >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd < >> david.lloyd at redhat.com> >> >>> > wrote: >> >>> >> >> >>> >> This is something we've talked about before. I think we should >> move >> >>> >> forward on this for the WFLY and WFCORE projects. >> >>> >> >> >>> >> Ideally we'd also have a "responsible person" field which would be >> >>> >> populated by the component lead by default. But I don't think >> this is >> >>> >> necessary as long as our component leads are triaging issues in >> their >> >>> >> areas (which they should be). >> >>> >> >> >>> >> I think we should just do it. WDYT? >> >>> >> >> >>> >> -- >> >>> >> - DML >> >>> >> _______________________________________________ >> >>> >> wildfly-dev mailing list >> >>> >> wildfly-dev at lists.jboss.org >> >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Andrig (Andy) T. Miller >> >>> > Global Platform Director, Middleware >> >>> > Red Hat, Inc. >> >>> >> >>> >> >>> >> >>> -- >> >>> - DML >> >> >> >> >> >> >> >> >> >> -- >> >> Andrig (Andy) T. Miller >> >> Global Platform Director, Middleware >> >> Red Hat, Inc. >> >> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> > >> > -- >> > Brian Stansberry >> > Manager, Senior Principal Software Engineer >> > Red Hat >> >> >> >> -- >> - DML >> _______________________________________________ >> 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/20180329/ad0795c0/attachment-0001.html From kkhan at redhat.com Fri Mar 30 06:54:58 2018 From: kkhan at redhat.com (Kabir Khan) Date: Fri, 30 Mar 2018 11:54:58 +0100 Subject: [wildfly-dev] JIRA: Proposal to make default assignee "Unassigned" for all areas In-Reply-To: References: Message-ID: Isn't this configurable on a component by component basis anyway? So if we make the default unassigned across the board, if a component lead prefers having issues assigned to them I think they can still do so. > On 29 Mar 2018, at 18:54, Steve Ebersole wrote: > > If triaging is a big concern, keeping the default assignee is one way to help make sure the triage happens (supposing it does now). Just because something is default assigned to you does not mean it has to stay that way - triage it and re-assign, un-assign, reject, etc > > On Thu, Mar 29, 2018 at 12:35 PM Rostislav Svoboda wrote: > When the default is gonna be unassigned for WFLY and WFCORE, following pages should get better visibility: > > - https://issues.jboss.org/projects/WFLY?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > - https://issues.jboss.org/projects/WFCORE?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page > > Reason is to have easy way how to identify component owner when there is lack of activity on the issue. > > Rostislav > On Thu, Mar 29, 2018 at 5:15 PM, David Lloyd wrote: > There's nothing stopping leads (or others) from commenting on issues > with questions and/or more information, also. I'm more inclined to do > that when I look at an issue and think "this isn't assigned to me, so > I better make a note for whoever works the issue instead of just > writing it on a forgotten notepad somewhere". Even if it ends up > being me, it's helpful. > > On Thu, Mar 29, 2018 at 9:58 AM, Brian Stansberry > wrote: > > I'm in favor of this change. > > > > I think in most cases it's important for people to communicate with > > component leads before they start doing much on an issue. But having the > > issued assigned to the lead hasn't AFAICT help ensure that kind of > > communication. > > > > On Thu, Mar 29, 2018 at 9:41 AM, Andrig Miller wrote: > >> > >> Good points. The issue has always been getting component leads to triage > >> their issues on a regular enough basis. > >> > >> If this is just hiding that problem, and causing issues with community > >> involvement, I am all for going back to unassigned. > >> > >> Andy > >> > >> On Thu, Mar 29, 2018 at 8:39 AM, David Lloyd > >> wrote: > >>> > >>> Speaking for myself, I'd rather have issues unassigned because having > >>> it assigned means "do not work on this; someone else is going to". > >>> Then they just sit like that, maybe for years. > >>> > >>> I think having a default assignee is hiding the symptom while at the > >>> same time discouraging volunteers from taking issues. It's even worse > >>> now that we have multiple teams within Red Hat itself who want to work > >>> issues. I often get emails like "I see that WFLY-xxx is assigned to > >>> you; is it OK if I take it?" For every one of these, there may be > >>> several (internal or external) where they just give up because the > >>> issue is "assigned", and they just wait forever for someone to deliver > >>> the fix/feature for them. > >>> > >>> We see every issue as they are created. If we don't take an issue at > >>> that time, being honest, are we really ever going to do it? > >>> > >>> On Thu, Mar 29, 2018 at 9:28 AM, Andrig Miller > >>> wrote: > >>> > This is the way it was a long time ago, and then we moved to default to > >>> > the > >>> > component lead because so many issues were being left in the unassigned > >>> > state. > >>> > > >>> > Perhaps the default assignment just makes thing "look" better, and > >>> > doesn't > >>> > force triage to occur, or perhaps it does? > >>> > > >>> > I think we just think about this a little more, since we made the > >>> > change > >>> > because of such a mountain of issues being in the unassigned state. > >>> > > >>> > Andy > >>> > > >>> > On Thu, Mar 29, 2018 at 8:20 AM, David Lloyd > >>> > wrote: > >>> >> > >>> >> This is something we've talked about before. I think we should move > >>> >> forward on this for the WFLY and WFCORE projects. > >>> >> > >>> >> Ideally we'd also have a "responsible person" field which would be > >>> >> populated by the component lead by default. But I don't think this is > >>> >> necessary as long as our component leads are triaging issues in their > >>> >> areas (which they should be). > >>> >> > >>> >> I think we should just do it. WDYT? > >>> >> > >>> >> -- > >>> >> - DML > >>> >> _______________________________________________ > >>> >> wildfly-dev mailing list > >>> >> wildfly-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > Andrig (Andy) T. Miller > >>> > Global Platform Director, Middleware > >>> > Red Hat, Inc. > >>> > >>> > >>> > >>> -- > >>> - DML > >> > >> > >> > >> > >> -- > >> Andrig (Andy) T. Miller > >> Global Platform Director, Middleware > >> Red Hat, Inc. > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > > > -- > - DML > _______________________________________________ > 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