From stuart.w.douglas at gmail.com Mon Apr 2 21:15:58 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 3 Apr 2018 11:15:58 +1000 Subject: [wildfly-dev] JSF and JSP activation Message-ID: Hi Everyone, At the moment JSP and JSF are being activated for all web deployments, which is relatively expensive as this involves quite a bit of class loading and TLD parsing. To give an idea about how much time this is actually taking I did a test with a large number of small servlet only deployments both with and without JSF, and JSF was accounting for 20% of total deployment time even though it was not actually used by any of the deployments. It also had a significant effect on memory usage, as the parsed TLD's are retained, and are quite large. The root of this issue is that the spec does not define clear activation criteria for these technologies. I am proposing that we formalise some activation criteria, so that we can avoid activating them if they are not required. JSP: For JSP I think we can use the following criteria (if either one is satisfied JSP is activated): - The presence of a JSP file mapping in web.xml - The presence of JSP files inside the deployment - The presence of JSF One thing that does concern me is that searching for JSP files in this way may be expensive in large deployments with lots of web resources. An alternate approach may be to try and make JSP lazy, so class loading and TLD passing does not happen until a request for a JSP file arrives. JSF: This is much less clear. I think we can use the presence of one of the following: - faces-config.xml - The faces servlet in web.xml - Something else? I am not really sure what effect this will have on backwards compatibility though. If this is a compatibility problem we could add an attribute to the JSF subsystem to restore the old mode. Does this sound reasonable? Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180403/56261895/attachment.html From anmiller at redhat.com Tue Apr 3 00:55:20 2018 From: anmiller at redhat.com (Andrig Miller) Date: Mon, 2 Apr 2018 22:55:20 -0600 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: >From the performance team perspective we would love to have this activated only if there is a deployment that needs them, that's for sure. JSF, Mojarra in particular, has lots of memory problems besides the initialization too, but that's another story that we will start discussing soon. This would help our Metaspace memory issues, and we should definitely do this. Andy On Mon, Apr 2, 2018 at 7:15 PM, Stuart Douglas wrote: > Hi Everyone, > > At the moment JSP and JSF are being activated for all web deployments, > which is relatively expensive as this involves quite a bit of class loading > and TLD parsing. > > To give an idea about how much time this is actually taking I did a test > with a large number of small servlet only deployments both with and without > JSF, and JSF was accounting for 20% of total deployment time even though it > was not actually used by any of the deployments. > > It also had a significant effect on memory usage, as the parsed TLD's are > retained, and are quite large. > > The root of this issue is that the spec does not define clear activation > criteria for these technologies. I am proposing that we formalise some > activation criteria, so that we can avoid activating them if they are not > required. > > JSP: > > For JSP I think we can use the following criteria (if either one is > satisfied JSP is activated): > > - The presence of a JSP file mapping in web.xml > - The presence of JSP files inside the deployment > - The presence of JSF > > One thing that does concern me is that searching for JSP files in this way > may be expensive in large deployments with lots of web resources. An > alternate approach may be to try and make JSP lazy, so class loading and > TLD passing does not happen until a request for a JSP file arrives. > > > JSF: > > This is much less clear. I think we can use the presence of one of the > following: > > - faces-config.xml > - The faces servlet in web.xml > - Something else? > > I am not really sure what effect this will have on backwards compatibility > though. If this is a compatibility problem we could add an attribute to the > JSF subsystem to restore the old mode. > > > Does this sound reasonable? > > Stuart > > > > > > _______________________________________________ > 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/20180402/adaed6d4/attachment.html From z06.guillermo at gmail.com Tue Apr 3 01:50:01 2018 From: z06.guillermo at gmail.com (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero?=) Date: Tue, 03 Apr 2018 05:50:01 +0000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: This would be great to have! As for JSF activation, note that faces-config.xml nor Faces Servlet are required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 which substitutes faces-config. Looking at FacesConfigInitializer class[1] might provide some more insight. I've always been puzzled with the "Initializing Mojarra" log when deploying a JAX-RS only app. The mentioned class supposedly should prevent JSF from unnecessary initializing. Perhaps some work could be done there which helps also other runtimes? Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan Tijms since he's the expert on this stuff. Regards, Guillermo Gonz?lez de Ag?ero [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java El mar., 3 abr. 2018 a las 3:16, Stuart Douglas () escribi?: > Hi Everyone, > > At the moment JSP and JSF are being activated for all web deployments, > which is relatively expensive as this involves quite a bit of class loading > and TLD parsing. > > To give an idea about how much time this is actually taking I did a test > with a large number of small servlet only deployments both with and without > JSF, and JSF was accounting for 20% of total deployment time even though it > was not actually used by any of the deployments. > > It also had a significant effect on memory usage, as the parsed TLD's are > retained, and are quite large. > > The root of this issue is that the spec does not define clear activation > criteria for these technologies. I am proposing that we formalise some > activation criteria, so that we can avoid activating them if they are not > required. > > JSP: > > For JSP I think we can use the following criteria (if either one is > satisfied JSP is activated): > > - The presence of a JSP file mapping in web.xml > - The presence of JSP files inside the deployment > - The presence of JSF > > One thing that does concern me is that searching for JSP files in this way > may be expensive in large deployments with lots of web resources. An > alternate approach may be to try and make JSP lazy, so class loading and > TLD passing does not happen until a request for a JSP file arrives. > > > JSF: > > This is much less clear. I think we can use the presence of one of the > following: > > - faces-config.xml > - The faces servlet in web.xml > - Something else? > > I am not really sure what effect this will have on backwards compatibility > though. If this is a compatibility problem we could add an attribute to the > JSF subsystem to restore the old mode. > > > Does this sound reasonable? > > Stuart > > > > > _______________________________________________ > 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/20180403/1c3facde/attachment-0001.html From stuart.w.douglas at gmail.com Tue Apr 3 03:24:21 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 3 Apr 2018 17:24:21 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Looking at that class it seems like the intention is clearly for JSF to only be activated if there is a faces-config.xml, a Servlet mapping or JSF annotations. Should be pretty easy for us to duplicate this logic in a DUP and avoid all the parsing and class loading. Stuart On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < z06.guillermo at gmail.com> wrote: > This would be great to have! > > As for JSF activation, note that faces-config.xml nor Faces Servlet are > required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 > which substitutes faces-config. > > Looking at FacesConfigInitializer class[1] might provide some more > insight. I've always been puzzled with the "Initializing Mojarra" log when > deploying a JAX-RS only app. The mentioned class supposedly should prevent > JSF from unnecessary initializing. Perhaps some work could be done there > which helps also other runtimes? > > Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan > Tijms since he's the expert on this stuff. > > > Regards, > > Guillermo Gonz?lez de Ag?ero > > [1] https://github.com/javaserverfaces/mojarra/blob/ > 4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/ > com/sun/faces/config/FacesInitializer.java > > El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< > stuart.w.douglas at gmail.com>) escribi?: > >> Hi Everyone, >> >> At the moment JSP and JSF are being activated for all web deployments, >> which is relatively expensive as this involves quite a bit of class loading >> and TLD parsing. >> >> To give an idea about how much time this is actually taking I did a test >> with a large number of small servlet only deployments both with and without >> JSF, and JSF was accounting for 20% of total deployment time even though it >> was not actually used by any of the deployments. >> >> It also had a significant effect on memory usage, as the parsed TLD's are >> retained, and are quite large. >> >> The root of this issue is that the spec does not define clear activation >> criteria for these technologies. I am proposing that we formalise some >> activation criteria, so that we can avoid activating them if they are not >> required. >> >> JSP: >> >> For JSP I think we can use the following criteria (if either one is >> satisfied JSP is activated): >> >> - The presence of a JSP file mapping in web.xml >> - The presence of JSP files inside the deployment >> - The presence of JSF >> >> One thing that does concern me is that searching for JSP files in this >> way may be expensive in large deployments with lots of web resources. An >> alternate approach may be to try and make JSP lazy, so class loading and >> TLD passing does not happen until a request for a JSP file arrives. >> >> >> JSF: >> >> This is much less clear. I think we can use the presence of one of the >> following: >> >> - faces-config.xml >> - The faces servlet in web.xml >> - Something else? >> >> I am not really sure what effect this will have on backwards >> compatibility though. If this is a compatibility problem we could add an >> attribute to the JSF subsystem to restore the old mode. >> >> >> Does this sound reasonable? >> >> Stuart >> >> >> >> >> _______________________________________________ >> 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/20180403/27a55a22/attachment.html From stuart.w.douglas at gmail.com Tue Apr 3 04:04:47 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 3 Apr 2018 18:04:47 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: I have done up a quick PR to support this (not really tested yet, so it might fail :-)) https://github.com/wildfly/wildfly/pull/11082 . I only tested this out against the 'kitchensink' and 'kitchensink-angularjs' quickstarts, and these appeared to work as expected. It also seemed to reduce boot time by ~400ms for the angularjs version (although I did not do any scientific testing). JSP is a bit harder, I need to think a bit more about exactly what this will entail. Stuart On Tue, Apr 3, 2018 at 5:24 PM, Stuart Douglas wrote: > Looking at that class it seems like the intention is clearly for JSF to > only be activated if there is a faces-config.xml, a Servlet mapping or JSF > annotations. > > Should be pretty easy for us to duplicate this logic in a DUP and avoid > all the parsing and class loading. > > Stuart > > On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> This would be great to have! >> >> As for JSF activation, note that faces-config.xml nor Faces Servlet are >> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >> which substitutes faces-config. >> >> Looking at FacesConfigInitializer class[1] might provide some more >> insight. I've always been puzzled with the "Initializing Mojarra" log when >> deploying a JAX-RS only app. The mentioned class supposedly should prevent >> JSF from unnecessary initializing. Perhaps some work could be done there >> which helps also other runtimes? >> >> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >> Tijms since he's the expert on this stuff. >> >> >> Regards, >> >> Guillermo Gonz?lez de Ag?ero >> >> [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5 >> a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/ >> faces/config/FacesInitializer.java >> >> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >> stuart.w.douglas at gmail.com>) escribi?: >> >>> Hi Everyone, >>> >>> At the moment JSP and JSF are being activated for all web deployments, >>> which is relatively expensive as this involves quite a bit of class loading >>> and TLD parsing. >>> >>> To give an idea about how much time this is actually taking I did a test >>> with a large number of small servlet only deployments both with and without >>> JSF, and JSF was accounting for 20% of total deployment time even though it >>> was not actually used by any of the deployments. >>> >>> It also had a significant effect on memory usage, as the parsed TLD's >>> are retained, and are quite large. >>> >>> The root of this issue is that the spec does not define clear activation >>> criteria for these technologies. I am proposing that we formalise some >>> activation criteria, so that we can avoid activating them if they are not >>> required. >>> >>> JSP: >>> >>> For JSP I think we can use the following criteria (if either one is >>> satisfied JSP is activated): >>> >>> - The presence of a JSP file mapping in web.xml >>> - The presence of JSP files inside the deployment >>> - The presence of JSF >>> >>> One thing that does concern me is that searching for JSP files in this >>> way may be expensive in large deployments with lots of web resources. An >>> alternate approach may be to try and make JSP lazy, so class loading and >>> TLD passing does not happen until a request for a JSP file arrives. >>> >>> >>> JSF: >>> >>> This is much less clear. I think we can use the presence of one of the >>> following: >>> >>> - faces-config.xml >>> - The faces servlet in web.xml >>> - Something else? >>> >>> I am not really sure what effect this will have on backwards >>> compatibility though. If this is a compatibility problem we could add an >>> attribute to the JSF subsystem to restore the old mode. >>> >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20180403/6050db97/attachment.html From z06.guillermo at gmail.com Tue Apr 3 04:57:18 2018 From: z06.guillermo at gmail.com (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero?=) Date: Tue, 03 Apr 2018 08:57:18 +0000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: But it should also checks for the existence of JSF classes, like Component. Having them on the classpath enabls JSF, so a classpath scan seems (unfortunately) needed to me. I imagine the received set of classes will contain the JSF implementation from the server modules, which implicitly enables JSF in the end. El mar., 3 abr. 2018 9:24, Stuart Douglas escribi?: > Looking at that class it seems like the intention is clearly for JSF to > only be activated if there is a faces-config.xml, a Servlet mapping or JSF > annotations. > > Should be pretty easy for us to duplicate this logic in a DUP and avoid > all the parsing and class loading. > > Stuart > > On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> This would be great to have! >> >> As for JSF activation, note that faces-config.xml nor Faces Servlet are >> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >> which substitutes faces-config. >> >> Looking at FacesConfigInitializer class[1] might provide some more >> insight. I've always been puzzled with the "Initializing Mojarra" log when >> deploying a JAX-RS only app. The mentioned class supposedly should prevent >> JSF from unnecessary initializing. Perhaps some work could be done there >> which helps also other runtimes? >> >> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >> Tijms since he's the expert on this stuff. >> >> >> Regards, >> >> Guillermo Gonz?lez de Ag?ero >> >> [1] >> https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java >> >> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >> stuart.w.douglas at gmail.com>) escribi?: >> >>> Hi Everyone, >>> >>> At the moment JSP and JSF are being activated for all web deployments, >>> which is relatively expensive as this involves quite a bit of class loading >>> and TLD parsing. >>> >>> To give an idea about how much time this is actually taking I did a test >>> with a large number of small servlet only deployments both with and without >>> JSF, and JSF was accounting for 20% of total deployment time even though it >>> was not actually used by any of the deployments. >>> >>> It also had a significant effect on memory usage, as the parsed TLD's >>> are retained, and are quite large. >>> >>> The root of this issue is that the spec does not define clear activation >>> criteria for these technologies. I am proposing that we formalise some >>> activation criteria, so that we can avoid activating them if they are not >>> required. >>> >>> JSP: >>> >>> For JSP I think we can use the following criteria (if either one is >>> satisfied JSP is activated): >>> >>> - The presence of a JSP file mapping in web.xml >>> - The presence of JSP files inside the deployment >>> - The presence of JSF >>> >>> One thing that does concern me is that searching for JSP files in this >>> way may be expensive in large deployments with lots of web resources. An >>> alternate approach may be to try and make JSP lazy, so class loading and >>> TLD passing does not happen until a request for a JSP file arrives. >>> >>> >>> JSF: >>> >>> This is much less clear. I think we can use the presence of one of the >>> following: >>> >>> - faces-config.xml >>> - The faces servlet in web.xml >>> - Something else? >>> >>> I am not really sure what effect this will have on backwards >>> compatibility though. If this is a compatibility problem we could add an >>> attribute to the JSF subsystem to restore the old mode. >>> >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20180403/502e62d1/attachment-0001.html From stuart.w.douglas at gmail.com Tue Apr 3 06:23:12 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 3 Apr 2018 20:23:12 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: My patch already checks for UIComponent, which is all the FacesInitializer does. It only checks deployment classes, there would be no point checking the faces implementation or it would activate every time. Stuart On Tue, Apr 3, 2018 at 6:57 PM, Guillermo Gonz?lez de Ag?ero < z06.guillermo at gmail.com> wrote: > But it should also checks for the existence of JSF classes, like > Component. Having them on the classpath enabls JSF, so a classpath scan > seems (unfortunately) needed to me. > > I imagine the received set of classes will contain the JSF implementation > from the server modules, which implicitly enables JSF in the end. > > El mar., 3 abr. 2018 9:24, Stuart Douglas > escribi?: > >> Looking at that class it seems like the intention is clearly for JSF to >> only be activated if there is a faces-config.xml, a Servlet mapping or JSF >> annotations. >> >> Should be pretty easy for us to duplicate this logic in a DUP and avoid >> all the parsing and class loading. >> >> Stuart >> >> On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < >> z06.guillermo at gmail.com> wrote: >> >>> This would be great to have! >>> >>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>> which substitutes faces-config. >>> >>> Looking at FacesConfigInitializer class[1] might provide some more >>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>> JSF from unnecessary initializing. Perhaps some work could be done there >>> which helps also other runtimes? >>> >>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>> Tijms since he's the expert on this stuff. >>> >>> >>> Regards, >>> >>> Guillermo Gonz?lez de Ag?ero >>> >>> [1] https://github.com/javaserverfaces/mojarra/blob/ >>> 4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/ >>> com/sun/faces/config/FacesInitializer.java >>> >>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>> stuart.w.douglas at gmail.com>) escribi?: >>> >>>> Hi Everyone, >>>> >>>> At the moment JSP and JSF are being activated for all web deployments, >>>> which is relatively expensive as this involves quite a bit of class loading >>>> and TLD parsing. >>>> >>>> To give an idea about how much time this is actually taking I did a >>>> test with a large number of small servlet only deployments both with and >>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>> though it was not actually used by any of the deployments. >>>> >>>> It also had a significant effect on memory usage, as the parsed TLD's >>>> are retained, and are quite large. >>>> >>>> The root of this issue is that the spec does not define clear >>>> activation criteria for these technologies. I am proposing that we >>>> formalise some activation criteria, so that we can avoid activating them if >>>> they are not required. >>>> >>>> JSP: >>>> >>>> For JSP I think we can use the following criteria (if either one is >>>> satisfied JSP is activated): >>>> >>>> - The presence of a JSP file mapping in web.xml >>>> - The presence of JSP files inside the deployment >>>> - The presence of JSF >>>> >>>> One thing that does concern me is that searching for JSP files in this >>>> way may be expensive in large deployments with lots of web resources. An >>>> alternate approach may be to try and make JSP lazy, so class loading and >>>> TLD passing does not happen until a request for a JSP file arrives. >>>> >>>> >>>> JSF: >>>> >>>> This is much less clear. I think we can use the presence of one of the >>>> following: >>>> >>>> - faces-config.xml >>>> - The faces servlet in web.xml >>>> - Something else? >>>> >>>> I am not really sure what effect this will have on backwards >>>> compatibility though. If this is a compatibility problem we could add an >>>> attribute to the JSF subsystem to restore the old mode. >>>> >>>> >>>> Does this sound reasonable? >>>> >>>> Stuart >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20180403/67ec0279/attachment.html From stuart.w.douglas at gmail.com Tue Apr 3 07:31:38 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 3 Apr 2018 21:31:38 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: I just did a quick hack that also avoids JSP taglib parsing, and tested it out on the kitchensink-angularjs example. As well as starting several hundred ms quicker according to YJP it also had the following reductions (with standalone.xml): Heap: 2mb Code Cache: 1mb Metaspace: 1mb Tomorrow I will have a look at a proper way of avoiding TLD parsing if JSP is not in use. Stuart On Tue, Apr 3, 2018 at 8:23 PM, Stuart Douglas wrote: > My patch already checks for UIComponent, which is all the FacesInitializer > does. It only checks deployment classes, there would be no point checking > the faces implementation or it would activate every time. > > Stuart > > On Tue, Apr 3, 2018 at 6:57 PM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> But it should also checks for the existence of JSF classes, like >> Component. Having them on the classpath enabls JSF, so a classpath scan >> seems (unfortunately) needed to me. >> >> I imagine the received set of classes will contain the JSF implementation >> from the server modules, which implicitly enables JSF in the end. >> >> El mar., 3 abr. 2018 9:24, Stuart Douglas >> escribi?: >> >>> Looking at that class it seems like the intention is clearly for JSF to >>> only be activated if there is a faces-config.xml, a Servlet mapping or JSF >>> annotations. >>> >>> Should be pretty easy for us to duplicate this logic in a DUP and avoid >>> all the parsing and class loading. >>> >>> Stuart >>> >>> On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < >>> z06.guillermo at gmail.com> wrote: >>> >>>> This would be great to have! >>>> >>>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>>> which substitutes faces-config. >>>> >>>> Looking at FacesConfigInitializer class[1] might provide some more >>>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>>> JSF from unnecessary initializing. Perhaps some work could be done there >>>> which helps also other runtimes? >>>> >>>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>>> Tijms since he's the expert on this stuff. >>>> >>>> >>>> Regards, >>>> >>>> Guillermo Gonz?lez de Ag?ero >>>> >>>> [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5 >>>> a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/ >>>> faces/config/FacesInitializer.java >>>> >>>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>>> stuart.w.douglas at gmail.com>) escribi?: >>>> >>>>> Hi Everyone, >>>>> >>>>> At the moment JSP and JSF are being activated for all web deployments, >>>>> which is relatively expensive as this involves quite a bit of class loading >>>>> and TLD parsing. >>>>> >>>>> To give an idea about how much time this is actually taking I did a >>>>> test with a large number of small servlet only deployments both with and >>>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>>> though it was not actually used by any of the deployments. >>>>> >>>>> It also had a significant effect on memory usage, as the parsed TLD's >>>>> are retained, and are quite large. >>>>> >>>>> The root of this issue is that the spec does not define clear >>>>> activation criteria for these technologies. I am proposing that we >>>>> formalise some activation criteria, so that we can avoid activating them if >>>>> they are not required. >>>>> >>>>> JSP: >>>>> >>>>> For JSP I think we can use the following criteria (if either one is >>>>> satisfied JSP is activated): >>>>> >>>>> - The presence of a JSP file mapping in web.xml >>>>> - The presence of JSP files inside the deployment >>>>> - The presence of JSF >>>>> >>>>> One thing that does concern me is that searching for JSP files in this >>>>> way may be expensive in large deployments with lots of web resources. An >>>>> alternate approach may be to try and make JSP lazy, so class loading and >>>>> TLD passing does not happen until a request for a JSP file arrives. >>>>> >>>>> >>>>> JSF: >>>>> >>>>> This is much less clear. I think we can use the presence of one of the >>>>> following: >>>>> >>>>> - faces-config.xml >>>>> - The faces servlet in web.xml >>>>> - Something else? >>>>> >>>>> I am not really sure what effect this will have on backwards >>>>> compatibility though. If this is a compatibility problem we could add an >>>>> attribute to the JSF subsystem to restore the old mode. >>>>> >>>>> >>>>> Does this sound reasonable? >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20180403/4ad57c9c/attachment-0001.html From arjan.tijms at gmail.com Tue Apr 3 08:36:54 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 3 Apr 2018 14:36:54 +0200 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Hi, I'm already on this list indeed ;) Indeed, the FacesInitizalizer only does these two things unconditionally: boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes, servletContext); boolean appHasFacesServlet = getExistingFacesServletRegistration(servletContext) != null; As can be seen from the code, it looks at the classes provided by the Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean annotated with @FacesConfig (which is a single CDI lookup). Note though that WildFly is using a somewhat older Mojarra release, so the code is a bit different in WildFly, although not that much. So if the application is not actually using JSF, that's all it does. And there should not be any additional overhead. If the application does use JSF indeed, there's overhead and that's indeed too much overhead. I've been trying on reducing this, for instance by using a pre-parsed internal faces-config file. See specifically this commit: https://github.com/javaserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a @Stuart, I wonder what the overhead is that you see when the application is not using JSF, and which test application you are actually using. Could it be that you somehow have a FacesServlet or faces-config.xml etc anyway? Kind regards, Arjan On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < z06.guillermo at gmail.com> wrote: > This would be great to have! > > As for JSF activation, note that faces-config.xml nor Faces Servlet are > required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 > which substitutes faces-config. > > Looking at FacesConfigInitializer class[1] might provide some more > insight. I've always been puzzled with the "Initializing Mojarra" log when > deploying a JAX-RS only app. The mentioned class supposedly should prevent > JSF from unnecessary initializing. Perhaps some work could be done there > which helps also other runtimes? > > Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan > Tijms since he's the expert on this stuff. > > > Regards, > > Guillermo Gonz?lez de Ag?ero > > [1] https://github.com/javaserverfaces/mojarra/blob/ > 4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/ > com/sun/faces/config/FacesInitializer.java > > El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< > stuart.w.douglas at gmail.com>) escribi?: > >> Hi Everyone, >> >> At the moment JSP and JSF are being activated for all web deployments, >> which is relatively expensive as this involves quite a bit of class loading >> and TLD parsing. >> >> To give an idea about how much time this is actually taking I did a test >> with a large number of small servlet only deployments both with and without >> JSF, and JSF was accounting for 20% of total deployment time even though it >> was not actually used by any of the deployments. >> >> It also had a significant effect on memory usage, as the parsed TLD's are >> retained, and are quite large. >> >> The root of this issue is that the spec does not define clear activation >> criteria for these technologies. I am proposing that we formalise some >> activation criteria, so that we can avoid activating them if they are not >> required. >> >> JSP: >> >> For JSP I think we can use the following criteria (if either one is >> satisfied JSP is activated): >> >> - The presence of a JSP file mapping in web.xml >> - The presence of JSP files inside the deployment >> - The presence of JSF >> >> One thing that does concern me is that searching for JSP files in this >> way may be expensive in large deployments with lots of web resources. An >> alternate approach may be to try and make JSP lazy, so class loading and >> TLD passing does not happen until a request for a JSP file arrives. >> >> >> JSF: >> >> This is much less clear. I think we can use the presence of one of the >> following: >> >> - faces-config.xml >> - The faces servlet in web.xml >> - Something else? >> >> I am not really sure what effect this will have on backwards >> compatibility though. If this is a compatibility problem we could add an >> attribute to the JSF subsystem to restore the old mode. >> >> >> Does this sound reasonable? >> >> Stuart >> >> >> >> >> _______________________________________________ >> 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/20180403/27527bed/attachment.html From guillaume at hibernate.org Tue Apr 3 11:43:43 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Tue, 3 Apr 2018 17:43:43 +0200 Subject: [wildfly-dev] Using Stax in WildFly and the javax.api module Message-ID: Hi, As JAXB will be removed from JDK 11, we are moving to Stax for parsing the Hibernate Validator XML descriptors. One issue is that the javax.xml.stream.api module, which is nicely isolated, typically depends on javax.xml.namespace for the QName class. Thus all the modules depending on the javax.xml.stream.api also depends on javax.api (which exposes imageio, swing and so on). See the staxmapper or the xts modules for instance. I'm wondering if we should better isolate the javax.xml features to avoid that situation? Not a big fan of exposing the Swing and ImageIO classes to HV. Thoughts? -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180403/297a5b1e/attachment.html From david.lloyd at redhat.com Tue Apr 3 11:58:32 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 3 Apr 2018 10:58:32 -0500 Subject: [wildfly-dev] Using Stax in WildFly and the javax.api module In-Reply-To: References: Message-ID: On Tue, Apr 3, 2018 at 10:43 AM, Guillaume Smet wrote: > Hi, > > As JAXB will be removed from JDK 11, we are moving to Stax for parsing the > Hibernate Validator XML descriptors. > > One issue is that the javax.xml.stream.api module, which is nicely isolated, > typically depends on javax.xml.namespace for the QName class. > > Thus all the modules depending on the javax.xml.stream.api also depends on > javax.api (which exposes imageio, swing and so on). See the staxmapper or > the xts modules for instance. > > I'm wondering if we should better isolate the javax.xml features to avoid > that situation? The XML-oriented WildFly modules will be merged into one module using the standard "java.xml" name, containing all the types found here [1], with the old "javax.xml.*" modules being deprecated. The "javax.api" module is being deprecated in favor of standard Java module names which should be usable by WildFly 13, and upstream within the next week or two. For more information see [2], [3], and other related (linked) JIRAs. [1] https://docs.oracle.com/javase/10/docs/api/java.xml-summary.html [2] https://issues.jboss.org/browse/WFCORE-3705 [3] http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006180.html -- - DML From guillaume at hibernate.org Tue Apr 3 12:20:54 2018 From: guillaume at hibernate.org (Guillaume Smet) Date: Tue, 3 Apr 2018 18:20:54 +0200 Subject: [wildfly-dev] Using Stax in WildFly and the javax.api module In-Reply-To: References: Message-ID: On Tue, Apr 3, 2018 at 5:58 PM, David Lloyd wrote: > The XML-oriented WildFly modules will be merged into one module using > the standard "java.xml" name, containing all the types found here [1], > with the old "javax.xml.*" modules being deprecated. The "javax.api" > module is being deprecated in favor of standard Java module names > which should be usable by WildFly 13, and upstream within the next > week or two. For more information see [2], [3], and other related > (linked) JIRAs. > OK, cool, problem solved then :). -- Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180403/3b325704/attachment.html From z06.guillermo at gmail.com Tue Apr 3 12:46:48 2018 From: z06.guillermo at gmail.com (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero?=) Date: Tue, 03 Apr 2018 16:46:48 +0000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: The fact is FacesInitializer also looks for a lot of annotation, but I see you duplicated that checks so it should be perfectly valid. El mar., 3 abr. 2018 12:23, Stuart Douglas escribi?: > My patch already checks for UIComponent, which is all the FacesInitializer > does. It only checks deployment classes, there would be no point checking > the faces implementation or it would activate every time. > > Stuart > > On Tue, Apr 3, 2018 at 6:57 PM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> But it should also checks for the existence of JSF classes, like >> Component. Having them on the classpath enabls JSF, so a classpath scan >> seems (unfortunately) needed to me. >> >> I imagine the received set of classes will contain the JSF implementation >> from the server modules, which implicitly enables JSF in the end. >> >> El mar., 3 abr. 2018 9:24, Stuart Douglas >> escribi?: >> >>> Looking at that class it seems like the intention is clearly for JSF to >>> only be activated if there is a faces-config.xml, a Servlet mapping or JSF >>> annotations. >>> >>> Should be pretty easy for us to duplicate this logic in a DUP and avoid >>> all the parsing and class loading. >>> >>> Stuart >>> >>> On Tue, Apr 3, 2018 at 3:50 PM, Guillermo Gonz?lez de Ag?ero < >>> z06.guillermo at gmail.com> wrote: >>> >>>> This would be great to have! >>>> >>>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>>> which substitutes faces-config. >>>> >>>> Looking at FacesConfigInitializer class[1] might provide some more >>>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>>> JSF from unnecessary initializing. Perhaps some work could be done there >>>> which helps also other runtimes? >>>> >>>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>>> Tijms since he's the expert on this stuff. >>>> >>>> >>>> Regards, >>>> >>>> Guillermo Gonz?lez de Ag?ero >>>> >>>> [1] >>>> https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java >>>> >>>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>>> stuart.w.douglas at gmail.com>) escribi?: >>>> >>>>> Hi Everyone, >>>>> >>>>> At the moment JSP and JSF are being activated for all web deployments, >>>>> which is relatively expensive as this involves quite a bit of class loading >>>>> and TLD parsing. >>>>> >>>>> To give an idea about how much time this is actually taking I did a >>>>> test with a large number of small servlet only deployments both with and >>>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>>> though it was not actually used by any of the deployments. >>>>> >>>>> It also had a significant effect on memory usage, as the parsed TLD's >>>>> are retained, and are quite large. >>>>> >>>>> The root of this issue is that the spec does not define clear >>>>> activation criteria for these technologies. I am proposing that we >>>>> formalise some activation criteria, so that we can avoid activating them if >>>>> they are not required. >>>>> >>>>> JSP: >>>>> >>>>> For JSP I think we can use the following criteria (if either one is >>>>> satisfied JSP is activated): >>>>> >>>>> - The presence of a JSP file mapping in web.xml >>>>> - The presence of JSP files inside the deployment >>>>> - The presence of JSF >>>>> >>>>> One thing that does concern me is that searching for JSP files in this >>>>> way may be expensive in large deployments with lots of web resources. An >>>>> alternate approach may be to try and make JSP lazy, so class loading and >>>>> TLD passing does not happen until a request for a JSP file arrives. >>>>> >>>>> >>>>> JSF: >>>>> >>>>> This is much less clear. I think we can use the presence of one of the >>>>> following: >>>>> >>>>> - faces-config.xml >>>>> - The faces servlet in web.xml >>>>> - Something else? >>>>> >>>>> I am not really sure what effect this will have on backwards >>>>> compatibility though. If this is a compatibility problem we could add an >>>>> attribute to the JSF subsystem to restore the old mode. >>>>> >>>>> >>>>> Does this sound reasonable? >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20180403/b4588440/attachment-0001.html From z06.guillermo at gmail.com Tue Apr 3 12:48:58 2018 From: z06.guillermo at gmail.com (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero?=) Date: Tue, 03 Apr 2018 16:48:58 +0000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: El mar., 3 abr. 2018 14:36, arjan tijms escribi?: > Hi, > > I'm already on this list indeed ;) > > Indeed, the FacesInitizalizer only does these two things unconditionally: > > boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes, > servletContext); > boolean appHasFacesServlet = > getExistingFacesServletRegistration(servletContext) != null; > > As can be seen from the code, it looks at the classes provided by the > Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean > annotated with @FacesConfig (which is a single CDI lookup). > > Note though that WildFly is using a somewhat older Mojarra release, so the > code is a bit different in WildFly, although not that much. > > So if the application is not actually using JSF, that's all it does. And > there should not be any additional overhead. If the application does use > JSF indeed, there's overhead and that's indeed too much overhead. I've been > trying on reducing this, for instance by using a pre-parsed internal > faces-config file. > But the implementation is on the classpath, so there will always be some JSF related class there. Stuart changes will fix this, but Payara suffers from this same problem as far as I saw. In fact I had this issue on my queue on pending reports. > > See specifically this commit: > https://github.com/javaserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a > > @Stuart, I wonder what the overhead is that you see when the application > is not using JSF, and which test application you are actually using. Could > it be that you somehow have a FacesServlet or faces-config.xml etc anyway? > > Kind regards, > Arjan > > > > > > > On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> This would be great to have! >> >> As for JSF activation, note that faces-config.xml nor Faces Servlet are >> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >> which substitutes faces-config. >> >> Looking at FacesConfigInitializer class[1] might provide some more >> insight. I've always been puzzled with the "Initializing Mojarra" log when >> deploying a JAX-RS only app. The mentioned class supposedly should prevent >> JSF from unnecessary initializing. Perhaps some work could be done there >> which helps also other runtimes? >> >> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >> Tijms since he's the expert on this stuff. >> >> >> Regards, >> >> Guillermo Gonz?lez de Ag?ero >> >> [1] >> https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java >> >> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >> stuart.w.douglas at gmail.com>) escribi?: >> >>> Hi Everyone, >>> >>> At the moment JSP and JSF are being activated for all web deployments, >>> which is relatively expensive as this involves quite a bit of class loading >>> and TLD parsing. >>> >>> To give an idea about how much time this is actually taking I did a test >>> with a large number of small servlet only deployments both with and without >>> JSF, and JSF was accounting for 20% of total deployment time even though it >>> was not actually used by any of the deployments. >>> >>> It also had a significant effect on memory usage, as the parsed TLD's >>> are retained, and are quite large. >>> >>> The root of this issue is that the spec does not define clear activation >>> criteria for these technologies. I am proposing that we formalise some >>> activation criteria, so that we can avoid activating them if they are not >>> required. >>> >>> JSP: >>> >>> For JSP I think we can use the following criteria (if either one is >>> satisfied JSP is activated): >>> >>> - The presence of a JSP file mapping in web.xml >>> - The presence of JSP files inside the deployment >>> - The presence of JSF >>> >>> One thing that does concern me is that searching for JSP files in this >>> way may be expensive in large deployments with lots of web resources. An >>> alternate approach may be to try and make JSP lazy, so class loading and >>> TLD passing does not happen until a request for a JSP file arrives. >>> >>> >>> JSF: >>> >>> This is much less clear. I think we can use the presence of one of the >>> following: >>> >>> - faces-config.xml >>> - The faces servlet in web.xml >>> - Something else? >>> >>> I am not really sure what effect this will have on backwards >>> compatibility though. If this is a compatibility problem we could add an >>> attribute to the JSF subsystem to restore the old mode. >>> >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20180403/3de7cda5/attachment.html From arjan.tijms at gmail.com Tue Apr 3 14:51:00 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 3 Apr 2018 20:51:00 +0200 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Hi, On Tue, Apr 3, 2018 at 6:48 PM, Guillermo Gonz?lez de Ag?ero < z06.guillermo at gmail.com> wrote: > >> So if the application is not actually using JSF, that's all it does. And >> there should not be any additional overhead. If the application does use >> JSF indeed, there's overhead and that's indeed too much overhead. I've been >> trying on reducing this, for instance by using a pre-parsed internal >> faces-config file. >> > But the implementation is on the classpath, so there will always be some > JSF related class there. Stuart changes will fix this, but Payara suffers > from this same problem as far as I saw. In fact I had this issue on my > queue on pending reports. > The Mojarra classes itself are not scanned in the case of a Java EE application server. Specifically for Mojarra and Payara (Micro) I ran quite a few tests and compared performance with a JSF class present in the application and without. The difference was immediate obvious, so that clearly indicates a lot of work is not done if the application doesn't contain a JSF class. You could of course try to double check this. I'm not sure which issue you saw, but if there's indeed an issue I would be all to happy to try to solve it. Maybe you are confused with the admin console though? The Payara admin console uses JSF, so you'll see it being initialising for that, but not for the application (it prints out the context for which it initialises, so you could take a look at that). >The fact is FacesInitializer also looks for a lot of annotation, but I see you duplicated that checks so it should be perfectly valid. It doesn't so much look explicitly for annotations. It used to do that, but now it just uses the set of classes passed into the ServletContainerInitializer. Of course the declaration of the classes the FacesInitializer is interested in means that the Servlet container may need to do some extra work, but since a Servlet container already scans all application classes (to find @WebServlet etc), this is maybe not that much extra work. For JSF 3.0 we should maybe only look for @FacesConfig and faces-config.xml, but that's still a bit out into the future. Kind regards, Arjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180403/ef5f444c/attachment.html From z06.guillermo at gmail.com Tue Apr 3 14:54:38 2018 From: z06.guillermo at gmail.com (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero?=) Date: Tue, 03 Apr 2018 18:54:38 +0000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Thanks Arjan, I'll have a look and will let you know (outside of this list, if WF is not affected). El mar., 3 abr. 2018 20:49, arjan tijms escribi?: > Hi, > > On Tue, Apr 3, 2018 at 6:48 PM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> >>> So if the application is not actually using JSF, that's all it does. And >>> there should not be any additional overhead. If the application does use >>> JSF indeed, there's overhead and that's indeed too much overhead. I've been >>> trying on reducing this, for instance by using a pre-parsed internal >>> faces-config file. >>> >> But the implementation is on the classpath, so there will always be some >> JSF related class there. Stuart changes will fix this, but Payara suffers >> from this same problem as far as I saw. In fact I had this issue on my >> queue on pending reports. >> > > The Mojarra classes itself are not scanned in the case of a Java EE > application server. > > Specifically for Mojarra and Payara (Micro) I ran quite a few tests and > compared performance with a JSF class present in the application and > without. The difference was immediate obvious, so that clearly indicates a > lot of work is not done if the application doesn't contain a JSF class. You > could of course try to double check this. > > I'm not sure which issue you saw, but if there's indeed an issue I would > be all to happy to try to solve it. > > Maybe you are confused with the admin console though? The Payara admin > console uses JSF, so you'll see it being initialising for that, but not for > the application (it prints out the context for which it initialises, so you > could take a look at that). > > >The fact is FacesInitializer also looks for a lot of annotation, but I > see you duplicated that checks so it should be perfectly valid. > > It doesn't so much look explicitly for annotations. It used to do that, > but now it just uses the set of classes passed into the > ServletContainerInitializer. Of course the declaration of the classes the FacesInitializer > is interested in means that the Servlet container may need to do some > extra work, but since a Servlet container already scans all application > classes (to find @WebServlet etc), this is maybe not that much extra work. > > For JSF 3.0 we should maybe only look for @FacesConfig and > faces-config.xml, but that's still a bit out into the future. > > Kind regards, > Arjan > > > > > > >> >>> See specifically this commit: >>> https://github.com/javaserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a >>> >>> @Stuart, I wonder what the overhead is that you see when the application >>> is not using JSF, and which test application you are actually using. Could >>> it be that you somehow have a FacesServlet or faces-config.xml etc anyway? >>> >>> Kind regards, >>> Arjan >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < >>> z06.guillermo at gmail.com> wrote: >>> >>>> This would be great to have! >>>> >>>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>>> which substitutes faces-config. >>>> >>>> Looking at FacesConfigInitializer class[1] might provide some more >>>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>>> JSF from unnecessary initializing. Perhaps some work could be done there >>>> which helps also other runtimes? >>>> >>>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>>> Tijms since he's the expert on this stuff. >>>> >>>> >>>> Regards, >>>> >>>> Guillermo Gonz?lez de Ag?ero >>>> >>>> [1] >>>> https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java >>>> >>>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>>> stuart.w.douglas at gmail.com>) escribi?: >>>> >>>>> Hi Everyone, >>>>> >>>>> At the moment JSP and JSF are being activated for all web deployments, >>>>> which is relatively expensive as this involves quite a bit of class loading >>>>> and TLD parsing. >>>>> >>>>> To give an idea about how much time this is actually taking I did a >>>>> test with a large number of small servlet only deployments both with and >>>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>>> though it was not actually used by any of the deployments. >>>>> >>>>> It also had a significant effect on memory usage, as the parsed TLD's >>>>> are retained, and are quite large. >>>>> >>>>> The root of this issue is that the spec does not define clear >>>>> activation criteria for these technologies. I am proposing that we >>>>> formalise some activation criteria, so that we can avoid activating them if >>>>> they are not required. >>>>> >>>>> JSP: >>>>> >>>>> For JSP I think we can use the following criteria (if either one is >>>>> satisfied JSP is activated): >>>>> >>>>> - The presence of a JSP file mapping in web.xml >>>>> - The presence of JSP files inside the deployment >>>>> - The presence of JSF >>>>> >>>>> One thing that does concern me is that searching for JSP files in this >>>>> way may be expensive in large deployments with lots of web resources. An >>>>> alternate approach may be to try and make JSP lazy, so class loading and >>>>> TLD passing does not happen until a request for a JSP file arrives. >>>>> >>>>> >>>>> JSF: >>>>> >>>>> This is much less clear. I think we can use the presence of one of the >>>>> following: >>>>> >>>>> - faces-config.xml >>>>> - The faces servlet in web.xml >>>>> - Something else? >>>>> >>>>> I am not really sure what effect this will have on backwards >>>>> compatibility though. If this is a compatibility problem we could add an >>>>> attribute to the JSF subsystem to restore the old mode. >>>>> >>>>> >>>>> Does this sound reasonable? >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20180403/c9802c6b/attachment-0001.html From stuart.w.douglas at gmail.com Tue Apr 3 18:33:38 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 4 Apr 2018 08:33:38 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: For us the additional overhead is class loading and TLD's. We need to eagerly parse the TLD's so we know about any listeners, and then the JSF listener and ServletInitializer causes a lot of class loading. My change means that I can do the annotation/inheritance scan using Jandex, so there is no class loading, and if JSF is not present avoid loading any classes or parsing any TLD's entirely. Stuart On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms wrote: > Hi, > > I'm already on this list indeed ;) > > Indeed, the FacesInitizalizer only does these two things unconditionally: > > boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes, > servletContext); > boolean appHasFacesServlet = getExistingFacesServletRegistration(servletContext) > != null; > > As can be seen from the code, it looks at the classes provided by the > Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean > annotated with @FacesConfig (which is a single CDI lookup). > > Note though that WildFly is using a somewhat older Mojarra release, so the > code is a bit different in WildFly, although not that much. > > So if the application is not actually using JSF, that's all it does. And > there should not be any additional overhead. If the application does use > JSF indeed, there's overhead and that's indeed too much overhead. I've been > trying on reducing this, for instance by using a pre-parsed internal > faces-config file. > > See specifically this commit: https://github.com/javaserverfaces/mojarra/ > commit/0129ffe2aadb4e87f46d094159cee0910f73003a > > @Stuart, I wonder what the overhead is that you see when the application > is not using JSF, and which test application you are actually using. Could > it be that you somehow have a FacesServlet or faces-config.xml etc anyway? > > Kind regards, > Arjan > > > > > > > On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < > z06.guillermo at gmail.com> wrote: > >> This would be great to have! >> >> As for JSF activation, note that faces-config.xml nor Faces Servlet are >> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >> which substitutes faces-config. >> >> Looking at FacesConfigInitializer class[1] might provide some more >> insight. I've always been puzzled with the "Initializing Mojarra" log when >> deploying a JAX-RS only app. The mentioned class supposedly should prevent >> JSF from unnecessary initializing. Perhaps some work could be done there >> which helps also other runtimes? >> >> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >> Tijms since he's the expert on this stuff. >> >> >> Regards, >> >> Guillermo Gonz?lez de Ag?ero >> >> [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5 >> a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/ >> faces/config/FacesInitializer.java >> >> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >> stuart.w.douglas at gmail.com>) escribi?: >> >>> Hi Everyone, >>> >>> At the moment JSP and JSF are being activated for all web deployments, >>> which is relatively expensive as this involves quite a bit of class loading >>> and TLD parsing. >>> >>> To give an idea about how much time this is actually taking I did a test >>> with a large number of small servlet only deployments both with and without >>> JSF, and JSF was accounting for 20% of total deployment time even though it >>> was not actually used by any of the deployments. >>> >>> It also had a significant effect on memory usage, as the parsed TLD's >>> are retained, and are quite large. >>> >>> The root of this issue is that the spec does not define clear activation >>> criteria for these technologies. I am proposing that we formalise some >>> activation criteria, so that we can avoid activating them if they are not >>> required. >>> >>> JSP: >>> >>> For JSP I think we can use the following criteria (if either one is >>> satisfied JSP is activated): >>> >>> - The presence of a JSP file mapping in web.xml >>> - The presence of JSP files inside the deployment >>> - The presence of JSF >>> >>> One thing that does concern me is that searching for JSP files in this >>> way may be expensive in large deployments with lots of web resources. An >>> alternate approach may be to try and make JSP lazy, so class loading and >>> TLD passing does not happen until a request for a JSP file arrives. >>> >>> >>> JSF: >>> >>> This is much less clear. I think we can use the presence of one of the >>> following: >>> >>> - faces-config.xml >>> - The faces servlet in web.xml >>> - Something else? >>> >>> I am not really sure what effect this will have on backwards >>> compatibility though. If this is a compatibility problem we could add an >>> attribute to the JSF subsystem to restore the old mode. >>> >>> >>> Does this sound reasonable? >>> >>> Stuart >>> >>> >>> >>> >>> _______________________________________________ >>> 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/20180404/e0a392a0/attachment.html From arjan.tijms at gmail.com Tue Apr 3 19:16:27 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 4 Apr 2018 01:16:27 +0200 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Hi, On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas wrote: > For us the additional overhead is class loading and TLD's. We need to > eagerly parse the TLD's so we know about any listeners, and then the JSF > listener and ServletInitializer causes a lot of class loading. > The listener should never run though if the ServletInitializer doesn't discover any JSF class or artefact. With the "lot of class loading", do you mean the classes that the ServletInitializer loads in order to determine JSF is used or not? > My change means that I can do the annotation/inheritance scan using > Jandex, so there is no class loading, and if JSF is not present avoid > loading any classes or parsing any TLD's entirely. > I'd really like to use Jandex too in Mojarra, although I'm not entirely sure how to do this from within the library. Maybe a separate build though, not sure yet (but that's my problem to deal with I guess :P) I do wonder about parsing TLDs. Which one do you exactly mean, and when are they being parsed in your test case? Kind regards, Arjan > > Stuart > > On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms > wrote: > >> Hi, >> >> I'm already on this list indeed ;) >> >> Indeed, the FacesInitizalizer only does these two things unconditionally: >> >> boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes, >> servletContext); >> boolean appHasFacesServlet = getExistingFacesServletRegistration(servletContext) >> != null; >> >> As can be seen from the code, it looks at the classes provided by the >> Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean >> annotated with @FacesConfig (which is a single CDI lookup). >> >> Note though that WildFly is using a somewhat older Mojarra release, so >> the code is a bit different in WildFly, although not that much. >> >> So if the application is not actually using JSF, that's all it does. And >> there should not be any additional overhead. If the application does use >> JSF indeed, there's overhead and that's indeed too much overhead. I've been >> trying on reducing this, for instance by using a pre-parsed internal >> faces-config file. >> >> See specifically this commit: https://github.com/jav >> aserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a >> >> @Stuart, I wonder what the overhead is that you see when the application >> is not using JSF, and which test application you are actually using. Could >> it be that you somehow have a FacesServlet or faces-config.xml etc anyway? >> >> Kind regards, >> Arjan >> >> >> >> >> >> >> On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < >> z06.guillermo at gmail.com> wrote: >> >>> This would be great to have! >>> >>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>> which substitutes faces-config. >>> >>> Looking at FacesConfigInitializer class[1] might provide some more >>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>> JSF from unnecessary initializing. Perhaps some work could be done there >>> which helps also other runtimes? >>> >>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>> Tijms since he's the expert on this stuff. >>> >>> >>> Regards, >>> >>> Guillermo Gonz?lez de Ag?ero >>> >>> [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5 >>> a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/face >>> s/config/FacesInitializer.java >>> >>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>> stuart.w.douglas at gmail.com>) escribi?: >>> >>>> Hi Everyone, >>>> >>>> At the moment JSP and JSF are being activated for all web deployments, >>>> which is relatively expensive as this involves quite a bit of class loading >>>> and TLD parsing. >>>> >>>> To give an idea about how much time this is actually taking I did a >>>> test with a large number of small servlet only deployments both with and >>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>> though it was not actually used by any of the deployments. >>>> >>>> It also had a significant effect on memory usage, as the parsed TLD's >>>> are retained, and are quite large. >>>> >>>> The root of this issue is that the spec does not define clear >>>> activation criteria for these technologies. I am proposing that we >>>> formalise some activation criteria, so that we can avoid activating them if >>>> they are not required. >>>> >>>> JSP: >>>> >>>> For JSP I think we can use the following criteria (if either one is >>>> satisfied JSP is activated): >>>> >>>> - The presence of a JSP file mapping in web.xml >>>> - The presence of JSP files inside the deployment >>>> - The presence of JSF >>>> >>>> One thing that does concern me is that searching for JSP files in this >>>> way may be expensive in large deployments with lots of web resources. An >>>> alternate approach may be to try and make JSP lazy, so class loading and >>>> TLD passing does not happen until a request for a JSP file arrives. >>>> >>>> >>>> JSF: >>>> >>>> This is much less clear. I think we can use the presence of one of the >>>> following: >>>> >>>> - faces-config.xml >>>> - The faces servlet in web.xml >>>> - Something else? >>>> >>>> I am not really sure what effect this will have on backwards >>>> compatibility though. If this is a compatibility problem we could add an >>>> attribute to the JSF subsystem to restore the old mode. >>>> >>>> >>>> Does this sound reasonable? >>>> >>>> Stuart >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/20180404/b2737115/attachment-0001.html From stuart.w.douglas at gmail.com Tue Apr 3 19:33:59 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 4 Apr 2018 09:33:59 +1000 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: On Wed, Apr 4, 2018 at 9:16 AM, arjan tijms wrote: > Hi, > > On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas < > stuart.w.douglas at gmail.com> wrote: > >> For us the additional overhead is class loading and TLD's. We need to >> eagerly parse the TLD's so we know about any listeners, and then the JSF >> listener and ServletInitializer causes a lot of class loading. >> > > The listener should never run though if the ServletInitializer doesn't > discover any JSF class or artefact. > > With the "lot of class loading", do you mean the classes that the > ServletInitializer loads in order to determine JSF is used or not? > The TLD's is the main issue. > > > >> My change means that I can do the annotation/inheritance scan using >> Jandex, so there is no class loading, and if JSF is not present avoid >> loading any classes or parsing any TLD's entirely. >> > > I'd really like to use Jandex too in Mojarra, although I'm not entirely > sure how to do this from within the library. Maybe a separate build though, > not sure yet (but that's my problem to deal with I guess :P) > > I do wonder about parsing TLDs. Which one do you exactly mean, and when > are they being parsed in your test case? > https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFSharedTldsProcessor.java#L53 jsf_core.tld adds 'com.sun.faces.config.ConfigureListener', which then causes JSF classes to be loaded. Stuart > > Kind regards, > Arjan > > > > >> >> Stuart >> >> On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms >> wrote: >> >>> Hi, >>> >>> I'm already on this list indeed ;) >>> >>> Indeed, the FacesInitizalizer only does these two things unconditionally: >>> >>> boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes, >>> servletContext); >>> boolean appHasFacesServlet = getExistingFacesServletRegistration(servletContext) >>> != null; >>> >>> As can be seen from the code, it looks at the classes provided by the >>> Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean >>> annotated with @FacesConfig (which is a single CDI lookup). >>> >>> Note though that WildFly is using a somewhat older Mojarra release, so >>> the code is a bit different in WildFly, although not that much. >>> >>> So if the application is not actually using JSF, that's all it does. And >>> there should not be any additional overhead. If the application does use >>> JSF indeed, there's overhead and that's indeed too much overhead. I've been >>> trying on reducing this, for instance by using a pre-parsed internal >>> faces-config file. >>> >>> See specifically this commit: https://github.com/jav >>> aserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a >>> >>> @Stuart, I wonder what the overhead is that you see when the application >>> is not using JSF, and which test application you are actually using. Could >>> it be that you somehow have a FacesServlet or faces-config.xml etc anyway? >>> >>> Kind regards, >>> Arjan >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 3, 2018 at 7:50 AM, Guillermo Gonz?lez de Ag?ero < >>> z06.guillermo at gmail.com> wrote: >>> >>>> This would be great to have! >>>> >>>> As for JSF activation, note that faces-config.xml nor Faces Servlet are >>>> required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 >>>> which substitutes faces-config. >>>> >>>> Looking at FacesConfigInitializer class[1] might provide some more >>>> insight. I've always been puzzled with the "Initializing Mojarra" log when >>>> deploying a JAX-RS only app. The mentioned class supposedly should prevent >>>> JSF from unnecessary initializing. Perhaps some work could be done there >>>> which helps also other runtimes? >>>> >>>> Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan >>>> Tijms since he's the expert on this stuff. >>>> >>>> >>>> Regards, >>>> >>>> Guillermo Gonz?lez de Ag?ero >>>> >>>> [1] https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5 >>>> a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/face >>>> s/config/FacesInitializer.java >>>> >>>> El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< >>>> stuart.w.douglas at gmail.com>) escribi?: >>>> >>>>> Hi Everyone, >>>>> >>>>> At the moment JSP and JSF are being activated for all web deployments, >>>>> which is relatively expensive as this involves quite a bit of class loading >>>>> and TLD parsing. >>>>> >>>>> To give an idea about how much time this is actually taking I did a >>>>> test with a large number of small servlet only deployments both with and >>>>> without JSF, and JSF was accounting for 20% of total deployment time even >>>>> though it was not actually used by any of the deployments. >>>>> >>>>> It also had a significant effect on memory usage, as the parsed TLD's >>>>> are retained, and are quite large. >>>>> >>>>> The root of this issue is that the spec does not define clear >>>>> activation criteria for these technologies. I am proposing that we >>>>> formalise some activation criteria, so that we can avoid activating them if >>>>> they are not required. >>>>> >>>>> JSP: >>>>> >>>>> For JSP I think we can use the following criteria (if either one is >>>>> satisfied JSP is activated): >>>>> >>>>> - The presence of a JSP file mapping in web.xml >>>>> - The presence of JSP files inside the deployment >>>>> - The presence of JSF >>>>> >>>>> One thing that does concern me is that searching for JSP files in this >>>>> way may be expensive in large deployments with lots of web resources. An >>>>> alternate approach may be to try and make JSP lazy, so class loading and >>>>> TLD passing does not happen until a request for a JSP file arrives. >>>>> >>>>> >>>>> JSF: >>>>> >>>>> This is much less clear. I think we can use the presence of one of the >>>>> following: >>>>> >>>>> - faces-config.xml >>>>> - The faces servlet in web.xml >>>>> - Something else? >>>>> >>>>> I am not really sure what effect this will have on backwards >>>>> compatibility though. If this is a compatibility problem we could add an >>>>> attribute to the JSF subsystem to restore the old mode. >>>>> >>>>> >>>>> Does this sound reasonable? >>>>> >>>>> Stuart >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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/20180404/0ae0223a/attachment.html From arjan.tijms at gmail.com Tue Apr 3 19:42:03 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 4 Apr 2018 01:42:03 +0200 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Hi, On Wed, Apr 4, 2018 at 1:33 AM, Stuart Douglas wrote: > I do wonder about parsing TLDs. Which one do you exactly mean, and when >> are they being parsed in your test case? >> > > https://github.com/wildfly/wildfly/blob/master/jsf/subsystem > /src/main/java/org/jboss/as/jsf/deployment/JSFSharedTldsProcessor.java#L53 > > jsf_core.tld adds 'com.sun.faces.config.ConfigureListener', which then > causes JSF classes to be loaded. > Ah, right. That code is JBoss specific and something that JBoss does. I was thinking whether the Mojarra FacesInitizalizer did something wrong somewhere. Kind regards, Arjan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180404/9df4a21a/attachment.html From arjan.tijms at gmail.com Wed Apr 4 04:49:04 2018 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 4 Apr 2018 10:49:04 +0200 Subject: [wildfly-dev] JSF and JSP activation In-Reply-To: References: Message-ID: Hi, jsf_core.tld adds 'com.sun.faces.config.ConfigureListener', which then >> causes JSF classes to be loaded. >> > > Ah, right. That code is JBoss specific and something that JBoss does. I > was thinking whether the Mojarra FacesInitizalizer did something wrong > somewhere. > I am pretty sure most containers will do something similar, as according to the spec we need to be able to run listeners defined in TLD's, which mean they need to be parsed at deployment time. The only way around it is to try and determine earlier if Mojarra is actually needed or not in app server code, which has a lot more flexibility. Mojarra can only do what the various specs allow it to do, and there is not really any way around this just using Servlet/JSP API's. That's not quite correct any more I think. jsf_core.tld is an ancient artefact that's only there for backwards compatibility. Since quite a long time Mojarra adds `com.sun.faces.config.ConfigureListener` itself using the ServletContainerInitializer and Servlet 3.0 programmatic registration: servletContext.addListener(com.sun.faces.config.ConfigureListener.class); The *-taglib.xml variants are the current versions. (Mojarra 2.4 pre-parses its own internal ones during the build.) I'm also patching in my friend Bauke who may be able to confirm or further explain this if needed. You are right though that other containers have somewhat similar potentially outdated code present. GlassFish/Payara for instance look whether the "javax.faces.webapp.FacesServlet" is actually added (programmatically or otherwise), so they'll leave the detection part to the JSF implementation (Mojarra) and only use a single trigger point. I'm fairly sure this can be removed in Payara as well, so I'll look into removing it there if indeed possible. You are also right that the container often has more flexibility, although technically a JSF implementation is not constrained to just using Servlet or EE APIs, but since we want Mojarra to be able to run on other container we practically do constrain ourselves of course ;) Kind regards, Arjan On Wed, Apr 4, 2018 at 1:42 AM, arjan tijms wrote: > Hi, > > On Wed, Apr 4, 2018 at 1:33 AM, Stuart Douglas > wrote: > >> I do wonder about parsing TLDs. Which one do you exactly mean, and when >>> are they being parsed in your test case? >>> >> >> https://github.com/wildfly/wildfly/blob/master/jsf/subsystem >> /src/main/java/org/jboss/as/jsf/deployment/JSFSharedTldsProc >> essor.java#L53 >> >> jsf_core.tld adds 'com.sun.faces.config.ConfigureListener', which then >> causes JSF classes to be loaded. >> > > Ah, right. That code is JBoss specific and something that JBoss does. I > was thinking whether the Mojarra FacesInitizalizer did something wrong > somewhere. > > Kind regards, > Arjan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180404/a2d3aed8/attachment-0001.html From gloeckner.daniel at gmail.com Wed Apr 4 16:17:08 2018 From: gloeckner.daniel at gmail.com (=?utf-8?Q?Daniel_Gl=C3=B6ckner?=) Date: Wed, 4 Apr 2018 22:17:08 +0200 Subject: [wildfly-dev] Detailed statistics Message-ID: <334E5E7C-5FF7-42A1-93B7-6838BF8AE112@gmail.com> Hi, I was wondering about best practices for monitoring the inner parts of WildFly (thread pools, connection pools, queues, buffers?). The more the merrier ;) JMX would be the preferred option but I?m open for other suggestions. The idea is to poll at a regular interval and persist the statistics. Kind regards, Daniel From rory.odonnell at oracle.com Thu Apr 12 06:04:37 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 12 Apr 2018 11:04:37 +0100 Subject: [wildfly-dev] JDK 11 Early Access build 8 available Message-ID: <5f3db27b-28e7-d7c3-8746-38125df395d8@oracle.com> Hi Jason/Tomaz, **JDK 11 EA build 8, *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved 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/8/jdk-11+8.html *Notable changes in JDK 11 EA builds since last email:* * Build 8: o If you have a library that uses the Selector API heavily then now would be a good time to test it out. [1] * Build 7 o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. * Build 6: o JDK-8193033 : remove terminally deprecated sun.misc.Unsafe.defineClass. Users should use the public replacement `java.lang.invoke.MethodHandles.Lookup.defineClass` which was added in Java SE 9. [2] ** *SURVEY: The HotSpot Serviceability Agent (SA) *[3] * If you have used, or have (support) processes that utilize the Serviceability Agent or related APIs, then we would definitely appreciate if you would complete this survey: https://www.surveymonkey.com/r/CF3MYDL Regards, Rory [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html [2] https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A- [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html -- 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/20180412/60042056/attachment.html From david.lloyd at redhat.com Thu Apr 12 10:30:29 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 12 Apr 2018 09:30:29 -0500 Subject: [wildfly-dev] What's new in JBoss Modules 1.8 Message-ID: JBoss Modules 1.8 is now part of WildFly Core, and it includes a few major new features that you may want to be aware of: ? JDK module dependencies (MODULES-254, MODULES-314) ? This also works on Java 1.8, as initially discussed here: http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006180.html ? This also means that the following modules have been deprecated: ? "javax.api", in favor of various standard modules including the now-implicit "java.base" ? "javax.xml.stream.api" and the JAXP portion of "javax.api" in favor of "java.xml" ? "javax.sql.api" in favor of "java.sql" ? "sun.jdk" and "ibm.jdk" in favor of multiple standard modules ? For more information, see: ? https://github.com/wildfly/wildfly-proposals/pull/39 ? Improved JAXP redirection strategy (MODULES-339) ? No longer uses system properties to establish the default implementation ? Implemented by way of adding additional services to the end of each module's resource list ? This means the default implementation is local to the module system class loaders and does not "leak out" to embedding environments In addition, the following minor improvements are present: ? Automatic version detection (MODULES-343) ? If no version attribute is given in module.xml, the version is detected via the JAR file manifest ? Versions are only advisory (for diagnostics) and do not play a role in linkage or resolution ? Service declarations in module.xml (MODULES-349) ? Allows existing JARs to be supplemented with additional service definitions ? Service definitions are treated as an additional (last) resource root containing only service files ? Support for "data:" URLs (MODULES-340) ? See https://tools.ietf.org/html/rfc2397 ? Can be returned by resource loaders for dynamic resource generation ? Functional class transformation API (MODULES-346) ? A new buffer-based functional interface is added and preferred ? Can be used to avoid a dependency on the "java.instrument" module in the future ? A compatibility adapter class is also introduced ? APIs which accept the java.lang.instrument.ClassFileTransformer interface are deprecated ? Ability to add security providers from the command line (MODULES-344) ? The "-add-provider" switch is introduced which accepts module or module/class ? Add API to run any accessible "main" class within a module (MODULES-342) The following deprecations were introduced: ? APIs which accept java.lang.instrument.ClassFileTransformer are deprecated in favor of org.jboss.modules.ClassTransformer (MODULES-346) ? Module index related command line switches and operations are deprecated (MODULES-345) ? Resource root names are deprecated and are no longer used or supported (though the APIs and XML attributes remain for compatibility) (MODULES-352) ? "system" dependencies are deprecated (MODULES-254, MODULES-314) -- - DML From slaskawi at redhat.com Mon Apr 16 04:31:46 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Mon, 16 Apr 2018 08:31:46 +0000 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Adding +WildFly Dev to the loop Thanks for the explanation Rado. TL;DR: A while ago Sanne pointed out that we do not set `node-identifier` in transaction subsystem by default. The default value for the `node-identifier` attribute it `1`. Not setting this attribute might cause problems in transaction recovery. Perhaps we could follow Rado's idea and set it to node name by default? Some more comments inlined. Thanks, Sebastian On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar wrote: > Hi Sebastian, > > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec > wrote: > > Hey Rado, Paul, > > > > I started looking into this issue and it turned out that WF subsystem > > template doesn't provide `node-identifier` attribute [1]. > > I assume you mean that the default WildFly server profiles do not > explicitly define the attribute. Right ? thus the value defaults in > the model to "1" > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97 > which sole intention seems to be to log a warning on boot if the value > is unchanged. > Why they decided on a constant that will be inherently not unique as > opposed to defaulting to the node name (which we already require to be > unique) as clustering node name or undertow instance-id does, is > unclear to me. > Some context is on https://issues.jboss.org/browse/WFLY-1119. > In OpenShift environment we could set it to `hostname`. This is guaranteed to be unique in whole OpenShift cluster. > > > I'm not sure if you guys are the right people to ask, but is it safe to > > leave it set to default? Or shall I override our Infinispan templates and > > add this parameter (as I mentioned before, in OpenShift this I wanted to > set > > it as Pod name trimmed to the last 23 chars since this is the limit). > > It is not safe to leave it set to "1" as that results in inconsistent > processing of transaction recovery. > IIUC we already set it to the node name for both EAP and JDG > > https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411 > > https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 > which in turn defaults to the pod name ? so which profiles are we > talking about here? > Granted, we set it by default in CCT Modules. However in Infinispan we just grab provided transaction subsystem when rendering full configuration from featurepacks: https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19 The default configuration XML doesn't contain the `node-identifier` attribute. I can add it manually in the cloud.xml but I believe the right approach is to modify the transaction subsystem. > Rado > > > Thanks, > > Seb > > > > [1] usually set to node-identifier="${jboss.node.name}" > > > > > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero > > wrote: > >> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec > wrote: > >> > Thanks for looking into it Sanne. Of course, we should add it (it can > be > >> > set > >> > to the same name as hostname since those are unique in Kubernetes). > >> > > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it. > >> > > >> > Thanks again! > >> > Seb > >> > >> Thanks Sebastian! > >> > >> > > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero > >> > wrote: > >> >> > >> >> Hi all, > >> >> > >> >> I've started to use the Infinispan Openshift Template and was > browsing > >> >> through the errors and warnings this produces. > >> >> > >> >> In particular I noticed "WFLYTX0013: Node identifier property is set > >> >> to the default value. Please make sure it is unique." being produced > >> >> by the transaction system. > >> >> > >> >> The node id is usually not needed for developer's convenience and > >> >> assuming there's a single node in "dev mode", yet clearly the > >> >> Infinispan template is meant to work with multiple nodes running so > >> >> this warning seems concerning. > >> >> > >> >> I'm not sure what the impact is on the transaction manager so I asked > >> >> on the Narayana forums; Tom pointed me to some thourough design > >> >> documents and also suggested the EAP image does set the node > >> >> identifier: > >> >> - https://developer.jboss.org/message/981702#981702 > >> >> > >> >> WDYT? we probably want the Infinispan template to set this as well, > or > >> >> silence the warning? > >> >> > >> >> Thanks, > >> >> Sanne > >> >> _______________________________________________ > >> >> infinispan-dev mailing list > >> >> infinispan-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> > > >> > > >> > _______________________________________________ > >> > infinispan-dev mailing list > >> > infinispan-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html From tom.jenkinson at redhat.com Tue Apr 17 10:32:48 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Tue, 17 Apr 2018 15:32:48 +0100 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: On 16 April 2018 at 09:31, <> wrote: > Adding +WildFly Dev to the loop > > Thanks for the explanation Rado. > > TL;DR: A while ago Sanne pointed out that we do not set `node-identifier` > in transaction subsystem by default. The default value for the > `node-identifier` attribute it `1`. Not setting this attribute might cause > problems in transaction recovery. Perhaps we could follow Rado's idea and > set it to node name by default? > Indeed - it would cause serious data integrity problems if a non-unique node-identifier is used. > > Some more comments inlined. > > Thanks, > Sebastian > > On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar > wrote: > > > Hi Sebastian, > > > > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec > > wrote: > > > Hey Rado, Paul, > > > > > > I started looking into this issue and it turned out that WF subsystem > > > template doesn't provide `node-identifier` attribute [1]. > > > > I assume you mean that the default WildFly server profiles do not > > explicitly define the attribute. Right ? thus the value defaults in > > the model to "1" > > > > https://github.com/wildfly/wildfly/blob/master/ > transactions/src/main/java/org/jboss/as/txn/subsystem/ > TransactionSubsystemRootResourceDefinition.java#L97 > > which sole intention seems to be to log a warning on boot if the value > > is unchanged. > > Why they decided on a constant that will be inherently not unique as > > opposed to defaulting to the node name (which we already require to be > > unique) as clustering node name or undertow instance-id does, is > > unclear to me. > > Some context is on https://issues.jboss.org/browse/WFLY-1119. > > > > In OpenShift environment we could set it to `hostname`. This is guaranteed > to be unique in whole OpenShift cluster. > > > We do this too in EAP images. To Rado's point, the default is "1" so we can print the warning to alert people they are misconfigured - it seems to be working :) > > > > > I'm not sure if you guys are the right people to ask, but is it safe to > > > leave it set to default? Or shall I override our Infinispan templates > and > > > add this parameter (as I mentioned before, in OpenShift this I wanted > to > > set > > > it as Pod name trimmed to the last 23 chars since this is the limit). > Putting a response to this in line - I am not certain who originally proposed this. You must use a globally unique node-identifier. If you are certain the last 23 characters guarantee that it would be valid - if there is a chance they are not unique it is not valid to trim. > > > > It is not safe to leave it set to "1" as that results in inconsistent > > processing of transaction recovery. > > IIUC we already set it to the node name for both EAP and JDG > > > > https://github.com/jboss-openshift/cct_module/blob/ > master/os-eap70-openshift/added/standalone-openshift.xml#L411 > > > > https://github.com/jboss-openshift/cct_module/blob/ > master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 > > which in turn defaults to the pod name ? so which profiles are we > > talking about here? > > > > Granted, we set it by default in CCT Modules. However in Infinispan we just > grab provided transaction subsystem when rendering full configuration from > featurepacks: > https://github.com/infinispan/infinispan/blob/master/server/ > integration/feature-pack/src/main/resources/configuration/ > standalone/subsystems-cloud.xml#L19 > > The default configuration XML doesn't contain the `node-identifier` > attribute. I can add it manually in the cloud.xml but I believe the right > approach is to modify the transaction subsystem. > > > > Rado > > > > > Thanks, > > > Seb > > > > > > [1] usually set to node-identifier="${jboss.node.name}" > > > > > > > > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero infinispan.org> > > > wrote: > > >> > > >> On 9 April 2018 at 09:26, Sebastian Laskawiec > > > wrote: > > >> > Thanks for looking into it Sanne. Of course, we should add it (it > can > > be > > >> > set > > >> > to the same name as hostname since those are unique in Kubernetes). > > >> > > > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it. > > >> > > > >> > Thanks again! > > >> > Seb > > >> > > >> Thanks Sebastian! > > >> > > >> > > > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero infinispan.org> > > >> > wrote: > > >> >> > > >> >> Hi all, > > >> >> > > >> >> I've started to use the Infinispan Openshift Template and was > > browsing > > >> >> through the errors and warnings this produces. > > >> >> > > >> >> In particular I noticed "WFLYTX0013: Node identifier property is > set > > >> >> to the default value. Please make sure it is unique." being > produced > > >> >> by the transaction system. > > >> >> > > >> >> The node id is usually not needed for developer's convenience and > > >> >> assuming there's a single node in "dev mode", yet clearly the > > >> >> Infinispan template is meant to work with multiple nodes running so > > >> >> this warning seems concerning. > > >> >> > > >> >> I'm not sure what the impact is on the transaction manager so I > asked > > >> >> on the Narayana forums; Tom pointed me to some thourough design > > >> >> documents and also suggested the EAP image does set the node > > >> >> identifier: > > >> >> - https://developer.jboss.org/message/981702#981702 > > >> >> > > >> >> WDYT? we probably want the Infinispan template to set this as well, > > or > > >> >> silence the warning? > > >> >> > > >> >> Thanks, > > >> >> Sanne > > >> >> _______________________________________________ > > >> >> infinispan-dev mailing list > > >> >> infinispan-dev at lists.jboss.org > > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > >> > > > >> > > > >> > _______________________________________________ > > >> > infinispan-dev mailing list > > >> > infinispan-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > >> _______________________________________________ > > >> infinispan-dev mailing list > > >> infinispan-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.jboss.org/pipermail/wildfly-dev/ > attachments/20180416/65962cf1/attachment-0001.html > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180417/3f6d382c/attachment.html From stuart.w.douglas at gmail.com Tue Apr 17 21:11:01 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 18 Apr 2018 11:11:01 +1000 Subject: [wildfly-dev] Tests for incomplete bugs Message-ID: Hi Everyone, Historically we have been ok with pull requests being submitted that add tests for things that are not yet complete. In practice this has been kinda problematic for reviewers, as these pull requests can hang around for a long time, and this ends up wasting a lot of reviewer time as we have to continually check the status of the PR. You basically end up with multiple reviewers continually polling the issue to check if it is ready, instead of a single person just submitting it when it is complete. I think that there is no real benefit to having the tests as a seperate PR that gets opened before the fix. Instead I propose that tests that do not pass yet are linked/co-ordinated under the relevant JIRA, and when the fix is submitted the tests can be submitted as part of the same PR. Does anyone have any objections to this? Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180418/79d2162d/attachment.html From darran.lofthouse at redhat.com Wed Apr 18 07:05:39 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Wed, 18 Apr 2018 11:05:39 +0000 Subject: [wildfly-dev] Tests for incomplete bugs In-Reply-To: References: Message-ID: +1 If multiple engineers are working on the same problem they should set up their own topic branch (can just be in one of their personal repos) somewhere and collaborate together then submit a combined PR from that branch that contains both the fix and the test case. Sometimes I think PRs are used as an easy way to get branches into CI, we should probably look again at how easy it is to get topic branches into CI without relying on the PR process to get jobs running. Regards, Darran Lofthouse. On Wed, 18 Apr 2018 at 02:12 Stuart Douglas wrote: > Hi Everyone, > > Historically we have been ok with pull requests being submitted that add > tests for things that are not yet complete. > > In practice this has been kinda problematic for reviewers, as these pull > requests can hang around for a long time, and this ends up wasting a lot of > reviewer time as we have to continually check the status of the PR. You > basically end up with multiple reviewers continually polling the issue to > check if it is ready, instead of a single person just submitting it when it > is complete. > > I think that there is no real benefit to having the tests as a seperate PR > that gets opened before the fix. Instead I propose that tests that do not > pass yet are linked/co-ordinated under the relevant JIRA, and when the fix > is submitted the tests can be submitted as part of the same PR. > > Does anyone have any objections to this? > > Stuart > _______________________________________________ > 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/20180418/3677106c/attachment-0001.html From stuart.w.douglas at gmail.com Wed Apr 18 08:54:53 2018 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 18 Apr 2018 12:54:53 +0000 Subject: [wildfly-dev] Tests for incomplete bugs In-Reply-To: References: Message-ID: In the cases I am taking about the is no point even testing on CI, as it is already known that the underling bug is not fixed yet. Stuart On Wed, 18 Apr. 2018, 9:05 pm Darran Lofthouse, wrote: > +1 > > If multiple engineers are working on the same problem they should set up > their own topic branch (can just be in one of their personal repos) > somewhere and collaborate together then submit a combined PR from that > branch that contains both the fix and the test case. > > Sometimes I think PRs are used as an easy way to get branches into CI, we > should probably look again at how easy it is to get topic branches into CI > without relying on the PR process to get jobs running. > > Regards, > Darran Lofthouse. > > > On Wed, 18 Apr 2018 at 02:12 Stuart Douglas > wrote: > >> Hi Everyone, >> >> Historically we have been ok with pull requests being submitted that add >> tests for things that are not yet complete. >> >> In practice this has been kinda problematic for reviewers, as these pull >> requests can hang around for a long time, and this ends up wasting a lot of >> reviewer time as we have to continually check the status of the PR. You >> basically end up with multiple reviewers continually polling the issue to >> check if it is ready, instead of a single person just submitting it when it >> is complete. >> >> I think that there is no real benefit to having the tests as a seperate >> PR that gets opened before the fix. Instead I propose that tests that do >> not pass yet are linked/co-ordinated under the relevant JIRA, and when the >> fix is submitted the tests can be submitted as part of the same PR. >> >> Does anyone have any objections to this? >> >> Stuart >> _______________________________________________ >> 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/20180418/0cf4765d/attachment.html From slaskawi at redhat.com Wed Apr 18 09:07:54 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 18 Apr 2018 13:07:54 +0000 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Hey Tom, Comments inlined. Thanks, Sebastian On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson wrote: > > > On 16 April 2018 at 09:31, <> wrote: > >> Adding +WildFly Dev to the loop > > >> >> Thanks for the explanation Rado. >> >> TL;DR: A while ago Sanne pointed out that we do not set `node-identifier` >> in transaction subsystem by default. The default value for the >> `node-identifier` attribute it `1`. Not setting this attribute might cause >> problems in transaction recovery. Perhaps we could follow Rado's idea and >> set it to node name by default? >> > Indeed - it would cause serious data integrity problems if a non-unique > node-identifier is used. > >> Some more comments inlined. >> >> Thanks, >> Sebastian >> >> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >> wrote: >> >> > Hi Sebastian, >> > >> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >> > wrote: >> > > Hey Rado, Paul, >> > > >> > > I started looking into this issue and it turned out that WF subsystem >> > > template doesn't provide `node-identifier` attribute [1]. >> > >> > I assume you mean that the default WildFly server profiles do not >> > > explicitly define the attribute. Right ? thus the value defaults in > > >> > the model to "1" >> > >> > >> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97 >> > which sole intention seems to be to log a warning on boot if the value >> > is unchanged. >> > Why they decided on a constant that will be inherently not unique as >> > opposed to defaulting to the node name (which we already require to be >> > unique) as clustering node name or undertow instance-id does, is >> > unclear to me. >> > Some context is on https://issues.jboss.org/browse/WFLY-1119. >> > >> >> In OpenShift environment we could set it to `hostname`. This is guaranteed >> to be unique in whole OpenShift cluster. >> >> >> We do this too in EAP images. > To Rado's point, the default is "1" so we can print the warning to alert > people they are misconfigured - it seems to be working :) > This is the point. From my understanding, if we set it to node name (instead of "1"), we could make it always work correctly. We could even remove the code that emits the warning (since the node name needs to be unique). To sum it up - if we decided to proceed this way, there would be no requirement of setting the node-identifier at all. > > >> > > > >> > > I'm not sure if you guys are the right people to ask, but is it safe >> to >> > > leave it set to default? Or shall I override our Infinispan templates >> and >> > > add this parameter (as I mentioned before, in OpenShift this I wanted >> to >> > set >> > > it as Pod name trimmed to the last 23 chars since this is the limit). >> > Putting a response to this in line - I am not certain who originally > proposed this. > > You must use a globally unique node-identifier. If you are certain the > last 23 characters guarantee that it would be valid - if there is a chance > they are not unique it is not valid to trim. > If that's not an issue, again, we could use the same limit as we have for node name. > > > >> > > > >> > It is not safe to leave it set to "1" as that results in inconsistent >> > processing of transaction recovery. >> > IIUC we already set it to the node name for both EAP and JDG >> > >> > >> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411 >> > >> > >> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >> > > which in turn defaults to the pod name ? so which profiles are we > > >> > talking about here? >> > >> >> Granted, we set it by default in CCT Modules. However in Infinispan we >> just >> grab provided transaction subsystem when rendering full configuration from >> featurepacks: >> >> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19 >> >> The default configuration XML doesn't contain the `node-identifier` >> attribute. I can add it manually in the cloud.xml but I believe the right >> approach is to modify the transaction subsystem. >> >> >> > Rado >> > >> > > Thanks, >> > > Seb >> > > >> > > [1] usually set to node-identifier="${jboss.node.name}" >> > > >> > > >> > > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero > infinispan.org> >> > > wrote: >> > >> >> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec > redhat.com> > > >> > wrote: >> > >> > Thanks for looking into it Sanne. Of course, we should add it (it >> can >> > be >> > >> > set >> > >> > to the same name as hostname since those are unique in Kubernetes). >> > >> > >> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it. >> > >> > >> > >> > Thanks again! >> > >> > Seb >> > >> >> > >> Thanks Sebastian! >> > >> >> > >> > >> > > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero > infinispan.org> > > >> > >> > wrote: >> > >> >> >> > >> >> Hi all, >> > >> >> >> > >> >> I've started to use the Infinispan Openshift Template and was >> > browsing >> > >> >> through the errors and warnings this produces. >> > >> >> >> > >> >> In particular I noticed "WFLYTX0013: Node identifier property is >> set >> > >> >> to the default value. Please make sure it is unique." being >> produced >> > >> >> by the transaction system. >> > >> >> >> > >> >> The node id is usually not needed for developer's convenience and >> > >> >> assuming there's a single node in "dev mode", yet clearly the >> > >> >> Infinispan template is meant to work with multiple nodes running >> so >> > >> >> this warning seems concerning. >> > >> >> >> > >> >> I'm not sure what the impact is on the transaction manager so I >> asked >> > >> >> on the Narayana forums; Tom pointed me to some thourough design >> > >> >> documents and also suggested the EAP image does set the node >> > >> >> identifier: >> > >> >> - https://developer.jboss.org/message/981702#981702 >> > >> >> >> > >> >> WDYT? we probably want the Infinispan template to set this as >> well, >> > or >> > >> >> silence the warning? >> > >> >> >> > >> >> Thanks, >> > >> >> Sanne >> > >> >> _______________________________________________ >> > >> >> infinispan-dev mailing list >> > > >> >> infinispan-dev at lists.jboss.org > > >> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > infinispan-dev mailing list >> > > >> > infinispan-dev at lists.jboss.org > > >> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> _______________________________________________ >> > >> infinispan-dev mailing list >> > >> infinispan-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180418/91e45c6a/attachment-0001.html From tom.jenkinson at redhat.com Wed Apr 18 09:37:23 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Wed, 18 Apr 2018 14:37:23 +0100 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: On 18 April 2018 at 14:07, Sebastian Laskawiec wrote: > Hey Tom, > > Comments inlined. > > Thanks, > Sebastian > > On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson > wrote: > >> >> >> On 16 April 2018 at 09:31, <> wrote: >> >>> Adding +WildFly Dev to the loop >> >> >>> >>> Thanks for the explanation Rado. >>> >>> TL;DR: A while ago Sanne pointed out that we do not set `node-identifier` >>> in transaction subsystem by default. The default value for the >>> `node-identifier` attribute it `1`. Not setting this attribute might >>> cause >>> problems in transaction recovery. Perhaps we could follow Rado's idea and >>> set it to node name by default? >>> >> Indeed - it would cause serious data integrity problems if a non-unique >> node-identifier is used. >> >>> Some more comments inlined. >>> >>> Thanks, >>> Sebastian >>> >>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>> wrote: >>> >>> > Hi Sebastian, >>> > >>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>> > wrote: >>> > > Hey Rado, Paul, >>> > > >>> > > I started looking into this issue and it turned out that WF subsystem >>> > > template doesn't provide `node-identifier` attribute [1]. >>> > >>> > I assume you mean that the default WildFly server profiles do not >>> >> > explicitly define the attribute. Right ? thus the value defaults in >> >> >>> > the model to "1" >>> > >>> > https://github.com/wildfly/wildfly/blob/master/ >>> transactions/src/main/java/org/jboss/as/txn/subsystem/ >>> TransactionSubsystemRootResourceDefinition.java#L97 >>> > which sole intention seems to be to log a warning on boot if the value >>> > is unchanged. >>> > Why they decided on a constant that will be inherently not unique as >>> > opposed to defaulting to the node name (which we already require to be >>> > unique) as clustering node name or undertow instance-id does, is >>> > unclear to me. >>> > Some context is on https://issues.jboss.org/browse/WFLY-1119. >>> > >>> >>> In OpenShift environment we could set it to `hostname`. This is >>> guaranteed >>> to be unique in whole OpenShift cluster. >>> >>> >>> We do this too in EAP images. >> To Rado's point, the default is "1" so we can print the warning to alert >> people they are misconfigured - it seems to be working :) >> > > This is the point. From my understanding, if we set it to node name > (instead of "1"), we could make it always work correctly. We could even > remove the code that emits the warning (since the node name needs to be > unique). > > To sum it up - if we decided to proceed this way, there would be no > requirement of setting the node-identifier at all. > For OpenShift you are right there is no requirement for someone to change the node-identifier from the podname and so that is why EAP images do that. For bare-metal it is different as there can be two servers on the same machine so they were configured to use the hostname as they node-identifier then if they were also connected to the same resource managers or the same object store they would interfere with each other. > > >> >> >>> > >> >> >>> > > I'm not sure if you guys are the right people to ask, but is it safe >>> to >>> > > leave it set to default? Or shall I override our Infinispan >>> templates and >>> > > add this parameter (as I mentioned before, in OpenShift this I >>> wanted to >>> > set >>> > > it as Pod name trimmed to the last 23 chars since this is the limit). >>> >> Putting a response to this in line - I am not certain who originally >> proposed this. >> >> You must use a globally unique node-identifier. If you are certain the >> last 23 characters guarantee that it would be valid - if there is a chance >> they are not unique it is not valid to trim. >> > > If that's not an issue, again, we could use the same limit as we have for > node name. > > >> >> >> >>> > >> >> >>> > It is not safe to leave it set to "1" as that results in inconsistent >>> > processing of transaction recovery. >>> > IIUC we already set it to the node name for both EAP and JDG >>> > >>> > https://github.com/jboss-openshift/cct_module/blob/ >>> master/os-eap70-openshift/added/standalone-openshift.xml#L411 >>> > >>> > https://github.com/jboss-openshift/cct_module/blob/ >>> master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >>> >> > which in turn defaults to the pod name ? so which profiles are we >> >> >>> > talking about here? >>> > >>> >>> Granted, we set it by default in CCT Modules. However in Infinispan we >>> just >>> grab provided transaction subsystem when rendering full configuration >>> from >>> featurepacks: >>> https://github.com/infinispan/infinispan/blob/master/server/ >>> integration/feature-pack/src/main/resources/configuration/ >>> standalone/subsystems-cloud.xml#L19 >>> >>> The default configuration XML doesn't contain the `node-identifier` >>> attribute. I can add it manually in the cloud.xml but I believe the right >>> approach is to modify the transaction subsystem. >>> >>> >>> > Rado >>> > >>> > > Thanks, >>> > > Seb >>> > > >>> > > [1] usually set to node-identifier="${jboss.node.name}" >>> > > >>> > > >>> >> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >> infinispan.org> >>> > > wrote: >>> > >> >>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >> redhat.com> >> >> >>> > wrote: >>> > >> > Thanks for looking into it Sanne. Of course, we should add it (it >>> can >>> > be >>> > >> > set >>> > >> > to the same name as hostname since those are unique in >>> Kubernetes). >>> > >> > >>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it. >>> > >> > >>> > >> > Thanks again! >>> > >> > Seb >>> > >> >>> > >> Thanks Sebastian! >>> > >> >>> > >> > >>> >> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >> infinispan.org> >> >> >>> > >> > wrote: >>> > >> >> >>> > >> >> Hi all, >>> > >> >> >>> > >> >> I've started to use the Infinispan Openshift Template and was >>> > browsing >>> > >> >> through the errors and warnings this produces. >>> > >> >> >>> > >> >> In particular I noticed "WFLYTX0013: Node identifier property is >>> set >>> > >> >> to the default value. Please make sure it is unique." being >>> produced >>> > >> >> by the transaction system. >>> > >> >> >>> > >> >> The node id is usually not needed for developer's convenience and >>> > >> >> assuming there's a single node in "dev mode", yet clearly the >>> > >> >> Infinispan template is meant to work with multiple nodes running >>> so >>> > >> >> this warning seems concerning. >>> > >> >> >>> > >> >> I'm not sure what the impact is on the transaction manager so I >>> asked >>> > >> >> on the Narayana forums; Tom pointed me to some thourough design >>> > >> >> documents and also suggested the EAP image does set the node >>> > >> >> identifier: >>> > >> >> - https://developer.jboss.org/message/981702#981702 >>> > >> >> >>> > >> >> WDYT? we probably want the Infinispan template to set this as >>> well, >>> > or >>> > >> >> silence the warning? >>> > >> >> >>> > >> >> Thanks, >>> > >> >> Sanne >>> > >> >> _______________________________________________ >>> > >> >> infinispan-dev mailing list >>> >> > >> >> infinispan-dev at lists.jboss.org >> >> >>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > >> > >>> > >> > >>> > >> > _______________________________________________ >>> > >> > infinispan-dev mailing list >>> >> > >> > infinispan-dev at lists.jboss.org >> >> >>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > >> _______________________________________________ >>> > >> infinispan-dev mailing list >>> > >> infinispan-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: http://lists.jboss.org/pipermail/wildfly-dev/ >>> attachments/20180416/65962cf1/attachment-0001.html >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180418/5b87349a/attachment.html From brian.stansberry at redhat.com Wed Apr 18 14:29:12 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 18 Apr 2018 13:29:12 -0500 Subject: [wildfly-dev] Tests for incomplete bugs In-Reply-To: References: Message-ID: I agree. Separating things also means that the eventual fix PR probably isn't going to have the test. So it can either get merged without the test (bad) or the people doing merging are misusing their time coordinating combined testing of two PRs. On Tue, Apr 17, 2018 at 8:11 PM, Stuart Douglas wrote: > Hi Everyone, > > Historically we have been ok with pull requests being submitted that add > tests for things that are not yet complete. > > In practice this has been kinda problematic for reviewers, as these pull > requests can hang around for a long time, and this ends up wasting a lot of > reviewer time as we have to continually check the status of the PR. You > basically end up with multiple reviewers continually polling the issue to > check if it is ready, instead of a single person just submitting it when it > is complete. > > I think that there is no real benefit to having the tests as a seperate PR > that gets opened before the fix. Instead I propose that tests that do not > pass yet are linked/co-ordinated under the relevant JIRA, and when the fix > is submitted the tests can be submitted as part of the same PR. > > Does anyone have any objections to this? > > Stuart > > _______________________________________________ > 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/20180418/64a11225/attachment-0001.html From cdewolf at redhat.com Thu Apr 19 03:52:04 2018 From: cdewolf at redhat.com (Carlo de Wolf) Date: Thu, 19 Apr 2018 09:52:04 +0200 Subject: [wildfly-dev] Tests for incomplete bugs In-Reply-To: References: Message-ID: It would prove the test code is valid. I have seen some false positives. :) So having an independent run of the test is nice, but it must end up in the same PR as the fix. Filing a test-only PR isn't very pretty, because it creates smoke for the mergers. Carlo On 18-04-18 14:54, Stuart Douglas wrote: > In the cases I am taking about the is no point even testing on CI, as > it is already known that the underling bug is not fixed yet. > > Stuart > > On Wed, 18 Apr. 2018, 9:05 pm Darran Lofthouse, > > wrote: > > +1 > > If multiple engineers are working on the same problem they should > set up their own topic branch (can just be in one of their > personal repos) somewhere and collaborate together then submit a > combined PR from that branch that contains both the fix and the > test case. > > Sometimes I think PRs are used as an easy way to get branches into > CI, we should probably look again at how easy it is to get topic > branches into CI without relying on the PR process to get jobs > running. > > Regards, > Darran Lofthouse. > > > On Wed, 18 Apr 2018 at 02:12 Stuart Douglas > > > wrote: > > Hi Everyone, > > Historically we have been ok with pull requests being > submitted that add tests for things that are not yet complete. > > In practice this has been kinda problematic for reviewers, as > these pull requests can hang around for a long time, and this > ends up wasting a lot of reviewer time as we have to > continually check the status of the PR. You basically end up > with multiple reviewers continually polling the issue to check > if it is ready, instead of a single person just submitting it > when it is complete. > > I think that there is no real benefit to having the tests as a > seperate PR that gets opened before the fix. Instead I propose > that tests that do not pass yet are linked/co-ordinated under > the relevant JIRA, and when the fix is submitted the tests can > be submitted as part of the same PR. > > Does anyone have any objections to this? > > Stuart > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180419/978ac253/attachment.html From psotirop at redhat.com Thu Apr 19 04:10:18 2018 From: psotirop at redhat.com (Panagiotis Sotiropoulos) Date: Thu, 19 Apr 2018 10:10:18 +0200 Subject: [wildfly-dev] Tests for incomplete bugs In-Reply-To: References: Message-ID: +1 (In cases of 1 to 1 server code and testcases) On Thu, Apr 19, 2018 at 9:52 AM, Carlo de Wolf wrote: > It would prove the test code is valid. I have seen some false positives. :) > > So having an independent run of the test is nice, but it must end up in > the same PR as the fix. > > Filing a test-only PR isn't very pretty, because it creates smoke for the > mergers. > > Carlo > > > On 18-04-18 14:54, Stuart Douglas wrote: > > In the cases I am taking about the is no point even testing on CI, as it > is already known that the underling bug is not fixed yet. > > Stuart > > On Wed, 18 Apr. 2018, 9:05 pm Darran Lofthouse, < > darran.lofthouse at redhat.com> wrote: > >> +1 >> >> If multiple engineers are working on the same problem they should set up >> their own topic branch (can just be in one of their personal repos) >> somewhere and collaborate together then submit a combined PR from that >> branch that contains both the fix and the test case. >> >> Sometimes I think PRs are used as an easy way to get branches into CI, we >> should probably look again at how easy it is to get topic branches into CI >> without relying on the PR process to get jobs running. >> >> Regards, >> Darran Lofthouse. >> >> >> On Wed, 18 Apr 2018 at 02:12 Stuart Douglas >> wrote: >> >>> Hi Everyone, >>> >>> Historically we have been ok with pull requests being submitted that add >>> tests for things that are not yet complete. >>> >>> In practice this has been kinda problematic for reviewers, as these pull >>> requests can hang around for a long time, and this ends up wasting a lot of >>> reviewer time as we have to continually check the status of the PR. You >>> basically end up with multiple reviewers continually polling the issue to >>> check if it is ready, instead of a single person just submitting it when it >>> is complete. >>> >>> I think that there is no real benefit to having the tests as a seperate >>> PR that gets opened before the fix. Instead I propose that tests that do >>> not pass yet are linked/co-ordinated under the relevant JIRA, and when the >>> fix is submitted the tests can be submitted as part of the same PR. >>> >>> Does anyone have any objections to this? >>> >>> Stuart >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180419/6f62efdd/attachment.html From claudio at claudius.com.br Thu Apr 19 09:12:56 2018 From: claudio at claudius.com.br (Claudio Miranda) Date: Thu, 19 Apr 2018 10:12:56 -0300 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Hi, just to let you know, HAL 3.0 is already merged in wildfly master branch, so you may run it and give some feedback. On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: > 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 -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br From hbraun at redhat.com Thu Apr 19 09:17:51 2018 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 19 Apr 2018 06:17:51 -0700 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Congrats to Harald and Claudio! Heiko On 19. April 2018 at 15:17:02, Claudio Miranda (claudio at claudius.com.br) wrote: Hi, just to let you know, HAL 3.0 is already merged in wildfly master branch, so you may run it and give some feedback. On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: > 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 -- Claudio Miranda claudio at claudius.com.br http://www.claudius.com.br _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180419/7309d54d/attachment-0001.html From david.lloyd at redhat.com Thu Apr 19 09:28:41 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 19 Apr 2018 08:28:41 -0500 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: My first impression is - it seems faster than the old console. It loaded more or less instantly in my (local) browser. So far so good! On Thu, Apr 19, 2018 at 8:12 AM, Claudio Miranda wrote: > Hi, just to let you know, HAL 3.0 is already merged in wildfly master > branch, so you may run it and give some feedback. > > On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: >> 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 > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML From hpehl at redhat.com Thu Apr 19 10:02:45 2018 From: hpehl at redhat.com (Harald Pehl) Date: Thu, 19 Apr 2018 16:02:45 +0200 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Glad you like it. We've setup a website for the new console, which summarises what's new and contains some background info. [1] // Harald [1] https://hal.github.io/ > On 19. Apr 2018, at 15:28, David Lloyd wrote: > > My first impression is - it seems faster than the old console. It > loaded more or less instantly in my (local) browser. So far so good! > > On Thu, Apr 19, 2018 at 8:12 AM, Claudio Miranda > wrote: >> Hi, just to let you know, HAL 3.0 is already merged in wildfly master >> branch, so you may run it and give some feedback. >> >> On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: >>> 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 >> >> >> >> -- >> Claudio Miranda >> >> claudio at claudius.com.br >> http://www.claudius.com.br >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180419/25e7a3fd/attachment.html From brian.stansberry at redhat.com Thu Apr 19 10:08:26 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 19 Apr 2018 09:08:26 -0500 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Congrats, guys! On Thu, Apr 19, 2018 at 8:28 AM, David Lloyd wrote: > My first impression is - it seems faster than the old console. It > loaded more or less instantly in my (local) browser. So far so good! > > On Thu, Apr 19, 2018 at 8:12 AM, Claudio Miranda > wrote: > > Hi, just to let you know, HAL 3.0 is already merged in wildfly master > > branch, so you may run it and give some feedback. > > > > On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: > >> 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 > > > > > > > > -- > > Claudio Miranda > > > > claudio at claudius.com.br > > http://www.claudius.com.br > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180419/797d9d41/attachment.html From anmiller at redhat.com Thu Apr 19 10:21:18 2018 From: anmiller at redhat.com (Andrig Miller) Date: Thu, 19 Apr 2018 08:21:18 -0600 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Have a little typo on the main page of the web site: HAL *ist* the project name for the WildFly and JBoss EAP management console. On Thu, Apr 19, 2018 at 8:02 AM, Harald Pehl wrote: > Glad you like it. We've setup a website for the new console, which > summarises what's new and contains some background info. [1] > > // Harald > > [1] https://hal.github.io/ > > > On 19. Apr 2018, at 15:28, David Lloyd wrote: > > My first impression is - it seems faster than the old console. It > loaded more or less instantly in my (local) browser. So far so good! > > On Thu, Apr 19, 2018 at 8:12 AM, Claudio Miranda > wrote: > > Hi, just to let you know, HAL 3.0 is already merged in wildfly master > branch, so you may run it and give some feedback. > > On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: > > 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 > > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > - 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/20180419/60d1073d/attachment.html From hpehl at redhat.com Thu Apr 19 11:07:28 2018 From: hpehl at redhat.com (Harald Pehl) Date: Thu, 19 Apr 2018 17:07:28 +0200 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: Thanks Andy - fixed. > On 19. Apr 2018, at 16:21, Andrig Miller wrote: > > Have a little typo on the main page of the web site: > > HAL ist the project name for the WildFly and JBoss EAP management console. > > On Thu, Apr 19, 2018 at 8:02 AM, Harald Pehl > wrote: > Glad you like it. We've setup a website for the new console, which summarises what's new and contains some background info. [1] > > // Harald > > [1] https://hal.github.io/ > > >> On 19. Apr 2018, at 15:28, David Lloyd > wrote: >> >> My first impression is - it seems faster than the old console. It >> loaded more or less instantly in my (local) browser. So far so good! >> >> On Thu, Apr 19, 2018 at 8:12 AM, Claudio Miranda >> > wrote: >>> Hi, just to let you know, HAL 3.0 is already merged in wildfly master >>> branch, so you may run it and give some feedback. >>> >>> On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl > wrote: >>>> 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 >>> >>> >>> >>> -- >>> Claudio Miranda >>> >>> claudio at claudius.com.br >>> http://www.claudius.com.br >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> - 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/20180419/9aa67adb/attachment-0001.html From smarlow at redhat.com Fri Apr 20 11:38:20 2018 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 20 Apr 2018 11:38:20 -0400 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: I love the new console, congratulations! Should the new application deployment view (Content + Management Model), order be reversed or will users look at Content more often than Management Model? The first item should probably be whatever is looked at more often, hard to know what that is but personally I prefer to see the Management model first and Content second. :) I tried to edit the JPA enabled (equivalent of issuing :write-attribute(name=enabled,value=true)) flag for a deployment persistence unit but wasn't quite sure what to do after choosing the 'edit' option. I tried entering 'true' in the edit control but didn't know what to do to accept the change. I figured out to press the little Oo control but that gives me an invalid expression error, pressing help on that, shows: "The expression as ${key} or ${key:default} Required field." Scott On Thu, Apr 19, 2018 at 9:12 AM, Claudio Miranda wrote: > Hi, just to let you know, HAL 3.0 is already merged in wildfly master > branch, so you may run it and give some feedback. > > On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl wrote: > > 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 > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180420/caddef5b/attachment.html From hpehl at redhat.com Fri Apr 20 12:09:25 2018 From: hpehl at redhat.com (Harald Pehl) Date: Fri, 20 Apr 2018 18:09:25 +0200 Subject: [wildfly-dev] HAL.next / replace console in WildFly 13 In-Reply-To: References: Message-ID: <83641ED5-8945-4DAF-A777-EF99766B4D38@redhat.com> Thanks Scott for the feedback. I've filed [1] to track your issue. [1] https://issues.jboss.org/browse/HAL-1447 // Harald > On 20. Apr 2018, at 17:38, Scott Marlow wrote: > > I love the new console, congratulations! > > Should the new application deployment view (Content + Management Model), order be reversed or will users look at Content more often than Management Model? The first item should probably be whatever is looked at more often, hard to know what that is but personally I prefer to see the Management model first and Content second. :) > > I tried to edit the JPA enabled (equivalent of issuing :write-attribute(name=enabled,value=true)) flag for a deployment persistence unit but wasn't quite sure what to do after choosing the 'edit' option. I tried entering 'true' in the edit control but didn't know what to do to accept the change. I figured out to press the little Oo control but that gives me an invalid expression error, pressing help on that, shows: "The expression as ${key} or ${key:default} Required field." > Scott > > > On Thu, Apr 19, 2018 at 9:12 AM, Claudio Miranda > wrote: > Hi, just to let you know, HAL 3.0 is already merged in wildfly master > branch, so you may run it and give some feedback. > > On Fri, Mar 2, 2018 at 6:29 AM, Harald Pehl > wrote: > > 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 > > > > -- > Claudio Miranda > > claudio at claudius.com.br > http://www.claudius.com.br > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180420/2dc6cc38/attachment.html From acurvers at gmail.com Mon Apr 23 16:37:54 2018 From: acurvers at gmail.com (Alexander Curvers) Date: Mon, 23 Apr 2018 22:37:54 +0200 Subject: [wildfly-dev] Apache CXF pretty logging Message-ID: Hello peers, what would be the easiest way to set the Apache CXF to pretty log the XML in and outbound WS messages. I enabled logging I know the default log handler of CXF can be set to pretty Log messages, but how to set the option? Thanks in advance. Regards Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180423/233420c9/attachment.html From asoldano at redhat.com Mon Apr 23 18:45:26 2018 From: asoldano at redhat.com (Alessio Soldano) Date: Tue, 24 Apr 2018 00:45:26 +0200 Subject: [wildfly-dev] Apache CXF pretty logging In-Reply-To: References: Message-ID: Did you try value="pretty" ? See https://docs.jboss.org/author/display/JBWS/Advanced+User+Guide#AdvancedUserGuide-Logging Cheers On Mon, Apr 23, 2018 at 10:37 PM, Alexander Curvers wrote: > Hello peers, > > what would be the easiest way to set the Apache CXF to pretty log the XML > in and outbound WS messages. > I enabled logging > > > > > > > I know the default log handler of CXF can be set to pretty Log messages, > but how to set the option? > > Thanks in advance. > > Regards Alexander > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Alessio Soldano Associate Manager Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180424/4f13566f/attachment-0001.html From brian.stansberry at redhat.com Tue Apr 24 22:08:47 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 24 Apr 2018 21:08:47 -0500 Subject: [wildfly-dev] Rename of JIRA "Domain Management" component to "Management" Message-ID: FYI, I've renamed the "Domain Management" component to simply "Management" in the WFLY and WFCORE JIRA projects. The old name was misleading as it implied the component is about domain mode, which has never been true. Probably less than a quarter of work in the component over the years has been about domain mode, and that percentage is decreasing as we focus more on cloud use cases. This has been on my todo list for years now and I'm cleaning off my desk a bit. :) In case it's helpful, here's what's covered by this component: 1) The functionality associated with all the WildFly 'kernel' management resources, i.e. the many resources that are not part of an extension/subsystem. 2) The Extension API that subsystem authors code against, including the many helper/base classes they can use. 3) The server boot and shutdown logic. (This could be considered 'Server' component but in practice it's easier to lump this in with Management.) 4) The basic management client API and the support code for JBoss Remoting-based remote communication from a client. 5) Domain mode. Management-related things that are not in this component but which should be tracked via other component: A) Client-side issues with the CLI: use the CLI component. (OTOH just because you used the CLI to produce an issue on the server doesn't mean it's a CLI issue.) B) Client-side issues with the web console: use the Web Console component. C) JMX issues: use the JMX component. D) Management issues for a particular subsystem: use the subsystem's JIRA component. If you think there may be a general issue, add Management as well, but don't skip the subsystem's component. Best regards, Brian -- 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/20180424/0b7c70ea/attachment.html From acurvers at gmail.com Thu Apr 26 04:20:26 2018 From: acurvers at gmail.com (Alexander Curvers) Date: Thu, 26 Apr 2018 10:20:26 +0200 Subject: [wildfly-dev] Apache CXF pretty logging In-Reply-To: References: Message-ID: Hi Alessio, I did try that but I have not seen the desired effect on the logging. @all anyone has other suggestions? Regards Alexander Groeten Alexander 2018-04-24 0:45 GMT+02:00 Alessio Soldano : > Did you try value="pretty" ? > > See https://docs.jboss.org/author/display/JBWS/Advanced+User+ > Guide#AdvancedUserGuide-Logging > > Cheers > > On Mon, Apr 23, 2018 at 10:37 PM, Alexander Curvers > wrote: > >> Hello peers, >> >> what would be the easiest way to set the Apache CXF to pretty log the XML >> in and outbound WS messages. >> I enabled logging >> >> >> >> >> >> >> I know the default log handler of CXF can be set to pretty Log messages, >> but how to set the option? >> >> Thanks in advance. >> >> Regards Alexander >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > > Alessio Soldano > > Associate Manager > > Red Hat > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180426/777502f8/attachment.html From ebenzacar at gmail.com Thu Apr 26 13:48:39 2018 From: ebenzacar at gmail.com (Eric B) Date: Thu, 26 Apr 2018 13:48:39 -0400 Subject: [wildfly-dev] Is there a single maven BOM artifact I can use toget/build the entire wildfly ee server? In-Reply-To: References: <59e272f4.2fb9df0a.8d596.3131@mx.google.com> Message-ID: Hi Arjan, Sorry for reviving such an old thread, but I'm stuck on debugging some difficult behaviour with remoting connections in Wildfly and need to debug/step through the application server. In this old post of yours, you indicated that you've already needed all the server dependencies for debugging purposes. Do you remember what you used/needed to import/include them all easily/automatically? Is there a simple way to add something to my pom.xml to have the full sources available for debugging? Thanks, Eric On Sat, Oct 14, 2017 at 6:45 PM, arjan tijms wrote: > Hi, > > On Sat, Oct 14, 2017 at 9:26 PM, Toma? Cerar > wrote: > >> I doubt you actually need widfly server dependencies but only EE with >> friends ones. >> > > In many cases somewhat more advanced developers actually want all the > server dependencies. This is absolutely crucial for debugging. I've needed > this many times over in my role as app developer. > > Kind regards, > Arjan Tijms > > > > >> >> >> -- >> >> tomaz >> >> >> >> *From: *Eric B >> *Sent: *sobota, 14. oktober 2017 02:39 >> *To: *wildfly-dev at lists.jboss.org >> *Subject: *[wildfly-dev] Is there a single maven BOM artifact I can use >> toget/build the entire wildfly ee server? >> >> >> >> I'm trying to debug some code, and I am often hitting classes in >> Wildfly/Undertow/etc in my stack that I don't have the source code for. >> >> >> >> I'd love to be able to add a dependency in my pom.xml so that Eclipse >> will automatically d/l the sources from maven central for me and add them >> to my debugger. I'm looking for an artifact that I'd be able to list >> something like: >> >> >> >> >> >> wildfly >> >> org.wildfly >> >> 10.1.0 >> >> provided >> >> pom >> >> >> >> >> >> >> >> That would then download all the sources for me, and I'd be in business. >> >> >> >> Is there something like this BOM available for wildfly? >> >> >> >> Thanks, >> >> >> Eric >> >> >> >> >> >> _______________________________________________ >> 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/20180426/d95f698e/attachment-0001.html From slaskawi at redhat.com Mon Apr 30 22:39:25 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 01 May 2018 02:39:25 +0000 Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template In-Reply-To: References: Message-ID: Fair enough Tom. Thanks for explanation. One more request - would you guys be OK with me adding a node-identifier="${ jboss.node.name}" to the transaction subsystem template [1]? This way we wouldn't need to copy it into Infinispan (since we need to set it). [1] https://github.com/wildfly/wildfly/blob/master/transactions/src/main/resources/subsystem-templates/transactions.xml#L6 On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson wrote: > On 18 April 2018 at 14:07, Sebastian Laskawiec > wrote: > >> Hey Tom, >> >> Comments inlined. >> >> Thanks, >> Sebastian >> >> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson >> wrote: >> >>> >>> >>> On 16 April 2018 at 09:31, <> wrote: >>> >>>> Adding +WildFly Dev to the loop >>> >>> >>>> >>>> Thanks for the explanation Rado. >>>> >>>> TL;DR: A while ago Sanne pointed out that we do not set >>>> `node-identifier` >>>> in transaction subsystem by default. The default value for the >>>> `node-identifier` attribute it `1`. Not setting this attribute might >>>> cause >>>> problems in transaction recovery. Perhaps we could follow Rado's idea >>>> and >>>> set it to node name by default? >>>> >>> Indeed - it would cause serious data integrity problems if a non-unique >>> node-identifier is used. >>> >>>> Some more comments inlined. >>>> >>>> Thanks, >>>> Sebastian >>>> >>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar >>>> wrote: >>>> >>>> > Hi Sebastian, >>>> > >>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec >>>> > wrote: >>>> > > Hey Rado, Paul, >>>> > > >>>> > > I started looking into this issue and it turned out that WF >>>> subsystem >>>> > > template doesn't provide `node-identifier` attribute [1]. >>>> > >>>> > I assume you mean that the default WildFly server profiles do not >>>> >>> > explicitly define the attribute. Right ? thus the value defaults in >>> >>> >>>> > the model to "1" >>>> > >>>> > >>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97 >>>> > which sole intention seems to be to log a warning on boot if the value >>>> > is unchanged. >>>> > Why they decided on a constant that will be inherently not unique as >>>> > opposed to defaulting to the node name (which we already require to be >>>> > unique) as clustering node name or undertow instance-id does, is >>>> > unclear to me. >>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119. >>>> > >>>> >>>> In OpenShift environment we could set it to `hostname`. This is >>>> guaranteed >>>> to be unique in whole OpenShift cluster. >>>> >>>> >>>> We do this too in EAP images. >>> To Rado's point, the default is "1" so we can print the warning to alert >>> people they are misconfigured - it seems to be working :) >>> >> >> This is the point. From my understanding, if we set it to node name >> (instead of "1"), we could make it always work correctly. We could even >> remove the code that emits the warning (since the node name needs to be >> unique). >> >> To sum it up - if we decided to proceed this way, there would be no >> requirement of setting the node-identifier at all. >> > > For OpenShift you are right there is no requirement for someone to change > the node-identifier from the podname and so that is why EAP images do that. > > For bare-metal it is different as there can be two servers on the same > machine so they were configured to use the hostname as they node-identifier > then if they were also connected to the same resource managers or the same > object store they would interfere with each other. > > >> >> >>> >>> >>>> > >>> >>> >>>> > > I'm not sure if you guys are the right people to ask, but is it >>>> safe to >>>> > > leave it set to default? Or shall I override our Infinispan >>>> templates and >>>> > > add this parameter (as I mentioned before, in OpenShift this I >>>> wanted to >>>> > set >>>> > > it as Pod name trimmed to the last 23 chars since this is the >>>> limit). >>>> >>> Putting a response to this in line - I am not certain who originally >>> proposed this. >>> >>> You must use a globally unique node-identifier. If you are certain the >>> last 23 characters guarantee that it would be valid - if there is a chance >>> they are not unique it is not valid to trim. >>> >> >> If that's not an issue, again, we could use the same limit as we have for >> node name. >> >> >>> >>> >>> >>>> > >>> >>> >>>> > It is not safe to leave it set to "1" as that results in inconsistent >>>> > processing of transaction recovery. >>>> > IIUC we already set it to the node name for both EAP and JDG >>>> > >>>> > >>>> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411 >>>> > >>>> > >>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282 >>>> >>> > which in turn defaults to the pod name ? so which profiles are we >>> >>> >>>> > talking about here? >>>> > >>>> >>>> Granted, we set it by default in CCT Modules. However in Infinispan we >>>> just >>>> grab provided transaction subsystem when rendering full configuration >>>> from >>>> featurepacks: >>>> >>>> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19 >>>> >>>> The default configuration XML doesn't contain the `node-identifier` >>>> attribute. I can add it manually in the cloud.xml but I believe the >>>> right >>>> approach is to modify the transaction subsystem. >>>> >>>> >>>> > Rado >>>> > >>>> > > Thanks, >>>> > > Seb >>>> > > >>>> > > [1] usually set to node-identifier="${jboss.node.name}" >>>> > > >>>> > > >>>> >>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero >>> infinispan.org> >>>> > > wrote: >>>> > >> >>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec >>> redhat.com> >>> >>> >>>> > wrote: >>>> > >> > Thanks for looking into it Sanne. Of course, we should add it >>>> (it can >>>> > be >>>> > >> > set >>>> > >> > to the same name as hostname since those are unique in >>>> Kubernetes). >>>> > >> > >>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it. >>>> > >> > >>>> > >> > Thanks again! >>>> > >> > Seb >>>> > >> >>>> > >> Thanks Sebastian! >>>> > >> >>>> > >> > >>>> >>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero >>> infinispan.org> >>> >>> >>>> > >> > wrote: >>>> > >> >> >>>> > >> >> Hi all, >>>> > >> >> >>>> > >> >> I've started to use the Infinispan Openshift Template and was >>>> > browsing >>>> > >> >> through the errors and warnings this produces. >>>> > >> >> >>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier property >>>> is set >>>> > >> >> to the default value. Please make sure it is unique." being >>>> produced >>>> > >> >> by the transaction system. >>>> > >> >> >>>> > >> >> The node id is usually not needed for developer's convenience >>>> and >>>> > >> >> assuming there's a single node in "dev mode", yet clearly the >>>> > >> >> Infinispan template is meant to work with multiple nodes >>>> running so >>>> > >> >> this warning seems concerning. >>>> > >> >> >>>> > >> >> I'm not sure what the impact is on the transaction manager so I >>>> asked >>>> > >> >> on the Narayana forums; Tom pointed me to some thourough design >>>> > >> >> documents and also suggested the EAP image does set the node >>>> > >> >> identifier: >>>> > >> >> - https://developer.jboss.org/message/981702#981702 >>>> > >> >> >>>> > >> >> WDYT? we probably want the Infinispan template to set this as >>>> well, >>>> > or >>>> > >> >> silence the warning? >>>> > >> >> >>>> > >> >> Thanks, >>>> > >> >> Sanne >>>> > >> >> _______________________________________________ >>>> > >> >> infinispan-dev mailing list >>>> >>> > >> >> infinispan-dev at lists.jboss.org >>> >>> >>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> > >> > >>>> > >> > >>>> > >> > _______________________________________________ >>>> > >> > infinispan-dev mailing list >>>> >>> > >> > infinispan-dev at lists.jboss.org >>> >>> >>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> > >> _______________________________________________ >>>> > >> infinispan-dev mailing list >>>> > >> infinispan-dev at lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html >>>> >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180501/a3d31a5d/attachment-0001.html