[wildfly-dev] JSF and JSP activation

[Guillermo González de Agüero]

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/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/502e62d1/attachment-0001.html