Re: [wildfly-dev] JSF and JSP activation

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