[wildfly-dev] JSF and JSP activation

Tue Apr 3 14:54:38 EDT 2018

Thanks Arjan, I'll have a look and will let you know (outside of this list,
if WF is not affected).

El mar., 3 abr. 2018 20:49, arjan tijms <arjan.tijms at gmail.com> escribió:

> Hi,
>
> On Tue, Apr 3, 2018 at 6:48 PM, Guillermo González de Agüero <
> z06.guillermo at gmail.com> wrote:
>
>>
>>> 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.
>>>
>> But the implementation is on the classpath, so there will always be some
>> JSF related class there. Stuart changes will fix this, but Payara suffers
>> from this same problem as far as I saw. In fact I had this issue on my
>> queue on pending reports.
>>
>
> The Mojarra classes itself are not scanned in the case of a Java EE
> application server.
>
> Specifically for Mojarra and Payara (Micro) I ran quite a few tests and
> compared performance with a JSF class present in the application and
> without. The difference was immediate obvious, so that clearly indicates a
> lot of work is not done if the application doesn't contain a JSF class. You
> could of course try to double check this.
>
> I'm not sure which issue you saw, but if there's indeed an issue I would
> be all to happy to try to solve it.
>
> Maybe you are confused with the admin console though? The Payara admin
> console uses JSF, so you'll see it being initialising for that, but not for
> the application (it prints out the context for which it initialises, so you
> could take a look at that).
>
> >The fact is FacesInitializer also looks for a lot of annotation, but I
> see you duplicated that checks so it should be perfectly valid.
>
> It doesn't so much look explicitly for annotations. It used to do that,
> but now it just uses the set of classes passed into the
> ServletContainerInitializer. Of course the declaration of the classes the FacesInitializer
> is interested in means that the Servlet container may need to do some
> extra work, but since a Servlet container already scans all application
> classes (to find @WebServlet etc), this is maybe not that much extra work.
>
> For JSF 3.0 we should maybe only look for @FacesConfig and
> faces-config.xml, but that's still a bit out into the future.
>
> Kind regards,
> Arjan
>
>
>
>
>
>
>>
>>> See specifically this commit:
>>> https://github.com/javaserverfaces/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/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/c9802c6b/attachment-0001.html 