[wildfly-dev] JSF and JSP activation

[Stuart Douglas]

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