[wildfly-dev] JSF and JSP activation
Guillermo González de Agüero
z06.guillermo at gmail.com
Tue Apr 3 01:50:01 EDT 2018
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/1c3facde/attachment-0001.html
More information about the wildfly-dev
mailing list