[wildfly-dev] JSF and JSP activation

[arjan tijms]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180403/ef5f444c/attachment.html