JSF and JSP activation

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

JSF and JSP activation

Stuart Douglas
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Andrig Miller
From the performance team perspective we would love to have this activated only if there is a deployment that needs them, that's for sure.

JSF, Mojarra in particular, has lots of memory problems besides the initialization too, but that's another story that we will start discussing soon.

This would help our Metaspace memory issues, and we should definitely do this.

Andy

On Mon, Apr 2, 2018 at 7:15 PM, Stuart Douglas <[hidden email]> wrote:
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

z06.guillermo
In reply to this post by Stuart Douglas
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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Stuart Douglas
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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Stuart Douglas
I have done up a quick PR to support this (not really tested yet, so it might fail :-)) https://github.com/wildfly/wildfly/pull/11082 .

I only tested this out against the 'kitchensink' and 'kitchensink-angularjs' quickstarts, and these appeared to work as expected. It also seemed to reduce boot time by  ~400ms for the angularjs version (although I did not do any scientific testing). 

JSP is a bit harder, I need to think a bit more about exactly what this will entail.

Stuart

On Tue, Apr 3, 2018 at 5:24 PM, Stuart Douglas <[hidden email]> wrote:
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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

z06.guillermo
In reply to this post by Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

arjan.tijms
In reply to this post by z06.guillermo
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.


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

z06.guillermo
In reply to this post by Stuart Douglas
The fact is FacesInitializer also looks for a lot of annotation, but I see you duplicated that checks so it should be perfectly valid.

El mar., 3 abr. 2018 12:23, Stuart Douglas <[hidden email]> escribió:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

z06.guillermo
In reply to this post by arjan.tijms


El mar., 3 abr. 2018 14:36, arjan tijms <[hidden email]> escribió:
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.
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.


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

arjan.tijms
Hi,

On Tue, Apr 3, 2018 at 6:48 PM, Guillermo González de Agüero <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

z06.guillermo
In reply to this post by z06.guillermo
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 <[hidden email]> escribió:
Hi,

On Tue, Apr 3, 2018 at 6:48 PM, Guillermo González de Agüero <[hidden email]> 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




 


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Stuart Douglas
In reply to this post by arjan.tijms
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.

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.

Stuart

On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms <[hidden email]> 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.


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

arjan.tijms
Hi,

On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas <[hidden email]> 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?

 
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?

Kind regards,
Arjan


 

Stuart

On Tue, Apr 3, 2018 at 10:36 PM, arjan tijms <[hidden email]> 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.


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

Stuart Douglas


On Wed, Apr 4, 2018 at 9:16 AM, arjan tijms <[hidden email]> wrote:
Hi,

On Wed, Apr 4, 2018 at 12:33 AM, Stuart Douglas <[hidden email]> 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?


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 <[hidden email]> 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.


@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 <[hidden email]> 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


El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<[hidden email]>) 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

arjan.tijms
Hi,

On Wed, Apr 4, 2018 at 1:33 AM, Stuart Douglas <[hidden email]> wrote:
I do wonder about parsing TLDs. Which one do you exactly mean, and when are they being parsed in your test case?


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

Ah, right. That code is JBoss specific and something that JBoss does. I was thinking whether the Mojarra FacesInitizalizer did something wrong somewhere.

Kind regards,
Arjan

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: JSF and JSP activation

arjan.tijms
Hi,

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

Ah, right. That code is JBoss specific and something that JBoss does. I was thinking whether the Mojarra FacesInitizalizer did something wrong somewhere.

I am pretty sure most containers will do something similar, as according to the spec we need to be able to run listeners defined in TLD's, which mean they need to be parsed at deployment time.

The only way around it is to try and determine earlier if Mojarra is actually needed or not in app server code, which has a lot more flexibility. Mojarra can only do what the various specs allow it to do, and there is not really any way around this just using Servlet/JSP API's.


That's not quite correct any more I think. jsf_core.tld is an ancient artefact that's only there for backwards compatibility. Since quite a long time Mojarra adds `com.sun.faces.config.ConfigureListener` itself using the ServletContainerInitializer and Servlet 3.0 programmatic registration:

servletContext.addListener(com.sun.faces.config.ConfigureListener.class);

The *-taglib.xml variants are the current versions. (Mojarra 2.4 pre-parses its own internal ones during the build.) I'm also patching in my friend Bauke who may be able to confirm or further explain this if needed. 

You are right though that other containers have somewhat similar potentially outdated code present. GlassFish/Payara for instance look whether the "javax.faces.webapp.FacesServlet" is actually added (programmatically or otherwise), so they'll leave the detection part to the JSF implementation (Mojarra) and only use a single trigger point. I'm fairly sure this can be removed in Payara as well, so I'll look into removing it there if indeed possible.

You are also right that the container often has more flexibility, although technically a JSF implementation is not constrained to just using Servlet or EE APIs, but since we want Mojarra to be able to run on other container we practically do constrain ourselves of course ;)

Kind regards,
Arjan




On Wed, Apr 4, 2018 at 1:42 AM, arjan tijms <[hidden email]> wrote:
Hi,

On Wed, Apr 4, 2018 at 1:33 AM, Stuart Douglas <[hidden email]> wrote:
I do wonder about parsing TLDs. Which one do you exactly mean, and when are they being parsed in your test case?


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

Ah, right. That code is JBoss specific and something that JBoss does. I was thinking whether the Mojarra FacesInitizalizer did something wrong somewhere.

Kind regards,
Arjan


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev