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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >

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 <stuart.w.douglas(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >

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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

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/0129ffe2aadb4e87f46d094... @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(a)gmail.com&gt; 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/4ea1679838f5a6bf6899c2829... > > El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (< > stuart.w.douglas(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >

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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >

Hi, On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas < stuart.w.douglas(a)gmail.com&gt; 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 <arjan.tijms(a)gmail.com&gt; > 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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> >

> 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.

> 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.