[wildfly-dev] JSF and JSP activation

[Stuart Douglas]

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 <stuart.w.douglas at gmail.com>
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 <stuart.w.douglas at gmail.com>
>> 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