[wildfly-dev] JSF and JSP activation

Tue Apr 3 19:33:59 EDT 2018

On Wed, Apr 4, 2018 at 9:16 AM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> For us the additional overhead is class loading and TLD's. We need to
>> eagerly parse the TLD's so we know about any listeners, and then the JSF
>> listener and ServletInitializer causes a lot of class loading.
>>
>
> The listener should never run though if the ServletInitializer doesn't
> discover any JSF class or artefact.
>
> With the "lot of class loading", do you mean the classes that the
> ServletInitializer loads in order to determine JSF is used or not?
>

The TLD's is the main issue.

>
>
>
>> My change means that I can do the annotation/inheritance scan using
>> Jandex, so there is no class loading, and if JSF is not present avoid
>> loading any classes or parsing any TLD's entirely.
>>
>
> I'd really like to use Jandex too in Mojarra, although I'm not entirely
> sure how to do this from within the library. Maybe a separate build though,
> not sure yet (but that's my problem to deal with I guess :P)
>
> I do wonder about parsing TLDs. Which one do you exactly mean, and when
> are they being parsed in your test case?
>

https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFSharedTldsProcessor.java#L53

jsf_core.tld adds 'com.sun.faces.config.ConfigureListener', which then
causes JSF classes to be loaded.

Stuart

>
> Kind regards,
> Arjan
>
>
>
>
>>
>> Stuart
>>
>> On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm already on this list indeed ;)
>>>
>>> Indeed, the FacesInitizalizer only does these two things unconditionally:
>>>
>>> boolean appHasSomeJsfContent = appMayHaveSomeJsfContent(classes,
>>> servletContext);
>>> boolean appHasFacesServlet = getExistingFacesServletRegistration(servletContext)
>>> != null;
>>>
>>> As can be seen from the code, it looks at the classes provided by the
>>> Servlet container, for a faces-config.xml in WEB-INF, and for the CDI bean
>>> annotated with @FacesConfig (which is a single CDI lookup).
>>>
>>> Note though that WildFly is using a somewhat older Mojarra release, so
>>> the code is a bit different in WildFly, although not that much.
>>>
>>> So if the application is not actually using JSF, that's all it does. And
>>> there should not be any additional overhead. If the application does use
>>> JSF indeed, there's overhead and that's indeed too much overhead. I've been
>>> trying on reducing this, for instance by using a pre-parsed internal
>>> faces-config file.
>>>
>>> See specifically this commit: https://github.com/jav
>>> aserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a
>>>
>>> @Stuart, I wonder what the overhead is that you see when the application
>>> is not using JSF, and which test application you are actually using. Could
>>> it be that you somehow have a FacesServlet or faces-config.xml etc anyway?
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 3, 2018 at 7:50 AM, 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/face
>>>> s/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/20180404/0ae0223a/attachment.html 